Software-Container erlauben, Server-Dienste in einen unter allen Linux-Distributionen lauffähigen Container zu packen.

Container auf dem Computer haben eine ähnliche Funktion wie ihre Namensvettern in der physischen Welt. Sie dienen dazu, Software transportabel zu verpacken, und zwar so standardisiert, dass sie sich unter allen Linux-Distributionen sofort starten lässt. Das Grundprinzip der Containerisierung illustriert am besten eine Chroot genannte Kernel-Funktion, die es unter unixoiden Betriebssystemen schon seit vier Jahrzehnten gibt.

Eine solche Abschottung, die Programmen ein Verzeichnis als Dateisystem-Root präsentiert, kommt auch aus Sicherheitsgründen zum Einsatz. Vor allem aber hilft sie, wenn Sie Ihr System mithilfe eines externen Rettungssystems reparieren müssen: Booten Sie ein Live-System von einer DVD, hängen Sie das Dateisystem der beschädigten Installation per Mount-Befehl in ein Unterverzeichnis ein und starten mit Chroot eine Shell (Abbildung 1). Dann lässt sich zum Beispiel mit Grub-install der Bootloader neu installieren.

Abbildung 1: Der Befehl chroot macht einen Ordner, unter dem in einem Kubuntu-Live-System eine OpenSuse-Systempartition eingehängt ist, zum neuen Root-Verzeichnis (/), aus dem sich alle OpenSuse-Kommandozeilenprogramme wie gewohnt aufrufen lassen.

Globalisierung

Traditionelle Linux-Programmpakete funktionieren generell nur unter der Distribution, für die sie konzipiert wurden. Dennoch kann auch eine mehrere Jahre alte Ubuntu-Live-DVD eine aktuelle OpenSuse-Installation “kickstarten” (Abbildung 2): Eine im Ubuntu-Live-System geöffnete Chroot-Shell führt ein OpenSuse-Programm genauso aus, als würde OpenSuse selbst laufen.

Abbildung 2: YaST gibt es für Ubuntu nicht. Das Programm aus Leap 15.4 wurde hier lediglich von einer Kubuntu-18.04-Live-DVD per Chroot aus dem Dateisystem einer OpenSuse-Leap-Installation heraus gestartet.

Ein Programm unter einer beliebigen Linux-Distribution aufzurufen, eröffnet interessante Perspektiven. Tatsächlich bieten Container (Abbildung 3), die prinzipiell so arbeiten wie das Duo aus Rettungs-DVD und Kickstart-System, eine fertige Laufzeitumgebung für Software, die auf jedem Linux-System ohne Veränderungen funktioniert (Abbildung 4). Lediglich die CPU-Architektur (beim PC: x86_64) muss übereinstimmen.

Abbildung 3: Wie ein Chroot in einem Rettungssystem machen Container für die in ihnen enthaltenen Anwendungen ein Verzeichnis des Host-Systems zum Wurzelverzeichnis. Unterschiedliche Container können sich Quell-Images und Inhaltsschichten teilen, um Speicherplatz zu sparen.

Die OpenSuse-Tipps der letzten Ausgabe stellten mit Appimage und Flatpak neuere Pakettypen für Linux vor. Beide umgehen die Distributionsgebundenheit, indem sie die Abhängigkeiten für das Programm mit einschließen. Container stellen mit anderen technischen Mitteln ebenfalls vollständige Laufzeitumgebungen aus einem oder mehreren Programmen und den nötigen Bibliotheken zur Verfügung. Es lassen sich sogar Kombinationen wie Webanwendung plus Webserver und PHP [1] oder ganze Linux-Distributionen [2] verpacken.

Appimages punkten also durch direkte Ausführbarkeit ohne Installation. Flatpaks glänzen durch Integration in den Desktop, etwa mit einheitlichen Dialogfeldern für Öffnen und Speichern. Container hingegen zeichnen sich dadurch aus, dass sie nicht nur Programme und Abhängigkeiten verwalten und abkapseln, sondern auch den nötigen Laufzeitspeicherplatz.

