nspawn anstatt chroot: Mit systemd Container erstellen

systemd

Das systemd Mitbringsel nspawn ist keine Neuheit.
Es ähnelt grundsätzlich dem chroot-Befehl, soll und kann dabei aber einiges vereinfachen. Für mich bewegt es sich zwischen lxc und chroot, und hat trotzallem eine Daseinsberechtigung.

Im Gegensatz zu chroot bildet nspawn ein gesamtes Dateisystem virtuell ab, bootet jeweiligen Container in einem eigenen „process tree“ und wirkt tatsächlich wie ein reales, unabhängiges System inklusive Init-System.
Auf diese Weise erstellte Container fügen sich optimal in das System ein, sind leicht zu handhaben und können mit lokalen Diensten im Einklang stehen (zum Beispiel durch „Auslöser“/Trigger).
Wer sich erst einmal eingelesen hat, bindet etwa Verzeichnisse in Container ein („–bind“) oder erstellt komplexere Netzwerkkonfigurationen (es geht auch „ganz ohne“). Die Möglichkeiten sind zwar begrenzt, im Gegensatz zu chroot aber gigantisch.
systemd-nspawn beschreibt sich als „chroot on steroids“ und eigenet sich ableitend nicht für größere Deployments. Hierfür empfehle ich weiterhin Docker, mit einem Auge auf CoreOS, das sich von Docker trennen- und noch intensiver auf Sicherheit fokussieren möchte.

Kleine aber feine Sache nebenbei: Eine ganz besondere Neuerung, die Poettering am 12.12.2014 für systemd-nspawn vorstellte, ist die Möglichkeit vergängliche/temporäre Snaptshots eines btrfs-Dateisystems zu booten:

systemd-nspawn -xb -D /

In Arch und Fedora wird die Neuerung schon anwendbar sein, Debian hinkt in Jessie und Sid noch hinterher.
Ein großes Potential sehe ich darin, ein kritisches System auf Änderungen zu testen, die den Boot-Vorgang behindern könnten. Jede Änderung am System ließe sich sinnvoll testen, ohne die Stabilität zu beeinflussen.
Inkluse Schalter „–template=“ würde der Snaptshot vorab im hier definierten Verzeichnis abgelegt werden, wird im Anschluss also nicht gelöscht.
Poettering nennt noch einige weitere Vorteile. Ich denke, wir sollten die Augen offen halten.

Einrichtung (Beispiel)

Auf meinem Host installiere ich „debootstrap“, um ein blankes Debian System in ein Verzeichnis X zu entpacken:

apt-get install debootstrap

Den Container „jessiecon01“ lege ich in „/var/lib/container“ ab. „Bootstrappen“ möchte ich Debian Jessie, in jedem Fall aber ein systemd-basierendes System.

mkdir /var/lib/container/jessiecon01
debootstrap jessie /var/lib/container/jessiecon01

Ein paar Dinge werde ich im Container vor dem Booten noch einrichten.
Ohne Switch „-b“ wirkt der systemd-nspawn Befehl wie chroot, einige der Vorteile stehen nicht zur Verfügung. Aber die erstellte Shell reicht, um die notwendigen Vorkehrungen zu treffen:

systemd-nspawn -D /var/lib/container/jessiecon01
# im Container:
	passwd # Setzen des Passworts für Benutzer root
	apt-get install locales dbus # dbus ist notwendig, locales eine Empfehlung
	dpkg-reconfigure locales # siehe oben
	hostnamectl set-hostname jessiecon01
	timedatectl set-timezone Europe/Berlin
	exit

Im nächsten Schritt wird der Container interaktiv booten, der Vorgang ist also direkt am Host zu verfolgen.
Anschließend begrüßt eine Anmeldemaske:

systemd-nspawn -D /var/lib/container/jessiecon01 -b

Als Dienst starten

nspawn erstellt einen Dienst, der für alle Container in „/var/lib/container“ verwendet werden kann.
Wurde der Container in einem anderen Verzeichnis abgelegt, reicht ein Symlink in das obige Standardverzeichnis aus.

Der System wird systemd-üblich aktiviert und gestartet.
Nach dem @-Zeichen steht der Containername. Der Dienst übernimmt diesen Wert als Variable:

systemctl enable systemd-nspawn@jessiecon01.service
systemctl start systemd-nspawn@jessiecon01.service

Ein eigener Dienst ist ebenso denkbar, zum Beispiel um sinnvolle Parameter im Startbefehl zu verändern:

cat > /etc/systemd/system/jessiecon01.service <

Auch hier den Dienst erst aktivieren und dann, bei Bedarf, starten:

systemctl enable jessiecon01.service
systemctl start jessiecon01.service

Einige komplexe Aufgaben sowie die rudimentäre Steuerung wie das Neustarten oder Herunterfahren, übernehmen systemd-eigene Werkzeuge wie "machinectl", "hostnamectl", "timedatectl", "systemctl" und weitere xyzctl. Diese Tools eignen sich nämlich nicht nur für den Host, sondern können dank dem Parameter "--machine=container" auch zur Steuerung von lokalen Containern verwendet werden.

2 Antworten auf “nspawn anstatt chroot: Mit systemd Container erstellen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.