Gerade fand in Berlin die dort jährlich abgehaltene All Systems Go! statt, eine Konferenz, die sich auf grundlegende Linux-Technologien im User-Space konzentriert. Die Veranstaltung wurde 2015 von den systemd-Entwicklern um Lennart Poettering und Kay Sievers unter dem Namen systemd.conf ins Leben gerufen und 2017 in All Systems Go! umbenannt.
Ein Vortrag hat mich dort besonders abgeholt. Der Meta-Mitarbeiter Alexandre Fiori stellte darin sein Projekt systemd Machine Editor, kurz sdme vor. Hinter dem unscheinbaren Namen verbirgt sich ein Werkzeug, das komplette Linux-Systeme auf Basis von systemd-nspawn als Container startet. Besonders interessant ist dabei die Möglichkeit, mit einem einzigen Befehl praktisch einen Klon des aktuell laufenden Systems zu erzeugen.
Das eigene System als Container
Der Befehl sudo sdme new erzeugt standardmäßig einen Container auf Basis des Root-Dateisystems des Hosts, startet ihn und öffnet unmittelbar eine Shell darin. Anders als die Bezeichnung Klon zunächst vermuten lässt, wird das gesamte Dateisystem dabei nicht kopiert. sdme verwendet OverlayFS und bindet das Root-Dateisystem des Hosts als schreibgeschützte untere Schicht ein. Alle Änderungen innerhalb des Containers landen in einem eigenen, beschreibbaren, darüber liegenden Layer. Das spart sowohl Zeit als auch Speicherplatz und stellt gleichzeitig sicher, dass Änderungen im Container das Host-System nicht verändern.
Gleicher Kernel, eigene systemd-Instanz
Der Container verwendet denselben Kernel sowie zunächst dieselben Programme und Bibliotheken wie der Host, bootet aber eine eigene systemd-Instanz. Dadurch stehen auch systemctl, journalctl und weitere reguläre systemd-Dienste zur Verfügung. In dieser Hinsicht verhält sich der Container eher wie ein vollständiges Linux-System als wie ein klassischer Docker- oder Podman-Container, der meist für eine einzelne Anwendung oder eine überschaubare Gruppe von Prozessen ausgelegt ist.
Nicht auf den Host beschränkt
Damit eignet sich sdme beispielsweise dafür, Paketinstallationen, Änderungen an Diensten oder Distributions-Upgrades zunächst in einer Umgebung auszuprobieren, die dem tatsächlich eingesetzten System sehr nahekommt. Gerade bei Änderungen, die tief in das System eingreifen, ist das interessanter als ein Container mit einem frisch heruntergeladenen Basis-Image. Die Verzeichnisse /etc/systemd/system und /var/log blendet sdme bei einem solchen Host-Klon standardmäßig aus, damit der Container weder die Dienste noch die Protokolle des Hosts übernimmt.
Das Klonen des laufenden Systems ist allerdings nur eine Anwendung von sdme. Das Werkzeug kann Root-Dateisysteme auch aus Verzeichnissen, Tar-Archiven, QCOW2- und Raw-Images sowie aus OCI-Registries importieren. Unterstützt werden nach Angaben des Projekts unter anderem Ubuntu, Fedora, Arch Linux, NixOS, openSUSE und CentOS. Aus einem importierten Root-Dateisystem lassen sich anschließend wiederum systemd-nspawn-Container erzeugen.
OCI-Images importieren
Auch klassische OCI-Images, wie sie etwa über Docker Hub verteilt werden, gehören zum Repertoire. Anwendungen wie Nginx, Redis oder PostgreSQL können auf diese Weise importiert und innerhalb eines vollständigen Linux-Systems als systemd-Dienst gestartet werden. Darüber hinaus versteht sdme Kubernetes-Pod-YAML-Dateien und kann daraus Multi-Container-Pods erzeugen. Diese Funktionen sind laut Dokumentation allerdings teilweise noch experimentell.
Mit sdme fs build existiert außerdem ein eigener Mechanismus zum Erzeugen angepasster Root-Dateisysteme. Die dafür verwendeten Konfigurationsdateien erinnern an Dockerfiles und kennen unter anderem Anweisungen wie FROM, COPY und RUN. Damit lassen sich etwa zusätzliche Pakete installieren oder eigene systemd-Dienste in ein Basis-System integrieren.
systemd statt eigener Container-Runtime
Technisch setzt sdme weitgehend auf Komponenten, die auf systemd-basierten Distributionen ohnehin vorhanden sind. Für die Container kommt systemd-nspawn zum Einsatz, die Verwaltung erfolgt unter anderem über machinectl und die D-Bus-Schnittstellen von systemd. OverlayFS stellt die Copy-on-Write-Schichten bereit. Einen dauerhaft laufenden eigenen Daemon benötigt sdme nicht. Das Werkzeug selbst wird als einzelnes statisch gelinktes Programm angeboten; zusätzlich stehen Pakete für verschiedene Distributionen und für x86_64 sowie AArch64 bereit.
Da sdme beim Klonen des Hosts nicht dessen komplettes Root-Dateisystem dupliziert, fällt der zusätzliche Speicherbedarf für einen solchen Container zunächst sehr gering aus, denn gespeichert werden nur die Änderungen. Wie groß ein sdme-Container letztlich wird, hängt daher hauptsächlich davon ab, was darin installiert oder verändert wird.
Voraussetzung ist allerdings ein installiertes Paket systemd-container, sofern die Distribution systemd-nspawn und machinectl nicht ohnehin mitliefert. systemd muss mindestens in v255 vorliegen, sämtliche Verwaltungsoperationen von sdme benötigen derzeit Root-Rechte. Sind die Voraussetzungen erfüllt, installiert man sdme mit dem Befehl curl -fsSL https://sdme.io/install.sh | sudo sh oder einem dedizierten Paket als .rpm oder .deb oder baut es aus dem Quelltext. Das Projekt wird auf GitHub entwickelt.
Isolation nicht mit Podman verwechseln
Bei aller Ähnlichkeit zu klassischen Containern verfolgt sdme bei der Absicherung einen anderen Ansatz als Docker oder Podman. Standardmäßig teilt sich ein sdme-Container beispielsweise den Netzwerk-Namespace mit dem Host. Zusätzliche Sicherheitsmechanismen wie User-Namespaces oder reduzierte Linux-Capabilities sind nicht in gleichem Umfang wie bei klassischen Containern voreingestellt. Das Projekt stellt dafür unter anderem den Schalter --hardened bereit, der bei Bedarf mehrere zusätzliche Schutzmechanismen aktiviert.
Die Entwickler weisen in der Dokumentation darauf hin, dass vollständige systemd-Systeme andere Anforderungen haben als auf einzelne Anwendungen zugeschnittene OCI-Container. Wer möglichst restriktiv isolierte Anwendungen betreiben möchte, ist daher mit Docker oder Podman unter Umständen besser bedient. sdmezielt dagegen stärker auf vollständige Linux-Umgebungen, Entwicklungs- und Testsysteme sowie Szenarien, bei denen systemd selbst Bestandteil des Tests ist.
Gerade dieser Ansatz macht das noch junge Projekt meiner Meinung nach interessant. Einen beinahe identischen Klon des eigenen Systems mit sudo sdme new innerhalb weniger Sekunden in eine wegwerfbare Testumgebung zu verwandeln, eröffnet einige Möglichkeiten, ohne dafür eine VM oder ein eigenes Container-Image vorbereiten zu müssen.
Foto von Bernd 📷 Dittrich auf Unsplash
