Wednesday, February 11, 2015

Rocket: Containers without Docker

Rocket is a container runtime from CoreOS. It is a response to Docker's feature creep. Simultaneously with Rocket, the CoreOS team released the App Container Spec, a specification of the image format consumed by a container runtime. Multiple container runtimes could then be written and could all consume the same images. In this post I will talk about my experience with it and what I like and don't like so far. Note that I don't have a ton of experience with this tool at this point.

There are a couple of things inside the app container spec/rocket ecosystem that are just fantastic(actually I'm pumped about basically the whole thing):

Security is a first class concern

Rocket uses gpg to verify the authenticity of App Container Images(aci). It does this by allowing the administrator to trust keys, then containers signed by those keys are trusted. Rocket maintains its own keyring with trust levels. This borrows from the techniques used to secure Linux packaging. Rocket/ACI also use sha512sums to uniquely identify ACIs.

Built on core unix utilities

The main operations (actually all operations) involved in creating, signing, verifying, and sharing ACI's are composed out of the standard unix utilites: tar, gpg, gzip. Any helper utilities just serialize these functions. actool is one such utility. This keeps ACI's simple, doesn't tie anyone to custom tooling, increases debugability and hackability. Particularly in the signing and verification components, this means no one has to trust CoreOS or anyone else.

Emphasis on pushing exactly what you want into the container

With ACI, you copy the files you want into the container and stop there. This encourages small images, and encourages administrators to know exactly what is going in their images.

Networking just works

No crazy -p port:port:ipaddress nonsense, you specify the listen port in the configuration file, boom done. Listens on all interfaces.

Configuration file makes sense, extendable

When you build an ACI, you bake a manifest.json into it. This is a configuration file with a combination of runtime settings and overall metadata. I am already comparing and contrasting with Puppet's metadata.json. Both of these files contain basic metadata such as authorship information. And both are young formats with tooling and use still growing up. JSON's schemalessness allows users and devs to rapidly prototype and try out new information and structures in these files.

HTTP

Http is used as the primary transport. ACI's are simple files. These ACI's can be pushed into webservers or s3 and pulled out with wget or the rocket utility itself.
This is a massive improvement over the current docker-hub situation. Rocket has some rudimentary support for inferring github http locations from names such as 'coreos.com/etcd'

No comments:

Post a Comment