Sie bilden also eine Blackbox, aus der heraus die darin laufende Software keinen Zugriff auf das Wirtssystem bekommt. Auch die gespeicherten Daten liegen innerhalb des Containers. Für Desktop-Programme, die Dateien im Heimatverzeichnis öffnen und speichern sollen, eignen sie sich daher nicht. Für Server-Dienste ist diese Methode aber geradezu perfekt: Bei einem Umzug auf einen anderen Rechner müssen Sie lediglich den Container umkopieren.

Container starten Sie auf der Basis von Images, die sich mit der Installations-DVD einer Linux-Distribution vergleichen lassen. Das mit Flathub für Flatpak-Pakete vergleichbare Online-Repository Docker Hub macht das Beziehen von Images zum Kinderspiel: Es genügt ein Kommandozeilenaufruf wie sudo docker pull nextcloud. Als Format für Container hat sich OCI [3] etabliert.

Da jeder Docker-Aufruf grundsätzlich Root-Rechte benötigt, verzichten wir zur einfacheren Lesbarkeit im folgenden Text darauf, den Kommandos jeweils sudo voranzustellen.

Nutzlast

Nun ist es an der Zeit für ein praktisches Beispiel. Das Docker-Hub-Repository enthält ein Image für einen Nextcloud-Server. Um ihn auf Ihrem System zu starten, installieren Sie, sofern nicht vorhanden, das Paket docker beziehungsweise docker.io und aktivieren den Docker-Systemdienst:

$ sudo systemctl enable docker --now

Zum Herunterladen führen Sie lediglich den Konsolenbefehl docker pull nextcloud aus. Dann starten Sie auf Basis des Images einen Container (Abbildung 4), in dem die gewünschte Anwendung läuft. Die Einzelheiten dazu erläutert die Seite auf Docker Hub: Zum Starten eines vollwertigen Servers, der ohne zusätzlichen Webserver auskommt, führen Sie docker run -d -p 8080:80 nextcloud aus. Anschließend lässt sich unter der Adresse http://localhost:8080 bereits die Nextcloud-Startseite abrufen.

Abbildung 4: Server-Dienste (wie hier Nextcloud) lassen sich am schnellsten per Container aufsetzen.

Der Befehl docker run startet eine neue Container-Instanz aus dem Docker-Repository. Das ist bei einem statusbehafteten Dienst nur beim ersten Mal erwünscht. Möchten Sie den Nextcloud-Server nach einem Reboot erneut aktivieren, dann fragen Sie mit docker ps -a alle existierenden Container ab. Hier sehen Sie alle per Run-Befehl erzeugten Container, aber auch solche mit dem Status exited (beendet). Um eine Instanz mit bereits enthaltenen Daten neu zu initiieren, benutzen Sie den Befehl docker start, gefolgt von der Container-ID oder dem Namen des Containers.

Der fertig installierte Container besteht aus den Dateien des Images plus freiem Speicherplatz. Während niemals ein Schreibzugriff auf das Image stattfindet, verändert sich der Container, wenn Sie die dort laufende Software konfigurieren oder Daten darin speichern. Ausgehend vom originalen Image lassen sich jederzeit wieder neue Container in der Ausgangskonfiguration erzeugen.

Um ein Backup zu erleichtern, kennt Docker zusätzlich sogenannte Volumes, die Verzeichnisse des Containers nach /var/lib/docker/volumes/ ins Host-Dateisystem exportieren. Der Nextcloud-Container exponiert seine gesamte Installation im Webroot /var/www/html/ nach draußen, und zwar in einem anonymen, im Verzeichnis volumes/ mit einem Hash als Namen versehenen Ordner.

