Praise for systemd-nspawn

systemd-nspawn is an awesome API (albeit with a somewhat arcane name) for the OS-level virtualization (speak: ‘containerization’) features of the Linux kernel. It appears way less complex than other toolsets, while is is well integrated into the host’s system, which gives it an amazing convenience. It also has features lacking from other containerization tools, which opens up very interesting application possibilities.

Below I’ll just briefly mention the most striking and useful characteristics I’ve got to know about it in recent months.

I can already say that after having worked with all the best known containerization technologies over the last years, systemd-nspawn has been a real eye-opener and game changer for me. That is why I’m taking the time to write this blog post — and no, I’m not in any way affiliated with the project.

Simplicity

systemd-nspawn has no container image format; a regular directory tree on the host’s file system is the template for a container (although it does have support for OCI images). This eliminates the enormous complexity (and steep learning curves) of describing container images (Dockerfile), build tools (docker build, podman build, buildah etc.), and image handling (docker image, podman image). It also eliminates the complexities of transferring, storing and re-using images (repositories, public hubs, etc.).

Please read the last paragraph again; the time advantage of the elimination of all that complexity cannot be overstated.

For example, a full container file system can be created using debootstrap, and then handled and transferred using rsync; that’s it; at max, two tools in total, which are universal at that.

Convenience

Because systemd-nspawn (Debian package systemd-container) comes along Systemd, it is very well integrated — well — into Systemd!

For example, via the recommended package libnss-mymachines, the container name is made available to the local name resolution, which, for example, allows you to directly point your browser to the container. This works even when the container runs in an isolated network where the container has a dedicated private IP address.

It is also possible to start systemd-nspawn using systemd-run, which allows the container to run in the background, being managed as a regular Systemd unit.

Useful features

The root file system may optionally be mounted as persistent or as ephemeral (changes are discarded together with the container).

For me, the ‘killer feature’ certainly is the ability to boot full, containerized Linux-based systems; in other words, it is possible to run Systemd inside a container! This makes systemd-nspawn a replacement for Virtual Machines (at least for certain applications), and allows many interesting new applications.

Flexibility

Unlike other containerization projects, systemd-nspawn doesn’t impose architectural constraints like “only one process per container” (e.g. in a Dockerfile, there “can only be one” CMD and ENTRYPOINT instruction) that are designed to enforce the possibility scale horizontally. In contrast, systemd-nspawn doesn’t constrict this; you can run one process, any number of them, or even boot into a full system with hundreds of services.

End notes

Despite its comparatively arcane name, systemd-nspawn it has the potential to replace a lot of other containerzation techniques, especially where toolset or ecosystem complexity cannot be tolerated. It does not impose constraints

Seriously, give systemd-nspawn a try. To get started, use the excellent Arch Linux documentation https://wiki.archlinux.org/title/systemd-nspawn which works well for Debian too (but use Debian Bookworm or more recent, I found that systemd-nspawn is quite mature there and has no rough edges).