LWN: Comments on "The Rocket containerization system"

The Rocket containerization system

Mook — Thu, 11 Dec 2014 06:08:33 +0000

> why in the world would you trust an image from a website that anyone can upload to? that's worse than just downloading and executing random binaries.

> Now, a recipe for building an image from distro X would be reasnable (I think Fedora calls this a kickstart definition)

My understanding is that that's pretty much how the docker hub thing works; it grabs a recipe possibly with associated files, runs it on their servers, and exposes the result.

Of course, that means you should probably read that recipe and figure out if the associated files (and actions in the recipe, any downloads that does, etc.) might be dangerous before actually grabbing the image. Their last release was about vulnerabilities when pulling evil images...

The Rocket containerization system

dlang — Fri, 05 Dec 2014 08:02:01 +0000

sometimes, but usually not.

even with a security update, you need to test the fix before you put it in production to make sure that it doesn't break anything else, and if you are doing things correctly, the image you test on is what you deploy to production. If the risk is bad enough, you take the service down in the meantime.

The Rocket containerization system

epa — Fri, 05 Dec 2014 06:55:03 +0000

Makes sense. That said, for security vulnerabilities you often do want to patch absolutely as soon as possible, so there may still be a case for 'yum upgrade' inside each container as a stopgap measure until the newly built one is pushed out.

The Rocket containerization system

dlang — Thu, 04 Dec 2014 22:11:45 +0000

> I'm having a hard time parsing the sentence because it seems to hold two opposing ideas simultaneously but I think that saying that Docker is a monolithic component that can't be replaced is logically mutually exclusive of the fact that they have replaced it.

they can't replace part of it because it's monolithic, so they are replacing all of it.

The Rocket containerization system

raven667 — Thu, 04 Dec 2014 22:06:26 +0000

> I think it's less not wanting to compete on a platform they don't control and more not wanting to try and compete where they can't just replace one part of things and are stuck with a monolithic component that they have to work around rather than being able to replace a layer.

I'm having a hard time parsing the sentence because it seems to hold two opposing ideas simultaneously but I think that saying that Docker is a monolithic component that can't be replaced is logically mutually exclusive of the fact that they have replaced it.

> I will refrain from drawing parallels with the systemd discusssion ;-)

Also two opposing ideas in the same sentance, nice. 8-)

CoreOS heavily relies on systemd and the dbus API, that's how fleet controls services, a better parallel would be if systemd were a single-vendor rather than representing a consortium of the major distros and device makers, and if this mythical systemd vendor came out with a competing system with their own HA and config synchronization built into systemd directly. Project Atomic is the closest to that but there is a much more level playing field between Atomic and CoreOS, both participate in systemd, neither has authority over the other.

The Rocket containerization system

dlang — Thu, 04 Dec 2014 20:43:38 +0000

you need that reproducibility anyway.

doing an install and then upgrading it works for a while, but eventually you will need to create the image again (even with debian you can't always upgrade forever), and if you don't have the build reproducible, you will be in trouble.

been there, done that, have the scars :-)

once you have reproducible builds, immutable images become much easier to mange than having to upgrade each image. If you have resilient services, you can bring up the new image as your failover, and failover to it using the same process you would use if you had a system failure. This should be a clean failover, and it makes sure that your failover mechanism actually works because it's not something that never gets tested.

The Rocket containerization system

epa — Thu, 04 Dec 2014 20:23:58 +0000

Hmm, immutable images make some sense but in that case you need a reproducible procedure to build each image you use. So when a bug like heartbleed occurs you pull down the latest packages from Debian or wherever, type 'make' and get your new image ready to deploy. If you have anything less than that level of automation, it seems that using immutable images adds more difficulty to system administration than it removes.

The reproducible procedure could include doing a full package update from the upstream distribution before freezing the image, so you can still take advantage of tools like apt and yum.

The Rocket containerization system

dlang — Thu, 04 Dec 2014 19:41:51 +0000

Taking what's been posted here at face value, I think it's less not wanting to compete on a platform they don't control and more not wanting to try and compete where they can't just replace one part of things and are stuck with a monolithic component that they have to work around rather than being able to replace a layer.

