Docker

Ohne Docker: "Bei mir läuft es, aber auf dem Server nicht!" (Der Klassiker: "It works on my machine"). Weil du Python 3.9 hast und der Server Python 3.8.

Mit Docker: Du schreibst eine Bauanleitung (Dockerfile): "Nimm Python 3.9, kopiere meinen Code rein, starte es." Docker baut daraus ein Image (die Blaupause). Aus dem Image startest du einen Container (die laufende App). Du gibst dem Kollegen das Image, und er hat garantiert 1:1 die gleiche Umgebung wie du.

Praxisbruecke: Der typische Anfängerfluss lautet: Image suchen, Container starten, Logs lesen, Port prüfen, Container stoppen. Wer diese fuenf Schritte sicher kann, versteht Docker im Alltag deutlich besser.

1. Container vs. VM (Virtuelle Maschine)

• VM: Ein ganzes Haus im Haus. Jede VM hat ein eigenes, komplettes Betriebssystem (Kernel). Schwer und langsam (Startzeit Minuten).
• Container: Ein Zelt im Haus. Alle Container teilen sich den Kernel des Wirts-Systems (Host). Leicht und schnell (Startzeit Millisekunden).

2. Docker Compose

Eine App besteht selten nur aus einem Teil. Du brauchst Webserver + Datenbank + Cache. Mit docker-compose.yml beschreibst du das ganze Orchester: "Starte Wordpress (Container A) und MySQL (Container B) und verbinde sie." Ein Befehl: docker-compose up – und die ganze Landschaft steht.

Technisch ist Docker eine Werkzeugkette aus Client, Daemon, Images, Containern, Netzwerken, Volumes und Registries. Probleme entstehen oft, wenn man diese Bausteine vermischt.

1. Architektur: Client-Server Trennung (REST API)

Viele Entwickler denken, docker auf der Command Line wäre das System selbst. Falsch. Der docker CLI Command auf deinem Mac ist nur ein "dummer" HTTP-Client. Er feuert ein JSON via cURL-artigem Stream an den UNIX-Socket /var/run/docker.sock. Dahinter sitzt erst der mächtige Docker Daemon (dockerd). Der Daemon ist das Hirn: Er baut Architektur auf, kommandiert den Kernel, pullt Images und erstellt Netzwerke. Weil es eine strikte Client/Server-REST-Trennung ist, kannst du von deinem Windows Laptop aus völlig nativ über SSH den dockerd eines AWS Amazon-Linux-Servers im Hintergrund fernsteuern.

2. Containerd und RunC (Die Evolution)

Früher war "Docker" ein einziger monolithischer Go-Block. Heute hat die Industrie Docker in Bausteine gesprengt (um Standards wie OCI zu schaffen). Der dockerd (Daemon) macht fast nichts Großes mehr. Wenn du Container startest, reicht dockerd das Kommando an containerd weiter (High-Level Runtime, gemanaged von Kubernetes/CNCF). containerd reicht das an runc weiter (Low-Level C-Runtime). runc spricht mit dem Linux-Kernel per C-Primitiven und vollzieht die Kernel-Isolation (Namespaces, cgroups), übergibt den Exec-Code und stirbt sofort wieder. Der Container "hängt" fortan lose im containerd-Sheduler. Diese massive Schichten-Architektur minimiert Crash-Flächen massiv.

3. Docker on Mac/Windows: Die Virtualisierungs-Lüge

Ein Linux-Container erfordert einen nativen Linux-Kernel zur Ausführung (da er nicht wie im VMware modell simulieren kann, was nicht da ist). Auf Linux Servern klappt Docker deswegen unfassbar gut. Wie funktionieren Docker-Container dann auf Windows und MacOS, obwohl diese keine Unix/Linux Kernel (cgroups) besitzen? Es ist ein Hack: Docker Desktop installiert heimlich eine "echte" Linux-Virtuelle-Maschine (Hyper-V / WSL2 auf Windows, oder QEMU/HyperKit auf macOS) unsichtbar in den Hintergrund deines Rechners. In dieser unsichtbaren kleinen Linux-VM rennt der Docker Daemon. Dein lokales macOS Terminal schickt nur API-Befehle durch den Hypervisor-Tunnel dorthin. Resultat: Exzellent für Entwicklung, aber grottenschlechte Performance beim I/O-Dateimount zwischen Mac-SSD und Linux-VM.