© Sergey Nivens, 123RF

Open-Source-Software spielt in der Cloud zwar die erste Geige, doch als Betriebssystem fehlt manchem Linux die Leichtigkeit, um in die Sphären aufzusteigen. Cloudbetriebssysteme wollen Anwendungen in der Rechenwolke schlank machen, das Linux-Magazin stellt vielversprechende Anwärter vor.

Als “quelloffenes Betriebssystem für die Cloud” geht mittlerweile einiges durch. Das weiß, wer versucht hat, den Begriff zu googeln. Geht es aber um Kandidaten, die im Rechenzentrum laufen und Webanwendungen ausliefern sollen, wird die Luft überraschend dünn.

Drinnen oder draußen

Der Artikel betrachtet spezielle Vertreter der Gattung Cloud-OS. Generell zerfallen die Fundstücke zu den Cloudbetriebssystemen grob in drei Kategorien. Da sind die Desktop-artigen Systeme. Zu ihnen gehören etwa Chromium OS [1] oder auch das inzwischen eingestellte Joli OS [2], ihnen widmet sich der Kasten “Quelloffen und wolkenartig”.

In eine zweite Kategorie fallen Technologien, die die Betriebssystemschicht außen vor lassen, um sich auf die Virtualisierungsebene zu konzentrieren. Bekannte Vertreter sind Smart OS [3] und Zero VM [4], zu denen der erwähnte Kasten auch Details beisteuert.

Die dritte Kategorie besteht aus Systemen, die den in der Einführung genannten Ansatz verfolgen. Es sind quelloffene Betriebssysteme, die zwar primär für den Einsatz als Gäste in der Wolke trainiert sind, sich prinzipiell aber auch im Rechenzentrum zu Hause fühlen. Sie bilden die Basis für die eigentlichen (Web-)Anwendungen und kommen diesen möglichst wenig in die Quere.

Die Grenzen zwischen den Kategorien fließen, in der Praxis sind die Kandidaten weniger klar voneinander getrennt. Für diesen Artikel besteht das Teilnehmerfeld aus OSv [5], Mirage OS [6] und Cirros [7]. Auch dazu zählt neben Core OS [8], dem das Linux-Magazin kürzlich [9] einen Artikel widmete, auch die Jeos-Familie (Just enough operating system, [10]). Zu ihr liefert der Kasten “Saftiges Linux” Details. Am Ende stellt der Artikel noch zwei neue, Docker-zentrierte Systeme von Canonical und Red Hat vor.

Der neue Star – OSv

OSv ist ein noch recht junges Projekt, die Erstausgabe erschien im September 2013. Ein Blick in das Git-Log zeigt, dass der erste Eintrag vom 1. Dezember 2012 stammt. Dennoch avancierte OSv auf der Linuxcon Europe 2013 in Edinburgh bereits zu einem kleinen Star. Kein Wunder, sind die Leute hinter OSv – Cloudius Systems [11] – doch keine Unbekannten. CEO Dor Laor und CTO Avi Kivity Kennern gelten der Szene als Väter von KVM [12]. Hinzu kommt Glauber Costa, der eine wichtige Rolle in der Linux-Virtualisierung gespielt hat.

OSv versteht sich als minimalistische Schicht zwischen dem Hypervisor und einer Cloudanwendung, eine Installation und der Betrieb auf echter Hardware sind nicht vorgesehen. Ein Teil des Erfolgs beruht darauf, dass sich das Betriebssystem lokal installieren lässt, wofür der Anwender zwischen KVM, Xen [13], VMware [14] oder Virtualbox [15] als Unterbau wählt. Daneben funktioniert OSv auch in bekannten öffentlichen Clouds wie der Amazon Elastice Cloud (EC2) oder in Googles Compute Engine (GCE).

