Ein Docker-Container ist eine Grenze, kein Rundum-sorglos-Paket

Am 26. April 1956 hob ein Kran im Hafen von Newark achtundfünfzig abnehmbare Aluminiumaufbauten von Lastwagen auf den umgebauten Tanker Ideal-X. Hinter dem Vorhaben stand Malcom McLean, ein ehemaliger Lkw-Fahrer aus North Carolina, der es leid war, seine Fracht Stück für Stück von Hand verladen zu sehen (1). Die Aufbauten waren austauschbar und für sich genommen uninteressant, aber genau darin lag der Clou: Ein Kran musste nicht wissen, was in ihnen steckte, ein Schiff nicht, wie sie beladen wurden. Die internationalen Standards für Maße und Eckbeschläge, auf die sich Häfen, Reedereien und Spediteure verlassen konnten, folgten erst in den 1960er-Jahren. Was 1956 begann, war nicht die fertige Norm, sondern die Idee, dass eine Schnittstelle mehr wert sein kann als die Kiste selbst.

Fast sechzig Jahre später griffen Softwareentwickler nach genau diesem Prinzip, um ein Problem zu lösen, das mit Schifffahrt nichts zu tun hatte: Eine Anwendung, die auf dem Rechner der Entwicklerin tadellos lief, stürzte auf dem Server des Kunden ab. Der Code war derselbe. Die Umgebung war es nicht: eine andere Betriebssystemversion, eine fehlende Bibliothek, eine andere Konfiguration. Der Fachbegriff dafür ist unter Entwicklern seit Jahrzehnten ein Running Gag: Works on my machine.

Docker überträgt genau dieses Prinzip in die Softwarewelt. Eine Anwendung wird zusammen mit ihrer Laufzeit und den Bibliotheken, die sie zwingend braucht, zu einem Image gebündelt: einer in sich geschlossenen Vorlage, aus der sich ein Container starten lässt. Unter vergleichbaren Voraussetzungen bringt er überall dieselbe definierte Laufzeitumgebung mit, ob auf dem Laptop der Entwicklerin, dem Testserver oder in der Cloud eines Kunden. Die Umgebung wird Teil der Lieferung, nicht länger eine Wettannahme am Zielort.

Solomon Hykes, ein Programmierer und Unternehmer, stellte Docker im März 2013 auf der PyCon in Santa Clara erstmals öffentlich vor, in einem fünfminütigen Lightning Talk (2). Was danach folgte, war weniger eine Erfindung als eine Übersetzung: Namespaces und Cgroups gab es im Linux-Kernel bereits seit Jahren, kaum genutzt von der breiten Masse der Entwicklerinnen und Entwickler. Hykes' eigentliche Leistung bestand darin, diese Mechanismen mit geschichteten Images, einer beschreibbaren Bauanleitung namens Dockerfile und einem Registry-Modell zu einem Arbeitsablauf zu verbinden, den normale Teams tatsächlich benutzen konnten. Aus dem internen Werkzeug einer kleinen Plattformfirma wurde binnen weniger Jahre die Technik, die Linux-Container in den Mainstream der Softwareentwicklung brachte.

Der nächste Schritt wiederholte McLeans Geschichte fast wörtlich. 2015 gründeten Docker, CoreOS und weitere Unternehmen der Branche unter dem Dach der Linux Foundation die Open Container Initiative, kurz OCI, und Docker stiftete ihr sein Image-Format und seine Laufzeit (3). Die Initiative definiert heute offene Spezifikationen für Image-Formate, Laufzeiten und deren Verteilung. Ein OCI-kompatibles Image ist damit nicht an Docker gebunden. Wie im Hafen fragt am Ende niemand, wer die Kiste gepackt hat, nur ob ihre Schnittstellen zum restlichen System passen.

An dieser Stelle lohnt sich eine Unterscheidung, die den technischen Kern trifft: Ein Container ist keine virtuelle Maschine. Eine virtuelle Maschine stellt über einen Hypervisor virtuelle Hardware bereit und betreibt darauf ein eigenes Betriebssystem samt eigenem Kernel, ressourcenintensiver, aber mit einer stärkeren Trennung vom Wirtssystem. Ein Container dagegen teilt sich den Kernel des Hosts. Namespaces geben seinen Prozessen eine eigene Sicht auf System, Netzwerk und Dateisystem; Cgroups erfassen und begrenzen ihren Verbrauch von Rechenleistung, Arbeitsspeicher und weiteren Ressourcen (4). Das Ergebnis ist meist deutlich kleiner als ein vergleichbares VM-Image und startet in der Regel erheblich schneller.