Laufen mehrere Container mit anonymen Volumes, dann lassen sich die Verzeichnisse nicht dem Namen nach zuordnen. Darum ist es besser, den Docker-Container mit dem Kommando aus der ersten Zeile von Listing 1 zu starten. Der Parameter -v gibt dem Volume den Namen nextcloud, unter dem Sie es dann im Ordner /var/lib/docker/volumes/ finden.

# docker run -p 8080:80 -d -v nextcloud:/var/www/html nextcloud
# docker commit Container-ID Image-Name:Version
# docker save -o /Pfad/zur/Datei Dateiname.tar.gz
# docker update --restart unless-stopped Container-Name

Mutanten

Der enorme Erfolg von Containern im Unternehmensumfeld beruht nicht zuletzt auf der Tatsache, dass man Änderungen eines Containers während seiner Laufzeit wieder in ein Image zurückführen kann (Listing 1, zweite Zeile). Aus dieser Basis lassen sich erneut beliebig viele laufende Container-Instanzen ableiten.

Zwar ist es das gängige Verfahren, auf einer Container-Registry wie Docker Hub einen kostenlosen Account anzulegen, um die eigenen angepassten Images dort mit docker push hochzuladen. Anschließend kann man sie dann auf einem anderen Rechner wie das offizielle Nextcloud-Image mit docker pull beziehen. Wer seine Container aber nur auf eine Handvoll Rechner verteilen möchte, kommt schneller ans Ziel, wenn er sie mit dem Befehl aus der dritten Zeile von Listing 1 als Tarball exportiert. Mit docker load -i lässt sich das Image auf einem anderen Computer importieren und dort genauso starten wie das per pull online bezogene Nextcloud-Image.

Um den Container nicht nach jedem System-Reboot neu starten zu müssen, geben Sie für einen automatischen Start beim Erzeugen des Containers mit docker run zusätzlich den Parameter --restart unless-stopped an. Um bestehende Container umzustellen, benutzen Sie den Aufruf aus der letzten Zeile von Listing 1.

In vieler Hinsicht entsprechen Container virtuellen Maschinen, die ebenfalls Schnappschüsse ihres Gesamtzustands aufzeichnen und bei Bedarf zu alten Zuständen zurückkehren. Der wesentliche Unterschied besteht darin, dass im Container kein eigener Betriebssystemkern läuft: Es lässt sich gleich das gewünschte Programm starten, ohne vorher ein virtuelles System zu booten.

Zudem benötigen Container keine Virtualisierungssoftware, die aufwendig die gesamte Rechnerhardware als Software emuliert (Abbildung 5). Das macht sie schneller. Für den Einstieg in den Umgang mit Containern empfehlen wir das Get-Started-Tutorial von Docker [4].

Abbildung 5: Eine virtuelle Maschine (hier Qemu/KVM im grafischen Virt-Manager) muss alle Hardwarekomponenten eines PCs mit einigem Aufwand per Software emulieren.

Container gestatten es Heimanwendern, die Hersteller-Referenzimplementierung von Server-Programmen wie Nextcloud auf jeder Linux-Distribution in der aktuellsten Version auszuführen. Viele Softwareentwickler stellen solche Container auf Docker Hub als Official Images zur Verfügung. Software aus einer Fremdquelle auszuführen, setzt Vertrauen in deren Integrität voraus. Docker Hub gibt an, den Official-Status zu überprüfen; die Entwicklung der Images findet für jedermann nachvollziehbar auf Github statt [5].

Doch der praktische Nutzen von Containern auch für durchschnittliche Anwender ist nur ein Grund, warum sich die OpenSuse-Tipps des Themas annehmen. Der andere sind die Planungen für einen gänzlich neuen Aufbau der Suse-Distribution [6]: Im Rahmen des Projekts Advanced Linux Platform (ALP) plant Suse, die monolithische Grundstruktur seiner Distribution aufzubrechen, bei der alle Pakete auf genau eine systemweit installierte Version der benötigten Bibliotheken aufsetzen.

