Docker einfach erklärt: Software überall gleich starten

Das löst ein bekanntes Problem: Auf dem Laptop funktioniert die Software, auf dem Server fehlt aber eine Bibliothek oder es läuft eine andere Version. Docker nimmt viele dieser Unterschiede aus dem Spiel. Ganz automatisch „überall gleich“ läuft eine Anwendung trotzdem nicht. Prozessorarchitektur, Betriebssystem, Daten, Geheimnisse, Netzwerk und Updates bleiben wichtig.

Meine kurze Empfehlung: Docker lohnt sich besonders für Teams, die dieselbe Anwendung mehrmals aufbauen, testen oder ausliefern. Für eine einzelne, stabile Anwendung ohne Umgebungsprobleme kann eine direkte Installation einfacher sein.

Für wen ist Docker sinnvoll?

Docker passt gut, wenn du:

• mit mehreren Entwicklern an derselben Software arbeitest,
• eine Web-App oder API zuverlässig bereitstellen möchtest,
• Test-, Staging- und Produktionsumgebung näher zusammenbringen willst,
• mehrere Dienste wie Web-App, Datenbank und Cache lokal starten musst,
• eine Anwendung auf einem neuen Server reproduzierbar einrichten willst.

Docker ist nicht automatisch die beste Wahl, wenn niemand im Team Container betreiben kann, eine fertige SaaS-Lösung das Problem bereits löst oder du ein kleines Programm nur einmal auf einem Rechner startest.

Was ist Docker – ohne Fachchinesisch?

Stell dir ein Image wie einen versiegelten Baukasten vor. Darin liegen das Programm, die benötigten Werkzeuge und eine Anleitung zum Start. Ein Container ist der aufgebaute Baukasten in Aktion.

Du kannst aus einem Image mehrere Container starten. Änderst du einen laufenden Container, ändert das nicht den Bauplan. Für eine neue Version baust du ein neues Image und ersetzt den alten Container. Dieses Wegwerfen und Ersetzen ist gewollt: Die Anwendung soll berechenbar neu entstehen können.

Ein Container ist keine kleine virtuelle Maschine. Eine virtuelle Maschine bringt ein vollständiges Gastbetriebssystem mit eigenem Kernel mit. Container sind isolierte Prozesse und teilen sich grundsätzlich den Kernel ihrer Umgebung. Deshalb sind sie meist leichter als VMs. Auf macOS und Windows stellt Docker Desktop die nötige Linux-Umgebung im Hintergrund bereit.

So funktioniert Docker Schritt für Schritt

Der typische Ablauf besteht aus sechs einfachen Schritten:

1. Du beschreibst deine Anwendung in einem Dockerfile.
2. Docker baut daraus ein Image.
3. Optional lädst du das Image in eine Registry.
4. Ein Rechner lädt genau dieses Image und startet daraus einen Container.
5. Konfiguration und Geheimnisse kommen beim Start hinzu; dauerhafte Daten liegen außerhalb des Containers.
6. Für ein Update baust du ein neues Image, prüfst es und ersetzt den laufenden Container kontrolliert.

Ein erster Container zum Ausprobieren

Wenn Docker bereits installiert ist, startet dieser Befehl das offizielle Lern-Image von Docker:

docker run -d --name docker-demo -p 127.0.0.1:8080:80 docker/welcome-to-docker

Danach öffnest du http://localhost:8080. Der Teil 127.0.0.1:8080:80 leitet den lokalen Port 8080 an Port 80 im Container weiter. Durch 127.0.0.1 bleibt der Dienst auf diesem Rechner erreichbar, statt ihn unbeabsichtigt an allen Netzwerkschnittstellen freizugeben.

Mit diesen Befehlen stoppst und entfernst du den Test:

docker stop docker-demo
docker rm docker-demo

Das Beispiel zeigt den Kern: Docker lädt ein Image, erzeugt daraus einen Container und verbindet einen Port. Es beweist noch nicht, dass eine eigene Anwendung produktionsreif ist.

Wozu dient Docker Compose?

