LXD

The next candidate in the overview is LXD [3] (Figure 3). Again, I need to detour into the cloud to explain the motivation behind the solution. Much like Docker, OpenStack cloud software also is experiencing a great deal of hype, so what would make more sense than to combine the two? At first glance, an OpenStack cloud with Docker as the virtualizer running in it seems to be the ultimate combination.

Figure 3: Although LXD partly uses the LXC binaries, the LXD API in the form of lxd runs in the background.

However, if you start taking a closer look at Docker and OpenStack, you will quickly notice that the two solutions are not that easy to combine. For example, Docker comes with its own image management and relies on each host having a copy of the container image for which it is to launch a container. In contrast, OpenStack has its own image service, Glance.

Similar problems crop up when it comes to networking and storage. The dilemma is comparable to the Docker problems that the CoreOS developers saw in their own project: Docker is much more than a container standard; it is a separate platform for container operations. Teaming up with OpenStack thus does not work very well, either (Figure 4).

Figure 4: Docker can operate in OpenStack, but it is not a very elegant solution from a technical point of view. LXD seeks to remedy the situation.

A driver that teaches OpenStack Nova – the OpenStack virtualization manager – how to handle Docker may already exist. It was already an integral part of Nova, but some releases ago, the Nova Docker driver was removed from the platform. The official message at the time was that the developers wanted to improve the driver without taking the OpenStack release cycles into consideration and then put it back into OpenStack. In fact, it is unclear today if and when this will happen.

Canonical must be frustrated about this: After all, the corporation invested a large amount of money in becoming the vanguard of the FL/OSS world in terms of OpenStack. Most OpenStack clouds currently run on Ubuntu, but the containers are still missing. In contrast, KVM, Qemu, and Xen can be operated more or less painlessly as hypervisors in OpenStack installations. To this day, there is no approach for container virtualization with Docker that is suitable for production operations. The tinkering with Docker that is necessary today can hardly be described as ready for production.

This prompted Canonical to build a new framework and containers specially designed for operations in OpenStack. The company dubbed the project LXD. The similarity of this name to LXC is no coincidence: LXD sees itself as a supplement to LXC, which handles distributed operation of LXC containers within an OpenStack installation.

LXD to the Rescue

Under the hood, LXD thus uses LXC, and it thus becomes clear that LXD relies on the typical Linux container interfaces: cgroups and namespaces. In the media, Canonical's announcement hit home like a bombshell: Canonical was more or less committed to Docker, after all. Did the announcement that Canonical was building its own container solution mean a departure from Docker?

Canonical hurried to deny such allegations. Canonical stated that it was still convinced that Docker was the best container solution for various applications, but in the OpenStack field, they thought that LXD offered a faster track. In the meantime, Canonical underpinned the announcement of LXD at the OpenStack developer meeting at the end of 2014 with some usable code, and LXD can now be operated on Ubuntu 14.04.

Canonical delivers OpenStack integration into the bargain, with a hypervisor driver for Nova in the form of nova-compute-lxd, which can manage LXD containers on OpenStack hosts. This is made possible by the API component in LXD: In typical OpenStack style, LXD extends LXC by adding a RESTful API, which can be controlled and managed from the outside using HTTP-based commands. Viewed in the light of day, LXD is thus a collection of tools, written in Go, that remotely controls LXC containers.

Similarities to Rocket definitely exist: LXD also lacks a daemon that handles the control of all the containers centrally on a host. API calls instruct the matching binaries to install the containers directly on the hosts without needing a daemon. As with Rocket, this makes it easier for external solutions to dock onto LXD – and not just for OpenStack.

A contributing factor is that LXD does not try to manage the complete life cycle of a container. Although the LXD programs take care of starting and stopping, what happens to the virtual machine in the meantime is entirely the responsibility of the management solution in the background.

Whether or not Canonical really has started to rock the Docker boat remains to be seen. For example, Mirantis now has a solution that installs Docker in a way that makes it usable with OpenStack; however, not without some technical contortions. The screenshots published by Mirantis do not really lend themselves to drawing conclusions on how meaningfully Docker can be run in combination with OpenStack.

If you want containers with OpenStack, LXD is the right choice. If you do not want to integrate containers with a cloud framework like OpenStack, you will probably find it easier to go for the standard Docker and solutions such as Kubernetes or CoreOS.

Photon by VMware

VMware launching its own container solution seems a little strange at first glance. After all, VMware still generates most of its turnover with classical full virtualization. Containers do not have a reason to exist in the ESXi sphere, which is precisely why VMware's sortie into the container market makes sense on closer inspection. If customers really do want to move from full virtualization to containers, then VMware has a vested interest in earning money by providing containers, if need be.

Officially, the reasons are different. VMware has announced that Photon OS [4] (Figure 5) has been placed under a free license to ensure that an efficient system is available for operating containers in the data center. From a technical point of view, Photon by VMware is thus more than LXD or Rocket. VMware's work is more of an alternative to solutions such as Kubernetes or CoreOS: It is a minimal operating system that also executes the manager's containers.

Figure 5: VMware has published the source code for Photon OS online. The implementation that VMware uses for containers is a very small in-house solution.