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.
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 (
and image handling (
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
and then handled and transferred using
rsync; that’s it; at max, two tools in total, which are
universal at that.
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-run, which allows the
container to run in the background, being managed as a regular Systemd unit.
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.
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”
ENTRYPOINT instruction) that are designed to enforce the possibility scale horizontally.
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.
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).