© Anna Khomulo, 123RF

Cgroups und Namespaces sind unter Linux das Nonplusultra, wenn es um Container-Technologien geht. Deshalb fußen auch gleich mehrere ganz neue Ansätze auf dieser Technik. Und alle versprechen eine Fülle nie gesehener Vorteile. Was ist dran?

Seit Docker das Tagesgespräch dominiert, sagen nicht wenige Beobachter der Virtualisierung mit KVM oder Xen sinkende Nutzerzahlen voraus. Ob diese Prophezeiung eintritt, wird sich erst mit der Zeit zeigen. Auf jeden Fall haben Container gute Argumente auf ihrer Seite. Beispielsweise spricht die hohe Dichte virtueller Umgebungen auf dem Virtualisierungs-Host für sie. Im direkten Vergleich mit Vollvirtualisierern haben hier Container klar die Nase vorn.

Mit steigendem kommerziellen Interesse an Containern ist auch die Zahl der auf dem Markt verfügbaren Lösungen kontinuierlich gewachsen: Anfangs stritten LXC und Docker um die Gunst der Nutzer. Mittlerweile bietet VMware einen eigenen Container-Ansatz (Photon), ebenso Core OS, das sich von Docker losgesagt hat. Canonical führt in Form von LXD ein drittes Produkt ins Feld und auch Docker selbst will mitreden.

Für den Admin ist auf den ersten Blick also gar nicht erkennbar, auf welche Lösung er für seine Einsatzbereiche setzen soll. Das Linux-Magazin gibt einen Überblick über die neuesten Ansätze und erklärt, welcher am besten zu welchem Einsatzzweck passt.

Der Klassenprimus: Docker

Dass Docker ([1], Abbildung 1) in der Riege der “jungen Wilden” genauso mitspielt wie bei den etablierten Lösungen, ist leicht zu erklären: Keine andere Container-Lösung hat in den vergangenen Jahren so viel Aufmerksamkeit auf sich gezogen. Bei keiner ist das Wachstum an Features so rasant. Und keine andere Lösung hat in so kurzer Zeit so viele Kritiker auf sich gezogen wie Docker. Rocket, LXD und Photon OS nehmen ausdrücklich jeweils für sich in Anspruch, ganz anders zu sein als Docker.

Abbildung 1: Docker ist der Klassenprimus in Sachen Container, doch mittlerweile auch viel mehr als ein einfacher Container-Standard.

Technisch betrachtet fallen bei Docker gleich mehrere Details auf. Da ist zunächst der Umstand, dass Docker mittlerweile den Betrieb von Containern mit einer eigenen Bibliothek abwickelt, der Libcontainer. Die war nicht von Anfang an Bestandteil der Lösung; bis Version 0.9 setzte Docker direkt auf LXC, um Container zu starten und zu verwalten. Dass man sich dennoch für eine eigene Container-Plattform entschieden hat, lag am Fehlen verschiedener Features auf Seiten von LXC. Libcontainer dokumentiert im Grunde den Projekt-Anspruch, ein universelles Container-Format für Linux zu schaffen, an das sich andere Lösungen anhängen können.

Der zweite wichtige Punkt bei Docker besteht darin, dass es die alleinige Herrschaft über die Container für sich beansprucht. Auf jedem Host läuft ein eigener Docker-Dienst, dessen Kindprozesse die Container sind. Will der Admin einen Docker-Container starten, setzt er einen entsprechenden CLI-Befehl ab, der beim Docker-Daemon auf dem jeweiligen Host landet. Der Docker-Daemon startet den Container, sorgt dafür, dass er wie gewünscht läuft, und ist schließlich auch dafür verantwortlich, den Container auf Zuruf des Admin zu löschen.

Docker-Fans halten gerade dieses umfassende Lifecycle-Management für eine Schlüsselqualifikation. Sobald auf einem Host die Docker-Binaries installiert sind, kann es losgehen. Und weil im Netz eine große Menge von Docker-Containern verfügbar ist, dauert es bis zum ersten laufenden Container nicht lange.

Damit kommt Docker heute hauptsächlich dort zum Einsatz, wo es darum geht, fertige Container mit vorinstallierter Software im Stile von PaaS zu betreiben. Der Entwickler einer Software bietet einen passenden Container an, den der Nutzer runterlädt und startet. Damit ist schon alles getan. Die einzelnen Docker-Komponenten sind dabei so eng miteinander verwoben, dass es für externe Lösungen so gut wie unmöglich ist, sich in den Prozess noch sinnvoll einzuklinken.