Völlig losgelöst

Bisher steht noch nicht in allen Details fest, wie diese neue Struktur der Distribution aussehen wird. Sicher ist, dass Container eine wichtige Rolle dabei spielen werden, die Abhängigkeiten zwischen einem gut getesteten und nicht zwangsläufig brandaktuellen Systemunterbau und taufrischen Anwendungen zu entkoppeln.

Es dürfte auch für Laien nachvollziehbar sein, dass das enge Geflecht an Abhängigkeiten zwischen den Paketen für das Auffrischen der Distribution ein Problem darstellt. Wer etwa unter OpenSuse Leap mit zypper info --requires gimp die Abhängigkeiten von Gimp abfragt, dem liefert der Paketmanager über 80 Zeilen Abhängigkeiten.

Während in Abbildung 6 nicht unbedingt jede Zeile für ein gesondertes Paket steht, lässt sich doch erkennen, dass ein Paket oft von 50 oder mehr anderen Packages abhängt, die wiederum alle ihre eigenen Abhängigkeiten mitbringen, und so weiter. Es entsteht also ein dichtes Netz von Paketabhängigkeiten für die ganze Distribution. Daher birgt schon das Auffrischen eines einzigen Pakets viel Problempotenzial (Abbildung 7).

Abbildung 6: Die Liste der Paketabhängigkeiten eines Programms wie Gimp fällt so lang aus, dass sie nicht auf den Screenshot passt.

Abbildung 7: Der OpenSuse Build Service automatisiert den Bau neuer Paketversionen. Dabei treten laufend Fehler auf, die die Suse-Entwickler dann per Hand ausräumen müssen.

Am 22.12.2022 erschien der zweite Prototyp von ALP. Er ist noch weit von einem praxistauglichen System entfernt, doch die Vorschau demonstriert bereits die künftig eingesetzten Techniken. So wird das Basissystem wie auch bei Fedora Silverblue [7] als sogenanntes Immutable-System ausgelegt sein. Dabei ist das Root-Dateisystem im Read-only-Modus eingehängt.

Die Installation von Updates oder neuer Software erfolgt deshalb aus dem unverändert weiterlaufenden Snapshot des Btrfs-Dateisystems heraus in einen neu angelegten Schnappschuss, den erst ein Reboot zum aktiven macht. Das Dateisystem sorgt dafür, dass dabei nicht das gesamte, einige GBytes große System kopiert werden muss: Lediglich die Veränderungen zwischen altem und neuem Schnappschuss belegen Plattenplatz.

Tatsächlich ändert sich dadurch bei Suse gar nicht so viel: Schon bisher legte eine OpenSuse-Standardinstallation vor allen Veränderungen einen Btrfs-Snapshot an, zu dem man per Reboot zurückkehren konnte. Neu ist also letztlich nur die Reihenfolge: Bisher wurde das aktuelle System aufgefrischt, während ein neu angelegter Snapshot den alten Zustand für den Fall der Fälle konservierte. Nun erhält der neue, noch inaktive Snapshot die Updates, während das System bis zum Reboot auf der alten Basis weiterläuft. Diese Technik war sogar bisher schon im Installer unter der Bezeichnung Transaktionaler Server verfügbar (Abbildung 8), nicht jedoch als Option für ein Desktop-System.

Abbildung 8: Den Update-Mechanismus für ein Read-only-Root-Dateisystem konnte der Suse-Installer auch bisher schon einrichten, wenn auch nur in Zusammenhang mit einem minimalen Server-System ohne grafische Oberfläche.

Was die Zahl der Reboots beim Update angeht, wird Suse dennoch nicht Windows-Niveau erreichen: Das als Write-only und Immutable ausgelegte System umfasst lediglich einen schlanken Kern, der praktisch nur aus dem Linux-Kernel und einer Container-Laufzeitumgebung besteht. Kernel-Updates erforderten aber auch bisher schon einen Neustart. Als Vorteil verbucht diese Architektur, dass ein nur lesbares Dateisystem den Kernbereich vor Schadsoftware oder versehentlichem Löschen schützt.

