systemd-nspawn: Leichtgewichtige Container ohne Docker

1. Wann systemd-nspawn die bessere Wahl gegenüber Docker ist

systemd-nspawn eignet sich immer dann, wenn ein vollständiges, isoliertes Linux System benötigt wird, das sich wie eine eigenständige Maschine verhält, statt einen einzelnen Prozess in einer Container Hülle zu kapseln. Anders als ein typischer Docker Container, der genau einen Hauptprozess ausführt, startet ein nspawn Container üblicherweise ein komplettes Init System als PID 1, inklusive eigenem Logging, eigenen Services und eigenem Netzwerk Stack, wodurch es sich eher wie eine sehr leichte virtuelle Maschine verhält als wie ein klassischer Applikations Container.

Typische Einsatzszenarien sind Build und Test Umgebungen für unterschiedliche Distributionen, isolierte Entwicklungs Sandboxes auf einem Arbeitsplatz, oder minimalistische Hosting Setups, bei denen kein zusätzlicher Container Runtime Daemon installiert werden soll, weil systemd auf praktisch jedem modernen Linux Server ohnehin bereits läuft. Für Microservice Architekturen mit vielen unabhängig deploybaren Einzelprozessen bleibt Docker oder Podman dagegen meist die passendere Wahl, weil dort das Ein Prozess pro Container Modell und das reichhaltige Image Ökosystem klare Vorteile bieten.

2. Container aus einem Verzeichnis erstellen und starten

Der einfachste Einstieg ist ein Container direkt aus einem lokalen Verzeichnis, das ein vollständiges Root Dateisystem enthält. Werkzeuge wie debootstrap für Debian basierte Systeme oder dnf --installroot für RPM basierte Distributionen füllen ein leeres Verzeichnis mit einem lauffähigen Basissystem, das anschließend direkt als Container Root dient, ganz ohne vorgefertigtes Container Image aus einer Registry.

Der Befehl systemd-nspawn -D startet dieses Verzeichnis als Container mit einer interaktiven Shell, während systemd-nspawn -bD stattdessen ein vollständiges Boot mit Init System als PID 1 auslöst, inklusive systemd internem Logging und Service Management innerhalb des Containers. Dieser Boot Modus ist der eigentliche Kern von nspawn: Der Container verhält sich danach in nahezu jeder Hinsicht wie ein eigenständiges System, in dem sich mit systemctl status Dienste genauso verwalten lassen wie auf einem physischen Host.

# Minimales Debian System in ein Verzeichnis installieren
sudo debootstrap bookworm /var/lib/machines/test-container

# Container interaktiv als Shell starten
sudo systemd-nspawn -D /var/lib/machines/test-container

# Vollstaendiger Boot mit Init System als PID 1
sudo systemd-nspawn -bD /var/lib/machines/test-container

3. Container aus einem Image starten und importieren

Neben lokalen Verzeichnissen unterstützt systemd-nspawn auch fertige Disk Images im raw, qcow2 oder Tar Format über das Flag -i beziehungsweise --image=. Solche Images lassen sich mit machinectl pull-tar oder machinectl pull-raw direkt von einer HTTP oder HTTPS Quelle importieren, wobei systemd optional die GPG Signatur des Images prüft, bevor es lokal gespeichert wird.

Nach dem Import landet das Image standardmäßig unter /var/lib/machines/, dem von systemd nspawn und machinectl gemeinsam genutzten Standardverzeichnis für Container. Von dort lässt sich der Container über seinen Namen direkt mit machinectl start starten, ohne den vollen Pfad erneut angeben zu müssen, was den täglichen Umgang gegenüber der reinen Verzeichnis Variante deutlich komfortabler macht.

# Fertiges Tar Image importieren, inklusive GPG Signaturpruefung
machinectl pull-tar https://images.example.com/debian-12.tar.xz debian-base

# Importierten Container über machinectl starten
machinectl start debian-base
machinectl shell debian-base

4. Networking-Optionen: von Shared Network bis Bridge

Ohne explizite Netzwerkkonfiguration teilt sich ein nspawn Container standardmäßig den Network Namespace des Hosts, was zwar einfach ist, aber keinerlei Netzwerkisolation bietet und Portkonflikte zwischen Host und Container provoziert. Für echte Isolation aktiviert das Flag --network-veth ein virtuelles Ethernet Paar zwischen Host und Container, wobei auf der Hostseite automatisch eine Schnittstelle nach dem Muster ve- entsteht.

