© federico rostagno, 123RF

Deis kombiniert Docker und Core OS, um daraus eine Platform-as-a-Service-Basis (PaaS) zu bauen. Seit November 2014 gibt es eine Version 1.0 der Software, ihre Entwickler bezeichnen sie als “produktionsreif”. Das wirft die Frage auf, ob Deis ein hippes Windei ist oder Substanz hat.

Wer seine Finger am Puls der Zeit haben möchte, der hat in der IT so einiges zu tun. Im Monatstakt jagen derzeit neue Trends durch die Szene, das Thema Container-Virtualisierung zum Beispiel ist ein ausgesprochen virales.

Kein Wunder: Im direkten Vergleich zwischen Container-Virtualisierung und der klassischen Virtualisierung mit Hilfe von KVM [1] oder Xen [2] punkten Container einerseits mit deutlich weniger Hardware-Overhead und ermöglichen eine höhere Dichte pro Rack. Andererseits hält sich der administrative Aufwand für ihren Betrieb in engeren Grenzen als der für KVM & Co.

Das erklärt den raketenhaften Aufstieg von Docker [3], LXD [4] und anderen Werkzeugen (siehe Kasten “Docker und LXD”): Alles, was sich Container nennt, läuft im Augenblick wie geschnitten Brot, und es ist auch noch kein Ende des Hype in Sicht.

Abbildung 1: Docker und Open Stack sind trotz des Hype rund um die beiden Komponenten bis heute kein Traumpaar. Daher wittern andere Anbieter Chancen.

Huckepack

Inzwischen gibt es eine ganze Flotte von Lösungen, die auf LXC oder Docker aufbauen und dabei die Container-Virtualisierung in spezifischer Weise nutzen, um selbst Grundlage für andere Anwendungen zu sein. Project Atomic ([5], [6]) und Core OS ([7], [8]) sind Beispiele genau dafür.

Das zweite ist gewissermaßen eine nackte Linux-Distribution, die nur eine Sache wirklich gut beherrscht: den Betrieb von Docker-Containern (siehe Kasten “Core OS”). Red Hats Project Atomic verfolgt einen ähnlichen Ansatz.

Docking gescheitert

Doch auch in der Docker-Welt ist nicht alles auf einem guten Kurs. Das Deis-Projekt [9] tritt an, um einige der architektonischen Schwachstellen von Docker zu umschiffen und das Produkt in einen produktionsreifen Kontext einzubinden. Zwar bieten Entwickler ihre Anwendungen heute gern in Containerform an – für produktive Umgebungen sind diese jedoch häufig unbrauchbar.

Kristian Köhntopp, ein Urgestein der deutschsprachigen IT-Szene, hat bereits einige öffentliche Provokationen zum Thema Docker vom Stapel gelassen [10]. Er ist nicht der einzige, der Docker sehr kritisch sieht. Als Wurzel des Problems betrachten viele Docker-Gegner dessen Overlay-Design, das zu wilden Modifikationen einlade. Doch auch die Sicherheit lässt zu wünschen übrig, wie eine Gartner-Studie kürzlich feststellte.

Ein Docker-Container ist intern ja nichts anderes als ein Dateisystem, das über eine Overlay-Schicht (Au-FS) verschiedene Deltas mit auf den Weg bekommt. Diese enthalten die Software, welche die Nutzer der Docker-Container benötigen. Das Problem hierbei: Was für Entwickler, die Docker in der Produktentwicklung einsetzen, gut funktioniert, geht im Tagesgeschäft der Operator oder Betriebler regelmäßig schief. Denn wenn sich die Admins einen x-beliebigen Container installieren, holen sie sich ein trojanisches Pferd in ihr Setup.

Zudem ist, was beim Entwickler bootet, nicht automatisch reif für den produktiven Einsatz. Kein Wunder also, dass einige Docker als großartiges Werkzeug für Entwickler, aber als eine Katastrophe für Betriebler betrachten und als nicht hilfreich im Devops-Bereich.

