Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Rocket: CoreOS New Container Runtime

Rocket: CoreOS New Container Runtime

This item in japanese

Lire ce contenu en français

CoreOS has released a prototype version of its new Rocket container runtime, an alternative to the Docker runtime, amid disagreements on the Docker process model and the path the project is taking.

CoreOS does not agree on Docker expanding functionality from the container to launching cloud servers, clustering or overlay networking, and so it is building Rocket to focus on composability, security, and speed, creating a standard simple container while fixing some of the issues with Docker.

The decision not to fork Docker is based on claims that the Docker process model, running everything through a central daemon, is fundamentally flawed. Rocket tries to build things differently from Docker in several aspects:

  • Composition: Tools for downloading, installing, and running containers should be independent and composable.
  • Security: Isolation should be pluggable, with image auditing and application identity.
  • Image distribution: Image discovery should be federated and distributed, with pluggable alternative protocols such as BitTorrent or easier private distribution without a registry.
  • Open: The format and runtime should be well-specified and developed by a community, allowing independent implementations of tools to be consistent.

Rocket is a command line tool, rkt, that implements the App Container specification created by CoreOS for an open portable container format, composed of:

  • App Container Image (ACI): Signed and optionally encrypted tgz with all the bits to run the container. Encryption allows distribution via BitTorrent, public object storage, or mirror networks.
  • App Container runtime: Environment in which the container should run, including devices, environment variables, privileges and a definition of a meta-data service interface for exposing data to the environment from outside the container.
  • App Container discovery: Federated protocol for finding and downloading images, inspired by golang’s vanity URL convention for import paths. Images can referred to with names such as, allowing federated downloads without running a registry.

Reactions to the announcement immediately followed. Ben Golub, Docker, Inc. CEO, disagrees with some of the arguments and questions the rhetoric and timing of the Rocket announcement (DockerCon Europe is being hosted this week):

For now, we want to emphasize that this is all part of a healthy, open source process. We welcome open competition of ideas and products. [...] While we disagree with some of the arguments and questionable rhetoric and timing of the Rocket announcement, we hope that we can all continue to be guided by what is best for users and developers.

Ben highlights the ecosystem and open governance around Docker, a project with over 700 contributors, 95% of whom do not work for Docker, Inc., and 65,000 free Docker images. The company still sees the extension to multi-container architectures key in the development of Docker, covering orchestration services for networking, scheduling, composition, clustering, etc. These orchestration capabilities should be created openly and delivered as open APIs, and not be monolithic, allowing plugins to switch services without sacrificing portability, in the same way it already happens with execution engines (libcontainer, LXC) and file systems (BTRFS, device mapper, AUFS, XFS).

In a similar way Solomon Hykes, Docker creator and Docker, Inc. CTO, commented about Rocket, welcoming the competition of tools like LXD, Rocket and nspawn, although he was more critic about the announcement:

"disappointed" doesn't even begin to describe how I feel about the behavior and language in this post and in the accompanying press campaign. If you're going to compete, just compete! Slinging mud accomplishes nothing and will backfire in the end.

Solomon also denied claims of investor pressure to change Docker direction, or that the direction of the project is driven solely by Docker, Inc. and addressed some of the technical concerns in CoreOS Rocket announcement:

The fact that Docker is building a platform does not at all mean that 'docker', the command-line tool, will become bloated and monolithic. Quite the contrary! The major theme of Docker is in fact the exact opposite: to make it more modular, and make it easier to use one part without the other. In fact, the very features mentioned by the CoreOS blog post (machine management, clustering) will not, in fact, be incorporated into the Docker binary.

In the other hand, Pivotal, a company using Docker in their Cloud Foundry PaaS offering, already announced their involvement in the App Container effort:

CoreOS’ specification and engineering approach aligns with our perspectives and process management needs for running thousands of containers in production. [...] Pivotal is enthusiastic about the development of open container specifications and their potential, and calls on the industry to review the CoreOS specifications, and get involved.

Despite the announcement, CoreOS will continue to ship Docker fully integrated in the operating system, and will continue to contribute and be present on the Docker governance board, where Brandon Philips, co-founder and CTO of CoreOS, serves already.

Rate this Article