CoreOS, Docker, and batteries

When the CoreOS folks announced Rocket, it was with much concern over the “new direction” of the Docker project, as they saw it. They felt compelled to launch a competitor to Docker because Docker was straying from its roots as being merely a container standard and runtime.

Something rang a bit hollow as I read that original announcement, and it was not the theory that CoreOS was really responding to Docker encroaching on the market they were trying to capture. Others have speculated on this at length, and there probably is something to it. But no, I think the thing that rang hollow to me was CoreOS’ face-value, negative reaction to Docker’s “batteries included, but removable” philosophy. That finally came into focus today as Ubuntu announced Snappy Ubuntu Core (or is it “Ubuntu Snappy” or “Ubuntu Core Snappy”?).

Snappy Ubuntu Core is positioning itself in the same space as CoreOS (and RedHat’s Project Atomic, for that matter). It is a transactionally-updated, minimal cloud OS designed to provide a standard interface to containerized applications (via frameworks, of which docker is the first available). One of the things the Ubuntu folks highlight is that, unlike CoreOS, they don’t bake in things like fleet. To them, that’s a benefit. To me, it’s the same as saying, “We have fewer of the features everyone using this will need. Good luck figuring that out on your own!”

That’s when it hit me. CoreOS likes to include batteries too, and they don’t even make them removable like Docker does. CoreOS comes with etcd, fleet, and docker built in. I love that they do this; it takes a lot of work off of my plate and lets me start where my needs truly become unique rather than attempting to fill in the same gaps everyone else is filling in. But calling out Docker for doing this same thing (and doing it better since Docker’s batteries are removable) is a bit hypocritical.

In my time researching CoreOS and its ecosystem, I found that I would prefer to replace etcd with Consul in my CoreOS cluster because Consul’s features are a superset of what etcd provides. But I can’t easily do that. Etcd is too baked-in to CoreOS. It’s not a big deal because you can easily run Consul in a container and even bootstrap it with etcd. I put the code for that on GitHub if anyone else would like to try it.

But why isn’t CoreOS sticking to merely being a transactionally-updated, minimal cloud OS designed to provide a standard interface to containerized applications? Because that would be less useful, and they know it.

Just like it would be less useful for Docker to require that we all hunt down our own orchestration, cluster management, and other essential “batteries” for real-world deployments of containers.

I love CoreOS because of the batteries they include (though I wish they were more removable), and I love Docker for the same reason. But I am worried about CoreOS’ apparent split personality in this area.

 
14
Kudos
 
14
Kudos

Now read this

RabbitMQ cluster on kubernetes with StatefulSets

UPDATE 2018-1-8: Don’t do it this way. Use the k8s support built in to either the official autocluster plugin (for RabbitMQ 3.6.x) or the new built-in peer discovery feature in RabbitMQ 3.7.x+. UPDATE 2017-3-18: Improved the postStart... Continue →