© Jaroslaw Baczewski, 123RF

Während der Docker-Hype schon wieder abzuklingen scheint, haben sich gleich mehrere Container-Alternativen in Marsch gesetzt und hoffen auf Landgewinne. Darunter ist Canonicals Container-Ansatz LXD, entworfen mit Open Stack im Blick.

Xen, KVM und VMware sind ausgesprochen erfolgreiche Produkte in der Klasse der Hypervisoren. Aus diesem Grund denken viele Admins beim Stichwort “Virtualisierung” zunächst an eine dieser Lösungen. Dabei sind sowohl Xen als auch KVM Vollvirtualisierer, die allerdings mittels passender Treiber auch Paravirtualisierung beherrschen. Im Prinzip emulieren aber alle drei Lösungen den ganzen Computer – und fressen dadurch nicht wenige Ressourcen.

Die Docker-Revolution

Deshalb erfreut sich die Containervirtualisierung so großer Beliebtheit: Denn bei Containern wird nicht ein ganzer Computer emuliert, sondern nur ein Dateisystem innerhalb des Hosts, aus dem die Dienste des Virtualisierungscontainers unter normalen Umständen nicht ausbrechen können. Containervirtualisierung für Linux ist keineswegs neu: Open VZ ist neben den klassischen Linux-Containern (LXC, http://1) schon seit einigen Jahren als Pionier unterwegs. Umfassend durchsetzen konnten sich Container im direkten Wettbewerb mit den Vollvirtualisierern aber lange nicht. Das hatte zum Teil technische Gründe, war zum Teil aber auch auf PR- und Marketingprobleme zurückzuführen.

Und dann kam Docker: Diese Implementation von Linux-Containern eroberte über Nacht die Herzen von Admins und Entwicklern gleichermaßen und hat sich nun mehr als zwei Jahre lang als veritabler Hype gehalten http://2. Anfangs schien es gleich einen ganzen Haufen von Gründen dafür zu geben, dass Docker mit seiner neuartigen Virtualisierung die Lösung der Zukunft bietet.

Erstens bot Docker nämlich eine deutlich höhere Dichte als KVM oder Xen. Weil nicht jedes virtuelle System einen kompletten Computer imitiert, sind die Container-VMs deutlich schlanker. Obendrein macht Docker viele Aufgaben sehr leicht: Weil ein Container ein abgeschlossenes Konstrukt ist, kann es praktisch auf jedem Host laufen, der Container unterstützt.

Wenn Entwickler ein Programm schreiben, können sie es in Form von Containern leicht an ihre Kunden weitergeben. Das passiert auf der Grundlage von Overlay-Images: Das immer gleiche Basis-Image bekommt also zusätzliche Layer mit Änderungen. Garniert wird das System bei Docker von verschiedenen Verwaltungswerkzeugen, mit denen sich Docker-Container im Stile einer Versionsverwaltung à la Git gut und komfortabel verwalten lassen.

Die Alternativen

Zwischenzeitlich ist Docker in der Realität angekommen, der Hype um die Lösung hat merklich abgenommen. Hersteller, Admins und Entwickler sind nämlich darauf gekommen, dass Docker nur selten die eierlegende Wollmilchsau ist. Stattdessen hat es einige ernsthafte Probleme bei alltäglichen Einsatzszenarien im Rechenzentrum.

Seither schießen Alternativen aus dem Boden: Rocket aus der Feder der Core-OS-Entwickler, auch Systemd kann in Zukunft containern, nicht zuletzt erlebt LXC ein Revival und erfährt wieder verstärkt Entwicklung. Freilich will auch Canonical nicht patzen und kündigte anlässlich des Open Stack Summit in Paris letztes Jahr LXD http://3 an. Zeit und Gelegenheit waren kein Versehen: LXD soll das Standbein Canonicals im Markt der Containervirtualisierung für Open Stack sein und damit ein Geschäftsfeld erschließen, das die großen Hersteller über lange Zeit vernachlässigt haben.

Wodurch unterscheidet sich LXD von Docker, wie funktioniert die Lösung und spielt sie wirklich gut mit Open Stack zusammen? Das Linux-Magazin hat einen genauen Blick auf die ersten Alphaversionen von LXD geworfen – und war durchaus angetan von dem, was die Shuttleworth-Entwickler da präsentierten.

Dockers Probleme

In LXD will Canonical einige der Probleme umgehen, unter denen Docker noch immer leidet. Nicht wenige Admins etwa verteufeln Docker, weil sich Container auf Docker-Basis zwar komfortabel, aber für den produktiven Einsatz nicht sinnvoll pflegen lassen. Für Entwickler sei Docker zwar ganz hervorragend, weil sich auf Basis fertiger Container schnell eine komplette Entwicklungsumgebung zusammenzimmern lässt.

Doch für produktive Umgebungen, so die Admins, sei ein Docker-Container wie eine Blackbox. Die Nutzer könnten sich wegen der diversen Overlays kaum ein Bild vom Inhalt des Containers machen, den sie von dem Entwickler erhalten haben. Auch sei es auf Basis von Containern mit Docker kaum möglich, Änderungen nachzuvollziehen.

Hinzu kommt, dass Docker und Open Stack bis heute nicht sehr gut miteinander können. Das liegt auch an Bugs und fehlenden Funktionen im Code; zu einem größeren Teil aber an unterschiedlichen Konzepten: In Open Stack etwa gibt es einen zentralen Image-Dienst, aus dem sich die Hypervisoren ihre Images holen, wenn sie eine neue VM starten sollen. Bei Docker ist jeder Host selbst ein kleiner Image-Dienst: Damit sich ein Container starten lässt, muss er im Image-Speicher des jeweiligen Docker-Hosts bereits lokal vorhanden sein.

Durch einen Hack im Nova-Docker-Treiber, der Open Stack und Docker vereinigen soll, funktioniert das momentan zwar einigermaßen: Der Hypervisor lädt einfach das Image aus Glance herunter und legt es vor dem Start des Containers lokal im Hypervisor ab, wo es dann als Zombie-Image ohne Namen vorliegt. Insgesamt befriedigt die Situation aber nicht. Denn eigentlich sollte Docker sich beim Starten einer VM das Image direkt aus Glance ziehen, lokal dann den Container betreiben und die Daten wegwerfen, wenn der Container nicht mehr benötigt wird.

Apropos Nova-Docker [4]: Der Treiber hat eine lebhafte Geschichte hinter sich. Zurzeit ist er gar nicht offiziell Teil von Open Stack. Kurz vor der Icehouse-Version entfernten die Entwickler den Treiber nämlich, weil sie ihn für zu kaputt hielten. Mittlerweile hat er einiges an Entwicklung hinter sich gebracht. Langfristig ist das Ziel, ihn wieder zum fixen Bestandteil von Open Stack zu machen. Bis das passiert, dürfte aber noch einiges geschehen. Genug Zeit also für Canonical, um LXD gut in Stellung zu bringen.

Technische Grundlagen

Lange Zeit nach der Ankündigung in Paris war LXD gewissermaßen Vapoware, von der es kaum Code gab. Zur Präsentation bei der Open-Stack-Konferenz hatten die Entwickler eine allererste Version ihres Programms samt Open-Stack-Integration zum Download freigegeben. An einen produktiven Einsatz jener Version war aber nicht zu denken. Anfang 2015 kam dann langsam Code von den Entwicklern, der einen Ausblick auf LXD bot. Bemerkenswert ist dabei vor allem, dass LXD unter der Haube eng mit LXC verbunden ist.

Der Oberbegriff Container im Linux-Kontext bietet Raum für Verwirrung. Im Grunde ist ein Container nichts anderes als ein virtuelles Dateisystem, das mittels einiger Funktionen des Linux-Kernels wie Namespaces und Process Groups vom physikalischen Hauptsystem getrennt ist. Egal welcher Container zum Einsatz kommt – ob Docker, LXD oder Rocket –, die genutzten Werkzeuge im Kernel sind bei allen Lösungen identisch. Interessant wird damit vorrangig die Frage, welche Zusatzfunktionen die Containerlösungen anbieten, um die Nutzung der immer gleichen Kernelschnittstellen komfortabel zu ermöglichen. Canonical hat sich bei LXD offensichtlich dafür entschieden, auf die schon vorhandene Lösung LXC zu setzen.

LXD lagert alle Aufgaben zum Starten und Verwalten von Containern an LXC aus. LXD selbst ist also eigentlich nur ein Framework, das dem Admin nach vorne ein Restful-API anbietet und im Hintergrund LXC anweist, Container nach Vorgabe des Nutzers zu starten. Die Fähigkeiten jenes Daemon bestimmen im Wesentlichen darüber, welche Funktionen LXD unterstützt.

LXD ausprobieren

Canonical hält bei LXD die gute Tradition aufrecht, den interessierten Nutzern schon vorab einen Blick auf die Software zu erlauben. Wer ein Ubuntu 14.04 griffbereit hat, kann sich LXD schon jetzt im Detail anschauen. Die passenden Pakete liefert Ubuntu in einem eigenen Repository mit (Abbildung 1).

Abbildung 1: Die Installation von LXD ist auf einem Ubuntu-System mit den Ubuntu-Versionen 14.04 kein Problem.

Wer keinen separaten Ubuntu-Host hat, kann den LXD-Test auch in einer VM von VMware oder Virtualbox durchspielen. Weil LXD kein Vollvirtualisierer ist, braucht es auch keine Features wie Intels Virtualization Technology for Directed I/O (VT-D) oder AMDs Secure Virtual Machine (SVM). Eine normale VM mit aktuellem Ubuntu reicht schon.

Auf der Website des LXD-Github-Repository erfährt man, dass die Geschwindigkeit der Entwicklung derzeit so hoch ist, dass nur automatisch generierte Nightly Builds möglich sind. Um diese auf das eigene System zu holen, ist zunächst das entsprechende PPA zu aktivieren:

sudo add-apt-repository ppa:ubuntu-lxc/lxd-daily

Falls das Programm »add-apt-repository« nicht verfügbar ist, lässt sich das durch die Installation der beiden Pakete »software-properties-common« und »python-software-properties« beheben. Die Befehle »apt-get update« und »apt-get install lxd« holen danach LXD auf das System.

Will der Nutzer dann ein eigenes Image in den LXD-Image-Speicher packen, geht das mit dem Skript »lxd-images« (Abbildung 2). Es lädt aus einem Onlinestore das angeforderte Image herunter und verfüttert es an LXD. Ein Beispiel für Debian Wheezy wäre:

scripts/lxd-images import lxc debian wheezy amd64 --alias debian --alias
debian/wheezy --alias debian/wheezy/amd64

Abbildung 2: Nach der LXD-Installation lässt sich mittels »lxd-images« ein LXD-Image herunterladen und in LXD installieren.

Der Befehl »lxc launch debian« startet danach schließlich einen eigenen Container auf der Basis von Debian Wheezy (Abbildung 3).

Abbildung 3: Der Mühe Lohn: Ein funktionierender LXC-Container, der sich aus LXD heraus steuern lässt.

Ecken und Kanten

Der Test der Software durch das Linux-Magazin zeigte, dass LXD noch eine Baustelle ist. Das betont allerdings auch Canonical: LXD ist augenblicklich für den produktiven Einsatz noch nicht geeignet. Angesichts der vielen Warnungen hat sich LXD im Test insgesamt aber gut geschlagen: Das Starten und Stoppen von Containern klappte beispielsweise ganz passabel.

Seit Februar arbeiten die LXD-Entwickler an »nova-compute-lxd« [5], das in Open Stack Kilo oder spätestens dessen Nachfolgeversion LXD mit Open Stack Weise integrieren soll. Aktuell fehlt diese Funktionalität aber noch.

Viel getan, viel zu tun

Der erste Blick auf LXD macht Lust auf mehr. An erster Stelle steht die Open-Stack-Integration: Schafft Canonical es, LXD tatsächlich so gut mit Open Stack zu kombinieren, wie es vorgibt, wird LXD die Open-Stack-Welt im Sturm erobern. Denn für praktisch keine andere Container-Lösung außer Docker existiert aktuell eine passable Open-Stack-Anbindung. Und die Integration von Docker und Open Stack ist aus verschiedenen Design-Gründen eher schwierig.

Mark Shuttleworth hat selbst einiges Geld in Open Stack gesteckt – und es ist auch bekannt, dass Ubuntu die erste Distribution war, die ganz massiv auf Open Stack gesetzt hat. Bis heute ist Ubuntu für die meisten Admins die erste Wahl in Sachen Open Stack. Und obwohl Red Hat und Suse mittlerweile in ähnlichen Dimensionen zur Open-Stack-Entwicklung beitragen, scheint Ubuntu in Sachen Open Stack weiterhin fast uneinholbar vorn zu sein. LXD darf sicher auch als Versuch Canoncials gelten, diesen Zustand zu erhalten.

Technisch funktioniert LXD bereits im frühen Stadium gut, streckenweise sogar besser als Docker. Dank des händisch installierten »nova-compute-lxd« konnte LXD etwa in Open Stack die gleichen grundlegenden Aufgaben erledigen, die auch die Kombination aus Nova, Docker und »nova-docker« leisten kann. Bei der LXD-Entwicklung spielte Open Stack von Anfang an eine große Rolle. In vielerlei Hinsicht ist LXD so konstruiert, dass es sich ausdrücklich an Open Stack orientiert. Mit Open Stacks Image- und Netzwerkdiensten, Glance und Neutron, kann LXD von Anfang an umgehen.

Bei Redaktionsschluss werkelten die Entwickler daran, der LXD-Open-Stack-Integration in Form von »nova-compute-lxd« auch Support für den Start von Cinder-Volumes zu verpassen. Ist die Basisfunktionalität für die Kombination aus Open Stack und LXD vorhanden, dürfte die Luft für die Nova-Docker-Kombination spürbar dünner werden.

Fest steht, dass es spannend bleibt im Markt der Virtualisierung mit Containern. In Form von LXD erwächst Docker ein mächtiger Konkurrent, der sich zwar nicht als Werkzeug zum Verteilen fertiger Applikationen eignet – dafür fehlt die Git-artige Verwaltung der Images –, der aber schon jetzt das erste Mittel der Wahl sein dürfte, wenn es darum geht, aus Gründen von Density und Performance Container an Open Stack anzubinden.