© Kamil Majda'nski, 123RF

Im Zeitalter von Container und Cloud verliert das Betriebssystem an Geltung. Fast unverwundbare Rumpfsysteme, die sich nur noch ums Elementare kümmern, kommen da gerade recht und retten den Tag.

Die Rolle des Betriebssystems in der IT wandelt sich gerade deutlich. In der Prä-Cloud-Ära war das OS die maßgebliche und bestimmende Komponente. Seine Meister, die Systemadministratoren, erfreuten sich einer gewissen Beliebtheit, die alle emotionalen Bandbreiten abdeckte. Der Sysadmin Appreciation Day [1] und die Geschichten vom BOfH (Bastard Operator from Hell, [2]) sind nur zwei Zeugnisse dieser Kultur.

Cloud, Virtualisierung und nicht zuletzt die Container haben das Planetenmodell mit dem Betriebssystem im Zentrum erschüttert und verändert. In ihrem Gefolge entwickelte sich eine Reihe neuer Ansätze. Um einen Teil der Aufgaben kümmert sich dabei die möglichst schlanke und damit sichere Infrastruktur, den Rest übernehmen die darauf aufsetzenden Container. Welche Rolle quelloffene Betriebssysteme in diesem neuen Szenario spielen, beleuchtet dieser Artikel, der an einen vor einiger Zeit erschienenen [3] anschließt.

Mehr oder weniger

Grob vereinfacht bemisst sich der Dienstleistungswert eines Betriebssystems an der mitgelieferten Software, wobei auch der Umkehrschluss möglich ist. Sinken also die Erwartungen an die vorhandene Kernsoftware, muss das Betriebssystem auch weniger Pakete mitbringen. Diesem Prinzip folgen auch die Verschlanker von Linux-Systemen. Im einfachsten Fall reduzieren sie die mitgelieferte Software. Gehen sie die Sache konsequenter an, schauen sie auch genauer auf die verwendeten Prozesse, Prozeduren und andere Designansätze.

Zu den bekanntesten Distributionen, die dem zweiten Ansatz folgen, gehören Cirros [4], Alpine [5], Jeos (Just enough Operating System [6]) und das frühere Core OS [7]. Letzteres heißt nun Container Linux und passt besser in eine Kategorie, die der Text weiter unten bespricht.

Ein dürres Ubuntu

Gutes Anschauungsmaterial für “Weniger ist mehr” liefert das erwähnte Cirros (Abbildung 1). Das Projekt ist inzwischen mehr als fünf Jahre alt. Die erste öffentliche Version 0.3.0 erschien im Oktober 2011. Aktuell ist Version 0.3.5, der Quelltext steht unter der GNU Public License in Version 2 (GPLv2).

Abbildung 1: Cirros ist ein kleines Linux, der Bootvorgang verläuft fast zu normal.

Das kleine Cloudbetriebssystem setzt sich aus zwei Bausteinen zusammen: einem Ubuntu-Kernel und Buildroot [8]. Der zweite zielt eigentlich darauf ab, Linux-Systeme für den Embedded-Bereich zu montieren, bei denen Platz gewöhnlich ein Luxus ist. Das aber ist eine Anforderung, die sich mit der im Cloud- und Containerumfeld deckt. Auch hier soll der OS-Anteil möglichst klein ausfallen. Der Ubuntu-Kernel ist gesetzt, weil Scott Moser [9] hinter Cirros steckt, hauptberuflich technischer Leiter von Ubuntu Server bei Canonical.

Zum gegenwärtigen Zeitpunkt gibt es fertige Images für 32- und 64-Bit-Architekturen der Intel- und AMD-Welt. ARM und Power-PC unterstützt Cirros ebenfalls, allerdings noch nicht für 64-Bit-Systeme [10]. Die Entwickler verstehen ihr Cloudbetriebssystem primär als Werkzeug für Tests oder zum Untersuchen von Problemen. Open Stack benennt Cirros zum Beispiel offiziell als Testimage in der Dokumentation [11].

