Open Source im professionellen Einsatz
Linux-Magazin 02/2016
© chuyu, 123RF

© chuyu, 123RF

Container mit Systemd

Volle Ladung

Ursprünglich als Tool für Systemd-Tester gedacht, mausert sich Systemd-nspawn zu einer eigenständigen Containerlösung. Bei Rkt von Core OS ist es bereits als Low-Level-Tool im Einsatz. Rkt-Entwickler Jonathan Boulle stellt Systemd-nspawn vor.

476

Dank Systemd-nspawn [1], einem schlanken Containertool im Systemd-Ökosystem, laufen einzelne Befehle, umfangreiche Dienste oder gar komplette Betriebssysteme in einer abgekapselten Umgebung unter Linux. Anfangs diente das Tool den Systemd-Entwicklern eigentlich nur dazu, Systemd [2] selbst zu bauen und zu betreiben, ohne damit dem Hostsystem in die Quere zu kommen, auf dem sie arbeiteten.

Seitdem hat es sich jedoch weiterentwickelt und schließt inzwischen eine Reihe von Funktionen ein, die von einer fortgeschrittenen Netzwerkkonfigurationen über eine SE-Linux-Integration bis hin zur Unterstützung für ein natives Overlay-Dateisystem reichen. Das aktuelle Systemd-nspawn ist also ein vielseitiges und funktionsreiches Tool und deckt eine ganze Palette verschiedener Einsatzszenarien für den Betrieb von Anwendungen unter Linux ab.

Um näher herauszufinden, was Systemd-nspawn ausmacht, lohnt es sich, Bekanntschaft mit einigen der mit ihm verwandten Tools zu machen.

Chroot

Chroot [3] bietet einen der ältesten und einfachsten Wege, um einen bestimmten Grad an Prozess-Isolation auf Linux zu erreichen. Der »chroot« -Systemaufruf erlaubt es dem aufrufenden Prozess, in eine isolierte Dateisystem-Umgebung zu wechseln. Ab diesem Punkt betrachtet Linux jede Referenz auf einen Pfad im Dateisystem, den die Anwendung geht, als relativ zu ihrem Chroot-Verzeichnis. Ein Beispiel für dieses Verhalten wäre:

chroot /home/redaktion/images/jessie/ /bin/ls

Der zweite Teil der Zeile versucht dank des ersten, den Befehl »ls« in der Chroot-Umgebung auszuführen (Abbildung 1). Das neue Wurzelverzeichnis befindet sich dann auf dem Host unter »/home/redaktion/images/jessie/« . Nach dem Einsatz des »chroot« -Befehls sieht der Prozess auf dem Host allerdings keine Dateien außerhalb von »/home/redaktion/images/jessie/« mehr.

Abbildung 1: Eine Chroot-Umgebung bietet eine einfache, wenn auch unsichere Form der Isolation.

Letztlich verändert »chroot« lediglich den Mechanismus, den Linux verwendet, um Pfadnamen aufzulösen. Das tut es, sobald ein Prozess versucht auf das Dateisystem zuzugreifen. Damit gewährt Chroot zwar einen rudimentären Level an Isolation auf Dateisystemebene, der aber lässt sich unglücklicherweise recht einfach brechen.

Es gibt mehrere Wege, aus dem Chroot zu entkommen, etwa indem ein Prozess bereits vor seinem Aufruf per File Descriptor auf eine Datei außerhalb des Chroot verweist. Daher lässt sich diese Form der Isolation nicht als sicherer Mechanismus bezeichnen. Des Weiteren fehlen Chroot fortgeschrittene Möglichkeiten der Prozess-Isolation, die für Linux wünschenswert erscheinen, wenn es zum Beispiel um die Speichernutzung oder die Netzwerkschnittstellen geht.

Besser isoliert

Glücklicherweise haben in den letzten fünf Jahren einige ausgefeiltere Containment-Tools die Bühne betreten, zu denen neben Systemd-nspawn auch Docker [4] und das von uns entwickelte Rkt [5] gehören. Sie nutzen spezielle Kernelfeatures, um eine bessere Isolation zwischen den Prozessen des Systems zu erreichen. Während aber Docker und Rkt auf eine Nutzergruppe abzielen, die vorwiegend Anwendungen in Containern laufen lassen möchte, handelt es sich bei Systemd-nspawn eher um ein Low-Level-Tool, das sich an Entwickler richtet.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 4 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.