Opus Deis

Deis setzt nun genau an dieser Stelle an. Das Projekt will den Container-Dschungel rund um Docker lichten und standardisierte Container erstellen, die dann PaaS anbieten. Als ihr großes Vorbild benennen die Deis-Entwickler Heroku [11], einen Pionier in Sachen Cloudangebot auf PaaS-Grundlage – die Anleihen sind ohnehin unübersehbar. Der Artikel will die Frage beantworten, ob sich ein Blick auf Deis lohnt oder ob hier ein Strohfeuer ohne wirkliche Substanz lodert – oder eine Zukunftstechnik, mit der sich zu befassen wichtig ist.

PaaS als kniffelige Aufgabe

Platform as a Service verfolgt ein simples Prinzip. Wer eine Website nur mit PHP oder Python betreiben möchte, interessiert sich nicht für den technischen Unterbau, sondern nur für die Frage, ob der Unterbau das liefert, was für den Betrieb des jeweiligen Dienstes nötig ist.

Typische Cloud-Computing-Installationen bieten dafür einen perfekten Ansatz. Denn hier kann der Anbieter seinen Kunden Infrastruktur wie auf Knopfdruck anbieten. Will ein Kunde beispielsweise eine neue VM, so lässt sich diese innerhalb weniger Sekunden aus der Dose herstellen. Ob sie dann auf KVM basiert oder doch auf einer Containertechnik, ist für die Applikationen in der virtuellen Maschine irrelevant.

Sehr relevant hingegen ist für den Anbieter die Frage, wie er das virtuelle System so bestückt, dass die Kunden es tatsächlich nutzen können. Ein nacktes Ubuntu hilft nicht, wenn der Kunde ein Setup mit Apache, PHP und diversen anderen Diensten benötigt. Denn die dazugehörigen Installationsarbeiten möchte der Kunde sich ja ersparen.

Die kniffelige Aufgabe für den Anbieter ist damit klar: Wie soll er VMs so mit Software bestücken, dass sie erfüllen, was die Kunden sich als Plattform für den Betrieb von Software wünschen? Und wie lässt sich dieser Vorgang so automatisieren, dass “as a Service” keine leere Worthülse bleibt und Kunden sich nach Bedarf mit virtuellen Systemen eindecken können? Deis bietet einen Werkzeugkasten, mit dem sich Admins die Plattformen für ihre Kunden nach Bedarf zusammenkomponieren.

12 Factors

Heroku [11] hat als einer der größten PaaS-Anbieter der Welt zusammen mit ein paar anderen Unternehmen versucht, die goldenen Regeln für PaaS in Worte zu fassen. Zwar stammt Deis nicht von Heroku, hält sich aber recht genau an diese Regeln. Um die Plattform zu verstehen, schadet es daher nicht, sich im Detail anzusehen, was unter dem Titel “12 Factors” durchs Web geistert [12].

