Container Ship

Container-based virtualization solutions such as Docker have less hardware overhead and support higher densities than classical virtualization tools such as KVM [1] or Xen [2]. This increased efficiency, along with simpler management, explains the meteoric rise of Docker [3], LXD [4], OpenStack [5], and other container-based tools: Everything called a "container" is currently very popular, and no end is in sight for the hype (Figure 1).

Developers are busily building a whole new fleet of solutions designed to support the container paradigm. Project Atomic [6] and CoreOS [7] [8] are perfect examples of this trend. CoreOS is a naked Linux distribution that only supports one thing really well: the operation of Docker containers (see the "CoreOS" box).

However, not everything is on a positive track in the Docker world. Many Docker detractors believe the root of the problem is Docker's overlay design, because they think its modifications are too wild, but the security also leaves something to be desired.

A Docker container is internally nothing more than a filesystem that receives various deltas via an overlay layer (AuFS), including the software Docker container users need. The problem is, what works well for developers using Docker regularly goes wrong in the operator's daily work, because if the admins install just any container, they may get a Trojan horse in their setup. Moreover, what boots for the developer is not automatically ready for production use. No wonder then that some people regard Docker as a great tool for developers but a disaster for operators and unhelpful in the devops area.

Deis [11] steps up to avoid some of Docker's architectural vulnerabilities and to integrate the product into a production-ready context. According to the Deis project website, "Deis is a lightweight application platform that deploys and scales 12-factor apps as Docker containers across a cluster of CoreOS machines" (see also the box titled "Twelve Factors").

The Deis project aims to clear the container jungle around Docker and create standardized containers that then provide platform-as-a-service (PaaS). The Deis developers say their big model was Heroku [12] – a pioneer of PaaS cloud offerings – and the similarities are evident.

The tricky task for any provider is: How do you equip the VMs to satisfy what the customers want as a platform for operating software? Also, how can this process be automated so that "as a service" are not just empty words and customers can stock up on virtual systems as required? Deis provides a toolbox with which admins can bring together the platforms for their customers.

Deis in a Nutshell

Deis uses etcd to scale a PaaS application sensibly in width. If Deis starts a PaaS VM, etcd steadily receives a series of entries, which an admin can use to restore the VM later.

The Deis developers themselves describe the workflow of their application in the Deis documentation using a graph (Figure 2). The figure clearly shows the three core components: Deis serves as a kind of tool that takes care of the coordination between the PaaS services, Docker, and CoreOS; that is, it acts as the control panel.

On the basis of an initial image, Deis creates Docker containers on demand with specific capabilities. CoreOS then runs the constructed Docker containers.

The Deis workflow occurs in three phases. In the first phase, Deis generates the container. Relying on Git, Deis receives information about container properties via finished instruction packages – called applications. The applications contain the code that is later supposed to run within a container.

So, if an operator wants a Jetty server, the corresponding Deis application will supply Java code. In every application, a special file called procfile describes the application and language to Deis.

A whole range of completed applications [15] on Deis is already waiting in the network. The user can install the applications via the Deis client, which is a separate command-line tool. A deis create command running in the application directory will suffice to create the application. Then, git push deis Master is used to trigger the build process (Figure 3).

In the background, Deis creates a Docker container based on blank templates that obeys the application commands. Ubuntu 14.04 is standard for these images, but you can specify the image through a specific file in the application: All options for the user are exposed by Dockerfile [16], which Docker also offers.

Because Deis always builds a container from plain images, an application that follows the 12 factors can be reproduced easily later. Thus, in the second phase, a naked container without its own identity lands in the Docker registry.

A classic Docker container from Deis does not contain support services such as databases. The PaaS provider is given the task of operating a central database or central instances of other services that containers refer to later. This design ensures scalability because PaaS customers no longer have to think about the infrastructure.

The third phase deals with VM scheduling. A separate Deis component – the scheduler – goes through the list of available CoreOS hosts in the background and decides on which host it will start the container. If a suitable host is found, Deis gets the container off the ground and gives it a range of configuration parameters that are not part of the image. A Deis container is, in fact, a generic Docker image that Deis combines with specific settings from etcd at run time.

The Network et al.

The impressive Deis network component, which is referred to as a router, demonstrates that Deis is deeply involved in the Docker processes. To enable PaaS for different protocols, Deis must centrally control how VMs access their network. The router component is basically the jack of all trades (Figure 4): Based on Nginx load-balancing capabilities, the Deis router ensures that VMs are accessible externally. Routers in Deis are horizontally scalable and work like a mesh network. They also only expose VMs if the container underlying a VM is started successfully.

In addition to central components such as builders, registry (the Deis API), and routers, several other components contribute to Deis. PostgreSQL stores state information about the VMs as a database, and Ceph provides persistent storage to containers that need it. A centralized logging system uses Logspout and Logger. Via an API, the admin can find out the current state of each VM. A cache based on Redis speeds up communication.

Steep Learning Curve

Deis offers many exciting and useful features, but the complex configuration means a lot of background work for the administrator to get the required Deis infrastructure up and running.

The maxim, leaving most of the work to git push as the only necessary command, is in the Heroku style. Deis does not grasp it completely, but the deis create preceding the container start is pretty close to the target, which may be enough for developers. Anyone who is used to working with Git and is familiar with how it works will like the simple approach.

Not all PaaS platform customers are trained programmers, however. PaaS is supposed to create low initial hurdles, so a user interface that customers could use to click together their containers delivered by Deis, would be important.

Deis is missing a working GUI, though, and there is nothing in the network regarding this issue – except for a bug report [17]. According to a statement by Deis developers, a user interface is not on the to-do list for the near future. Anyone who would like to familiarize less savvy customers with a company's PaaS services will find the process difficult with Deis.

The Aim: Web Applications

Deis application examples [15] almost always involve different web applications, and you will come to grips with "different language environments" quickly, explain the creators: A Deis container usually involves a process instruction through which Deis learns what type of container should be used.

However, Deis is not particularly well equipped architecturally when the task is not directly about applications but rather frameworks. Nothing prevents users from building their own apps for development environments, but you won't find many corresponding examples off the shelf.

Docker or Rocket?

Anyone who wants to try Deis should ideally do so in VMs and should expect a few hours work for installation and deployment. The components connected with Deis will likely require special attention.

A recent development that could be significant for the future of Deis is that CoreOS finally broke from Docker in December 2014 [18] and presented its own container technology called Rocket [19]. Of course, the CoreOS developers promise that everything about Rocket will improve.

Against this background, the interesting question is whether Deis will get enthusiastic about Rocket or continue to use Docker as long as it is still available in CoreOS.

At the same time, other projects are waiting in the wings to take up the race against Deis. For example, Solum (Figure 5), like Deis, wants to make PaaS available with a mouse click. Unlike Deis, Solum [20] integrates almost seamlessly with OpenStack (see the "Deis and OpenStack" box).

The container market remains unsettled and erratic, and the remaining solutions have yet to emerge. It is difficult to predict whether Deis will be one of the winners, but for now, it sets the technical standard in many ways and irons out some of Docker's biggest problems.

However, issues such as the missing user interface and lack of integration into other environments are real problems. At least for now, the race across the Linux ocean is not yet over for these container ships.