Virtuelle Maschinen und Docker: ein schweres Haus und ein leichtes Zelt

„Installieren Sie eine Linux-VM und bauen Sie die Umgebung identisch nach.“

Drei Monate nach meinem Einstieg war die Stimmung im Büro angespannt. Unser einziger Senior wurde auf ein anderes Projekt versetzt und war so sehr mit dem Packen seiner Sachen beschäftigt, dass von Übergabe kaum die Rede sein konnte. Der Teamleiter hatte sich dagegen schon lange aus der eigentlichen Entwicklungsarbeit zurückgezogen und war von aktuellen Technologietrends weit entfernt.

Eines Tages rief mich der Teamleiter zu sich. „Wenn Ihr Senior weg ist, sind Sie der Einzige, der die Server noch betreuen kann. Selbst wenn der Server ausfällt, müssen Sie ihn allein wiederherstellen können. Installieren Sie Linux als virtuelle Maschine, VM, auf Ihrem aktuellen Entwicklungs-Laptop, also Windows, und bauen Sie exakt dieselbe Umgebung wie auf dem Produktivserver nach.“

Ab diesem Tag begann mein Elend. Ich installierte VMware, lud die Ubuntu-ISO herunter, und allein die Installation fraß einen halben Tag. Ich durchsuchte das Firmen-Wiki, um Java, Node.js und PostgreSQL einzurichten. „Neu ist bestimmt besser“, dachte ich und installierte Java 17, nur um festzustellen, dass der Legacy-Code auf Java 8 basierte und nicht einmal baute. Also alles wieder löschen und neu installieren. Jedes Mal, wenn ich nur eine Zeile Code änderte, musste ich mvn build ausführen, die jar-Datei in die VM schieben und dort starten. Es war reiner Schmerz.

Dann kam mir plötzlich eine Frage. „Moment mal. Beim letzten Deployment auf den Produktivserver hat doch einfach ein einziger docker service update-Befehl gereicht, oder?“

Meine lokale virtuelle Maschine war so schwerfällig und voller Konfigurationsaufwand. Was war also dieses Ding namens Docker auf dem Produktivserver, das mit nur einem Befehl ein Update erledigte?

Die schwere Lösung: die virtuelle Maschine

Die Methode, die mir der Teamleiter aufgetragen hatte, also Linux auf Windows zu installieren, ist genau das, was eine virtuelle Maschine, VM, ist. Man baut auf einem physischen Rechner, dem Host, ein komplettes ‘virtuelles Haus’, also ein Guest OS.

• Funktionsweise: Auf einem einzigen Computer laufen mehrere Betriebssysteme, etwa Linux auf Windows und darauf noch einmal Linux…
• Problem: Wer ein Haus baut, muss alles neu errichten: Stützen, Wände und sogar das Badezimmer, also den Kernel.
  • Nur um eine einzige App laufen zu lassen, muss man ein mehrere Gigabyte großes OS komplett installieren.
  • Das Booten dauert eine Ewigkeit. Genau deshalb war mein Laptop so langsam geworden.
  • Ressourcen werden ineffizient genutzt. Selbst wenn gar nichts passiert, frisst allein der Betrieb des OS Arbeitsspeicher.

Am Ende isoliert eine VM die Umgebung zwar zuverlässig, aber für Entwicklung oder Deployment ist sie einfach zu schwer und zu langsam, um sie ständig hin und her zu bewegen.

Die leichte Revolution: Docker

Genau deshalb entstand Docker, also die Container-Technologie. Docker baut nicht wie eine VM ein komplettes Haus. Es spannt stattdessen ein Zelt auf.

• Funktionsweise: Docker teilt sich den Garten, also den Kernel, eines bereits gebauten Hauses, des Host-OS, hier Linux. Es spannt nur isolierte Zelte auf, die Container.
• Merkmale:
  • Das OS, also der Kernel, wird geteilt: Im Zelt gibt es kein schweres OS. Darin stecken nur meine App und ihre Bibliotheken.
  • Leicht: Die Größe wird in Megabyte, also MB, gemessen.
  • Schnell: Booten? Gibt es nicht. Ein Container startet so schnell, wie man einen einzelnen Prozess startet, also in Millisekunden.

Der update-Befehl, den ich auf dem Produktivserver ausführte, installierte also kein schweres Betriebssystem neu. Er bedeutete nur: „Altes Zelt abbauen, neues Zelt mit der neuen Code-Version wieder aufstellen.“ Natürlich musste das in Sekundenschnelle fertig sein.

[Code Verification] Ist Docker wirklich so leichtgewichtig?

Reden wir nicht nur davon, dass Docker leicht ist, sondern überprüfen wir es wirklich. Wenn man eine Linux-, also Ubuntu-, Umgebung starten will, ist der Unterschied zwischen VM und Docker drastisch.

1. Ubuntu als VM starten: ISO-Datei herunterladen (2 GB) -> Installation (20 Minuten) -> Booten (1 Minute).
2. Ubuntu mit Docker starten:

# Ubuntu mit Docker-Befehl starten (bei fehlendem Image wird heruntergeladen)
$ docker run -it ubuntu:latest /bin/bash

Ergebnis:

• Download: etwa 30 MB, ein abgespecktes Image, das nur den Kern von Ubuntu enthält
• Startzeit: etwa 0,5 Sekunden

Kaum hatte ich Enter gedrückt, war ich schon in einer Ubuntu-Umgebung. Möglich ist das, weil ein Docker-Container kein echtes Betriebssystem ist. Er ist nur „ein isolierter Raum, der sich den Kernel des Host-OS, also meines Rechners, leiht und dabei so tut, als wäre er ein eigenes OS.“

Praxis-Tipp: der wahre Grund für Docker

Seit wir Docker im Arbeitsalltag eingeführt haben, hat sich mein Leben komplett verändert.

1. „Richten Sie Ihre Umgebung ein“ gibt es nicht mehr: Früher bekamen neue Mitarbeiter ein zehnseitiges A4-Dokument nach dem Motto „Java installieren, Umgebungsvariablen setzen, DB aufsetzen…“ in die Hand gedrückt. Heute heißt es nur noch: „Installieren Sie Docker und geben Sie docker-compose up ein.“
2. Raus aus der Versionshölle: Was, wenn Projekt A Java 8 und Projekt B Java 17 braucht? Installiert man beides lokal, gibt es Konflikte und alles gerät durcheinander. Mit Docker packt man Java 8 in Container A und Java 17 in Container B und kann beide gleichzeitig starten, ganz ohne Probleme. Denn die beiden sind vollständig voneinander ‘isoliert’, Stichwort Isolation.

Zum Schluss: Wir liefern nicht nur eine Datei, sondern eine ganze Umgebung

Mit Docker hat sich das Entwicklungsparadigma verändert. Wir schicken nicht mehr nur den Quellcode, .java, auf den Server. Wir frieren die OS-Einstellungen, Bibliotheken und Umgebungsvariablen, die der Code braucht, in einem ‘Image’ ein und schicken das ganze Paket.

Doch wie wird dieses magische ‘Docker-Image’ eigentlich erzeugt? Ist es nur eine komprimierte Datei? Überraschenderweise ist ein Docker-Image wie ein Kuchen aus mehreren Schichten, also Layern, aufgebaut.

Beim nächsten Mal schauen wir uns das Geheimnis hinter Dockers Effizienz genauer an: Images und ihre Layer-Struktur.