• Die ersten beiden Regeln beziehen sich auf Code. Danach soll sich der Code von PaaS-Anwendungen stets in einem getrackten Repository wie etwa Git [13] befinden. Setzt ein Entwickler Funktionen anderer Software ein, soll er sie klar benennen, als Abhängigkeit definieren und isolieren.
• Konfigurationsdateien mit Login-Daten oder Ähnlichem sollten nicht in der Anwendung selbst stecken, sondern Teil der Umgebung sein, in der eine PaaS-Anwendung läuft. Etcd setzt diese Richtlinie perfekt um: Es liest sämtliche Parameter aus einer Datenbank mit zentralem API aus, von der alle Dienste zehren.
• Entwickler sollen mit der Anwendung verbundene Dienste wie MySQL-Datenbanken, aber auch Twitter & Co. stets als notwendige Attached Resource im Hinterkopf behalten. Etcd läuft zum Beispiel im Hintergrund, stellt aber wichtige Informationen für die Applikation bereit. Dienste und Applikationen sind bei Deployments nicht voneinander zu trennen.
• Letzteres trifft hingegen nicht auf Entwicklungs- und Produktionsstränge zu, die trennt der Admin besser. Der Punkt zielt explizit auf typische Docker-Container ab, die oft direkt aus den Händen des Entwicklers in den Live-Betrieb gehen.
• Stateless-Protokolle skalieren besser in die Breite als Stateful-Protokolle und sollten den Vorzug erhalten, wenn technisch möglich. Ein definierter Standardport garantiert für die Erreichbarkeit jeder Applikation.
• Wenn eine Software robust läuft, sich aber auch schnell starten und zuverlässig beenden lässt, erzeugt das beim Benutzer ein stimmiges PaaS-Gefühl.
• Entwickler- und Staging-Zweige orientieren sich am besten so nah wie möglich an dem, was in der Produktion tatsächlich zum Einsatz kommt.
• Logs versteht ein Admin weniger als Textdateien, sondern vielmehr als Event-Reihenfolgen, Applikationen sollen die Ausgaben nicht speichern oder routen, sondern sie einfach an »stdout« schicken. Der Entwickler kann sich den Stream ansehen, Produktionssysteme sollen ihn aber extern speichern.
• Schließlich sollen Admin- und Management-Prozesse unabhängig von jenen Prozessen laufen, die für den Alltagsbetrieb nötig sind.

Die zwölf Gebote sollen auch Deis helfen für Nutzer auf Grundlage von Core OS, Docker und Git beliebige Anwendungen oder Sprachumgebungen aufzusetzen.

Deis in a Nutshell

Um etwa eine PaaS-Anwendung sinnvoll in die Breite zu skalieren, nutzt Deis die Features von Etcd. Startet Deis eine PaaS-VM, erhält Etcd für sie stets eine Reihe von Einträgen, mit deren Hilfe ein Admin die VM später wiederherstellt.

Die Deis-Entwickler selbst beschreiben den Workflow ihrer Applikation in der Deis-Dokumentation mittels einer Grafik (Abbildung 2). Die zeigt deutlich die drei Kernkomponenten: Deis dient gewissermaßen als Tool, das sich um die Koordination zwischen den tatsächlichen PaaS-Diensten, Docker und Core OS kümmert – also das Control Panel.

Abbildung 2: Der Workflow von Deis lässt sich grob in drei Phasen gliedern.

Docker selbst ist hier lediglich ein Werkzeug: Auf Grundlage eines Basis-Image erstellt Deis auf Zuruf Docker-Container, die spezifische Fähigkeiten besitzen. Core OS ist ebenfalls nicht viel mehr als ein Handlanger: Ihm kommt am Ende die Aufgabe zu, die gebauten Docker-Container zu betreiben.

Deis-Workflow

In drei Phasen gelangt der Deis-Admin von der Benutzeranfrage zum fertigen System. In Phase 1 erzeugt Deis die Container. Es setzt dabei auf Git. Über fertige Anweisungspakete – so genannte Applications – erhält Deis selbst die Information, welche Eigenschaften ein Container haben soll. Die Applications enthalten den Code, der später innerhalb eines Containers laufen soll, und zwar in der Skriptsprache, die später auch im Container selbst dominiert.

Wünscht sich der Betreiber also einen Jetty-Server, liefert die entsprechende Deis-Application vorrangig Java-Code. Eine spezielle Datei namens »procfile« in jeder Application verrät Deis, um welche Art von Anwendung und Sprache es sich im konkreten Fall handelt.

Im Netz wartet bereits eine ganze Reihe fertiger Applications [18] auf Deis. Über den Deis-Client, ein separates Kommandozeilentool, installiert sie der Benutzer. Ein im Application-Verzeichnis ausgeführtes »deis create« genügt, um die Application anzulegen. Dann folgt ein »git push deis Master« , um den Buildprozess anzustoßen – der Benutzer ist an dieser Stelle bereits fertig (Abbildung 3).