Auf der Suche nach Wechselgründen hin zu Docker-Alternativen sticht gerader dieser Punkt hervor. Und liefert die Rechtfertigung für den ersten Probanden im Überblick: Rocket.

Core OS und Rocket

Dass Core OS in die Riege von Container-Anbietern aufsteigen würde, das schien noch vor einem Jahr praktisch undenkbar. Eigentlich widerspricht das auch der Idee, der sich Core OS verpflichtet fühlt: Core OS versteht sich in erster Linie als Werkzeug, um den Betrieb von Containern im Flottenverbund zu organisieren. Container sind ja zunächst an den Host gebunden, auf dem der Nutzer sie gestartet hat.

Dabei fällt der Faktor Cloud praktisch unter den Tisch: Werkzeuge, die das komfortable Starten von mehreren Containern gleichzeitig ermöglichen und die diese Container dann auch gleich auf mehrere Hosts verteilen, sind im Linux-Kernel bislang gar nicht vorgesehen. Selbst Docker enthält bis heute keine Funktion, die so etwas ermöglicht.

Das Core-OS-Projekt ist ein Beispiel für nachgerüstete Cluster-Fähigkeiten bei Containern. Sie bilden damit eine Cloud, die dem Kunden nahezu beliebig viel Kapazität zur Verfügung stellen kann. Und diese Kapazität ist anschließend nach Bedarf abrufbar. Für solche Setups ist Core OS gedacht: Es handelt sich um ein minimales Betriebssystem, das ab Werk nicht sehr viel mehr kann, als Container zu starten – und diese dann im Flottenverbund zu verwalten.

Jeder Core-OS-Host ist also mit genug Intelligenz ausgestattet, um zu wissen, auf welchem Host welcher Container läuft. Will der Admin einen Verbund von Containern starten, um zum Beispiel per Mausklick eine komplette IaaS-Webserver-Farm aus dem Boden zu stampfen, so eilt Core OS mit den passenden Werkzeugen zu Hilfe. Tools wie Etcd, Fleetd und viele andere bringen dann die Container in die Cloud.

Traumpaar

Von Anfang an setzte Core OS auf Docker als Standard-Container-Format. So ließ sich sagen: Ein Container, der auf Host 1 läuft, läuft mit hoher Wahrscheinlichkeit auch auf Host n. Weil Docker die nötige Integration im Userland gleich mitliefert, war diese Lösung für Core OS oder Kubernetes das ideale Werkzeug.

Brandon Philips, einer der Core-OS-Gründer, avancierte zwischenzeitlich sogar zum Top-Commiter beim Docker-Projekt. Viel Arbeit, die bei Core OS entstand, floss zurück zu Docker. Mit der immer stärkeren Nutzung von Docker als PaaS-Werkzeug wandelte sich allerdings dessen Fokus und die Beziehung zwischen Core OS und Docker bekam tiefe Risse.

Rosenkrieg

Der Zwist gipfelte in der Core-OS-Ankündigung, dass man künftig lieber sein eigenes Container-Format entwickeln wolle. Das Kind hat bereits einen Namen: Rocket ([2], Abbildung 2) tauften die Entwickler ihre Erfindung. In Richtung der Docker-Leute sparte Core OS denn auch nicht mit Kritik: Vom ursprünglichen Ansatz, einfach ein Container-Standard für Linux zu sein, sei heute nicht mehr viel übrig geblieben. Das Container-Manifest, einst technische Richtschnur für Docker, sei mittlerweile ganz verschwunden. Überhaupt müsse man, so die Core-OS-Entwickler, mittlerweile eher von einer Docker-Plattform als von einfachen Containern reden.

Abbildung 2: Rocket ist der Core-OS-Gegenansatz zu Docker. Der Krawallkurs der Core OS-Entwickler liegt darin begründet, dass ihnen Docker viel zu umfassend geworden ist.

