If you focus on virtualization today, you've surely encountered the new world of Linux container technology. Docker provides a powerful, enterprise-level tool that makes it easy for admins to roll out new and lightweight instances of their applications.

This workshop shows how to configure Docker [1] with the OwnCloud cloud service and demonstrates Docker at work with complex applications that require a web server, a database, and persistent storage.

Getting Started

It does not matter whether you use the Docker as your container manager: The basis for any container is always an image that consists of the distribution filesystem. You can either use pre-built images or build an image yourself. The do-it-yourself approach has advantages, and once you build an image, you can modify it later to adapt it to new situations.

Docker requires an instruction file, known as the Dockerfile, that describes the operation for creating the image. It is important to be familiar with some naming conventions: The filename of each Dockerfile must start with an uppercase letter. A Dockerfile consists of several consecutive instructions, where each line contains a command followed by a parameter. Commands, for example, RUN , must be written out in full and entirely in uppercase letters. Parameters can consist of several words, as is typically the case with Linux command lines that use their own parameters, such as, chmod +x ./My_Script.sh.

Listing 1 shows the Dockerfile for the image of a MySQL database. The base image is selected in the FROM line. The name centos:latest refers to the centos image with the latest tag as another, subordinate, specification: latest always means the latest revision of the image. Releases are identified as in this example: ubuntu:12.04.

To find the image, Docker connects with the central registry or the hub (formerly known as the index). Users exchange images via this publicly accessible platform, so admins usually do not have to build an image from scratch.

Pre-built images are available for many applications. You can find an image using the search function on the Docker website  [2] or the docker search pattern_desc command. If the specified image is not available locally, Docker will automatically download it. Alternatively, you can retrieve an image with the docker pull image_name command.

If a line starts with RUN, Docker executes the command that follows when it creates the image, but not when running the container. The specified command must not require interaction on the part of the administrator. Commands that require interactive input must be appropriately encapsulated – for example with expect – or configured with a matching parameter, so that Docker can continue to run without any input (e.g., yum install -y). RUN commands can occur any number of times in Dockerfiles.

The lines in the Dockerfile are processed sequentially when creating an image with docker build. Each command in the Dockerfile automatically creates a new image, which Docker only stores as a diff to the previously stored image. Rerunning docker build does not lead to the commands being re-executed; instead, Docker reads the results from the cache to save time.

If one intermediate step defined in Dockerfile changes, Docker must also repeat all the subsequent steps. The relationship between different images is revealed in a chart created by running docker images -viz | dot -T png -o docker-images.png (Figure 1).

Figure 1: Parent/child and other relationships between different Docker images are revealed in the graphical output of the docker images tool.

The ADD command adds files and directories to the image. In the MySQL Dockerfile, ADD commands are included through the start.sh script, which is stored as the /start file in the image. If you want to add many files to an image, you can also bundle them in a tarball, which you pass in directly as an argument to ADD. You can also stipulate URLs, such as http://server_name.fqdn/myfile.sh.

ENTRYPOINT vs. CMD

The CMD or ENTRY POINT keyword determines which command will run by default when executing a container. In most cases, this is either the binary of a service, a startup script, or an init replacement, such as supervisor or runit.

Note the subtle difference: CMD /start tells Docker to use /bin/sh -c, or to be more precise /bin/sh -c '/start', to run the command. If you want to run the command directly, you need to pass it in as a list; for example:

CMD [ 'Program', '--Argument1', '--Argument2' ]

The main difference between CMD and ENTRYPOINT becomes apparent at run time; Listing 2 shows an example in the interactive Docker shell. Both images run the /bin/echo program. If you specify CMD, you can override the command specified in the Dockerfile, but not with ENTRYPOINT (see the example in Listing 2).

The instruction set for Dockerfiles is very extensive [2]. Michael Crosby's website [3] provides more useful information about the many options in Dockerfile. Listing 3 shows a complete Dockerfile for the OwnCloud scenario [4].

Building Images

After you have completed your Dockerfile, you need to build the actual image. The docker build command needs the path to the directory containing the Dockerfile as a mandatory parameter. A path can also be a URL – or even the standard input. Additionally, it makes sense to name the resulting image directly and add a tag so that you can easily reference it later:

$ cd /path/to/Dockerfile
$ docker build -t myimage:test .

After building an image by reference to a Dockerfile, you can create and run containers based on the image. Listing 4 shows the output of the docker images command, which lists the locally available images.

To start a container, just type docker run owncloud_httpd:latest, which executes the container in the foreground. The -d parameter starts the container in the background. After running, Docker returns the checksum of the started container.

docker run -d centos:latest sleep 30
a6c462a7999ab01db374ffe502b02d5aac1cd6

This option proves especially useful when used in scripts. To start an interactive session in a container, you need the -i and -t parameters. -i stands for interactive and binds the container to the standard input; -t allocates a pseudo-terminal, and --rm lets you automatically delete the stopped container:

docker run -i -t --rm fedora:latest /bin/bash
bash-4.2# cat /etc/fedora-release
Fedora release 20 (Heisenbug)

The --rm option is useful for tests with containers that you do not want to continue after stopping them.

This procedure also makes it possible to start an interactive session and transfer the results (e.g., package installations or configuration changes) to a new image (Listing 5). The --name parameter in this example directly assigns a name, which the user can use later to access this container. If you do not specify --name, Docker generates a random name.

After a successful docker commit, you can now start a new container:

docker run -d myhttpd:latestapachectl -DFOREGROUND

The docker ps command displays only containers that are currently running. If Docker has stopped a container because the executed command was completed, the administrator must use docker ps -a to see all the containers.