Das Cloud-OS bringt eine Reihe von Helfern mit, die alle mit »cirros-« beginnen. Tabelle 1 listet sie zusammen mit einer kurzen Erklärung auf. Alle Kommandos sind Shellskripte und erlauben so einen einfachen Blick hinter die Kulissen. Sie sind nicht sonderlich gut dokumentiert – weder im Code selbst noch auf der Webseite des Projekts.

Beim Hochfahren kommt das traditionelle Sys-V-Initsystem zum Zuge. Gegen Ende des Bootvorgangs assistieren dann Cirros-spezifische Skripte. Die sind so angelegt, dass sie mit dem Cloud-Init-Gerüst [12] funktionieren, die passenden Konfigurationsdateien liegen unter »/etc/cirros-init/«. Zum Lieferumfang gehören Vorlagen für Amazons EC2, für ein so genanntes Konfigurationslaufwerk (»configdrive«) und für lokale Starts, also ohne Cloud [13]. Das ist recht nützlich. So testet der Benutzer den kompletten Ablauf des Anlegens und Hochfahrens einer Cloudinstanz – inklusive der Anpassung im Postinstall-Stadium.

Unter Cirros’ Motorhaube warten keine Überraschungen. Die Datenablage übernimmt das fast schon ehrwürdige Ext 3. Der Einsatz von Busybox [14] für die meisten ausführbaren Programme und von Dropbear [15] als SSH-Daemon sind eine Konsequenz aus dem Buildroot-Unterbau. Der gestandene Linux-Admin dürfte sich mühelos zurechtfinden.

Dienst am Container

Bei Cirros, aber auch Jeos und – mit Abstrichen – Alpine, handelt es sich zwar um abgespeckte Betriebssysteme, dennoch lassen sie sich universell einsetzen. Prinzipiell können sie als Unterbau für alle möglichen Aufgaben dienen.

Mit dem Siegeszug der Container ist hingegen eine neue Variation kleiner, quelloffener Betriebssysteme entstanden. Im Gegensatz zu den Kandidaten aus dem vorigen Abschnitt sind die Neuen stark spezialisiert. Ihre Hauptaufgabe besteht darin, ein Fundament für die Container bereitzustellen.