Die radikal reduzierte Betriebssystemschicht von OSv soll wesentlich zwei Aufgaben erfüllen: unter einem nahezu beliebigen Hypervisor laufen und als Plattform für die eigentliche Cloudapplikation dienen. Auch hier ist Minimalismus Programm: Die Laufzeitumgebung für eine Posix-kompatible C++-Anwendung darf schlank sein, Analoges gilt für Java oder Ruby. Weitere Aufgaben muss das Betriebssystem nicht erledigen.

Die Entwickler sind jedoch noch einen Schritt weitergegangen. Sie haben OSv von Grund auf neu geschrieben, wobei die Wahl, anders als beim traditionellen Linux, auf C++ als Programmiersprache fiel. Verschiedene andere Open-Source-Projekte standen dabei Pate für den Programmcode des Cloudbetriebssystems, zu nennen sind hier Free BSD [16], Open Solaris [17], Prex [18] und Musl [19]. Für diese Bestandteile gelten die jeweiligen Lizenzen des Ursprung-Quelltextes, der Rest von OSv steht unter der 3-Clause-BSD-Lizenz.

Einfach genug

OSv verzichtet auf ein Nutzerkonzept, alle Prozesse laufen quasi im Kernelspace. Das macht das System schlanker und schneller, weil beispielsweise Kontextwechsel zwischen Kernel- und Userspace wegfallen und es nicht zwischen verschiedenen Applikationen umschalten muss. Qua Design soll OSv nur eine einzige Anwendung – streng genommen einen Prozess – ausführen.

Auch die Laufzeitumgebung für Java-Anwendungen profitiert davon, dass OSv Prozesse in den Kernelspace verlegt, da die Java Virtual Machine (JVM) fast ein Bestandteil des Kernels ist. Indem OSv Teile der Speicherverwaltung direkt weiterreicht, muss die JVM keine Schnittstellen wie »mmap()« verwenden.

Damit aber noch nicht genug. OSv verzichtet nicht nur auf Spinlocks [20], die Entwickler vermeiden Locks generell. Wo dies nicht möglich ist, kommt eine spezielle Mutex-Variante [21] zum Einsatz. Dieses Vorgehen weiten sie auch auf den Netzwerkstack aus, für den die OSv-Entwickler auf das Kanalkonzept von Van Jacobson [22] setzen. Aus der Free-BSD-Ecke haben sie die Datenträgerverwaltung übernommen, daher überrascht es nicht, ZFS [23] vorzufinden. Die Pseudodateisysteme »/proc« und »/dev« sind zwar vorhanden, aber nahezu leer.

Das Thema Sicherheit haben die OSv-Entwickler komplett an das darunterliegende Hostsystem delegiert. Das Resultat ist ein Betriebssystem, das lediglich 30 MByte groß ist (Listing 1). Zum Vergleich: Schon allein ein “handelsüblicher” Desktop-Linux-Kernel belegt in Binärform und ohne Module auf der Festplatte locker 5 MByte. OSv ist ein 64-Bit-Betriebssystem und in der x86-Welt zu Hause. Doch die Entwickler arbeiten bereits am ARM-Support, der recht weit fortgeschritten ist.

01 $ du -sh osv-base.qemu
02 29M     osv-base.qemu
03 $ qemu-img info osv-base.qemu
04 image: osv-base.qemu
05 file format: qcow2
06 virtual size: 10G (10842275840 bytes)
07 disk size: 29M
08 cluster_size: 65536

Da OSv deutlich anders gestrickt ist als ein traditionelles Linux (oder Free, Net, Open BSD), fragt sich ein Admin natürlich, wie er ein System verwaltet, das keine Benutzer kennt, bei dem alles im Kernelspace läuft und das nur für eine einzelne Anwendung ausgelegt ist. Der Nutzer wiederum möchte wissen, wie er seine Lieblingsanwendung auf OSv zum Laufen bekommt.

