Was ist Docker?

Das Problem, das Docker löst

Software hat Abhängigkeiten: bestimmte Versionen von Sprachen, Bibliotheken, Systemtools. Auf verschiedenen Rechnern unterscheiden sich diese — und die App verhält sich anders. Docker packt alles in einen isolierten Container, der überall gleich startet.

Image und Container

• Image: die unveränderliche Vorlage (Bauplan der Anwendung)
• Container: eine laufende Instanz eines Images
• Dockerfile: das Rezept, aus dem ein Image gebaut wird

FROM node:22-alpine
WORKDIR /app
COPY . .
RUN npm ci && npm run build
CMD ["node", "server.js"]

Images bestehen aus Schichten

Ein Docker-Image entsteht nicht am Stück, sondern in Schichten: Jede Anweisung im Dockerfile fügt eine neue Ebene hinzu. Das hat einen praktischen Nutzen — Docker speichert unveränderte Schichten zwischen und baut nur das neu, was sich geändert hat. Ändert man nur den eigenen Code, müssen die Basis und die installierten Abhängigkeiten nicht erneut geladen werden. Dieser Cache macht wiederholte Builds sehr schnell, wenn man das Dockerfile geschickt anordnet: Selten Geändertes nach oben, häufig Geändertes nach unten.

Registries: Images teilen

Fertige Images müssen nicht auf dem eigenen Rechner bleiben. Eine Registry wie Docker Hub ist ein zentraler Speicher, aus dem man Images herunterlädt („pull“) oder in den man eigene hochlädt („push“). Genau das steckt hinter Zeilen wie FROM node:22-alpine: Docker holt sich ein offizielles, vorbereitetes Basis-Image aus der Registry. In der Praxis baut eine CI/CD-Pipeline das Image, lädt es in eine Registry und der Server zieht es von dort — überall exakt dasselbe.

Container statt virtueller Maschine

Eine virtuelle Maschine bringt ein komplettes Betriebssystem mit — das kostet Gigabyte an Speicher und Minuten beim Start. Ein Container teilt sich stattdessen den Kernel des Host-Systems und enthält nur die Anwendung samt ihren Abhängigkeiten. Dadurch startet er in Sekundenbruchteilen und verbraucht kaum Ressourcen. Auf einem einzigen Server lassen sich so viele Container gleichzeitig betreiben. Genau diese Leichtigkeit ist der Grund, warum sich Docker als Standard für moderne Bereitstellung durchgesetzt hat.

Isolation: was ein Container nicht sieht

Ein Container läuft in seiner eigenen kleinen Welt. Er hat ein eigenes Dateisystem, eigene Prozesse und eine eigene Netzwerkumgebung — von den übrigen Containern auf demselben Rechner bekommt er nichts mit, solange man es nicht ausdrücklich erlaubt. Genau darin liegt der Nutzen: Zwei Anwendungen dürfen unterschiedliche Versionen derselben Bibliothek verlangen, ohne sich in die Quere zu kommen. Diese Abschottung hat allerdings eine Konsequenz, die Einsteiger regelmäßig überrascht: Alles, was ein Container während seiner Laufzeit schreibt, ist beim nächsten Start wieder verschwunden. Daten, die überdauern sollen, gehören deshalb in ein Volume außerhalb des Containers.

Wenn mehrere Container zusammenspielen

Selten besteht eine Anwendung aus nur einem Container. Typisch sind drei: die Anwendung selbst, eine Datenbank und ein Cache. Damit sie einander erreichen, legt man sie in ein gemeinsames Docker-Netzwerk — dort sprechen sie sich schlicht über ihren Dienstnamen an, ohne dass IP-Adressen fest hinterlegt werden müssen. Beschrieben wird dieses Zusammenspiel in einer Compose-Datei, die alle Dienste, ihre Abhängigkeiten und ihre Konfiguration festhält. Aus einem unübersichtlichen Handgriff wird so eine Datei im Repository, die auf jedem Rechner dieselbe Umgebung erzeugt.

Wann ein Container läuft – und wann nicht mehr

Ein Container ist an genau einen Hauptprozess gebunden: Solange dieser läuft, läuft der Container; endet er — ordentlich oder durch einen Absturz —, ist auch der Container beendet. Das erklärt die häufigste Verwunderung von Einsteigern, deren Container sofort nach dem Start wieder verschwindet: Der hinterlegte Startbefehl war schlicht nach einer Sekunde fertig. Für den Dauerbetrieb legt man deshalb fest, wie sich Docker bei einem Abbruch verhalten soll, etwa durch automatischen Neustart. Ergänzend lässt sich eine Prüfung hinterlegen, die regelmäßig testet, ob die Anwendung im Inneren noch antwortet — sonst gilt ein hängender Prozess weiterhin als „läuft“.