The Rocket containerization system

The field of software-container options for Linux expanded again this week with the launch of the Rocket project by the team behind CoreOS. Rocket is a direct challenger to the popular Docker containerization system. The decision to split from Docker was, evidently, driven by CoreOS developers' dissatisfaction with several recent moves within the Docker project. 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.

There is no shortage of other Linux containerization projects apart from Docker already, of course—LXC, OpenVZ, lmctfy, and Sandstorm, to name a few. But CoreOS was historically a big proponent of (and contributor to) Docker.

The idea behind CoreOS was to build a lightweight and easy-to-administer server operating system, on which Docker containers can be used to deploy and manage all user applications. In fact, CoreOS strives to be downright minimalist in comparison to standard Linux distributions. The project maintains etcd to synchronize system configuration across a set of machines and fleet to perform system initialization across a cluster, but even that set of tools is austere compared to the offerings of some cloud-computing providers.

Launch

On December 1, the CoreOS team posted an announcement on its blog, introducing Rocket and explaining the rationale behind it. Chief among its stated justifications for the new project was that Docker had begun to grow from its initial concept as "a simple component, a composable unit" into a larger and more complex deployment framework:

The post also highlighted the fact that, early on in its history, the Docker project had published a manifesto that argued in favor of simple container design—and that the manifesto has since been removed.

The announcement then sets out the principles behind Rocket. The various tools will be independent "composable" units, security primitives "for strong trust, image auditing and application identity" will be available, and container images will be easy to discover and retrieve through any available protocol. In addition, the project emphasizes that the Rocket container format will be "well-specified and developed by a community." To that end, it has published the first draft of the App Container Image (ACI) specification on GitHub.

As for Rocket itself, it was launched at version 0.10. There is a command-line tool (rkt) for running an ACI image, as well as a draft specification describing the runtime environment and facilities needed to support an ACI container, and the beginnings of a protocol for finding and downloading an ACI image.

Rocket is, for the moment, certainly a lightweight framework in keeping with what one might expect form CoreOS. Running a containerized application with Rocket involves three "stages."

Stage zero is the container-preparation step; the rkt binary generates a manifest for the container, creates the initial filesystem required, then fetches the necessary ACI image file and unpacks it into the new container's directory. Stage one involves setting up the various cgroups, namespaces, and mount points required by the container, then launching the container's systemd process. Stage two consists of actually launching the application inside its container.

What's up with Docker

The Docker project, understandably, did not view the announcement of Rocket in quite the same light as CoreOS. In a December 1 post on the Docker blog, Ben Golub defends the decision to expand the Docker tool set beyond its initial single-container roots:

But the existence of such higher-level orchestration tools and multi-container applications, he said, does not prevent anyone from using the Docker single-container format. He does acknowledge that "a small number of vendors disagree with this direction", some of whom have "technical or philosophical differences, which appears to be the case with the recent announcement regarding Rocket."

The post concludes by noting that "this is all part of a healthy, open source process" and by welcoming competition. It also, however, notes the "questionable rhetoric and timing of the Rocket announcement" and says that a follow-up post addressing some of the technical arguments from the Rocket project is still to come.

Interestingly enough, the CoreOS announcement of Rocket also goes out of its way to reassure users that CoreOS will continue to support Docker containers in the future. Less clear is exactly what that support will look like; the wording says to "expect Docker to continue to be fully integrated with CoreOS as it is today", which might suggest that CoreOS is not interested in supporting Docker's newer orchestration tools.

In any case, at present, Rocket and its corresponding ACI specification makes use of the same underlying Linux facilities employed by Docker, LXC containers, and most of the other offerings. One might well ask whether or not a "community specification" is strictly necessary as an independent entity. But as containerization continues to make its way into the enterprise market, it is hardly surprising to see more than one project vie for privilege of defining what a standard container should look like.