The Rocket containerization system

This article brought to you by LWN subscribers

Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, pleasebuy a subscription and make the next set of articles possible.

The field of software-container options for Linux expanded againthis week with the launch of theRocket project by theteam behindCoreOS. Rocket is adirect challenger to the popularDocker containerization system.The decision to split from Docker was, evidently, driven by CoreOSdevelopers' dissatisfaction with several recent moves within theDocker project. Primarily, the CoreOS team's concern is Docker's expansion from a standalone container format to alarger platform that includes tools for additional parts of thesoftware-deployment puzzle.

There is no shortage of other Linux containerization projects apartfrom Docker already, of course—LXC,OpenVZ,lmctfy, andSandstorm, to name a few. But CoreOSwas historically a big proponent of (and contributor to) Docker.

The idea behind CoreOS was to build a lightweight andeasy-to-administer server operating system, on which Docker containerscan be used to deploy and manage all user applications. In fact,CoreOS strives to be downright minimalist in comparison to standardLinux distributions. The project maintainsetcd to synchronizesystem configuration across a set of machines andfleet to perform systeminitialization across a cluster, but even that set of tools is austerecompared to the offerings of some cloud-computing providers.

Launch

On December 1, the CoreOS team posted anannouncement on its blog,introducing Rocket and explaining the rationale behind it. Chiefamong its stated justifications for the new project was that Dockerhad begun to grow from its initial concept as "a simplecomponent, a composable unit" into a larger and more complexdeployment framework:

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

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

As for Rocket itself, it was launched at version 0.10. There is acommand-line tool (rkt) for running an ACI image, as well asadraftspecification describing the runtime environment and facilitiesneeded to support an ACI container, and the beginnings of a protocolfor finding and downloading an ACI image.

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

Stage zero is the container-preparation step; therkt binary generates amanifest for the container, createsthe initial filesystem required, then fetches the necessary ACI imagefile and unpacks it into the new container's directory. Stage oneinvolves setting up the various cgroups, namespaces, and mount pointsrequired by the container, then launching the container's systemdprocess. Stage two consists of actually launching the applicationinside its container.

What's up with Docker

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

But the existence of such higher-level orchestration tools andmulti-container applications, he said, doesnot prevent anyone from using the Docker single-container format. He doesacknowledge that "a small number of vendors disagree with thisdirection", some of whom have "technical orphilosophical differences, which appears to be the case with therecent announcement regarding Rocket."

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

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

In any case, at present, Rocket and its corresponding ACIspecification makes use of the same underlying Linux facilitiesemployed by Docker, LXC containers, and most of the other offerings.One might well ask whether or not a "community specification" isstrictly necessary as an independent entity. But as containerizationcontinues to make its way into the enterprise market, it is hardlysurprising to see more than one project vie for privilege of definingwhat a standard container should look like.