Zum zweiten Punkt lässt sich sagen, dass das Cloudbetriebssystem die meisten Linux-ABIs (Application Binary Interface) implementiert [24]. Doch fordern die oben geschilderten Designentscheidungen ihren Tribut. Ohne Benutzerkonzept fallen Multiuser-Anwendungen schon mal raus. Systemaufrufe wie »fork()« , »vfork()« und »clone()« funktionieren ebenfalls nicht – es soll ja nur ein Prozess laufen. Schließlich muss die auszuführende Anwendung in einem bestimmten Format vorliegen, auch bekannt als »Relocatable Shared Object« [25].

OSv sucht im Objektcode nach der Hauptfunktion »main()« und führt diese aus. Der Linux-Anwender kennt das von den Bibliotheken seines Systems, Abbildung 1 zeigt eine Variante des berühmten “Hello World”-Beispiels für OSv [29].

Abbildung 1: Die “Hello World”-Variante für OSv. Die auszuführende Anwendung liegt als ».so«-Datei vor.

Die Anwendung legt der Admin nun in einem OSv-Image ab. Hier führt die Dokumentation allerdings etwas in die Irre, denn in vielen Fällen gibt sie das Wurzelverzeichnis als Standardablage an. In den aktuellen Versionen von OSv ist es aber das Verzeichnis »/tools« . Anschließend konfiguriert er das Image noch so, dass die Anwendung es beim Start ausführt – fertig. Das Resultat ist eine OSv-Instanz (Image plus Anwendung).

In der Praxis fällt es einem Admin jedoch gar nicht so leicht, die beschriebenen Schritte umzusetzen. Möchte er die Anwendung ablegen, scheitert er womöglich bereits am fehlenden Support für die richtige ZFS-Version. Alternative Ansätze wie »scp« ändern das grundlegende Bild nicht, zudem widerspricht dies dem Anspruch auf ein einfach zu benutzendes Wolken-Betriebssystem. Hier springt das Werkzeug »capstan« in die Bresche – dazu gleich mehr.

Für Java-Anwendungen geht der Admin analog vor, die Java Virtual Machine muss dazu ebenfalls im Objektcode vorliegen. Den Start unter OSv leitet der Admin dann ungefähr so ein: »/tools/java.so -jar app.jar« .

Für einige Anwendungen gibt es übrigens vorgefertigte OSv-Instanzen. Dazu zählen Tomcat [30], Redis [31], Memcached [32] und Cassandra [33]. Auf Java-Freunde warten Instanzen mit den Open-JDK-Versionen 7 und 8. Wer tiefer in die Materie einsteigen möchte, sei auf die Wiki-Seite [34] des Projekts verwiesen.

Docker-Style

Wie erwähnt ist »capstan« [35] das Verwaltungswerkzeug für OSv und steht gleichfalls unter der 3-Clause-BSD-Lizenz. Es ist dem aufmerksamen Leser womöglich schon in Abbildung 1 aufgefallen. Bereits die ersten Gehversuche zeigen eine gewisse Verwandtschaft mit dem Docker-Werkzeug »docker« [36], die beabsichtigt ist.

Ein Teil des Erfolgs von »docker« besteht darin, dass es Container und davon abgeleitete Instanzen komfortabel dirigiert. Analoges wollen die Entwickler mit »capstan« für OSv erreichen. Die Installation ist denkbar einfach und legt ein kleines Binary im »$HOME/bin« -Verzeichnis des Anwenders ab. Die wichtigsten Kommandos listet Tabelle 1 auf.

Doch noch immer braucht der Admin zumindest drei Schritte, um eine OSv-Instanz mit der gewünschten Anwendung anzulegen. Er lädt das Basis-Image herunter (»pull« ), integriert die Applikation (»build« ) und startet die eigentliche Instanz (»run« ).

Capstan-Style

