Container Terminal

Version Control

Another treat for anyone interested in using Docker containers in a production environment is Docker's versioning system. Docker's developers have basically implemented a small clone of Git that is customized for Docker operation. It includes many commands that are reminiscent of Git: docker commit, docker diff, and docker history are just a few examples.

These functions ultimately ensure that you do not need a complete copy of the original file for each new version of an image. Depending on the containers, this approach would quickly use up too much space. Docker circumvents the problem very elegantly by managing a local "container repository," in which changes can be committed at any time. Using the previously described automated build function, you can at any time generate a finished container file for distribution from a specific version of an image. All told, container handling is thus implemented in a very elegant way.

The Docker API

Elegance is also evident in the Docker API, which is effectively a switching and interface center of a Docker installation that is managed in line with the RESTful principle via an API. In the background, the API is responsible for ensuring that docker commands entered at the command line are actually implemented. Consequently, all the Docker commands are ultimately API calls; the Docker API does the real work.

The advantage of such an architecture is obvious; with the API as an abstract command receiver in the background, there are few limits to what you can do in terms of developing front ends. All major cloud computing solutions rely on similar designs, and the principle has asserted itself in Docker, as in Amazon's EC2 or OpenStack. Besides the docker command-line tool, a GUI by the name of DockerUI [2] is also available (Figure 2), and a competitor known as Shipyard [3] vies for the favor of users, as well (Figure 3).

Figure 2: DockerUI is one of two GUIs that are available for Docker deployment. The alternative is …

Figure 3: … Shipyard, which also looks quite spartan, but has all the important functions in place.

Cloud Integration

With its capabilities, Docker is eminently well qualified for more complex tasks. If you do not need a fully virtualized system but merely a matching container – for example, for development purposes – you can benefit greatly from Docker. It is only logical to integrate Docker with typical cloud and virtualization solutions  – and with other tools that swim in the wake of the major cloud environments.

OpenStack very clearly dominates the market for open source clouds at the moment, a fact that has evidently not escaped the Docker developers' attention. After all, the OpenStack virtualization component, Nova [4], now comes with support for Docker.

Nova is basically modular, and the virtualization technology to be used can be enabled by a plugin. Thus, a simple entry in nova.conf decides which technology the OpenStack component uses in the background. The choices are, for example, KVM, HyperV, VMware, and, more recently, Docker (Figures 4 and 5). OpenStack then does not launch a complete VM in the background; instead, it creates a Docker container that offers its own functionality as a virtual system. Docker integration is seamless, so you do not see the difference between running KVM with a full VM and Docker at first glance. In detail, however, quality differences do exist.

Figure 4: This entry highlighted in this figure activates the Docker virtualization driver, which was introduced to OpenStack in the Havana release.

Figure 5: The Glance OpenStack image service can use Docker containers as images after a small configuration change.

These differences partly relate to the requirements that Docker imposes on itself. Because the application seeks always to present the same system externally, as described previously, it needs to go through some contortions internally. This approach requires a high degree of adaptability with respect to various factors such as the network.

The Docker driver in Nova only supports the old network stack (nova-network) in the Havana release of OpenStack, which will probably be removed in the next release of OpenStack. A bug report in Launchpad makes me suspect that this is a bug  – not a feature that has been deliberately left unimplemented [5]. Anyone using OpenStack with the forward-looking Neutron SDN stack cannot turn to Docker for the time being. However, precisely because Docker is currently all the rage, you can assume that this issue will be remedied in the foreseeable future. That said, this makes it hard to judge the maturity of the Docker implementation in Nova.