Docker — Containerisierung verändert die Spielregeln

Auf der PyCon in Santa Clara hat Solomon Hykes vor wenigen Tagen das Docker-Projekt vorgestellt — ein Tool zum Verpacken von Anwendungen in leichtgewichtige Container. Was wir gesehen haben, hat das Potenzial, die Art und Weise, wie wir Software entwickeln, testen und bereitstellen, grundlegend zu verändern. Schauen wir uns an, warum Docker so interessant ist und was es für Enterprise-Entwickler bedeutet.

Was Docker ist und warum es entstanden ist¶

Docker ist eine Open-Source-Plattform, die es ermöglicht, eine Anwendung zusammen mit all ihren Abhängigkeiten in einen standardisierten Container zu verpacken. Im Gegensatz zu virtuellen Maschinen, die komplette Hardware emulieren und einen eigenen Betriebssystemkernel ausführen, teilen Container den Kernel des Hostsystems und isolieren nur den Userspace. Das Ergebnis ist ein dramatisch geringerer Overhead — ein Container startet in Sekunden, nicht Minuten, und belegt Dutzende Megabyte statt Gigabyte.

Das Projekt entstand bei dotCloud, einem Unternehmen, das eine Platform-as-a-Service betreibt. Solomon Hykes und sein Team stellten fest, dass das interne Tool, das sie zur Verwaltung von Anwendungen auf ihrer Plattform nutzen, für die gesamte Community nützlich sein könnte. So wurde Docker als Open-Source-Projekt unter der Apache-2.0-Lizenz geboren.

Technisch basiert Docker auf zwei Schlüsseltechnologien des Linux-Kernels — cgroups (Control Groups) zur Ressourcenbegrenzung und Namespaces zur Prozessisolierung. Diese Mechanismen existieren seit Jahren in Linux, aber Docker ist das erste Tool, das sie der breiten Entwicklergemeinschaft über eine einfache Schnittstelle zugänglich macht.

Wie Docker funktioniert¶

Das grundlegende Konzept ist das Docker Image — ein schreibgeschütztes Template, das ein Betriebssystem, eine Laufzeitumgebung, Bibliotheken und eine Anwendung enthält. Images werden mit einer Datei namens Dockerfile erstellt, die die Schritte zum Aufbau der Umgebung beschreibt. Jeder Schritt erzeugt eine neue Schicht (Layer), was effizientes Teilen und Caching ermöglicht.

FROM ubuntu:12.04 RUN apt-get update && apt-get install -y python python-pip COPY requirements.txt /app/ RUN pip install -r /app/requirements.txt COPY . /app/ CMD [“python”, “/app/server.py”]

Dieses einfache Dockerfile zeigt die Stärke des Konzepts — in sechs Zeilen definieren wir eine komplette Umgebung für eine Python-Anwendung. Jeder mit dieser Datei kann ein identisches Image auf jedem Rechner mit Docker erstellen.

Ein Container wird aus einem Image erstellt — eine laufende Instanz des Images. Der Container fügt eine beschreibbare Schicht über den schreibgeschützten Image-Schichten hinzu. Änderungen im Container (neue Dateien, Konfigurationsänderungen) verbleiben in dieser obersten Schicht und verändern das ursprüngliche Image nicht. Das ist absolut entscheidend für die Reproduzierbarkeit.

Docker vs. Virtualisierung — wo die Unterschiede liegen¶

Unser Team nutzt VMware für die Produktion und VirtualBox für die Entwicklung seit Jahren. Natürlich fragen wir uns — warum sollten wir etwas anderes wollen? Die Unterschiede sind grundlegend und einer genaueren Betrachtung wert.

Performance: Eine virtuelle Maschine läuft auf einem Hypervisor und emuliert komplette Hardware. Das bedeutet eigener Kernel, eigenes Init-System, eigene Speicherverwaltung. Ein Container teilt den Kernel mit dem Host und isoliert nur Prozesse. In der Praxis bedeutet das, dass man Dutzende Container auf einem Server betreiben kann, wo man sonst nur eine Handvoll VMs hätte. Container-Start liegt im Sekundenbereich; VM-Start im Minutenbereich.

Isolation: Hier gewinnen virtuelle Maschinen nach wie vor. Volle Hardware-Virtualisierung bietet stärkere Isolation — eine kompromittierte VM kann den Host nicht leicht beeinflussen. Container teilen den Kernel, und bei einer Kernel-Schwachstelle könnte ein Angreifer theoretisch aus dem Container ausbrechen. Für sicherheitskritische Anwendungen im Bankensektor ist das eine relevante Überlegung.

Portabilität: Ein Docker Image läuft identisch auf dem Laptop des Entwicklers, auf dem Staging-Server und in der Produktion. Kein „bei mir funktioniert’s“. Das Image enthält alles — von Systembibliotheken bis zur Anwendungskonfiguration. Das ist ein enormer Vorteil gegenüber VMs, bei denen die Konsistenz zwischen Umgebungen mit Tools wie Puppet oder Chef gepflegt werden muss.