Docker will demnach kein Container-Format mehr sein, sondern eine universelle Plattform für das Verteilen und das Starten von Betriebssystem-Abbildern samt entsprechender Software für PaaS-Zwecke. Das sei in vielerlei Hinsicht ein Problem, insbesondere stößt den Core-OS-Entwicklern aber auf, dass ein typischer Docker-Container mittlerweile problemlos auch ein trojanisches Pferd sein könnte, das mit den Rechten von Root läuft. Jedenfalls habe sich Docker so weit von seinen ursprünglichen Zielen entfernt, dass es für den Betrieb in Core OS fast unbrauchbar geworden sei.

Die Rakete zur Hilfe

Mit Rocket wollen die Core-OS-Entwickler gegensteuern. Rocket ist im Grunde nur ein Container-Format. Viel mehr soll es gar nicht werden: Geplant ist, dass Rocket im Wesentlichen die Funktionen bietet, die in elementaren Docker-Setups ebenfalls vorhanden sind.

Das umfasst einerseits das Format, in dem die Container verteilt werden. Also etwa die Fragen, ob es sich um ein Image handelt und welche Art von Dateisystem dieses nutzt. Andererseits gehören zu einer solchen Container-Lösung auch die passenden Programme, die den Container-Betrieb ermöglichen: Irgendwas muss der Admin ja schließlich auf der Kommandozeile eingeben können, um einen Container zu starten.

Gleichzeitig soll das Rocket-Format einige der großen Docker-Probleme lösen. Dazu zählen die Core-OS-Entwickler das schon angeschnittene Thema Sicherheit, das sie über feiner granulierte Isolation angehen wollen, genauso wie das Image-Format selbst. Das soll die Community spezifizieren und pflegen und nicht wie bei Docker ein einzelnes Unternehmen, das vorrangig durch das eigene kommerzielle Interesse getrieben ist.

Technisch sind die Unterschiede zwischen den frühen Rocket-Versionen und dem aktuellen Docker bereits jetzt deutlich: Auf den Rocket-Hosts läuft kein Daemon mehr, mit dem der Admin per CLI redet und der schließlich die Container startet. An seiner Stelle startet das »rkt« -Programm die Container direkt. Das Praktische daran ist, dass sich Rocket-Container auf diese Weise auch gut mit ganz anderen Kontrollmechanismen wie etwa Systemd-Nspawn verbinden lassen. Der Newcomer Rocket bietet allein dadurch eine wesentlich universellere Schnittstelle an als das ältere und etablierte Docker.

Letztlich ist Rocket eine Alternative zu den Docker-Werkzeugen, die ähnliche Ziele verfolgt wie Docker ursprünglich auch. Unter der Haube setzt Rocket auf dieselbe Kernelfunktionalität, die auch Docker nutzt. In aktuellen Core-OS-Versionen lässt sich Rocket auch schon verwenden. Eine Vielzahl öffentlich verfügbarer Abbilder für Container wie bei Docker sucht man allerdings (noch) vergeblich. Damit ist erst zu rechnen, wenn das Rocket-Format an Verbreitung gewonnen hat.

Dass ein harter Wechsel von Docker zu Rocket in Core OS nicht sinnvoll gewesen wäre, ist wohl auch dem Projekt selbst aufgefallen: Bis jetzt jedenfalls erklären die Entwickler, dass Docker auch künftig in Core OS funktionieren soll. Pläne, den Docker-Support aus Core OS ganz zu streichen, gibt es aktuell nicht. Für Rocket gilt indes, dass es nur im Rahmen von Orchestrierungslösungen wie Core OS überhaupt sinnvoll nutzbar ist.

LXD

Der nächste Proband in der Übersicht ist LXD ([3], Abbildung 3). Auch hier ist es nötig, in Cloud-Gefilde abzuschweifen, um die Motivation hinter der Lösung zu verstehen. Einen ähnlichen Hype wie Docker erlebt gerade die Cloudlösung Open Stack. Obwohl Open Stack oft genug nicht die passende Lösung für ein Problem ist, scheint das Community-Projekt auf nicht wenige Admins eine geradezu magische Faszination auszuüben. Was läge also näher, als die beiden Hypes miteinander zu kombinieren? Open Stack als Cloud und Docker darin als Virtualisierer – das erscheint auf den ersten Blick als ultimative Kombination.

Abbildung 3: LXD nutzt auf der Kommandozeile zum Teil zwar die LXC-Binaries, doch im Hintergrund läuft das LXD-API in Form von »lxd«.