Diese Sparsamkeit hat einen Preis: Container kapseln Prozesse und deren Umgebung, bringen aber keinen eigenen Kernel mit. Wer eine stärkere Sicherheitsgrenze mit eigenem Kernel benötigt, greift trotzdem zur virtuellen Maschine. Die beiden Techniken konkurrieren weniger, als dass sie sich ergänzen: In vielen Rechenzentren läuft die eine in der anderen.

Bis hierhin könnte der Eindruck entstehen, ein Container trage einen vollständigen kleinen Rechner mit sich herum. Das stimmt nur zur Hälfte, und die andere Hälfte ist die eigentlich interessante. Fest verpackt sind die Anwendung, ihre Laufzeitumgebung und die Bibliotheken, die sie braucht. Draußen bleiben der Kernel des Wirtssystems, die angebundenen Netzwerke, persistente Daten und externe Dienste, mit denen die Anwendung spricht. Zugangsdaten und kundenspezifische Konfiguration gehören ebenfalls nicht ins Paket, sie werden dem Container erst beim Start mitgegeben.

Genau genommen ist ein Image die schreibgeschützte Vorlage. Erst wenn diese Vorlage gestartet wird, entsteht daraus ein Container mit einer zusätzlichen beschreibbaren Schicht. Reproduzierbarkeit entsteht deshalb nicht allein dadurch, dass etwas in einem Container läuft. Sie entsteht, wenn Images eindeutig versioniert, Abhängigkeiten festgelegt, Konfigurationen dokumentiert und persistente Daten sauber vom kurzlebigen Container getrennt werden. Selbst ein Versionsname garantiert das nicht vollständig: Ein Tag lässt sich auf ein anderes Image verschieben, erst dessen eindeutiger Inhaltswert, der Digest, bezeichnet exakt dieselbe Vorlage. Containerisierung beseitigt die Umgebung also nicht. Sie macht sichtbar, welcher Teil davon zur Anwendung gehört und wo die Verantwortung nach außen übergeht.

Schwierig wird es, sobald viele Container über mehrere Maschinen verteilt laufen: Instanzen fallen aus, müssen neu gestartet oder bei wachsender Last vervielfacht werden. In produktiven Systemen können so schnell Dutzende oder Hunderte gleichzeitig zusammenkommen. Google stand vor diesem Problem in einer Größenordnung, die kaum ein anderes Unternehmen kannte: Das intern entwickelte System Borg verwaltete Hunderttausende Jobs aus vielen Tausend verschiedenen Anwendungen (5). 2014 ließ Google zentrale Erfahrungen aus Borg in ein neues, offenes Projekt einfließen: Kubernetes (6). Wo Docker die einzelne Kiste packt, organisiert Kubernetes den Hafen: Es verteilt Arbeitslasten auf verfügbare Maschinen, ersetzt ausgefallene Instanzen und stellt bei wachsender Last weitere bereit.

Für ein mittelständisches Unternehmen oder einen Verband ist dieser zweite Schritt keineswegs automatisch notwendig. Diese Form der Cluster-Orchestrierung entfaltet ihren Wert vor allem dort, wo Lastspitzen, Ausfallsicherheit oder Dutzende Dienste gleichzeitig verwaltet werden müssen. Für viele Projekte genügen dagegen wenige Container auf einem einzigen Host, etwa mit Docker Compose oder einer verwalteten Container-Plattform.

Zuverlässigkeit entsteht durch Container nicht automatisch. Zunächst reduzieren sie die Zahl der Variablen. Ein getestetes Image lässt sich auch später mit derselben darin festgeschriebenen Laufzeitumgebung bereitstellen, vorausgesetzt, das konkrete Image bleibt erhalten und die äußeren Abhängigkeiten werden mit derselben Sorgfalt gepflegt. Eine neue Version kann parallel getestet werden, bevor sie die laufende ersetzt. Und ein fehlgeschlagenes Update lässt sich meist in Sekunden zurückrollen, solange keine Datenbankmigration dazwischenfunkt, die sich nicht ohne Weiteres umkehren lässt.

Auch unsere Plattform atomic, mit der urbanstudio Kundenprojekte betreibt, folgt diesem Prinzip: Jede Instanz läuft in einem eigenen, klar abgegrenzten Container. Das war und ist keine Frage der Ideologie, nur der Wunsch, eine Anwendung in die Hand nehmen zu können, ohne den Rest gleich mitzunehmen.