Anchoring the Setup

The conprep script for preparing the containers (Listing 3) now expects the two previously mentioned container configurations for testing Perl modules (and possibly others) under the container directory in a subdirectory named after the distribution (arch, ubuntu; see Figure 1). For each distribution, it immediately jumps into the directory with the Dockerfile for the distribution and calls the following command:

docker build --no-cache .

Figure 1: Each platform directory contains a Dockerfile with instructions on how to make the container.

The final dot stands for the current directory, where the firmly anchored configuration is located in Dockerfile. The --no-cache option makes sure that this really happens step by step and that Docker does not take any shortcuts via any images from earlier installations cached on the host. Now Docker retrieves the appropriate image from the repository and successively executes the specified commands.

Finding Containers

To create a container from a downloaded image, you need to run docker run, which happens implicitly because of the RUN directives listed in Dockerfile. If there are none, a call to docker run -t -i ubuntu ls, for example, would ensure that a container actually is created and that docker – after executing the ls command – jumps out of the container and returns control to the shell on the host.

Where are the new containers? The output from the docker command, surprisingly, reveals nothing about this; it only delivers the image IDs. However, you'll need the container IDs, not the image ID, to enter the container (in a roundabout way) and execute commands. The docker ps command can help you here; it displays all the active containers with their IDs. Stipulating the -l option tells it to output only the most recently generated container (Figure 2).

Figure 2: The docker ps -l command finds the last container generated.

The hex number in the first column is the ID of the container, but knowing this number also is not enough to let you jump into the container. Instead, Docker requires you to use the docker commit <id> <name> command to anchor this ID and assign a name to the version. After doing so, you can then finally type

docker run -i -t <name> /bin/sh

to enter the container. The script in Listing 3 goes through all the necessary snake charming and assigns each new container the name <distname>-perltest, where <distname> stands for the name of the distribution (e.g., ubuntu).

Line 20 separates the output lines of the previously issued tap() command (courtesy of the CPAN module Sysadm::Install) running docker ps -l. Line 22 grabs the second (and last) line and extracts the hex IDs at the beginning. The commit command in line 25 ties the version to the specified name.

The cdback function (which also comes from Sysadm::Install) at the end of the for loop jumps back to the original directory, so the next cd command works with a relative directory path.

After completing this work, a container is available for each distribution. Figure 3 shows how Docker opens a shell in the Arch Linux container and verifies the installed version.

Figure 3: The user opens a shell in the Arch Linux container and verifies the distribution version.

Smoke Rising from Containers

To get things moving toward running the smoke tests, the smoke-me script in Listing 4 takes the tarball of a Perl module as its argument (either downloaded from CPAN or generated by make tardist) and, like conprep previously, runs through all the distribution directories. It then goes ahead and checks whether the module can be installed on the Linux version in the container.

I still need to clarify how the tarball with the Perl module to be tested travels from the host system to the container. The option

docker run -v "/dir1:/dir2" -i -t cmd

tells Docker to create a mount /dir2 in the container that points to /dir1 on the host system. The script in Listing 4 first copies the tarball from the host system to a newly created temporary directory using the cp function from Sysadm::Install. It then tells Docker that the temporary directory can be found below /mnt/tmp inside the container – later on, cpanm immediately finds the right tarball at precisely this spot in the container.

The -v (for verbose) option in the script gets picked up by line 29 and passed on to the cpanm call in the container. The subsequent sysrun function (also from Sysadm::Install) ensures that the script displays the results of running tests in real time, so users can see the progress when the module's test suite is being executed. Figure 4 shows the test sequence in two different containers without -v – that is, with less detail.

Figure 4: The tarball of the Log4perl module completed its test suite in the containers for Arch Linux and Ubuntu.

Obviously no problems occurred, which successfully certifies the module for two Linux distributions. Another trick: If you have accumulated too many no longer functional Docker containers (docker ps -a displays them all), then some Unix foo at the command line can help: Because of the lack of an appropriate option for docker rm,

docker rm `docker ps -notrunc -a -q`

first collects the IDs of all inactive containers and then feeds them one by one to the delete command.