Wenn da bloß die Technik nicht wäre. Wer sich mit Docker und Open Stack etwas näher befasst, merkt schnell, dass sich beide Lösungen nicht so leicht verbinden lassen. Aus vielen Gründen: Docker etwa kommt mit einer eigenen Image-Verwaltung daher und ist darauf angewiesen, dass auf jedem Host eine Kopie des Container-Image liegt, für das es einen Container starten soll. Dem entgegen steht der Open-Stack-eigene Image-Dienst Glance.

In Sachen Netzwerk und Speicher gibt es ähnliche Probleme. Das Dilemma ist durchaus vergleichbar mit den Docker-Problemen, die Core-OS-Entwickler in ihrem Projekt sahen: Docker ist viel mehr als ein Container-Standard, es ist im Grunde eine eigene Plattform für den Container-Betrieb. Die Hochzeit mit Open Stack funktioniert entsprechend mehr schlecht als recht (Abbildung 4).

Abbildung 4: Docker lässt sich in Open Stack zwar grundsätzlich betreiben, im technischen Sinne schön ist das aber nicht. LXD will Abhilfe schaffen.

Einen Treiber, der Open Stack Nova – also der Virtualisierungs-Verwaltung von Open Stack – Docker beibringt, gibt es zwar. Der war sogar schon mal integraler Bestandteil von Nova. Doch vor einigen Releases entschloss man sich bei Open Stack, den Nova-Docker-Treiber aus der Plattform zu entfernen. Offiziell hieß es seinerzeit, dass die Entwickler ohne Rücksicht auf die Open-Stack-Releasezyklen den Treiber verbessern und dann in Open Stack wieder einbauen wollten. Tatsächlich ist bis heute völlig unklar, ob und wann das passieren wird.

Canonical muss das wurmen: Hat das Unternehmen doch viel Geld investiert, um in Sachen Open Stack die Speerspitze der FL/OSS-Welt zu sein. Die allermeisten Open-Stack-Clouds laufen aktuell unter Ubuntu. Bloß die Container fehlen noch – dagegen lassen sich KVM, Qemu und Xen als Hypervisoren in Open-Stack-Installationen praktisch schmerzfrei betreiben. Für Container-Virtualisierung mit Docker existiert aber bis dato kein Ansatz, der dem produktiven Betrieb gerecht wird. Denn die heute nötige Bastelei mit Docker lässt sich kaum als produktionsreif bezeichnen.

Kurzerhand entschloss sich Canonical dazu, ein neues Framework für Container zu bauen, das speziell für den Betrieb in Open Stack gemacht sein sollte. Die Firma taufte das Projekt auf den Namen LXD. Die Namensähnlichkeit zu LXC ist kein Zufall: LXD versteht sich als LXC-Aufsatz, der innerhalb einer Open-Stack-Installation den verteilten Betrieb von LXC-Containern ermöglicht.

LXD als Rettung

Unter der Haube benutzt LXD also LXC, womit auch klar ist, dass LXD auf die typischen Linux-Schnittstellen für Container setzt: Cgroups und Namespaces. Im medialen Echo schlug die Canonical-Ankündigung wie erwartet ein wie eine Bombe: Auch Canonical hatte sich Docker schließlich mehr oder minder verschrieben. War die Ankündigung, eine eigene Container-Lösung zu entwickeln, die verkappte Abkehr von Docker?

Immer noch ein bisschen Docker

Canonical beeilte sich, entsprechende Behauptungen zu dementieren. Man sei noch immer davon überzeugt, dass Docker die beste Container-Lösung für diverse Einsatzgebiete sei. Lediglich in Sachen Open Stack glaube die Firma, mit LXD auf dem schnelleren Pferd zu sitzen. Mittlerweile hat das Unternehmen die Ankündigung von LXD auf dem Open-Stack-Entwicklertreffen Ende 2014 mit brauchbarem Code untermauert: Unter Ubuntu 14.04 lässt sich LXD inzwischen betreiben.