Für produktivere Setups lässt sich dieses veth Interface mit --network-bridge= direkt an eine bestehende Bridge auf dem Host binden, wodurch der Container eine eigene IP Adresse im selben Subnetz wie der Host erhält. Alternativ erlaubt --network-macvlan= dem Container, über eine eigene virtuelle MAC Adresse direkt am physischen Netzwerk teilzunehmen, was besonders für Container relevant ist, die von außen über eine eigene IP erreichbar sein sollen, ohne dass NAT oder Port Forwarding im Spiel ist.

# Container mit eigenem veth Paar und Anbindung an eine Host Bridge starten
sudo systemd-nspawn -bD /var/lib/machines/web-container \
  --network-bridge=br0

# Alternative: eigene virtuelle MAC Adresse über macvlan
sudo systemd-nspawn -bD /var/lib/machines/web-container \
  --network-macvlan=eth0

5. Integration mit machinectl für den Alltagsbetrieb

machinectl ist das zentrale Verwaltungswerkzeug für nspawn Container und behandelt sie als vollwertige systemd Machines, gleichbedeutend mit dem Konzept, das auch für virtuelle Maschinen unter systemd Verwendung findet. Befehle wie machinectl list, machinectl status und machinectl poweroff funktionieren dabei unabhängig davon, ob der Container manuell mit systemd-nspawn oder über eine registrierte systemd Unit gestartet wurde.

Besonders praktisch ist machinectl shell, das eine Login Shell direkt im Container öffnet, ohne SSH Zugriff einrichten zu müssen, sowie machinectl copy-to und machinectl copy-from zum Kopieren von Dateien zwischen Host und Container über die machinectl Schnittstelle. Container, die dauerhaft laufen sollen, registriert man am besten als systemd Unit über systemctl enable systemd-nspawn@, wodurch machinectl und systemd den Lebenszyklus gemeinsam verwalten, inklusive automatischem Start beim Boot.

# Alle registrierten Container auflisten
machinectl list

# Container als systemd Unit dauerhaft aktivieren
sudo systemctl enable --now systemd-nspawn@web-container

# Direkten Shell Zugriff ohne SSH
machinectl shell web-container

6. Ressourcenlimits und Isolationstiefe im Vergleich

Da systemd-nspawn Container als reguläre systemd Units verwaltet, greifen dieselben Ressourcenlimit Mechanismen wie bei jedem anderen Service: MemoryMax, CPUQuota und IOWeight lassen sich direkt in der generierten Unit Datei oder über systemctl set-property zur Laufzeit setzen, ganz ohne separate Cgroup Konfiguration außerhalb des systemd Ökosystems. Das ist ein Vorteil gegenüber Docker, wo Ressourcenlimits über eigene CLI Flags statt über die native Distributionswerkzeuge konfiguriert werden.

Bei der Isolationstiefe liegt nspawn zwischen einem einfachen chroot und einer vollwertigen VM: Es nutzt dieselben Kernel Namespaces wie Docker, PID, Mount, UTS, IPC und optional Network, verzichtet aber standardmäßig auf eine vollständige Seccomp Filterung wie Docker sie mitbringt, wobei sich ein eigenes Seccomp Profil über --system-call-filter ergänzen lässt. Für Workloads mit hohem Sicherheitsbedarf sollte dieses Flag explizit gesetzt werden, statt sich auf die vergleichsweise offenen Standardeinstellungen zu verlassen.

# CPU und Memory Limit für einen laufenden Container per systemctl setzen
sudo systemctl set-property systemd-nspawn@web-container.service \
  CPUQuota=50% MemoryMax=512M

# Eigenes Syscall Filter Set ergänzen
sudo systemd-nspawn -bD /var/lib/machines/web-container \
  --system-call-filter=@basic-io --system-call-filter=@network-io

7. Bind Mounts und persistente Daten