Zum Glück gibt es einen deutlich einfacheren Weg. Das Werkzeug »capstan« lässt sich bequem über die Datei »Capstanfile« steuern, Listing 2 zeigt den Inhalt und die Ausführung für das weiter oben gezeigte “Hello World”-Beispiel. Als Repository für die verschiedenen Images dient einfach die Github-Seite des Projekts [37]. Das Kommando »capstan pull Name« sucht nach den entsprechenden Daten unter »http://github.com/Name« . Ein OSv-Image mit Shellzugriff lädt der OSv-User mittels »capstan pull cloudius/osv« herunter. Als lokales Repository dient »$HOME/.capstan/« , die Images liegen dort im Unterverzeichnis »repository« . Fertige OSv-Instanzen findet der Admin unter »$HOME/.capstan/instances/« .

01 $ cat Capstanfile
02 base: cloudius/osv-base
03
04 files:
05   /tools/hello.so: hello.so
06
07 cmdline: /tools/hello.so
08
09 $ time ~/bin/capstan run
10 Building capstan-example...
11 Uploading files...
12 1 / 1 [===...===] 100.00 % Created instance: capstan-example
13 OSv v0.16
14 eth0: 192.168.122.15
15 Hallo Linux-Magazin!
16
17 real    0m4.116s
18 user    0m1.536s
19 sys     0m0.741s

Die in Yaml [38] geschriebenen Datei benötigt lediglich drei Einträge. Welches OSv-Image als Basis dient, legt der Parameter »base« fest. Die zu kopierenden Dateien beschreibt »files« . Über »cmdline« bestimmt der Admin, welche Anwendung beim Booten der OSv-Instanz startet. Im Beispiel von Listing 2 legt er einfach »Capstanfile« und »hello.so« in einem Verzeichnis ab und ruft »capstan run« auf.

In dem einfachen Beispiel braucht der Download des 30-MByte-Image die meiste Zeit beim Instanzieren. Ein Beispiel dafür, wie der Cloudbetreiber einen simplen Webserver aufsetzt, liefert [39]. Es zeigt, wie er die Webapplikation mit Hilfe der Datei »Capstanfile« kompiliert, in den Tests des Linux-Magazins funktionierte dieser Weg allerdings nicht. Grob vereinfach generiert der Administrator die OSv-Instanz also in drei Schritten: Er schreibt die Applikation einschließlich des »Makefile« , er legt die Datei »Capstanfile« an und er ruft abschließend »capstan run« auf.

Das Beste zum Schluss

Zum Abschluss seien noch zwei Schmankerln genannt. Erstens kann der Anwender über das via HTTP-Port 8000 zugängliche Dashboard [46] nützliche Statistiken über die OSv-Instanz abrufen. Dort findet er Informationen über CPU-, Speicher- und Festplattenauslastung (Abbildung 2). Auf Wunsch liest er die Daten zu einzelnen Threads aus oder nutzt einen RESTful-Zugriff auf OSv-Interna. Daneben setzt er auch Kommandos wie »reboot« oder »dmesg« ab.

Abbildung 2: Das OSv-Instanz-Dashboard erlaubt dem Admin per Browser einen tiefen Einblick in die Systemaktivitäten von OSv.

Das zweite Schmankerl ist die eingebaute Kommandozeilen-Schnittstelle [47]. Gestandene Linux-Admins atmen hier üblicherweise auf, da einige der vertrauten Befehle auftauchen (Listing 3).

01 /# help
02 COMMAND DESCRIPTION
03 api     execute arbitrary OSv API operations as                      defined by the schema
04 cat     concatenate files and print on the standard          output
05 cd      change the shell working directory
06 date    print the system date and time
07 df      report file system disk space usage
08 dmesg   print operating system boot log
09 echo    display a line of text
10 exit    close shell and exit
11 free    display amount of free and used memory in                    system
12 hello   a command example
13 help    list console available commands and show help
14 ls      list directory contents
15 mkdir   make directories
16 reboot  reboot an OSv instance
17 rm      remove files or directories
18 top     display OSv threads

Das muss man OSv lassen: Es ist schnell und schlank und auf den Gastbetrieb in der Wolke zugeschnitten. Die Verwaltung mit »capstan« ist denkbar einfach. Als größte Herausforderung wartet die Integration der eigenen Cloudanwendung auf den Admin. Doch die weiter oben erwähnten vorgefertigten Images erleichtern den Einstieg erheblich.