Auch die Open-Stack-Integration liefert Canonical gleich mit: Für Nova steht mit »nova-compute-lxd« ein Hypervisor-Treiber bereit, der LXD-Container auf Open-Stack-Hosts verwalten kann. Möglich macht das der API-Teil von LXD: In bester Open-Stack-Manier erweitert LXD LXC nämlich um ein Restful-API, das sich von außen durch HTTP-basierte Befehle steuern und verwalten lässt. Bei Licht betrachtet ist LXD also eine Sammlung von Tools, geschrieben in Go, die LXC-Container aus der Ferne steuern.

Ähnlichkeiten zu Rocket sind durchaus vorhanden: Auch bei LXD fehlt der Daemon, der zentral die Steuerung aller Container auf einem Host übernimmt. API-Aufrufe führen dazu, dass entsprechende Binaries die Container ohne einen Daemon unmittelbar auf den Hosts anlegen. Wie bei Rocket wird es so für externe Lösungen leichter, an LXD anzudocken – nicht nur für Open Stack.

Dazu trägt auch bei, dass LXD nicht beansprucht, das gesamte Lifecycle-Management für einen Container zu übernehmen. Starten und Stoppen erledigen zwar die LXD-Programme, was dazwischen mit der VM passiert, liegt aber allein in der Verantwortung der Management-Lösung im Hintergrund.

Ob Canonical dem Docker-Hype tatsächlich ein Schnippchen geschlagen hat, muss sich erst noch herausstellen. Mirantis etwa hat mittlerweile auch eine Lösung im Angebot, die Docker so installiert, dass es mit Open Stack nutzbar wird. Die macht allerdings einige technische Verrenkungen nötig. Die von Mirantis lancierten Screenshots lassen jedenfalls keinen Schluss darüber zu, wie sinnvoll sich Docker tatsächlich mit Open Stack betreiben lässt.

Wer Container mit Open Stack haben will, ist bei LXD richtig. Wer Container nicht in ein Cloud-Framework wie Open Stack integrieren will, der tut sich mit normalem Docker und einer Lösung wie Kubernetes oder Core OS vermutlich deutlich leichter.

Photon von VMware

Dass VMware mit einer eigenen Container-Lösung aufwartet, scheint auf den ersten Blick zumindest eigenartig. Schließlich macht VMware bis heute den großen Teil seines Umsatzes mit klassischer Vollvirtualisierung: Container haben im ESXi-Umfeld eigentlich keine Daseinsberechtigung. Genau das ist aber auch der Grund, warum das Container-Engagement von VMware auf den zweiten Blick durchaus Sinn ergibt: Wenn Kunden unbedingt von Vollvirtualisierung hin zu Containern schwenken wollen, dann mögen sie ihr Geld gefälligst auch in Zukunft an VMware überweisen. Dann eben für Container.

Offiziell liest sich das natürlich anders. VMware erklärt, Photon OS ([4], Abbildung 5) – so der offizielle Name des Produkts – unter eine freie Lizenz gestellt zu haben, um ein möglichst effizientes System für den Betrieb von Containern in einem Rechenzentrum anzubieten. Technisch ist Photon von VMware also mehr als LXD oder Rocket. De facto ist VMwares Werk eher eine Alternative zu Lösungen wie Kubernetes oder Core OS: Es handelt sich um ein minimales Betriebssystem, das auch Container ausführt und verwaltet.

Abbildung 5: VMware stellt den Quelltext für Photon OS online. Die Umsetzung, die VMware für Container nutzt, ist ein sehr kleiner Eigenbau.

Viel Funktionalität

Mit Feature-Versprechen geizt die Firma aus Palo Alto nicht: Zwar nutzt Photon OS nicht Docker selbst, dessen Format für Container unterstützt es aber durchaus. Ebenfalls kommt es mit Containern im Rocket-Format zurecht. Selbstredend ist die perfekte Integration in vorhandene VMware-Umgebungen garantiert: Wer bereits eine VMware-Virtualisierungsplattform verwendet, der kann Photon-OS-Instanzen an diese Managementsoftware nahtlos anbinden.

Ungewöhnlich ist, dass VMware das Produkt von Anfang an offen entwickelt. Auf diese Weise will das Unternehmen laut eigener Aussage erreichen, dass sich eine Community rund um das Produkt bildet und von außen Patches kommen, die vielleicht Bugs reparieren oder Funktionalität erweitern. Dass der komplette Quelltext von Photon OS offen liegt, ermöglicht durchaus seltene Einblicke: Container realisiert VMwares Photon OS über ein eigenes Werkzeug namens »container« , das auf Cgroups und Namespaces basiert.