Eine echte Anwendung besteht oft aus mehreren Teilen. Eine Web-App braucht vielleicht eine Datenbank und einen Cache. Docker Compose hält deren Images, Ports, Netzwerke, Volumes und Konfiguration in einer gemeinsamen compose.yaml fest. Mit docker compose up lässt sich der beschriebene Verbund starten.

Ich halte Compose für den verständlichsten Einstieg, sobald mehr als ein Container beteiligt ist. Eine gepflegte Datei ist leichter zu prüfen als lange Befehle, die nur in der Shell-Historie stehen.

Image, Container und Volume: Wo bleiben die Daten?

Der Container selbst sollte austauschbar sein. Daten, die bleiben müssen – etwa hochgeladene Dateien oder eine Datenbank – gehören in ein Volume oder einen externen Speicherdienst. Docker verwaltet Volumes unabhängig vom Lebenszyklus eines einzelnen Containers.

Wichtig: Ein Volume ist noch kein Backup. Wird eine Datei im Volume gelöscht oder beschädigt, kann der Fehler ebenfalls dauerhaft sein. Lege deshalb fest, was gesichert wird, wo die Sicherung liegt und wie eine Wiederherstellung getestet wird.

„Überall gleich“ hat drei Ebenen

Der Werbesatz klingt absoluter, als er ist. Für eine saubere Entscheidung hilft diese Dreiteilung:

1. Gleich gebaut: Alle nutzen dasselbe Image – idealerweise eine eindeutig festgelegte Version oder einen Digest.
2. Gleich gestartet: Ports, Umgebungsvariablen, Volumes, Geheimnisse und CPU-Architektur passen zur Zielumgebung.
3. Gleich betrieben: Updates, Backups, Protokolle, Überwachung und Wiederanlauf sind ebenfalls geregelt.

Docker löst vor allem die erste Ebene und hilft bei der zweiten. Die dritte bleibt Betriebsarbeit. Genau dort entstehen meiner Meinung nach die meisten falschen Erwartungen: Ein erfolgreich gebautes Image ist noch kein zuverlässiger Dienst.

Auch die Hardware zählt. Ein Image für linux/amd64 ist nicht automatisch ein natives linux/arm64-Image. Multi-Plattform-Images können mehrere passende Varianten enthalten; alternativ kommen Emulation oder ein neuer Build infrage.

Wann Docker eine gute Entscheidung ist

Gute Szenarien

• Gemeinsame Entwicklungsumgebung: Neue Teammitglieder müssen nicht jede Laufzeit und Datenbankversion einzeln zusammensuchen.
• Wiederholbare Auslieferung: Dasselbe geprüfte Image wandert von der Testumgebung zum Server.
• Abhängigkeiten trennen: Zwei Projekte können unterschiedliche Versionen derselben Laufzeit verwenden.
• Mehrere Dienste lokal starten: Compose beschreibt Web-App, Datenbank und Cache an einer Stelle.
• Kurzlebige Testumgebungen: Ein Container lässt sich neu erzeugen, ohne den Rechner dauerhaft umzubauen.

Wann ich eher darauf verzichten würde

• Eine einzelne Anwendung läuft stabil, wird selten geändert und das Team gewinnt durch Container keinen klaren Vorteil.
• Niemand ist für Image-Updates, Registry-Zugänge, Volumes, Logs und Wiederherstellung verantwortlich.
• Eine vollständig verwaltete Plattform oder SaaS-Lösung erfüllt den Bedarf mit deutlich weniger Betriebsarbeit.
• Die Anwendung braucht sehr enge Hardware- oder Betriebssystemintegration, die im Container unnötig kompliziert wird.

Docker kann Komplexität verschieben, nicht verschwinden lassen. Du tauschst manuelle Installation gegen Images, Konfigurationsdateien und Container-Betrieb. Das ist ein guter Tausch, wenn diese Dateien wiederholt genutzt und gepflegt werden.

Die wichtigsten Risiken für Einsteiger

1. Veraltete Images

Ein altes Image enthält auch alte Bibliotheken. Nutze vertrauenswürdige Basis-Images, baue regelmäßig neu und teste Updates. Ein unveränderliches Image ist reproduzierbar, aber nicht automatisch dauerhaft sicher.

2. Geheimnisse im Image

