Using Docker containers to test Perl installations on multiple Linux versions
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 .
Listing 3
conprep
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).
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.
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.
Listing 4
smoke-me
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.
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.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.