Abbildung 3: Von der Application zum fertigen Container in wenigen Sekunden: »git push« macht’s möglich. Ein GUI fehlt Deis allerdings bis heute.

Im Hintergrund legt Deis auf Basis blanker Templates einen Docker-Container an, der den Befehlen der Application gehorcht. Standard für diese Images ist Ubuntu 14.04, doch lässt sich das über eine eigene Datei in der Application beeinflussen: Per »Dockerfile« [19] sind hier alle Optionen für den Nutzer exponiert, die auch Docker selbst bietet.

Die zwölf Faktoren machen sich hierbei bemerkbar. Weil Deis einen Container stets aus blanken Images baut, lässt sich dieser später ohne Verrenkungen reproduzieren. In der Docker-Registry landet in der zweiten Phase also ein nackter Container ohne eigene Identität.

Bemerkenswert ist überdies, dass ein klassischer Docker-Container aus Deis keine Hilfsdienste wie Datenbanken enthält. Das Stichwort lautet Attached Resources: Dem PaaS-Anbieter fällt die Aufgabe zu, eine zentrale Datenbank oder zentrale Instanzen anderer Dienste zu betreiben, auf welche sich die von Deis gebauten Container später beziehen. Das sorgt für Skalierbarkeit, denn PaaS-Kunden müssen nicht mehr an die Infrastruktur denken und diese schon gar nicht selbst betreiben.

Phase 3 befasst sich mit dem Scheduling der VM. Eine eigene Deis-Komponente, der Scheduler, geht im Hintergrund die Liste verfügbarer Core-OS-Hosts durch und entscheidet, auf welchem Host sie den Container startet. Ist ein passender Host gefunden, bringt Deis den Container auf den Weg und verpasst ihm obendrein eine Reihe von Konfigurationsparametern, die nicht Teil des Image sind. Ein Deis-Container ist also tatsächlich ein generisches Docker-Image, das Deis zur Runtime mit spezifischen Einstellungen aus Etcd heraus kombiniert.

In Sachen Netzwerk

Dass Deis tief in die Prozesse von Docker eingreift, demonstriert die als Router bezeichnete Deis-Netzwerk-Komponente sehr eindrücklich. Um PaaS für verschiedene Protokolle zu ermöglichen, muss Deis die Art und Weise, wie VMs auf ihr Netzwerk zugreifen, zentral steuern. Die Router-Komponente ist im Grunde das Mädchen für alles (Abbildung 4): Basierend auf den Load-Balancing-Fähigkeiten von Nginx sorgt der Deis-Router dafür, dass VMs von außen erreichbar sind. Router sind in Deis horizontal skalierbar und funktionieren wie ein Mesh-Netzwerk. Sie exponieren VMs zudem erst, wenn der einer VM zugrunde liegende Container erfolgreich gestartet ist.

Abbildung 4: Control- und Data-Plane sind die elementaren Deis-Bestandteile. Ganz besonders wichtig sind die Router, die auch als Mesh-Netzwerk arbeiten. Die schwarzen Felder sind die Attached Resources.

Klimbim drum herum

Neben den zentralen Komponenten wie Builder, Registry (das eigentliche API von Deis) und den Routern arbeiten bei Deis mehrere Zusatzkomponenten mit, um die Plattform robust zu machen.

PostgreSQL speichert als Datenbank State-Informationen über die VMs. Letztere sind aber nicht nur außerhalb der VMs zu finden, sondern auch innerhalb. Ceph bietet Containern, die ihn benötigen, persistenten Speicher an.

Das Logging funktioniert bei Deis zentralisiert und nutzt Logspout sowie Logger. Über ein API findet der Admin für jede VM heraus, in welchem Zustand sie sich befindet. Ein auf Redis basierender Cache beschleunigt die Kommunikation.

In Sachen hipper Software zieht Deis also alle Register. Dabei entsteht aber ein eher komplexes Setup, das für den Admin sehr viel Hintergrundarbeit bedeutet.

Nicht nur Licht