Teile und herrsche

Alle weiteren Systemkomponenten laufen in Containern. Deren Liste fällt aktuell aber noch kurz aus: Es gibt eine sogenannte Workload (den Container-Inhalt) für ein Cockpit-Web-Management-Panel, eine Firewall-Komponente, eine Gnome-Desktop-Umgebung, die Monitoring-Software Grafana, den Virtualisierer KVM, die Cluster-Verwaltungssoftware Warewulf sowie YaST in der grafischen und der Konsolen-Spielart. In Zukunft werden sich viele weitere Container ähnlich zuschalten lassen wie im Moment die Schemata der Paketverwaltung (Abbildung 9), wenngleich auf anderer technischer Basis.

Abbildung 9: Die in der neuen Systemarchitektur auf Container-Basis einspielbaren Systemkomponenten lassen sich aus Anwendersicht wohl am ehesten mit den heutigen Schemata aus der YaST-Paketverwaltung vergleichen.

Wer sich fragt, ob ein so kompliziertes und abweichend vom 30 Jahre lang gängigen Standard aufgebautes System in der Praxis funktioniert, der wirft am besten einen Blick auf die Mitbewerber. Ein Desktop-System auf Basis des Immutable-Designs gibt es mit Fedora Silverblue bereits. Das System scheint sich in der Praxis – bis auf häufig nötige Reboots – recht unauffällig zu verhalten [8]. Ubuntu setzt mit Snap zunehmend auf ein Paketformat, das in seinen Eigenschaften gewissermaßen zwischen Containern und Flatpaks liegt, sich aber außerhalb von Ubuntu nicht verbreiten konnte.

Als großen Vorteil verspricht die neue Architektur, dass mit ihr tatsächlich eine einzige, auf jeder Distribution nutzbare Version jeder erdenklichen Linux-Software denkbar ist. Je nach Typ (Desktop-Anwendung, Server-Dienst, Systemkomponente) liegt dieses generische Linux-Paket dann entweder als Container oder Flatpak vor.

Sollten dann überhaupt noch distributionsspezifische Software-Repositories gefragt sein, so lassen sich diese für die Distributoren mit sehr viel geringerem Entwicklungsaufwand bestücken, als das bei den klassischen RPM-, Debian- oder Arch-Linux-Paketen der Fall ist. Deren Erstellen setzt jeweils ein Kompilieren der Software aus dem Quellcode voraus.

Man kann sogar hoffen, dass sich die Qualität verbessert, wenn die eigentlichen Entwickler einer Software die Linux-Pakete erstellen und testen, und nicht mehr die Hersteller einer Linux-Distribution. Die Projektteams kennen ihr Programm besser als die Distributoren, die mit Tausenden von Paketen zu tun haben.

Fazit

Alles hat seinen Preis, auch die distributionsübergreifende Installierbarkeit von Software. Die bisherige strenge Kopplung von Anwendungen an genau eine Version einer Bibliothek, wie es die zentrale Paketverwaltung voraussetzt, sparte Arbeitsspeicher und Festplattenplatz. So etwas gab es unter Windows nie in der Art, was die Softwareverteilung für das Redmonder System deutlich erleichtert, Updates zum Schließen von Sicherheitslücken dagegen erschwert.

Um den Teufel an die Wand zu malen: Mit der neuen Architektur, die die bisherige zentrale Softwareverwaltung weitgehend ablöst, nähert sich Linux dem Konzept von Windows an. Dabei ist vermutlich die gestiegene Ressourcenanforderung angesichts der heutigen Rechner ein geringeres Problem als die Tatsache, dass sich eine mit einer Sicherheitslücke behaftete Komponente nicht mehr einfach durch Auffrischen eines einzigen Pakets reparieren lässt. (tle)