Docker — Erste Schritte mit Containern für Java-Entwickler

Beim letzten Java User Group Treffen in Prag hat jemand Docker erwähnt. Angeblich die Zukunft des Deployments, angeblich ändert es alles. Ich gebe zu, dass ich skeptisch war — nach fünfzehn Jahren in der IT habe ich „das ändert alles” schon oft gehört. Aber nach einem Wochenende des Experimentierens muss ich sagen: Docker ist interessant. Sehr interessant.

Was Docker ist (und was nicht)¶

Docker ist im Wesentlichen leichtgewichtige Virtualisierung auf Betriebssystemebene. Statt einer vollständigen virtuellen Maschine (mit eigenem Kernel, Init-System und allem) erstellt Docker einen isolierten Prozess, der sich den Kernel mit dem Host-System teilt. Das Ergebnis: Ein Container startet in Sekunden statt Minuten, braucht Megabytes statt Gigabytes und läuft mit minimalem Overhead.

Es ist nicht wirklich neu — Linux-Container (LXC) gibt es seit Jahren. Was Docker hinzugefügt hat, ist die Benutzerfreundlichkeit. Dockerfile, Image Registry (Docker Hub), Layered Filesystem — all das macht Container zu etwas, das jeder Entwickler beherrschen kann, nicht nur ein Linux-Guru.

Unser erstes Dockerfile — Java EE auf Tomcat¶

Wir fingen einfach an. Wir haben eine interne Anwendung auf Apache Tomcat 7 — eine einfache WAR-Datei, eine REST-API für mobile Clients. Das Dockerfile sieht überraschend einfach aus:

FROM tomcat:7-jre7
COPY myapp.war /usr/local/tomcat/webapps/
EXPOSE 8080
CMD ["catalina.sh", "run"]

Vier Zeilen. Das Erstellen des Images dauert wenige Sekunden. Das Starten des Containers eine Sekunde. Und die Anwendung läuft identisch auf meinem MacBook, auf dem Linux meines Kollegen und auf dem Testserver. „Works on my machine” ist tot.

Warum Docker uns begeistert hat¶

Reproduzierbarkeit. Ein Image ist unveränderlich. Was man baut, das bekommt man. Kein „auf dem Server fehlt eine Bibliothek” oder „dort ist eine andere Java-Version installiert”.

Isolierung. Jeder Container hat sein eigenes Dateisystem, Netzwerk und seine eigenen Prozesse. Zwei Container auf demselben Server stören sich nicht gegenseitig.

Geschwindigkeit. Ein neuer Entwickler im Team? Image pullen, docker run, und in einer Minute hat er eine laufende Entwicklungsumgebung. Statt zwei Tagen Laptop-Einrichtung.

Warum Docker uns beunruhigt hat¶

Produktiveinsatz? Docker ist Version 0.9. Ja, Null-Neun. Auf der Produktion eines Bankensystems setzen wir das noch nicht ein. Stabilität, Sicherheit, Monitoring — all das steckt noch im „Early Adopter”-Stadium.

Persistenz. Ein Container ist flüchtig — wenn man ihn stoppt, sind die Daten weg. Volume Mounts lösen die Persistenz, aber die Volume-Verwaltung ist noch rudimentär. Für Datenbanken in Containern sehe ich das als Problem.

Networking. Container verbinden ist per –link einfach. Aber was ist mit Load Balancing, Service Discovery, SSL-Terminierung? Dafür hat Docker (noch) keine Antwort. Es gibt Gerüchte über Orchestrierung und Clustering, aber das ist Zukunftsmusik.

Windows. Docker läuft auf Linux. Die Hälfte unseres Teams hat Windows. Boot2Docker (eine VM mit Linux) ist ein Workaround, keine Lösung. Wir hoffen, dass Microsoft Docker irgendwann nativ unterstützt.

Wo wir Docker jetzt einsetzen¶

Ausschließlich in Entwicklung und Testing:

• Lokale Entwicklungsumgebung — vollständiger Stack in docker-compose
• CI-Build-Agents — saubere Build-Umgebung im Container
• Demo-Umgebungen für Kunden — schnelles Setup auf jedem Server
• Experimentieren mit neuen Technologien (Elasticsearch, MongoDB)

In der Produktion? Noch nicht. Aber wir beobachten die Entwicklung aufmerksam. Ich habe das Gefühl, dass die Situation in ein oder zwei Jahren anders aussehen wird.

Docker verdient Ihre Aufmerksamkeit¶

Ich sage nicht, dass Sie morgen alles in Container umschreiben sollten. Aber Docker ist eine Technologie, die Sie kennen sollten. Installieren Sie es, versuchen Sie eine Ihrer Anwendungen zu containerisieren, spielen Sie mit docker-compose. Ich wette, es wird Sie begeistern.