Unit Automation

If you want to wake up the container automatically at system startup, you can do so with a systemd unit file (Listing 1), where you can also configure the network for the container. Systemd basically offers shared networking over a bridge or with a variety of other options. The shared variant, however, is most convenient if it is only a matter of passing through individual ports. The file from Listing 1 is a ready-made unit file for a Bullseye web server container that Nspawnd starts at boot time.

# /etc/systemd/nspawn/webserver-1.nspawn
[Exec]
PrivateUsers=pick
[Network]
Zone=web Port=tcp:443
[Files]
PrivateUsersChown=yes

After a systemd reload, the command

machinectl start webserver-1

starts the freshly created container. If you now configure the directory you just copied to run a web server, it will run autonomously and in isolation from the rest of the system. Even if someone breaks into an unmaintained Joomla or Typo3 on the web server, they do not automatically gain access to the resources of other users or the host – and completely without Docker, Podman, or other hipster stuff.

Mini-Containers

To understand what the second service I talk about in this article (systemd-portabled) does, you need to revisit the functionality of systemd-nspawnd. In practical terms, Portabled plays a very similar tune: Under the hood, it uses much of the functionality that Nspawnd also uses.

Portabled has been part of systemd since version 239, so it should certainly be in place on recent distributions. Although Podman and Docker fans won't like to hear it, Portabled essentially offers precisely the features that Red Hat, SUSE, and their offspring have in mind when they talk about "rump systems" and look to deliver their software in containers. However, it does so without most of their complexity.

Admittedly, the container and its environment consequently lack a few features that Docker and others give you. When it comes to just isolating services and making them portable, though, Portabled is very handy, especially for existing systems that you want to harden without having to switch completely to Docker or Podman.

The basic idea behind Portabled is that you build small container images containing one or more services along with a matching configuration. If a Linux system has a current kernel with support for namespaces and a current systemd environment, the container image can be rolled out on this host and operated there – so the theory goes. The highlight is that this process is completely independent of the package manager in place.

Finding an Image

For an image to be usable with Portabled, it only needs to meet a few requirements. As in the previous example, the recommendation is to use tools like debootstrap to create a basic filesystem. As in the case of Nspawnd, portable images do not need their own kernel or bootloader, but if you want to use a RAW image, it must be equipped with a suitable partition table that the Linux kernel on the host system understands. The systemd in the image also needs a working unit file for the service or services that the container will be running.

The /etc/machine-id file must be in place, as must /usr/lib/os-release. Also, a resolv.conf is required for the services in the container. Everything else is taken care of automatically by tools like debootstrap. The example here assumes that you have created a lamp.raw file that contains a basic Debian GNU/Linux 11 and has Apache 2, MariaDB, and PHP. Most importantly, the systemd unit files must be located in the image in /usr/lib/systemd/system/lamp-apache.service and /usr/lib/systemd/system/lamp-mariadb.service for Portabled to find them later. When Portabled then starts the container on the target system, it copies these files on the host and adds various custom settings that can relate to, say, logging or handling output on stdout. Clearly, the systemd developers wanted you to have to do as little work as possible with portable images.