Genau das sorgt für teils heftige Kritik und Unverständnis: die Komplexität der Lösung per se. Wer sich auf der Deis-Website lediglich die Grafiken anschaut, geht den Entwicklern schnell auf den Leim. Denn dann entsteht der Eindruck, Deis sei selbst eher wenig komplex und biete eine einfache Lösung für die schon erwähnten Docker-Probleme. Doch genau das ist nicht der Fall.

Dem Admin steht ein schönes Stück Arbeit bevor, um die benötigte Deis-Infrastruktur zum Laufen zu bringen. Womöglich will er auch eigene Hardware für Deis anschaffen, denn im Grunde ist das Framework eine Cloud.

Mini-Cloud

Der direkte Vergleich mit anderen Projekten wie Open Stack macht das schnell deutlich: Eine eigene Datenbank für Metadaten (zum Beispiel Informationen über vorhandene VMs) kennt Open Stack ebenso wie Deis. Eine eigene Netzwerk-Komponente gibt es in beiden Lösungen ebenfalls – bei Open Stack heißt sie Neutron, bei Deis ist es der Router. Zweifellos ist der Router in Deis sehr viel weniger komplex, als es Open Stack seinen Nutzern zumutet.

Doch mit dieser Komplexität wollen die Neutron-Entwickler ihre Kunden nicht ärgern, vielmehr geht es aus technischer Sicht kaum anders. Denn Open Stack ist auf Massenbetrieb ausgelegt. Wie hingegen ein Deis-Cluster performt, wenn der Administrator ihn Hunderttausenden von simultanen HTTP-Requests aussetzt, die auf Dutzenden Computing-Knoten landen, muss sich noch zeigen.

Generell entsteht an vielen Ecken der Eindruck, die Deis-Entwickler wollten auf Gedeih und Verderb das Cloud-Rad neu erfinden. De facto ist es nicht möglich, Deis mit einer anderen Cloudlösung sinnvoll zu integrieren. Wer schon eine Open-Stack-Cloud betreibt, kann Deis nicht einfach anbinden. Meist dürfte es nötig sein, separate Hardware anzuschaffen. Der Betrieb zweier konkurrierender Plattformen ist jedoch das Todesurteil für effizientes IT-Management.

Vielen Unternehmen dürfte dieser Aufwand vermutlich zu hoch sein, und die Vorteile, die sich aus effizientem PaaS mit Deis und Docker ergeben, wiegen diesen Nachteil nicht auf. Wer nicht ausschließlich im PaaS-Umfeld aktiv ist, wird mit Deis allein vermutlich kaum glücklich.

Lernkurve – steil

Zum Heroku-Stil gehört auch die Maxime, »git push« als einzigem notwendigen Befehl den größten Teil der Arbeit zu überlassen. So ganz packt Deis das allerdings nicht, aber das einem Containerstart vorausgehende »deis create« kommt dem Ziel bereits ziemlich nahe. Für Entwickler mag das reichen: Wer die Arbeit mit Git gewohnt ist und dessen Funktionsweise kennt, wird den einfachen Ansatz mögen.

Allein: Nicht alle Kunden von PaaS-Plattformen sind gelernte Programmierer. Eigentlich soll PaaS ja gerade niedrige Einstiegshürden schaffen. Ein UI, mit dem Kunden sich ihre per Deis ausgelieferten Container zusammenklicken könnten, wäre deshalb wichtig.

Doch ein funktionierendes GUI, also ein Pendant zu Open Stacks Horizon, fehlt Deis. Abgesehen von einem gleichlautenden Bugreport [20] findet sich zu dieser Problematik auch nichts im Netz. Laut Aussage der Deis-Entwickler steht ein UI auch nicht auf der To-do-Liste für die nähere Zukunft. Wer weniger versierte Kunden mit den PaaS-Diensten eines Unternehmens vertraut machen möchte, hat es mit Deis schwer.

Das Ziel: Webanwendungen