Umstritten ist, wer diese Idee zuerst hatte. Das ehemalige Core OS der gleichnamigen Firma hat den Gedanken auf jeden Fall in ein Produkt gegossen. Puristen könnten argumentieren, dass Projekt Atomic (und die kommerzielle Variante Red Hat Atomic Host ([16], [17]) sowie das ursprüngliche Snappy Ubuntu Core [18] eine höheren Grad an Spezialisierung aufwiesen.

Obwohl die ersten Varianten dieser Rumpfsysteme Ende 2014 das Licht der Welt erblickten, entwickelt sich ihr Ökosystem noch immer sehr dynamisch. So stellte Suse auf der Susecon im November 2016 eine Art Mikrobetriebssystem für Container vor ([19], [20]), das SLE Micro OS. Vor ein paar Monaten benannte Core OS die eigene Distribution in Container Linux [21] um. Der Name soll offenbar Ausrichtung und Zielsetzung des Betriebssystems stärker abbilden.

Vom Kapitän zum Hafenarbeiter

Googles Betriebssystem Chrome OS [22] stand Pate beim Design von Container Linux. Die Schiffstaufe erfolgte im Herbst 2013 unter der Version 2 der Apache-Lizenz. Da Container Linux auf Komponenten wie dem Kernel und Systemd aufbaut, gelten dort die jeweiligen Lizenzen. Der Ressourcenverbrauch erweist sich als recht gering, auf der (virtuellen) Festplatte und im Arbeitsspeicher sind es zirka 30 beziehungsweise 140 MByte (Abbildung 2).

Abbildung 2: Ein aktuelles Container Linux zeigt sich äußerst Ressourcen-sparend. Das betrifft sowohl den verwendeten Plattenplatz als auch den Arbeitsspeicher.

Container Linux verzichtet auf einen Paketmanager, wofür es gleich mehrere Gründe gibt. So geht das erwähnte Abspecken des Linux-Systems natürlich irgendwann zu Lasten der installierten Anwendungen. Das Betriebssystem soll nur noch ein paar Grundfunktionen erfüllen. Mit sinkender Zahl der installierten Anwendungen sinkt aber auch die Notwendigkeit, diese mit Hilfe eines Werkzeugs zu verwalten.

Container Linux geht hier rabiater vor und tauscht statt einzelner Dateien das komplette »/usr«-Verzeichnis aus (Abbildung 3). Die Hauptarbeit verrichten Linux-Container à la Docker [23] beziehungsweise Rkt [24], Etcd [25] und Kubernetes [26]. In früheren Versionen gehörte auch Fleet dazu, doch von diesem verabschiedete sich Core OS kürzlich [27]. Mit der Namensänderung der Linux-Distribution ging zugleich die vollständige Ausrichtung auf Kubernetes als Orchestrierungssoftware einher. Es geht nun nicht mehr um ein verteiltes Initsystem, sondern um das Verwalten von Containern. Dabei steht Kubernetes in der Regel mit auf dem Zettel.

Abbildung 3: Container Linux sieht im Normalbetrieb keine Änderungen an »/usr« vor – dies gilt sogar für einige Dateien in »/etc«.

Kanalarbeiter

Ein paar logistische Informationen können helfen, um den Einstieg in die Arbeit mit Container Linux zu erleichtern. Die Entwickler verwalten die drei Kanäle Stable, Beta und Alpha. Die Idee dahinter kennen Linux-Routiniers bereits von Debian. Fehlerkorrekturen oder neue Funktionen für Container Linux implementieren die Entwickler zunächst im Alpha-Kanal. Treten dort keine Fehler (mehr) auf, wandern die Änderungen in den Beta-Zweig, analog geschieht die Beförderung in den Stable-Kanal.

Für die Versionierung von Container Linux wäre eine übliche Variante, sie von Komponenten wie dem Kernel, Etcd oder der Docker-Version abzuleiten. Das Projekt hinter der Technologie hat sich allerdings für eine andere, einigermaßen obskure Variante entschieden. Die Versionsnummer entspricht der Anzahl von Tagen, die seit Beginn der Epoche von Container Linux – dem 1. Juli 2013 – vergangen sind. Die erste Version erschien am 3. Oktober 2013 und trug folglich die Nummer 94 [28]. Da die Entwickler zudem einer semantischen Versionierung folgen, hieß sie 94.0.0. Neue Funktionen oder Fehlerkorrekturen, die rückwärtskompatibel sind, führen somit nicht zur Erhöhung der Tagesanzahl.

Das Betriebssystem als Bücherschrank

Sowohl Cirros als auch Container Linux zeigen noch recht deutlich ihre Abstammung von klassischen Linux-Distributionen. Ausgangspunkt für diese abgespeckten und spezialisierten Versionen waren die Server- oder Desktop-Varianten von Linux.

Die Frage, wie viel Betriebssystem in der Cloud noch nötig ist, lässt sich aber auch aus einer anderen Perspektive stellen. Aus dieser stößt der Interessent früher oder später auf Mirage OS [29]. Laut Aussage der Entwickler reichen dessen Anfänge bis ins Jahr 2009 zurück. An die breite Öffentlichkeit trat das Projekt mit Version 1.0 im Dezember 2013. Tatsächlich versteht sich Mirage OS weniger als Betriebssystem und mehr als eine Art Bibliothek.

In diesem Kontext fällt gern auch das Wort Lib OS (Library Operating System) – eine Idee aus den 90er Jahren des vorigen Jahrhunderts ([30], [31]). Die ist radikal: Die Anwendung ist zugleich der zu bootende Betriebssystemkern, quasi der komplette virtuelle Server. Viele Aufgaben eines traditionellen Kernels fallen weg oder sind deutlich reduziert, etwa die Verwaltung des Netzwerks oder des Hauptspeichers. Das eröffnet unter anderem neue Möglichkeiten bei der Auswahl der Programmiersprache.

Mirage OS delegiert möglichst viele Aufgaben an die darunterliegende Schicht. Im Normalfall ist dies ein Hypervisor, es kann aber auch ein traditionelles Linux sein. Mit der aktuellen Version 3 unterstützt Mirage OS sowohl Xen [32] als auch KVM [33]. Hardware-seitig stehen dem Anwender die Architekturen x86 und ARM zur Auswahl, wobei Mirage OS unter der ISC-Lizenz steht. Organisatorisch ist das Cloud-OS als eines der Inkubator-Projekte innerhalb von Xen gelistet [34], Docker kaufte Anfang 2016 allerdings Unikernel Systems, die Firma hinter Mirage OS.

Kamele als Kernthema

Wer Mirage OS als Wolken-Betriebssystem nutzen möchte, muss erst lernen, die funktionale Programmiersprache Ocaml [35] zu beherrschen. Weil der Kernel viele Aufgaben eines traditionellen Kerns nicht wahrnehmen muss, sind C oder C++ als Programmiersprachen nicht mehr unbedingt die erste Wahl. Für die als singuläre Applikation funktionierenden Kerne – auch Unikernel genannt [36] – gibt es eine Tendenz, Programmiersprachen zu verwenden, die nicht so nah an der Hardware und Technik dran sind. Das bringt einige Vorteile.

Im Falle von Ocaml nennen die Entwickler die automatische Speicherverwaltung, die Typenprüfung während des Kompilierens und den modularen Aufbau [36]. Zudem genießt der generierte Maschinencode den Ruf, schnell und effizient zu sein. Für hartgesottene C-Programmierer stellt Ocaml aber womöglich eine große Hürde beim Umstieg auf Mirage OS dar. Ein wichtiges Werkzeug ist der zugehörige Paketmanager Opam [37]. Mit ihm installiert das Wolken-OS die notwendigen Bibliotheken beim Generieren des Unikernels (Listing 1).

01 $ mirage configure --unix
02 Mirage      Using scanned config file: config.ml
03 Mirage      Processing: /home/user/mirage-skeleton/console/config.ml
04 Mirage      => rm -rf /home/user/mirage-skeleton/console/_build/config.*
05 Mirage      => cd /home/user/mirage-skeleton/console && ocamlbuild -use-ocamlfind -tags annot,bin_annot -pkg mirage config.cmxs
06 console     Using configuration: /home/user/mirage-skeleton/console/config.ml
07 console     1 job [Unikernel.Main]
08 console     Installing OPAM packages.
09 console     => opam install --yes mirage-console mirage-unix
10 The following actions will be performed:
11  - install   mirage-unix.2.0.1
12  - install   mirage-console.2.0.0
13 === 2 to install ===
14
15 =-=- Synchronizing package archives -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
16
17 =-=- Installing packages =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
18 Building mirage-unix.2.0.1:
19   make unix-build
20   make unix-install PREFIX=/home/user/.opam/4.01.0
21 Installing mirage-unix.2.0.1.
22 Building mirage-console.2.0.0:
23   make
24   make install
25 Installing mirage-console.2.0.0.
26 console     Generating: main.ml
27 $

Laufen Ocaml und Opam schon auf dem Entwicklungssystem, kann es direkt losgehen. Falls nicht, sei auf die Installationsanleitung [38] verwiesen.

Natürlich gibt es auch das obligatorische Hello-World-Beispiel [39], das sehr lehrreich ist, weil es noch einmal wesentliche Aspekte von Mirage OS erläutert. Das Betriebssystem tickt ja sehr anders als gewohnt. Im ersten Ansatz erläutert die Anleitung, wie die Anwendung die Ausgabe auf eine Konsole bewerkstelligt. Da die Anwendung der Kernel ist, lässt sich die Verwaltung von Geräten für den Eigenbedarf schwer auslagern. Also muss die Anwendung diese Aufgabe wahrnehmen. Die zweite Lektion betrifft den Zugriff auf einfache Datenträger. Im Wolkenumfeld sind das die bekannten Blockgeräte. Die Kür bildet dann der Netzwerkstack inklusive eines einfachen Webservers (Abbildung 4).

Abbildung 4: Ein einfacher Webserver als Unikernel bei Mirage OS.

Mirage OS erlaubt es dem Anwender, das Binary seiner Anwendung in zwei verschiedenen Formaten zu generieren. Der Befehl »mirage configure –unix« erzeugt ein Kompilat als Datei, die traditionelle Linux-Umgebungen als normalen Prozess ausführen (Listing 2). Dank »mirage configure –xen« lässt sich die Anwendung hingegen als Xen-Kernel booten. Für den zweiten Fall findet der Benutzer eine Konfigurationsdatei, die er mit den bekannten »xl«-Kommandos weiterverarbeiten kann. Die entsprechende Datei im XML-Format erzeugt die Mirage-OS-Maschinerie ebenfalls.

01 $ mirage configure --unix
02 [...]
03 $
04 $ make depend
05 [...]
06 $
07 $ make
08 ocamlbuild -classic-display -use-ocamlfind -pkgs lwt.syntax,mirage-console.unix,mirage-types.lwt -tags "syntax(camlp4o),annot,bin_annot,strict_sequence,principal" -cflag -g -lflags -g,-linkpkg main.native
09 [...]
10 ln -nfs _build/main.native mir-console
11 $
12 $ file _build/main.native
13 _build/main.native: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=734e3fc7a56cd83bc5ac13d124e4a994ce39084f, not stripped

Die Beispiele auf der Projektseite von Mirage OS sind schick und funktionieren gut. Eine existierende Anwendung auf diesem Cloud-OS zum Laufen zu bringen, erfordert auf jeden Fall eine neue Implementierung. Neben dem Schreiben der eigentlichen Anwendung muss der Entwickler sich auch noch um den Zugriff auf Blockgeräte und das Netzwerk kümmern. Dies – kombiniert mit einer eventuell neuen Programmiersprache – ist kein geringer Preis.

Dies und das

Der Ansatz von Mirage OS ist schon recht einschneidend und geht manchen Cloudbetreibern vielleicht zu weit. Es geht auch sanfter. Ein weiterer bekannter Vertreter aus dem Unikernel-Lager ist OSv [40], andere Kandidaten listet die Webseite unter [41] auf.

Die neuen Rumpfsysteme, das schließt Cirros und Container Linux ein, stoßen auch bei Sicherheitsexperten auf Interesse. Der abgespeckte Userspace verringert die Angriffsfläche für potenzielle Angreifer. Die schlanke Softwareverwaltung verringert die Chance auf ein Sicherheitsloch durch prozeduralen Bürokratismus oder simple technische Probleme bei der Aktualisierung.

Was aber im Userspace funktioniert, lässt sich nicht ohne Weiteres auf den Betriebssystemkern übertragen. Abstrakt betrachtet ist das Entschlacken schon möglich. Die einfachste Variante wäre das Erzeugen eines angepassten Kerns, der nur die notwendige Software und Konfiguration enthält.

Die Unikernel gehen aber noch einen Schritt weiter. Hier stehen sogar die Zutaten und das Rezept für das Bauen eines Kernels auf dem Prüfstand. Manch einer mag in die Waagschale werfen, dass etwas exotische Systeme schwerer angreifbar sind, weil es weniger Werkzeuge gibt und das notwendige Wissen fehlt. Das ist allerdings ein zweischneidiges Schwert. Gibt es weniger Anwender und Experten, ist das Risiko einer unentdeckten Sicherheitslücke ebenfalls größer. Wirklich relevant sind tatsächlich die verringerte Angriffsfläche, weniger aktive Funktionen und eine vereinfachte Softwareverwaltung.

Fazit

Cloud und Container haben den Bedarf nach weiteren neuen quelloffenen Betriebssystemen geweckt. Manche davon stehen noch dem klassischen Linux recht nahe, andere wiederum starten auf der grünen Wiese und ignorieren jeglichen historischen Ballast. Mit Cirros und Container Linux hat der Artikel zwei Kandidaten aus der ersten Kategorie vorgestellt. Mirage OS (oder auch OSv) gehören eher zur Generation “Wir fangen von vorne an”.

Zwar lassen sich keine generellen Empfehlungen für IT-Landschaften aussprechen. Doch die jüngeren Betriebssysteme zeigen klar, dass sich die Randbedingungen geändert haben. Das Studium der Implementierungen von Cirros, Container Linux oder Mirage OS kann dabei Ideen und neue Ansätze liefern.