Klein, aber fein – Cirros

Neben OSv ist Cirros [7] nahezu unscheinbar. Das drei Jahre alte Projekt, dessen erste öffentliche Version 0.3.0 im Oktober 2011 erschien, liegt inzwischen in Version 0.3.3 vor. Der Quelltext steht unter der GPLv2. Das kleine Cloudbetriebssystem setzt sich aus zwei Bausteinen zusammen: einem Ubuntu-Kernel und Buildroot [48].

Letzteres ist eigentlich dafür vorgesehen, ein Linux-System für den Embedded-Bereich zu erzeugen, in dem Platz für ein Luxus ist und ein möglichst schlankes Betriebssystem eine extrem wichtige Rolle spielt. Diese Anforderung trifft aber auch auf Cloudsysteme zu, die den Betriebssystem-Anteil möglichst klein halten möchten.

Der Einsatz eines Ubuntu-Kernels verwundert nicht, wenn man weiß, dass Scott Moser hinter Cirros steckt, der hauptberuflich bei Canonical als technischer Leiter im Serverbereich arbeitet [49]. Aktuell gibt es Images für 32- und 64-Bit-Systeme der Intel/AMD-Welt. ARM wird ebenfalls unterstützt, aber noch nicht mit einer 64-Bit-Version.

Cirros ist etwas anders ausgerichtet als OSv. Die Entwickler verstehen ihr Cloudbetriebssystem primär als Werkzeug für Tests oder wollen damit Probleme untersuchen. Open Stack [50] beispielsweise nennt Cirros in seiner Dokumentation offiziell als Test-Image [51], Ähnliches gilt für Eukalyptus [52].

Vorhang auf

Ein aktuelles Festplattenabbild mit vorinstalliertem Cirros braucht weniger als 15 MByte Speicherplatz. Die meiste Zeit verbringt der Bootprozess mit dem Initialisieren des Kernels. Zur Erinnerung: Dieser stammt unmodifiziert von Ubuntu, aktuell von Version 12.04, demnächst wohl von der 14.04. Das Cloudbetriebssystem ist letztlich ein verschlanktes Linux und verhält sich damit analog zu seinen großen Brüdern und Schwestern. Qemu kann es einfach lokal starten (Abbildung 3) und testen.

Abbildung 3: Cirros ist eine kleines Linux, der Bootvorgang enthält keine Überraschungen.

Das Cloud-OS ist mit einer Reihe von Helferlein ausgestattet, die allesamt mit »cirros-« beginnen, Tabelle 2 listet sie mit je einer kurzen Erklärung auf. Alle Kommandos sind Shellskripte und erlauben so prinzipiell einen einfachen Blick hinter die Kulissen. Allerdings sind sie nicht sonderlich gut dokumentiert – weder im Code selbst noch auf der Webseite des Projekts.

Als Initsystem dienen erst das traditionelle Sys-V-Init, zum Schluss Cirros-spezifische Skripte. Die sind so angelegt, dass sie mit dem Cloud-Init-Gerüst [53] funktionieren. Die zugehörigen Konfigurationsdateien befinden sich unter »/etc/cirros-init/« . Im Lieferumfang enthalten sind Vorlagen für Amazons EC2, ein so genanntes Konfigurationslaufwerk (»config-drive« ) oder eine lokale Startmöglichkeit – also ohne Cloud [54].

Was auf den ersten Blick wie unnötiger Aufwand aussieht, ist tatsächlich recht nützlich. So testet der Anwender den kompletten Ablauf, prüft, wie er eine Cloudinstanz anlegt und hochfährt, und betrachtet die Postinstall-Skripte.