Passwörter, API-Schlüssel und private Schlüssel gehören nicht in Dockerfile, Quellcode oder Image. Für den Build dokumentiert Docker spezielle Secret-Mounts, weil Build-Argumente und Umgebungsvariablen im fertigen Image Spuren hinterlassen können.

3. Zu offen veröffentlichte Ports

Ein veröffentlichter Port ist standardmäßig möglicherweise von anderen Rechnern erreichbar. Binde lokale Tests an 127.0.0.1 und entscheide beim Serverbetrieb bewusst, welche Dienste über Reverse Proxy, Firewall und HTTPS erreichbar sein sollen.

4. Container mit zu vielen Rechten

Container sind isoliert, aber keine unüberwindbare Sicherheitsmauer. Gib einem Container nur die Rechte, Mounts und Netzwerkzugänge, die er wirklich braucht. Der Zugriff auf den Docker-Daemon ist besonders mächtig.

5. Daten ohne Wiederherstellungstest

Bewahre dauerhafte Daten außerhalb des austauschbaren Containers auf. Sichere sie getrennt und teste die Rücksicherung. Erst ein erfolgreicher Restore zeigt, dass die Sicherung brauchbar ist.

6. Kein Blick auf den laufenden Dienst

Container machen Fehler nicht unsichtbar. Prüfe Gesundheitszustand, Logs, Speicherplatz und Antwortzeiten. Für kleine Teams reicht am Anfang oft ein ruhiges Fehlermonitoring mit wenigen sinnvollen Alarmen.

Entscheidung in fünf Fragen

1. Welches konkrete Problem löst Docker für uns?
2. Können wir das Image eindeutig versionieren und regelmäßig aktualisieren?
3. Wo liegen dauerhafte Daten, und wurde ihre Wiederherstellung getestet?
4. Wer pflegt Geheimnisse, Ports, Rechte, Logs und Sicherheitsupdates?
5. Passt das Image zur Zielplattform und lässt sich der Start dokumentiert wiederholen?

Wenn auf die ersten drei Fragen keine klare Antwort existiert, würde ich noch nicht produktiv starten. Baue zuerst einen kleinen Testdienst, dokumentiere Update und Restore und entscheide dann.

Häufige Fragen

Ist Docker dasselbe wie eine virtuelle Maschine?

Nein. Eine VM virtualisiert einen ganzen Rechner mit eigenem Gastbetriebssystem. Ein Container ist ein isolierter Prozess mit den benötigten Dateien. In der Praxis können beide zusammenarbeiten.

Läuft ein Docker-Container wirklich überall gleich?

Er läuft dort weitgehend gleich, wo eine passende Container-Laufzeit, Architektur und Konfiguration vorhanden sind. Daten, Geheimnisse, Netzwerkzugänge und externe Dienste müssen weiterhin passen.

Brauche ich für Docker sofort Kubernetes?

Nein. Für einen einzelnen Server oder eine lokale Entwicklungsumgebung reichen Docker Engine beziehungsweise Docker Desktop und oft Docker Compose. Kubernetes löst Probleme größerer, verteilter Container-Landschaften und wäre für einen kleinen Einstieg meist unnötige Komplexität.

Bleiben Daten erhalten, wenn ich einen Container lösche?

Nur Daten außerhalb seiner beschreibbaren Schicht bleiben erhalten. Ein benanntes Volume kann einen Container überleben. Trotzdem brauchst du ein Backup- und Restore-Konzept.

Ist Docker automatisch sicher?

Nein. Docker bietet Isolation und Sicherheitsmechanismen, aber sichere Images, geringe Rechte, geschützte Geheimnisse, begrenzte Ports und regelmäßige Updates bleiben deine Aufgabe.

Fazit

Docker ist vor allem ein Werkzeug für wiederholbare Softwarepakete. Das Image ist der Bauplan, der Container die laufende Ausführung und das Volume der Platz für dauerhafte Daten.

Mein Maßstab ist einfach: Wenn Docker Aufbau, Test und Update sichtbar vereinheitlicht, lohnt sich der zusätzliche Betrieb. Wenn es nur eine weitere Schicht ohne klares Problem einführt, ist die einfachere Installation oft die bessere Entscheidung.