Community? Mal sehen

Ob dem Produkt allerdings der Community-Erfolg beschert sein wird, den VMware sich erhofft, ist zumindest fraglich. Denn auch wenn VMware den Ruf universell einsetzbarer Funktionalität aufbauen will: Als erster Punkt der Feature-Liste findet sich die bereits erwähnte Integration in andere VMware-Produkte. Weniger rosig sieht es mit der Integration in fremde Umgebungen aus: Von einer Open-Stack-Anbindung etwa war bisher keine Rede und auch entsprechender Code findet sich nicht.

Ein Ass hat VMware aber noch im Ärmel: Lightwave gesellt sich zu Photon OS und soll in Zukunft das Sicherheitsmanagement von Containern übernehmen. VMware will damit eine Möglichkeit schaffen, verschiedene Aspekte – etwa die Benutzerverwaltung oder X509-Zertifikate – zentral und vom Cloudcontroller aus abzuwickeln. Kleiner Haken: Der Cloudcontroller ist im Idealfall ein VMware-Produkt. Kompatibilität zu Protokollen wie LDAP oder Kerberos ist jedoch vorgesehen.

Im Vergleich hinterlässt Photon OS also einen zwiespältigen Eindruck. Auf der einen Seite ist VMwares Ansinnen klar erkennbar, sich ein Standbein fernab vom eigenen, klassischen Produktportfolio zu erarbeiten. Dass die Firma dabei auf quelloffene Software setzt, ist dem Unternehmen hoch anzurechnen, jedenfalls dann, wenn hinter der Entscheidung andere Beweggründe als die Hoffnung auf Patches stehen. Die enge Kopplung an vorhandene VMware-Produkte ist aber unverkennbar. Ob die Nische jener VMware-User groß genug ist, die auch bereit sind, an der Codebasis mitzuentwickeln, muss sich erst noch herausstellen.

Fazit

Der Markt an neuen Container-Lösungen bleibt einigermaßen unübersichtlich. Im ersten Augenblick fällt auf, dass die Zeit der universalen Ansätze wahrscheinlich vorbei sein dürfte: Dieses Feld hat Docker hinlänglich abgegrast, und im Cloud-Kontext ist der Betrieb einzelner Container ohnehin nicht sinnvoll. Hier steht ein Schwarm von Containern im Vordergrund.

Wer solche Anforderungen erfüllen muss, greift auf eine der vielen verfügbaren Alternativen zurück: Googles Kubernetes basiert auf Docker, auch Core OS hat seine Docker-Schnittstelle (noch) nicht verloren. Wer nicht auf spezielle Docker-Funktionalität angewiesen ist, erhält in Form von Rocket ein eigenes Container-Format innerhalb von Core OS, das schlanker und dessen Entwicklung nicht allein durch die Interessen einer einzelnen Firma gesteuert ist.

Für die Integration in Cloud-Computing-Lösungen dürfte LXD zusammen mit Open Stack im Moment der vielversprechendste Ansatz sein. Schließlich hat Canonical dieses Gespann auch ausdrücklich für jenen Einsatzzweck entwickelt. Gut funktionierende Alternativen existieren so richtig weder im Lager der Cloudlösungen noch im Container-Lager: Cloud Stack etwa, das als vielleicht einzige ernsthafte Alternative zu Open Stack übrig geblieben ist, hat im Moment weder Support für Docker noch für irgendeine der anderen hier aufgeführten Container-Technologien.

Nachdenklich lässt einen schließlich VMware zurück: Einerseits will die Firma mit Photon OS ihre Position in einem für sie neuen Markt finden. Auf der anderen Seite ist Photon OS zumindest bisher so eng mit den ganz typischen VMware-Produkten verwoben, dass ein autarker Betrieb von Photon OS wenig sinnvoll erscheint. Schließlich stünde VMwares Ansatz in diesem Fall auch in einer echten Konkurrenz zu Angeboten wie Core OS oder Kubernetes.

Damit gilt: Abhängig vom Einsatzzweck ergeben sich klare Möglichkeiten für den produktiven Betrieb von Containern. Die Auswahlmöglichkeiten pro Usecase sind allerdings merklich beschränkt – meist auf eine einzige. (jcb)