Many a developer looking to package their own application in a container for the first time finds themself out of their depth. Administrators who have not had much experience with containers to date are in a similar position if they are looking to containerize small tools for their own use and deliver them locally. The questions are many. Although the required knowledge can be painstakingly gathered, it takes a long time, and it's not much fun to boot. This article rushes to the rescue. Besides the basics of image building, I look at best practices and continuous integration and continuous deployment (CI/CD) mechanisms, as well as the question of a good DIY image registry. This much can be revealed in advance: The topic is not quite as complex as many critics assume and claim.

The Rise of Containers

Containers are on the rise, whether you like it or not. For years, this magazine has been pointing out that the major distributors, Red Hat and SUSE in particular, will be relying on containers in the future, if only because it saves them a lot of work. For example, Red Hat need only maintain its own software in containerized form once to make it available on RHEL 7, 8, and 9.

As long as a runtime environment for operating containers is available on a system, the underlying operating system hardly matters. Containers also offer a very useful technical alternative for software that the large distributors do not have in their own portfolios. Although Red Hat currently maintains various versions of MariaDB or MySQL for its enterprise distributions, in the future they will simply point to the official container images of the manufacturers instead of doing the work themselves.

This effect can already be seen on the desktop. Recently, Fedora announced that it would no longer maintain LibreOffice in package form but would point its own users to the official LibreOffice Flatpaks. Under the hood, Flatpaks are no more than containers, for which Red Hat doesn't have to put any effort. It is easy to imagine how this trend will continue.

However, not only do the manufacturers benefit from this approach, thanks to the container format, the developers of smaller applications could deliver their own applications to the users quickly and easily. They don't have to deal with annoying details like package managers and different packages for different versions of a distribution. In this respect, containers certainly are tempting.

Questions and More Questions

The questions are always the same: How do you turn the program source code, which is available as a tarball, into Docker containers that can be delivered by Docker Hub? Do practical CI/CD tools already exist that not only facilitate container building, but also professionalize it and automatically find errors? Is the use of Docker Hub even a good idea, or would a local registry, designed specifically for local images, be a better idea?

Luckily for you, Docker developers include the tools you need to create and deploy local container images with Docker, which fortunately does not involve complicated syntax or a whole new format for the metadata of the image to be built. To get your first custom image up and running quickly, all you need is a local folder on a Linux system with some basic tools and a Docker runtime environment in place.

Preparation

In plain English, this means that before image building, a few preparations need to be made on the build system. You can use your own computer for this process, although in organizations that build many images, the norm in recent years is to use a specially prepared system instead. This system does not even have to be a physical machine; a virtual instance is quite okay. At the latest, when a CI/CD toolchain comes into play, the build process will no longer take place on a local system anyway, although the development of the image will, including any necessary test runs. The developer's own preferences ultimately determine the desired procedure.

The general approach to getting a new image off the ground is entirely independent of personal preference. Docker itself ships the build functionality as a docker component. To use it, though, Docker must be installed on the local system. The first step is to set up the community edition of Docker locally. The following example assumes a system with Ubuntu 22.04.

To begin, you need to install some required software management packages (Listing 1, line 1); download the GPG key used to sign Docker's package lists, which Apt relies on to ensure that the packets come from a reliable source (line 2); add the package sources for Docker to the local list of package directories (line 3); and update the local package cache (line 4). Last but not least, run apt to install the community edition of Docker on your system (line 5). A call to systemctl (line 6) should then show active as the docker.service status. Assuming this is the case, the installation worked and the commands you need to build the image are in place locally.

01 $ sudo apt install apt-transport-https ca-certificates curl softwareproperties-common
02 $ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
03 $ echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
04 $ sudo apt update
05 $ sudo apt install docker-ce
06 $ sudo systemctl status docker