Union File System — die Schlüsselinnovation¶

Docker verwendet AUFS (Another Union File System) zur Verwaltung von Image-Schichten. Jede Anweisung im Dockerfile erzeugt eine neue Schicht. Schichten sind schreibgeschützt und werden zwischen Images geteilt — wenn zehn Ihrer Anwendungen Ubuntu 12.04 als Basis verwenden, existiert diese Schicht nur einmal auf der Festplatte. Das reduziert den Speicherbedarf dramatisch und beschleunigt das Herunterladen neuer Images.

Die beschreibbare Schicht des Containers verwendet eine Copy-on-Write-Strategie. Wenn ein Container eine Datei aus einer niedrigeren Schicht modifiziert, wird die Datei zuerst in die oberste Schicht kopiert und dann verändert. Das bedeutet, Lesezugriffe sind schnell (direkt aus der unteren Schicht), aber der erste Schreibzugriff auf eine bestehende Datei ist langsamer.

Docker Registry — Images teilen¶

Docker führt das Konzept einer Registry ein — ein zentrales Repository für Docker Images. Der öffentliche Docker Hub enthält bereits Hunderte von Images — von offiziellen Distributionen (Ubuntu, CentOS, Debian) über Datenbanken (MySQL, PostgreSQL, MongoDB) bis hin zu Applikationsservern (Nginx, Apache, Tomcat). Sie können auch eine private Registry für den internen Gebrauch betreiben, was in Enterprise-Umgebungen eine Notwendigkeit ist.

Der Workflow ist einfach: Entwickler bauen Images lokal, pushen sie in die Registry, und das Deployment-System pullt sie auf die Produktionsserver. Alle arbeiten mit demselben Artefakt — kein „aber ich hatte eine andere Version der Bibliothek” mehr.

Praktischer Einsatz — was wir ausprobiert haben¶

In unserem Team haben wir Docker an einem internen Projekt ausprobiert — einem Microservice zur Rechnungsverarbeitung. Die Anwendung ist in Java 7 geschrieben, läuft auf Tomcat 7 und verbindet sich mit einer PostgreSQL-Datenbank. Traditionell hätten wir eine WAR-Datei auf einen geteilten Tomcat-Server deployt und eine JNDI-Datasource konfiguriert. Mit Docker sind wir anders vorgegangen.

Wir haben ein Dockerfile erstellt, das von einem offiziellen OpenJDK-Image startet, Tomcat hinzufügt, die WAR-Datei kopiert und Umgebungsvariablen für die Datenbankverbindung setzt. Der gesamte Build dauert 45 Sekunden. Das resultierende Image hat 340 MB — das umfasst das Betriebssystem, JDK, Tomcat und unsere Anwendung.

Deployment auf einen Testserver? Ein Befehl: docker run -d -p 8080:8080 -e DB_HOST=postgres.internal our-invoices:1.0. In drei Sekunden läuft es. Eine neue Version gewünscht? Neues Image bauen, alten Container stoppen, neuen starten. Rollback? Die vorherige Version des Images starten. Die Einfachheit ist fast verdächtig.

Einschränkungen und Bedenken¶

Docker ist ein junges Projekt und hat seine Grenzen, die benannt werden müssen. Erstens läuft es nur unter Linux. Für Entwickler unter Mac OS X oder Windows bedeutet das, Docker in einer VM auszuführen (über Vagrant oder boot2docker). Das fügt eine Komplexitätsschicht hinzu und negiert teilweise den Einfachheitsvorteil.

Zweitens unterstützt Docker noch keine Orchestrierung mehrerer Container. Wenn Ihre Anwendung aus einem Webserver, Applikationsserver, einer Datenbank und einem Message Broker besteht, müssen Sie das Starten und Verknüpfen der Container manuell koordinieren. Für einfache Anwendungen ist das kein Problem, aber für Enterprise-Systeme mit Dutzenden von Komponenten ist es eine erhebliche Einschränkung. Wir erwarten, dass die Community bald Orchestrierungstools liefern wird.

Drittens die Datenpersistenz. Ein Container ist kurzlebig — alle Änderungen in der beschreibbaren Schicht gehen verloren, wenn er gestoppt wird. Für zustandslose Anwendungen ist das kein Problem, aber für Datenbanken und andere zustandsbehaftete Daten müssen Docker Volumes verwendet werden, die ein Verzeichnis vom Host in den Container abbilden. Die Volume-Verwaltung ist noch recht primitiv.

Viertens Monitoring und Logging. Traditionelle Tools wie Nagios oder Zabbix gehen davon aus, dass die Anwendung direkt auf einem Server läuft. Container fügen eine Abstraktionsschicht hinzu, die diese Tools noch nicht gut verarbeiten können. Wir werden neue Ansätze für das Monitoring benötigen.