Wie schon angedeutet, es warten unter der Motorhaube von Cirros keine Überraschungen. Zur Datenablage dient das fast schon altehrwürdige Ext 3. Dass Cirros Busybox [55] für die meisten ausführbaren Programme und Dropbear [56] als SSH-Daemon verwendet, ist eigentlich eine Konsequenz aus dem Buildroot-Unterbau. Der gestandene Linux-Admin sollte sich hier leicht zurechtfinden, es ist eben “nur” ein Linux. Die Entwickler überlegen allerdings, einen neuen Untersatz einzusetzen, im Gespräch sind Tiny-Core-Linux [57] und Yocto [58].

Der Fremde – Mirage OS

Glaubt man den Angaben der Entwickler, reichen die Anfänge von Mirage OS bis ins Jahr 2009 zurück. An die breite Öffentlichkeit trat das Projekt aber erst mit Version 1.0, die im Dezember 2013 erschien. Analog zu OSv geht dieses Cloudbetriebssystem einen ganz neuen Weg. Tatsächlich versteht sich Mirage OS gar nicht als Betriebssystem, sondern eher als eine Art Bibliothek [59]. Nicht zufällig fällt auch das Wort “Lib OS” (Library Operating System) – eine Idee aus den 90er Jahren [60].

Die Grundidee ist noch radikaler als die von OSv. Die Anwendung fungiert zugleich als 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.

Mirage OS delegiert möglichst viele Aufgaben an die darunterliegende Schicht. Im Normalfall ist dies ein Hypervisor, aktuell nur Xen, es darf aber auch ein traditionelles Linux sein. Für KVM-Support gibt es keine Pläne, allenfalls Ideen [61]. Mirage OS steht unter ISC-Lizenz, organisatorisch ist das Cloud-OS als eines der Inkubator-Projekte im Xen-Projekt gelistet. Natürlich zählte x86 zu den unterstützten Plattformen der ersten Stunde, seit Version 2.0 vom Juli 2014 kommt auch ARM zum Zug [62].

Kamele als Kernthema

Wer Mirage OS als System der Wahl für die Cloud betrachtet, muss sich mit der Programmiersprache Ocaml [63] befassen. Weil der Kernel viele Aufgaben eines traditionellen Kerns nicht wahrnimmt, sind C oder C++ als Programmiersprachen nicht unbedingt die erste Wahl.

Für die als singuläre Applikation funktionierenden Kerne – auch Unikernel genannt – gibt es eine Tendenz, Programmiersprachen zu verwenden, die nicht so nah an der Hardware sind. Das bringt einige Vorteile. Im Falle von Ocaml nennen Entwickler die automatische Speicherverwaltung, die Typenprüfung während des Kompilierens und den modularen Aufbau [64]. Zudem genießt der generierte Maschinencode den Ruf, schnell und effizient zu sein. Für hartgesottene C-Programmierer ist Ocaml hingegen schon eine große Hürde beim Einstieg in Mirage OS.

Ein wichtiges Werkzeug ist der zugehörige Paketmanager Opam [65]. Er ermöglicht es, die notwendigen Bibliotheken beim Generieren des Unikernels zu installieren (Listing 4). Sind Ocaml und Opam auf dem lokalen Entwicklungssystem installiert, kann es direkt losgehen. Anderenfalls sei auf die Installationsanleitung [66] verwiesen. Natürlich fehlt auch das obligatorische “Hello World”-Beispiel [67] nicht. Es ist auch deshalb lehrreich, weil es nochmals wesentliche Aspekte von Mirage OS erklärt.

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 =-=- Synchronizing package archives -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
15 =-=- Installing packages =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
16 Building mirage-unix.2.0.1:
17   make unix-build
18   make unix-install PREFIX=/home/user/.opam/4.01.0
19 Installing mirage-unix.2.0.1.
20 Building mirage-console.2.0.0:
21   make
22   make install
23 Installing mirage-console.2.0.0.
24 console     Generating: main.ml

