Basic and Overlay Images

Talking of keeping the workload manageable, the workflow described here suggests that you have to copy the default image created at the beginning for each container that will contain a service or multiple services; however, this is not true because Portabled also allows you to combine multiple partial images and create a complete image with OverlayFS. For this to work, the extension images in the /usr/lib/extension-release.d/ directory must contain a file with an arbitrary name that contains at least the ID= lines with the extension image ID, and SYSEXT_LEVEL= and VERSION_ID entries with the extension image data that extends the original image.

Like Nspawnd, Portabled also has its own command-line interface for manipulating containers: portablectl. For example, the command

portablectl attach --extension lamp_1.raw debian-bullseye_1.raw lamp

attaches the lamp extension to the image for Debian GNU/Linux Bullseye. In the next step, the container that Portabled stitches together with OverlayFS can then be treated as if it were a complete container in its own right. The workflow described here makes it quite easy to maintain a basic image and to vary the use of many small extensions.

mkosi Can Help

If you are not comfortable with the distributors' tools for creating an image, you will find that the mkosi (make operating system image) tool is a good alternative. In simple terms, mkosi is a small tool that creates a folder with the complete filesystem of a Linux distribution, which can then be used in systemd with Nspawnd or Portabled like a normal container.

The program can be found in the systemd GitHub directory [3]; its use is almost trivial. To create a Debian image that corresponds to that described in detail above, you just need the command:

$ mkosi -d debian -r bullseye-t gpt_ext4 -b --checksum --password secret --package openssh-client,vim -o image.raw

An image.raw file will then contain a Bullseye image that in turn contains openssh-clients and Vim, along with the standard selection of packages. If you are not a fan of command-line parameters, you can alternatively pass in a configuration file to mkosi. The example from Listing 2 has the same effect as the command above.

[Distribution] Distribution=debian
Release=bullseye
[Output]
Format=gpt_ext4 Bootable=yes Output=image.raw
[Packages]
Packages=openssh-client vim
[Validation]
Password=secret

One disadvantage of mkosi is that it does not take care of installing the packages it needs when creating images. On Debian systems, the task of manually installing the debootstrap and debian-archive-keyring packages falls to you before invoking mkosi (Figure 5).

Figure 5: With mkosi, building images is far easier, but you have to install the distribution-specific tools up front.

Accessing System Resources

One last question remains to be clarified in the context of this article; otherwise, the container fun might come to an abrupt end. How exactly do you provision host system resources in containers? I do not refer so much to specific hardware, because containers do not need their own kernel; they access the hardware directly through the host system's kernel anyway, although they detour through namespaces to do so, adding a degree of control. What I mean is much more likely to be programs that need access to parts of the /sys tree or that retrieve information from /proc. Occasionally, it also happens that an application in one container needs to access the Unix socket of an application in another container.

The answer to how this works is quite simple: You make sure the directory in question exists on the host and tell systemd to provide the folders as bind mounts in the container by means of the BindPaths= and BindReadOnlyPaths= directives in the container's systemd unit files. However, keep in mind that this is a deliberate, intentional blurring of security boundaries. Therefore, you should only go for this option if you have absolutely no alternative.