Auswirkungen auf die CI/CD-Pipeline¶

Wo wir das größte Potenzial von Docker sehen, ist Continuous Integration und Continuous Delivery. Heute baut unser CI-Server (Jenkins) die Anwendung, führt Tests aus und erstellt ein deploybare Artefakt (WAR, JAR, RPM). Mit Docker wird das Artefakt das Image selbst — es enthält nicht nur die Anwendung, sondern die gesamte Umgebung.

Das eliminiert eine ganze Klasse von Problemen. Es wird nicht mehr vorkommen, dass ein Test auf dem CI-Server besteht, aber in der Produktion wegen einer anderen Version einer Systembibliothek fehlschlägt. Das Image, das die Tests bestanden hat, ist identisch mit dem Image, das in der Produktion laufen wird. Kein anderes Tool gibt uns diese Garantie.

Darüber hinaus ermöglicht Docker paralleles Testen. Die Anwendung muss gegen PostgreSQL 9.1 und 9.3 getestet werden? Zwei Container mit verschiedenen Datenbankversionen starten und die Tests laufen parallel. Ohne Docker bräuchten wir zwei separate Server oder eine komplexe Konfiguration auf einem.

Was das für Enterprise bedeutet¶

Ist Docker bereit für den produktiven Enterprise-Einsatz? Heute, im März 2013, ehrlich gesagt — noch nicht. Das Projekt befindet sich in einem sehr frühen Stadium, die API ändert sich, die Dokumentation ist spärlich und die Community bildet sich erst. Aber die Richtung ist klar und das Potenzial enorm.

Für unsere Kunden im Bank- und Versicherungssektor sehen wir Docker als den zukünftigen Standard für Application Deployment. Stellen Sie sich eine Welt vor, in der jede Anwendung in ihrem eigenen isolierten Container mit exakt definierten Abhängigkeiten läuft. Wo Deployment einen Befehl und Rollback einen anderen bedeutet. Wo die Entwicklungsumgebung identisch mit der Produktion ist. Das ist die Welt, die Docker verspricht.

Wir empfehlen, jetzt mit dem Experimentieren zu beginnen. Probieren Sie Docker bei internen Projekten aus, lernen Sie die Konzepte, verstehen Sie die Einschränkungen. Wenn Docker für die Produktion bereit ist — und wir sind überzeugt, dass das innerhalb von ein bis zwei Jahren passieren wird — werden Sie bereit sein, es einzusetzen.

Vergleich mit LXC¶

Linux Containers (LXC) existieren länger als Docker und bieten ähnliche Funktionalität auf einer niedrigeren Ebene. Docker verwendete ursprünglich LXC als Backend für die Container-Verwaltung. Der Hauptunterschied liegt im Abstraktionsgrad — LXC bietet eine Low-Level-API für die Container-Verwaltung, während Docker Konzepte wie Images, Dockerfiles, Registries und Versionierung hinzufügt. Es ist der Unterschied zwischen Assembler und einer Hochsprache.

Für Systemadministratoren, die an die Arbeit mit LXC gewöhnt sind, mag Docker unnötig abstrakt erscheinen. Für Entwickler, die einfach nur ihre Anwendung verpacken und ausführen wollen, ist Docker deutlich zugänglicher. Und es ist die Zugänglichkeit, die über die Adoption einer Technologie entscheidet.

Die Zukunft der Containerisierung¶

Docker ist nicht der einzige Akteur im Bereich der Containerisierung. Google nutzt intern eine Container-Technologie namens Borg seit mehr als zehn Jahren und betreibt damit praktisch alle seine Dienste. Die Tatsache, dass Google zwei Milliarden Container pro Woche startet, beweist, dass Containerisierung in enormem Maßstab funktioniert.

Wir erwarten, dass Docker ein ganzes Ökosystem katalysieren wird — Tools für Orchestrierung, Monitoring, Networking und Container-Sicherheit. Es ist möglich, dass in fünf Jahren das Deployment einer Anwendung ohne Container genauso archaisch wirken wird wie heute ein Deployment ohne Versionskontrollsystem.

Fazit und Empfehlung¶

Docker ist eine der bedeutendsten Technologien, die wir in den letzten Jahren gesehen haben. Es verspricht ein Ende des „bei mir funktioniert’s“-Problems, dramatisch schnellere Deployments und eine bessere Auslastung der Serverressourcen. Das Projekt ist jung, aber die Richtung ist klar.

Unsere Empfehlung: Beginnen Sie zu experimentieren. Installieren Sie Docker, erstellen Sie ein Dockerfile für eine Ihrer Anwendungen, verstehen Sie die Konzepte von Images und Containern. Wenn Docker für die Produktion ausgereift ist, werden Sie bereit sein.