Zunächst erläutert die Anleitung, wie die Anwendung eine Konsole für Ausgaben nutzt. Da die Anwendung zugleich der Kernel ist, muss sie auch Geräte für den Eigenbedarf verwalten. Folgerichtig beschäftigt sich die zweite Lektion mit dem Zugriff auf einfache Datenträger. Im Cloudumfeld sind das die bekannten Blockgeräte. Die Kür ist 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. Mit »mirage configure –unix« ist das Kompilat eine Datei, die er einfach in einer traditionellen Linux-Umgebung als normalen Prozess ausführt (Listing 5). Analog leitet »mirage configure –xen« in die Wege, dass die Anwendung sich als Xen-Kernel booten lässt. Im zweiten Fall findet der Benutzer eine Konfigurationsdatei, die sich mit den bekannten »xl« -Kommandos weiterverarbeiten lässt, die zum Kommandozeilen-Toolstack gehören, der auf der Libxenlight basiert. Auch wer Libvirt [68] einsetzt, steht nicht im Regen. Die entsprechende Datei im XML-Format erzeugt die Mirage-OS-Maschinerie ebenfalls.

01 $ mirage configure --unix
02 [...]
03 $ make depend
04 [...]
01 $ make
02 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
03 [...]
04 $ ln -nfs _build/main.native mir-console
05 $ file _build/main.native
06 _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 der Projektseite sind schick und funktionieren gut. Eine existierende Anwendung auf Mirage OS zu bringen, erfordert auf jeden Fall eine neue Implementierung. Neben dem Kodieren der Applikation muss der Entwickler sich auch um den Zugriff auf Blockgeräte und das Netzwerk kümmern. Dies – kombiniert mit einer eventuell neuen Programmiersprache – ist kein geringer Preis.

Neue Wege

Kurz vor Redaktionsschluss erschienen zwei Versionen einer neuen Art von Cloudbetriebssystemen, die Container-Technologien wie Docker [36] unterstützen wollen. Das eingesetzte Betriebssystem dient nicht mehr direkt als Fundament für Anwendungen, sondern hostet vielmehr eine Docker-Instanz.

Es lassen sich gewisse Parallelen zu OSv oder Mirage OS erkennen. Die Docker-Schicht entspricht dabei ungefähr dem neuen schlanken Kernel beziehungsweise dem Lib OS oder auch Unikernel. Der Containerinhalt wäre dann die Komponente, die schnell starten und möglichst schlank sein soll.

Atomic und Snappy

Wer mit Container-Technologie arbeitet, hat wahrscheinlich von Fedoras Projekt Atomic [69] gehört oder gelesen. Das möchte Docker und das ganze Drumherum auf den Einsatz im harten Produktionsalltag vorbereiten. Ein Aspekt ist dabei das Setup des Hosts, bei dem es sich um eine abgespeckte Version von Fedora, Centos oder RHEL mit Optimierungen für Docker handelt.

Mit Version 21 führte das Fedora-Projekt Produkttypen für die Distribution ein, wie man sie von Red Hat Enterprise Linux kennt (siehe Fedora-Artikel in diesem Magazin). Eine der Produktvarianten heißt Cloud [42]. In ihr findet der Admin neben einem verschlankten Standard-Fedora auch eine Atomic-Implementierung. Die setzt auf atomare Updates und benutzt dazu Mechanismen aus Gnomes OS-Tree-Projekt [70].

Beide Images laufen direkt bei AWS (Abbildung 5). Auf der Webseite gibt es sogar einen Mechanismus, den Atomic-Host direkt in EC2 zu instanzieren, ohne Einsatz der AWS-Console.

Abbildung 5: Fedoras Atomic Cloud Image lässt sich unter anderem in Amazons EC2 einsetzen.

Der zweite Mitspieler in dieser Cloud-OS-Kategorie ist Canonical mit Snappy Ubuntu Core [71]. Die jüngst veröffentlichte Betaversion verwendet nicht mehr Debians Paketsystem für Updates, sondern setzt das so genannte Snappy-System ein, das auf dem Paketsystem Click [72] aufbaut, Yaml-Syntax und App-Armor verwendet und Software-Updates als Diffs ausliefert.