Die Deis-Applications unter [18] drehen sich beinahe immer um verschiedene Webapplikationen. Ihr Baby soll mit “verschiedenen Sprachumgebungen” schnell zurechtkommen, erklären die Macher: Ein Deis-Container enthält meist eine Prozessanweisung, durch die Deis lernt, welche Art von Container es sich aus den Fingern saugen soll.

Sand kommt ins Getriebe, wenn das Ansinnen eines Nutzers gar kein Prozess ist, sondern eine echte Plattform – zum Beispiel um darin Entwicklungsarbeit zu leisten. Für solche Umgebungen gelten ja de facto die gleichen Faktoren bei Performance und Dichte, die auch schon für echte Webapplikationen genannt wurden. Vermutlich gelten sie in den meisten Fällen sogar noch deutlicher, da es absolut keinen Grund dafür gibt, GCC und Konsorten in KVM-VMs zu betreiben – Container meistern diese Aufgabe mit Bravour.

Allerdings ist Deis architektonisch nicht besonders gut gerüstet, wenn es nicht direkt um Applikationen geht, sondern eher um Frameworks. Zwar hindert niemand den Nutzer daran, sich eigene Apps für Entwicklungsumgebungen zu bauen, von der Stange finden sich entsprechende Beispiele allerdings kaum.

Docker oder Rocket?

Wer Deis ausprobieren möchte, tut das idealerweise in VMs und rechnet mit ein paar Stunden Arbeit, was Installation und Deployment angeht. Das gilt vor allem für die mit Deis verbundenen Komponenten. Ob die Entwickler diesen Prozess in Zukunft sinnvoller gestalten und sich womöglich enger an Cloudumgebungen wie Open Stack anlehnen, lässt sich aktuell kaum beantworten.

Ohnehin dürfte es Gesprächsthemen geben, die bei den Deis-Entwicklern gerade für mehr Aufmerksamkeit sorgen: Core OS hat sich im Dezember 2014 schließlich von Docker losgesagt [21] und in Form von Rocket [22] seine eigene Containertechnologie vorgestellt, die man nun stringent forcieren möchte. Natürlich versprechen die Core-OS-Entwickler, dass mit Rocket alles besser werde.

Vor diesem Hintergrund interessiert die Frage, ob Deis sich für Rocket begeistern wird oder weiterhin Docker nutzt, so lange es noch in Core OS vorhanden ist, um gegebenenfalls danach auf eine der anderen Mikrodistributionen auszuweichen.

Gleichzeitig stehen andere Projekte in den Startlöchern, um das Rennen gegen Deis anzutreten und ihm Nutzer abzujagen. Solum [23] ist so ein Beispiel: Im Stil von Deis will es PaaS per Mausklick verfügbar machen. Im Gegensatz zu Deis integriert es sich aber fast nahtlos mit Open Stack (Abbildung 5).

Abbildung 5: Mit Solum erwächst Deis bereits ein Nachfolger auf dem schnelllebigen Containermarkt.

Doch gibt es zwischen den Projekten wesentlich mehr Gemeinsamkeiten als Unterschiede: Was bei Deis eine Application ist, heißt bei Solum Language Pack. Wie Deis ist auch Solum an die zwölf Faktoren angelehnt. Mit der Hosting-Firma Rackspace im Rücken dürfte überdies hinreichend kommerzielles Interesse sowie Kleingeld vorhanden sein.

Fest steht, dass der Containermarkt unruhig und sprunghaft bleibt und sich die bleibenden Lösungen erst noch herauskristallisieren müssen. Ob Deis dazu gehört, lässt sich kaum vorhersagen: Technisch setzt die Software, die bei Redaktionsschluss in der Version 1.2.0 vorliegt, in vielerlei Hinsicht Maßstäbe und räumt eines der größten Probleme von Docker aus dem Weg.

Faktoren wie die fehlende Integration in andere Umgebungen und, daraus resultierend, das fehlende UI verursachen jedoch Bauchweh. Bei den Containerschiffen ist das Rennen unter Linux noch nicht vorbei.