Systemd-nspawn : einen Linux-Container testen, ohne Docker zu installieren

Sie müssen ein Debian-Paket oder einen Dienst isolieren, um es auszuprobieren, ohne Docker auf dem Host zu installieren. Wenn die Maschine bereits mit systemd läuft, reicht systemd-nspawn, um ein Linux-Root in einem Testcontainer zu starten.

Die folgende Methode verwendet ein temporäres Debian Bookworm-Root, startet die Maschine mit einem privaten Netzwerk und überwacht dann ihren Status mit machinectl. Ziel: Testen, ohne versehentlich einen Dienst zu exponieren, und dann ordentlich stoppen.

Den systemd-Host vor dem Container vorbereiten

Reservieren Sie dieses Verfahren für einen aktuellen systemd-Host und ein Labor-Image. Auf einem Remote-Server halten Sie Ihre aktuelle SSH-Sitzung, bevor Sie den Container starten.

Das private Netzwerk verringert das Risiko während des Tests, schneidet jedoch auch den direkten Zugriff vom Container ab. Wenn Ihr Test Pakete nach dem Start herunterladen muss, beachten Sie dies, bevor Sie diese Option wählen.

ps -p 1 -o comm=
systemctl --version
command -v systemd-nspawn
command -v machinectl

Der erste Befehl sollte systemd anzeigen. Wenn systemd-nspawn oder machinectl fehlt, installieren Sie das Paket systemd-container auf Debian oder Ubuntu.

Fügen Sie nspawn nicht in einer bereits stark eingeschränkten VM oder einem Container hinzu, um einen Fehler zu umgehen. Kernel-Funktionen und einige Hutungen können fehlen, und die Fehlermeldung wird weniger lesbar sein als auf einem normalen systemd-Host.

Ein Debian-Root für den Test erstellen

Das Verzeichnis unter /var/lib/machines wird zum Dateisystem des Containers. Verwenden Sie einen aussagekräftigen Namen und richten Sie diesen Befehl niemals auf ein bestehendes Root, ein Produktionsmontage oder ein Backup-Verzeichnis.

sudo apt update
sudo apt install debootstrap systemd-container
sudo install -d -m 0755 /var/lib/machines/debian-test
sudo debootstrap --variant=minbase bookworm 
  /var/lib/machines/debian-test https://deb.debian.org/debian

debootstrap lädt eine minimale Debian-Basis vom Host herunter. Das private Netzwerk gilt nur für den Start des Containers, nicht für diese Erstellungsphase.

Diese Trennung verhindert, dass der erste Versuch zu einem Dienst wird, der im LAN erreichbar ist. Das Root bleibt leicht zu entfernen, wenn der Test nicht lange dauern soll.

Die Maschine mit einem privaten Netzwerk starten

Öffnen Sie eine zweite Sitzung auf dem Host, bevor Sie starten. Die erste hält nspawn im Vordergrund, wobei Fehlermeldungen sichtbar sind.

sudo systemd-nspawn -M debian-test 
  -D /var/lib/machines/debian-test 
  --private-network --boot

Die Option -M gibt der Maschine den Namen debian-test. -D bezieht sich auf das kurz zuvor erstellte Root.

Mit --private-network teilt der Container nicht den Netzwerk-Stack des Hosts. Für den ersten Start schützt diese Einschränkung besser als ein versehentlich exponierter Test-Daemon.

Die Maschine mit machinectl überwachen

Überprüfen Sie in der zweiten Sitzung zuerst, ob systemd die Maschine registriert hat. Gehen Sie dann in ihr Shell, um zu bestätigen, dass Sie sich tatsächlich in der Test-Debian befinden.

machinectl list
sudo machinectl shell debian-test
cat /etc/os-release
exit

machinectl list sollte debian-test während seiner Ausführung anzeigen. In der Shell sollte cat /etc/os-release mit der gewählten Debian Bookworm-Basis übereinstimmen.

Wenn die Maschine nicht angezeigt wird, kehren Sie zur nspawn-Sitzung zurück. Die oben angezeigte Nachricht gibt eine verlässlichere Spur als ein zufällig gestarteter Neustart.

• Stoppen Sie den Container mit sudo machinectl poweroff debian-test, oder verwenden Sie Ctrl+C in der nspawn-Sitzung, wenn der Start fehlgeschlagen ist.
• Überprüfen Sie anschließend, dass machinectl list debian-test nicht mehr anzeigt.
• Löschen Sie das Test-Image erst nach dem Stopp: sudo rm -rf /var/lib/machines/debian-test.

Der letzte Befehl löscht das gesamte Root des Containers. Behalten Sie das Verzeichnis, wenn Sie denselben Test wiederholen möchten, aber behandeln Sie es nicht als Produktionsbasis ohne Überwachung der Updates.

Wählen Sie nspawn, Docker oder Podman je nach Bedarf

Für eine vollständige, lokale und temporäre Linux-Maschine ist systemd-nspawn die direkteste Wahl auf einem systemd-Host. Es vermeidet, einen Docker-Stack nur zum Öffnen einer Test-Shell hinzufügen zu müssen.

Für den Aufbau von OCI-Images, die Integration einer CI-Pipeline oder das Verschieben desselben Containers zwischen mehreren Hosts sind Docker oder Podman geeigneter. Der Bedarf ist nicht derselbe.

Der Leitfaden zum Installieren von Docker auf Debian mit Überprüfungen behandelt diesen anderen Ansatz. Wenn Ihr Test von einem beim Start gestarteten Dienst abhängt, hilft die Seite um die systemd-Dienste zu überwachen, seinen Status zu kontrollieren. Die Dokumentation systemd-nspawn(1) auf man7 beschreibt die Optionen für Montage und Netzwerk.