Rarely has such a young software raised so much attention in such as short time as the Docker [1] container manager. Docker is one of the fastest growing open source developments in the history of free software. Released in March of 2013, it made it to version 1.0 in June of 2014 and was declared ready for production. In the same month, Docker was already part of Red Hat's release of RHEL 7. Further cooperative agreements exist with Canonical, openSUSE, CoreOS, VMware and others. Along with that, Docker is a member of Google's Kubernetes project [2].
The visualization associated with the name Docker sums it up: a ship/computer is loaded with containers that you can stack, transport, isolate, and protect (Figure 1). Docker containers in IT are isolated virtual environments for isolated execution of processes and applications. Docker is currently used primarily for developing, testing, and deploying applications and can isolate them along with their dependencies in containers. These applications have practically no overhead and can run nearly as fast as native applications.
Figure 1: The Docker logo says it all: The underlying computer is loaded with containers containing isolated images.
Unlike the well-known hypervisors [3] VirtualBox, VMware Workstation, HyperV, Parallels Desktop or Xen, a Docker container doesn't need its own operating system. Each container uses the basic functions of its host system and is therefore self-sufficient and isolated from other containers. Only the host's kernel needs to match that of the guest.
The Basics
The Docker use the groups
(cgroups
) [4] and kernel namespace
[5] technologies. The namespaces serve to isolate and protect, while cgroups ensure that the container can use the resources selectively granted to it by the host. Until version 0.8 (version 1.2 is the current one) Docker also availed itself of the functions of Linux Containers (LXC) [6], but developed its own API named Libcontainer
in version 0.9 that is also available to other projects.
Currently, Docker is mainly used as a PaaS [7], but it is becoming quite suitable as a resource-friendly alternative to desktop virtualization (Figure 2). Graphical tools are being developed to handle containers, and I will present one of them, Panamax, later in this article as one of the first interfaces its kind.
Figure 2: Comparing Docker with a virtual machine. Although VMs implement a whole OS for each instance, Docker shares an OS for all instances.
The Components
The Docker system consists of three main components: a daemon, a client, and images. The daemon is responsible for orchestrating the containers; the client is what you use to control Docker with commands. The client and daemon can run on the same machine or the client can contact the daemon on a datacenter server or over the cloud. Docker images are the equivalent of virtual machines (VMs) for VirtualBox or appliances in VMware. Compared with these, Docker images are extremely space-saving, can be stacked, and can be versioned in a CVS [8].
The Docker hub is laid out as a SaaS (Software as a Service) [9] and includes the repositories that now have around 15,000 complete image recipes (Figure 3). These are different from base images, which represent a base operating system along with related images containing one or more applications. Creating your own images isn't rocket science after a bit of training, but you need to know the command language of the distribution. An example would be to create an image using WordPress, PHP, MariaDB, SSH, or Nginx.
Figure 3: The Docker hub provides thousands of images ready for use.
Overlaid Layers
Thanks to the overlay functions supplied by aufs [10] or Device mapper [11], Docker has an efficient back end to store the containers. Each container, to put it simply, is stored as a transparent layer. The same functions are similar to thos employed when writing a Live CD (Figure 4). Quite recently, Btrfs [12] has been playing a role as well with its snapshot function. Details on the different filesystem functions for storing and managing containers can be found in Red Hat's documentation for their Atomic [13] project, a container operating system [14] still being developed.
Figure 4: The Docker layer model is similar to the layers on a Live CD.
Before I start going into details, I'll clarify things a bit. A Docker image is just a read-only template, a kind of recipe. A base image [15] provides rudimentary operating system functions and can have a parent-child relationship with other images that interact with the base image on various layers. For example, this could be an ownCloud image, which I'll get to later.
As a rule, containers consist of several images that contain all the functionality and dependencies that the content of the container (an operating system, application, or service) needs at runtime. The basic handling of Docker containers is through the command-line interface, relying heavily on Git [16] and easy to learn. The "Containers, Images, and Docker Files" box provides more information on how things work.
Container, Images, and Docker Files
To better understand how an image is created, look at the description of the ownCloud image in the Docker hub [17]. The Dockerfile
tab shows the important parts of the image. An image also includes licensing information and a README file that goes into specifics.
It's pretty clear what this image does and why it's a template. The FROM
line at the top identifies the base image being used – in this case, Debian Stable (Figure 5). When you download the Dockerfile, each line beginning with RUN
is run in sequence. First, wget
gets installed together with an archive key, the ownCloud repository and its dependencies.
The template then sets pre-installations of the Apache webserver, which, in this case, is in the base image or needs to be installed later. You can then load this complete image into a container where the base image is also loaded. Containers are by default isolated through "deny all" policies and can't communicate with the outside world. If you do want this, use EXPOSE
parameters with port numbers to expose. The VOLUME
parameter allows connecting with the host's filesystems or another container at a specified location. Since Docker 1.2, the containers' rights and privileges can be fine-grained controlled [18] so that the combination of cgroups and namespaces can meet their full potential.
Figure 5: Debian in execution.
A container thus consists of a base operating system and apps and metadata added by users. The image tells Docker what the container should include and, where appropriate, what command is used for startup. In the simplest case the container starts right away with a shell, although far more complicated processes can occur, such as automated test runs.
Because images are read-only, Docker opens a layer for the containers with help from a Union filesystem, such as aufs or Device mapper. These layers are writeable (wr), and the application runs within them. If a change occurs, such as an update, another layer is applied. Instead of changing the entire image at runtime, changes at runtime are integrated only when you convert the container into an image again using
docker commit
There are two kinds of Docker containers: interactively started or daemonized. If the container is to execute a predetermined sequence and then stop, start it interactively with
docker run -t -i debian:sid </command_1;command_2>
A container started with
docker run -d debian:sid /bin/bash
waits in the background for input.
Easier Control with Panamax
Even though Docker's command structure is quite simple and is based largely on Git, it quickly gets unwieldy with many containers. Panamax [19], the first graphical interface for managing Docker containers (still in beta), solves this problem (Figure 6).
Figure 6: Panamax makes deploying several docker containers easy.
To install the browser-based GUI, you first need to install Vagrant version 1.6.5 or higher and VirtualBox 1.4.2 or higher (Figures 7 and 8). If the versions aren't available to you, you'll need to get the Vagrant [20] and VirtualBox [21] packages in Debian format off their websites. Panamax can currently be installed only on Debian-based distributions or the Apple Mac OS. It's really only a question of time that stable versions of further package formats are supported.
Figure 7: Panamax offers an assisted installation from the command line.
Figure 8: Panamax allows you to search for installed containers.
Once the prerequisites are met, install the software using
$ curl http://download.panamax.io/installer/ubuntu.sh | bash
This installs the minimum CoreOS container operating system and Panamax in VirtualBox (Figure 9). The process runs automatically and finishes by having you enter the http://localhost:8888 URL in your browser, which opens the Panamax interface. There you can search for images, install, run, modify, manage and save (Figures 10 and 11). To make the best use of Panamax at this stage requires internalizing the Docker principle. Particularly important is distinguishing between an image and a container. With the help of Panamax and its documentation, you can get containers up and running quickly without entering any by hand (Figure 12). If an error occurs, you simply delete the image and start over.
Figure 9: Panamax shows an image successfully created.
Figure 10: The GUI also allows you to Ad ports, environmental variables, or services.
Figure 11: Installing the WordPress image using Panamax.
Figure 12: Panamax is well documented.
Conclusion
The container principle is far from new. FreeBSD jails [22], Solaris Zones [23], OpenVZ [24] and LXC have existed for quite some time. Even the good old Linux chroot
is nothing else in principle than a container. However, it looks like the makers of Docker bundled the right ideas into free software at the right time. (See the "Basic Commands" box for more information.)
You can install Docker with the following command:
$ sudo apt-get update && apt-get install docker.io
Serious work with Docker also involves installing the following packages:
$ sudo apt-get install cgroup-tools dbootstrap rinse cgroupfs-mount aufs-tools
To run commands without root privileges, do:
$ sudo gpasswd -a <username> docker
To open an account, go to the Docker sign-up page [26], then register as a user:
$ docker login
Search for the desired image, for example, Debian:
$ docker search debian
There are currently 360 different Debian images in the Docker hub, requiring you carefully select the one that fits your needs. Each image is described in detail. For the test, the first image with the name debian
should be enough.
$ docker pull debian
The image is then downloaded onto the local machine. Next, start the image in a container in the shell:
$ docker run -t -i debian /bin/bash
You can also simply load an image directly with docker run
without using docker pull
. The image will be fetched if it isn't available locally. Next, you'll see a prompt that shows something like:
user@70a1d73753b5:
The number after the name is the container ID.
$ user@70a1d73753b5: cat /etc/debian_version
should return 7.6
as the Debian version.
$ docker run -d ...
moves a container in the background.
$ docker ps
shows the running containers.
$ docker ps -a
shows all containers.
Use exit
or Ctrl+D to exit from the container.
$ docker rm debian
removes the previously stopped container.
$docker rmi debian
removes the image.
Many more options are described in the Docker user guide [27].
Three operating systems have emerged around Docker, CoreOS, Red Hat's Atomic project and Dockerera, using the container technology for clusters and other expanded applications. As much as it seems like the conventional virtualization such as VirtualBox and VMware can't keep up with the speed and lower consumption, VMs aren't likely to go away any time soon. Thus for security reasons at Google, Docker containers run on virtual machines. Hundreds of containers can be distributed among a few VMs with twice the security.
Docker in VMs can also run under different platforms, as the Boot2docker project [25] has shown (Figure 13). The operating system ISO image is based on Tiny Core Linux with only 23MB that can be run in VirtualBox and also in Mac OS and Windows. It was designed for using Docker containers in other than Linux. Boot2docker is ideal for a first Docker test.
Figure 13: Boot2docker ready for deployment.
What's Ahead
Whether Docker will become more accessible to end users is yet to be seen. No doubt containers make sense also deployed on the desktop. You can use Docker to isolate less trusted programs or processes from the rest of the operating system. Tests with slightly altered conditions can be run in containers and compared with diff
.
If you're occasionally building packages for your own use, you can depend on Docker as a build environment instead of chroot
. Also, a user can build an operating system tailored to her needs from a base image, save it as a Docker image, and then publish it on the Docker hub. If you want to test Docker without much effort, consider Boot2docker. l