Anders als Docker mit seinem expliziten Volume Konzept nutzt nspawn klassische Bind Mounts über das Flag --bind= beziehungsweise --bind-ro= für schreibgeschützte Mounts, um Verzeichnisse vom Host in den Container einzublenden. Das fühlt sich für Administratoren, die mit klassischen chroot oder Jail Umgebungen vertraut sind, natürlicher an als das Docker eigene Volume Management, bringt aber auch weniger eingebaute Abstraktion wie benannte Volumes mit.

Für persistente Datenbank oder Anwendungsdaten empfiehlt es sich, ein separates Verzeichnis außerhalb des Container Root Dateisystems zu pflegen und per Bind Mount einzubinden, damit ein versehentliches Löschen oder Neuaufsetzen des Containers die eigentlichen Daten nicht gefährdet. Da nspawn Container regulären Dateisystempfaden entsprechen, lassen sich Backups mit klassischen Werkzeugen wie rsync oder tar ohne container spezifisches Tooling durchführen.

# Persistentes Datenverzeichnis vom Host in den Container einbinden
sudo systemd-nspawn -bD /var/lib/machines/db-container \
  --bind=/srv/container-data/db:/var/lib/mysql

# Schreibgeschuetztes Konfigurationsverzeichnis einbinden
sudo systemd-nspawn -bD /var/lib/machines/db-container \
  --bind-ro=/etc/container-config:/etc/app-config

8. Abgrenzung zu vollwertigen Docker-Setups

Ein vollwertiges Docker Setup bringt ein reiches Image Ökosystem, standardisierte Compose Definitionen für Multi Container Anwendungen und eine breite Tooling Landschaft für CI Pipelines, Registries und Orchestrierung mit. systemd-nspawn kennt nichts davon: es gibt keine Registry Anbindung, kein Layered Image Format und keine eingebaute Multi Container Orchestrierung, was für komplexe, aus vielen Diensten bestehende Anwendungen schnell zur manuellen Fleißarbeit wird.

Der Kompromiss lohnt sich dort, wo genau diese Docker Komplexität unerwünscht ist: einzelne, langlebige System Container, die sich wie eine eigenständige, leichte VM verhalten sollen, minimalistische Hosts ohne zusätzlichen Runtime Daemon, oder Testumgebungen, in denen mehrere Distributionen parallel als vollständige, bootende Systeme benötigt werden. Für einen typischen Magento Stack mit mehreren lose gekoppelten Services bleibt Docker oder Podman meist die pragmatischere Wahl, während nspawn sich eher für einzelne, isolierte Systemdienste eignet, etwa einen dedizierten Build Server pro Distribution.

9. Praxisbeispiel: Isolierte Build-Sandbox für Paketbau

Ein gängiges Szenario im Hosting Umfeld ist eine isolierte Build Sandbox, in der Pakete oder PHP Extensions für eine bestimmte Distribution kompiliert werden, ohne den Host mit Build Abhängigkeiten zu verschmutzen. Ein per debootstrap erstelltes, minimales Debian Verzeichnis dient dabei als wiederverwendbare Basis, die vor jedem Build Lauf aus einem sauberen Snapshot zurückgesetzt werden kann, was mit einem einfachen btrfs oder overlayfs Snapshot des Container Verzeichnisses in Sekunden erledigt ist.

Weil der Build innerhalb eines vollständig gebooteten Systems läuft, funktionieren auch Build Prozesse, die selbst auf systemd Services angewiesen sind, etwa ein lokaler Datenbank Dienst für Integrationstests während des Build Laufs, ohne zusätzliche Klimmzüge. Nach Abschluss des Builds lässt sich das Ergebnis Artefakt einfach aus dem Container Verzeichnis herauskopieren, während der Container selbst danach verworfen oder auf den sauberen Snapshot zurückgesetzt wird.

# Build Sandbox aus sauberem Snapshot booten, Ergebnis nach Abschluss kopieren
sudo systemd-nspawn -bD /var/lib/machines/build-bookworm \
  --bind=/srv/build-output:/output

# Nach dem Build: Container Verzeichnis auf sauberen Zustand zuruecksetzen
sudo btrfs subvolume delete /var/lib/machines/build-bookworm
sudo btrfs subvolume snapshot /var/lib/machines/build-bookworm-clean \
  /var/lib/machines/build-bookworm

10. Zusammenfassung

11. FAQ: systemd-nspawn