Generell haben die Entwickler kräftig am Betriebssystem herumgeschraubt. Der Anwender findet nun drei Schichten vor. Ganz unten werkelt noch immer das altbekannte Linux, allerdings in einer auf das Allernotwendigste abgespeckten Variante. Was eine bestimmte Anwendung als Unterbau benötigt, das ist in so genannten Frameworks zusammengefasst, welche die mittlere Schicht ausmachen. Die Anwendung selbst kommt dann oben drauf. Der Admin verwaltet jede der drei Schichten separat.

Das erste verfügbare Framework für Ubuntu Core ist Docker, für das sich Snappy laut Erläuterungen der Projektwebseite insbesondere eigne. Zum gegenwärtigen Zeitpunkt lässt sich Snappy Ubuntu Core auch einfach in Microsofts Azure starten (Abbildung 6).

Abbildung 6: Das Anfang Dezember 2014 veröffentlichte Snappy Ubuntu Core liegt bislang nur in einer Betaversion vor. Die läuft allerdings bereits in Microsofts Cloudumgebung Azure.

Nicht zuletzt gibt es Parallelaktivitäten des Docker-Projekts selber. Der CTO Solomon Hykes präsentierte im Rahmen der Dockercon Europe 2014 in Amsterdam Machine [73]. Dieses frisch geschlüpfte Projekt erstellt einen Host, der lokal aber auch in der Cloud laufen kann. Microsoft Azure und Digital Ocean zählen zu den unterstützten Anbietern.

Krönender Abschluss

Die drei zuerst vorgestellten Kandidaten vertreten unterschiedliche Ansätze, um Anwendungen flink und schnell in der Cloud zu betreiben. Mirage OS bricht mit den meisten Traditionen. Die Anwendung ist der Betriebssystemkern und die Entwicklung erfolgt in Ocaml. Bei OSv läuft alles im Kernelspace, hier findet der Admin aber eine Umgebung im ELF-Format vor.

Beide Systeme sehen nur eine Anwendung pro virtueller Instanz vor. Sie verfolgen in verschiedenen Bereichen neue Konzepte, um die Performance zu verbessern und das traditionelle Betriebssystem auf das Nötigste zu reduzieren. Der Aufwand, um eine Cloudanwendung neu zu entwickeln, ist bei Mirage OS aber deutlich höher als bei OSv.

Cirros versucht hingegen, eine Brücke zwischen der alten und der neuen Welt zu schlagen. Es ist ein klassisches Linux, wenn auch ein minimalistisches, was es dem Admin in vielen Dingen einfacher macht. Als Mini-Linux lässt es die großen Brüder und Schwestern in Sachen Bootzeit und Betriebssystem-Overhead locker hinter sich.

Alle drei vorgestellten Systeme haben ihre Vor- und Nachteile. Am revolutionärsten dürfte Mirage OS sein. Die fehlende Unterstützung für KVM ist jedoch ein schweres Erbe. OSv scheint ein guter Mittelweg zwischen Heute und Morgen zu sein. Erlaubte es das Ausführen normaler Linux-Binaries, könnte das für zusätzlichen Aufwind sorgen. Cirros spielt seine Stärken bei eher traditionellen Anwendungen aus.

Für die Zukunft könnte sich der noch junge Docker-Ansatz als recht interessant erweisen. Eigentlich zählen aber das darunterliegende Linux und Docker eher zur Infrastruktur, analog zum Hypervisor. Das schnelle Aufsetzen von Anwendungen beginnt erst mit dem Initiieren der Container-Instanzen.

Der Ansatz hilft dem Container-Projekt aber, indem er es vereinfacht, Hosts anzulegen, was den Start optimiert. Der Admin muss sich jedoch Gedanken darüber machen, wie er die einzelnen Komponenten von Atomic-Cloud oder Ubuntu Core zuordnet.