Young and Wild

Ever since Docker started dominating daily conversations, more than a few observers have predicted that virtualization with KVM or Xen would suffer declines. Only time will tell whether these prophecies are true, but certainly containers have a lot going for them. In a direct comparison with full-fledged virtualizers, containers have an advantage with a high density of virtual environments on the virtualization host.

As commercial interest in containers grows, so does the number of solutions available on the market. While LXC and Docker have been vying for users' attention, VMware has introduced its own container approach (Photon OS), as has CoreOS, which has departed from Docker. Meanwhile, Canonical has launched a third product, LXD.

For administrators, it is difficult to tell at first glance which of these solutions is the correct choice for a given application. In this article, I provide an overview of the latest container approaches and clarify which is the best fit for different application scenarios.

The King of the Hill: Docker

I still rank Docker [1] (Figure 1) as "young and wild," even though it is an established solution, because no other container solution has attracted so much attention, seen such massive growth in terms of features, and impressed the critics.

Figure 1: Docker is the King of the Hill in the container world, but it's much more than a simple container standard by now.

From a technical standpoint, one or two details are worthy of note in the case of Docker. First, Docker now supports container operations with its own library, libcontainer . This was not part of the solution right from the start; up until version 0.9, Docker drew directly on LXC to start and manage containers. However, LXC lacked several features, so Docker decided to create its own container platform. The ambition of the libcontainer project is to establish a universal container format for Linux that other solutions can follow.

The second important point in Docker's case is that it strives to achieve exclusive mastery over the containers. Each host runs a separate Docker service, and its child processes are the containers. If you want to launch a Docker container, you issue a matching command from the command-line (CLI) that talks to the Docker daemon on the host in question. The Docker daemon then starts a container and makes sure it runs as desired; it is also responsible for deleting the container when told to do so by the administrator at the end of the day.

Docker fans consider this comprehensive life cycle management to be key. Once the Docker binaries are installed on the host, you can get started, and because a large number of Docker containers are available on the Internet, it doesn't take long to set up your first working container.

Therefore, Docker now is mainly used in the style of platform as a service (PaaS), wherein prefabricated containers with preinstalled software are deployed (i.e., the software developer offers an appropriate container that the user downloads and starts). The individual Docker components are so tightly meshed, that it is more or less impossible for external solutions to intervene meaningfully with the process. In the search for reasons to migrate to Docker alternatives, this is the one point that really stood out, and it provided a justification for the first candidate: Rocket.

CoreOS and Rocket

That CoreOS would enter the ranks of content providers seemed to be virtually impossible just a year ago. It is contradictory to how CoreOS sees itself: as a tool for organizing container operations in masses. Containers are originally tied to the host on which they were started by the user.

This scenario basically ignores the cloud as a factor: Tools that support conveniently starting multiple containers at the same time and then distributing them to multiple hosts were not originally envisaged in the Linux kernel. To this day, even Docker itself does not contain a function that supports something like this.

The CoreOS project is an example of retrofitted clustering capability for containers. You can create a cloud that offers the customer virtually unlimited capacity that is available on demand. CoreOS is a minimal operating system that, out of the box, can do much more than start containers and then manage them in swarms.

Each CoreOS host has sufficient intelligence to know on which host its container is running. If you want to launch a swarm of containers (e.g., to fire up a complete infrastructure as a service (IaaS) webserver farm at the push of a button), CoreOS steps in with the tools that let you do so. These tools (e.g., etcd, fleetd, and many others) then set up the containers in the cloud.

From the outset, CoreOS relied on Docker as its default container format. It was thus possible to say that a container running on host 1 would very likely run on host n . Because Docker supplied the necessary userland integration, the solution was the ideal tool for CoreOS or Kubernetes.

Much of the work done by CoreOS was fed back to Docker, with Brandon Philips, one of the founders of CoreOS, being a top committer to the project. With the increasing use of Docker as a PaaS tool, its focus shifted, however, and cracks started to appear in the relations between CoreOS and Docker.

The battle culminated in an announcement by CoreOS that the project would be looking to develop its own container format, and this format already had a name: Rocket [2] (Figure 2). CoreOS was not sparing with its criticism of the people at Docker: The original intent of being a container standard for Linux had been left behind, they said. In the meantime, the container manifesto, once a technical guideline for Docker, had completely disappeared, and, said the CoreOS developers, talk had turned more or less to a Docker platform rather than simple containers.

Figure 2: Rocket is the CoreOS counterpart to Docker.

According to the CoreOS developers, Docker no longer wants to be a container format, but more of a universal platform for distributing and starting operating system images, including matching software for PaaS purposes. This is viewed as a problem in many respects. The CoreOS developers particularly dislike that a typical Docker container could easily be a Trojan running with root privileges. Moreover, Docker has moved so far away from its original goals that it has become virtually unusable in CoreOS.

Rocket to the Rescue

Rocket is the attempt by CoreOS to create just a container format that does not aspire to be much more. The intent is for Rocket primarily to offer the functionality that exists in simple Docker setups. This includes, on the one hand, the format in which the containers are distributed; that is, it answers the questions as to whether an image is available and the kind of filesystem it uses. On the other hand, a container solution also needs matching programs that support container operations. After all, administrators need to be able to type something at the command line to launch a container.

At the same time, the Rocket format sets out to solve some of the major problems with Docker. In the CoreOS developers' opinion, this includes the topic of security, which they seek to manage through more granular isolation and through the image format itself. The idea is for the community to specify and maintain the format, instead of being guided by the commercial interests of a single company.

From a technology point of view, the differences between the early Rocket versions and the current Docker are already very much apparent. Rocket hosts no longer run a daemon, which the administrator talks to via the CLI and which then finally starts the containers. Instead, the rkt program starts the containers directly. The practical thing about this is that Rocket containers can thus also interact well with other control mechanisms, such as systemd-nspawn, which allows Rocket to offer a more universal interface than the older and more established Docker.

At the end of the day, Rocket is an alternative to the Docker tools that pursue goals similar to those originally sought by Docker. Under the hood, Rocket builds on the same kernel functionality that Docker uses. In the current CoreOS versions, Rocket can already be used, and you will search in vain for large numbers of publicly available images for containers. You can't expect Rocket images to start appearing until the Rocket format becomes more widespread.

The project itself seems to have understood that a cold migration from Docker to Rocket in CoreOS does not make much sense right now. Thus far, the developers are sticking to the statement that Docker will continue to be supported in CoreOS in the future. Plans to get rid completely of Docker support from CoreOS do not currently exist, so for Rocket, this means it is only usefully deployable in the framework of orchestration solutions like CoreOS.