I will refrain from drawing parallels with the systemd discusssion ;-)

The Rocket containerization system

dlang — Thu, 04 Dec 2014 19:38:15 +0000

> From a pure design PoV, there are many things that are fairly horrible about Docker, from the inability to support deployments across several machines

This shouldn't be part of the container definition, this should be an added layer of management above that (which is what it sounds like Rocket is intending to do)

> Is it really great that there are 65,000 images in Docker hub? Do we really need 900 images just running Redis?

why in the world would you trust an image from a website that anyone can upload to? that's worse than just downloading and executing random binaries.

Now, a recipe for building an image from distro X would be reasnable (I think Fedora calls this a kickstart definition)

I agree that Docker seems to be trying to cash in on the dev-ops hype.

The Rocket containerization system

cortana — Thu, 04 Dec 2014 18:43:49 +0000

Images should be immutable. You build a new image with a fixed version of openssl and push that out to your servers. That way you can always deploy the older version again if you need to roll back.

The Rocket containerization system

raven667 — Thu, 04 Dec 2014 16:30:00 +0000

> . Primarily, the CoreOS team's concern is Docker's expansion from a standalone container format to a larger platform that includes tools for additional parts of the software-deployment puzzle.

Well yes, CoreOS sells tools and additional parts for software deployment using containers so having Docker standardize on something other that what CoreOS wrote is a major competitive problem for them, they need to funnel people into their ecosystem to be able to extract revenue. So this seems primarily a business decision rather than a technical one, they don't want to compete on a platform that they don't control, so they are creating an incompatible platform that they do control and competing with that.

In some ways this shows how much competition really isn't affected by having the software be Free or Open Source, having software be proprietary is a disservice to the customers and you can be just as competitive without it.

The Rocket containerization system

epa — Thu, 04 Dec 2014 14:35:27 +0000

overnight, heartbleed happened; which of your images to you need to update, rebuild, redeploy?

Isn't it enough to run yum upgrade (or its moral equivalent) inside each image? Or is that not how it's done?

The Rocket containerization system

fishface60 — Thu, 04 Dec 2014 11:24:12 +0000

I'd like to see the file system magic of Docker split out.
Snapshotting and sharing of filesystem trees with pluggable backends would be useful for the project I work on, where we do isolated software builds.
You could probably also build a nifty DVCS on top of it which handles binaries better than git.

The Rocket containerization system

ms — Thu, 04 Dec 2014 11:13:53 +0000

I hope this goes well too.

From a pure design PoV, there are many things that are fairly horrible about Docker, from the inability to support deployments across several machines (though pieces like (Zettio|Weaveworks)/Weave address this to a large extent), to the mess of declarative and imperative actions in the Dockerfile, to the general mess of images and inability to reason about what's inside them, or how to update them, let alone compose them.

Is it really great that there are 65,000 images in Docker hub? Do we really need 900 images just running Redis? From a management and maintenance perspective, it's pretty much a disaster: overnight, heartbleed happened; which of your images to you need to update, rebuild, redeploy?

I would love to see even a subset of these issues addressed. For people who care about the long term ability to maintain and deploy services, the dev-ops hipster BS tends to not contribute a great deal. It's easy to get the impression Docker is chasing that market rather than the rather less sexy but crucial former market. If Rocket at the very least prompts some slightly more considered thinking about this sort of thing, that's all to the good.

(An aside: I have never understood why the libvirt-lxc people have not made more noise about their solution: IME, their stuff is more flexible and powerful.)

The Rocket containerization system

dlang — Thu, 04 Dec 2014 05:39:07 +0000

re: docker vs rocket
The way I read the rocket statement is that they will be able to run the docker containers

that in no way says that they will support the docker orchestration tools, current or future.

If they talked about supporting docker configurations, that would imply support for layered networks, etc. But just saying that they will support the containers could (and it sounds to me like it does) mean that you would be able to run the container image, but things external to the container (network definitions for example), would be configured with separate components.

This also doesn't mean that rocket won't support layered networks, just that if they do it will be as a separate layer, in separate binaries than the part that starts the container.

I hope this goes well.