Docker-Architektur: Client, Daemon, Registry

Wenn du docker run nginx in der Konsole tippst, läuft eine erstaunlich aufwändige Kette von Aktionen ab. Hinter Docker steckt nicht ein einzelnes Programm, sondern eine Client-Server-Architektur mit klar abgegrenzten Komponenten – Client, Daemon, Registry, Runtime. Jede hat eine spezifische Aufgabe, und sie kommunizieren über definierte Schnittstellen. Wer diese Architektur versteht, kann nicht nur Docker professionell einsetzen, sondern auch Fehler diagnostizieren und Sicherheitsentscheidungen treffen. In der IHK-Prüfung wird gerne abgefragt: „Welche Komponente macht was?" – und genau diese Frage beantwortet die Lektion.

Die Analogie: Stell dir Docker wie einen Restaurant-Lieferdienst vor. Du, der Gast (Client), bestellst per App eine Pizza. Die Bestellung geht an die Restaurantküche (Daemon), die die Pizza zubereitet. Die Zutaten holt die Küche aus dem Großhandel (Registry) – wenn sie nicht schon im Vorrat sind. Den Ofen, in dem die Pizza letztlich gebacken wird, bedient ein spezialisierter Koch (Container Runtime). Du als Gast siehst nur das fertige Ergebnis – die ganze Logistik dahinter läuft im Hintergrund.

1) Die Hauptkomponenten im Überblick

Eine produktive Docker-Installation besteht aus vier Hauptkomponenten, die zusammenarbeiten. Hier sind sie kompakt – wir betrachten danach jede einzeln:

2) Das Architekturbild – wie sprechen die Komponenten?

Schau dir an, wie ein docker run-Befehl durch die Architektur läuft. Die Komponenten kommunizieren über klar definierte Schnittstellen:

3) Der Docker Client – die Schnittstelle für Menschen

Der Docker Client ist das Programm docker, das du auf der Kommandozeile aufrufst. Er spricht die Docker Engine API – eine REST-Schnittstelle. Standardmäßig kommuniziert er über einen Unix-Socket (/var/run/docker.sock), kann aber auch TCP/TLS für Remote-Zugriffe nutzen.

Wichtig zu verstehen: Der Client führt selbst nichts aus. Er übersetzt nur deinen Befehl in einen API-Call und schickt ihn an den Daemon. Wenn du docker images tippst, ruft er GET /v1.43/images/json auf. Die ganze Arbeit – Image-Liste zusammenstellen, JSON formatieren, ausgeben – erledigt der Daemon. Der Client formatiert nur das Ergebnis schön für dich.

Konsequenz für die Sicherheit: Wer Zugriff auf den Docker-Socket hat, kann beliebige Container starten – auch privilegierte. Der Docker-Socket ist effektiv Root-Zugriff auf den Host. Deshalb gehört der User-Account, der Docker benutzen darf, in die Gruppe docker, aber nicht jeder Benutzer in diese Gruppe. Mehr in der Lektion Sicherheit in Docker-Umgebungen.

4) Der Daemon – das Herzstück

Der Docker Daemon (dockerd) ist der eigentliche Server-Prozess. Er läuft permanent im Hintergrund (typischerweise als systemd-Service) und übernimmt alle „echten" Aufgaben:

• Image-Verwaltung: Pull/Push zu Registries, Image-Cache, Layer-Speicherung, Garbage Collection alter Images
• Container-Lifecycle: Create, Start, Stop, Restart, Remove – mit allen Statusübergängen
• Netzwerk: Bridge-Netzwerke anlegen, IP-Adressen vergeben, NAT-Regeln in iptables einrichten
• Storage: Volumes anlegen, Bind-Mounts einrichten, Storage-Driver (overlay2, btrfs, zfs) verwalten
• Logs: Container-Output sammeln und über das Logging-Treiber-System weiterleiten
• Events: Container-Events (Start, Stop, OOM) an interessierte Beobachter weitergeben

Der Daemon braucht Root-Rechte, weil er Kernel-Features wie Namespaces und Cgroups einrichten muss. Es gibt einen experimentellen Rootless-Modus, der ohne Root-Rechte auskommt – mit Einschränkungen bei Netzwerk und Storage. In sicherheitskritischen Umgebungen ist Rootless attraktiv, in der Produktion läuft der Daemon aber meist klassisch als Root.

5) Die Container Runtime – wo's wirklich passiert

Hinter dem Daemon arbeitet die eigentliche Container-Runtime. Historisch hat Docker das selbst gemacht, heute sind die Aufgaben aufgeteilt:

• containerd – High-Level-Runtime, ein eigenständiges Projekt unter dem Dach der CNCF (Cloud Native Computing Foundation). Verwaltet Image-Pulls, Lifecycle, und ruft die Low-Level-Runtime auf.
• runc – Low-Level-Runtime, die nach OCI-Spezifikation (Open Container Initiative) Container im Kernel erstellt. Sehr klein (~10.000 Zeilen Go-Code), nur diese eine Aufgabe.

Diese Trennung ist wichtig: Sie macht Container-Runtime austauschbar. Statt runc kann man crun einsetzen (in C geschrieben, schneller), kata-runtime (jeder Container in einer Mini-VM, höhere Isolation) oder gVisor (User-Space-Kernel zwischen Container und Host). Statt containerd nutzt CRI-O eine alternative High-Level-Runtime, die speziell für Kubernetes optimiert ist.

Konsequenz für die Praxis: Kubernetes spricht heute meistens direkt mit containerd – ohne Docker dazwischen. Der berühmte Spruch „Kubernetes deprecates Docker" (2020) bedeutete genau das: K8s nutzt nicht mehr den Docker-Daemon als Schnittstelle, sondern containerd direkt. Für Endanwender ändert sich dadurch nichts, aber für Cluster-Operatoren schon.

6) Die Registry – wo Images leben

Container-Images werden nicht von Docker gebaut und behalten – sie liegen in Registries. Eine Registry ist ein HTTP-Service, der nach standardisiertem Protokoll Images speichert und ausliefert. Wichtige Registries:

Wichtig: Wenn du docker pull nginx tippst, ohne eine Registry anzugeben, geht Docker zu Docker Hub. Für eigene Registries musst du den vollständigen Namen angeben: docker pull harbor.firma.de/team/nginx:1.25. Die Authentifizierung erfolgt mit docker login.

In der Praxis spielt die Registry-Wahl eine wichtige Rolle in der CI/CD-Pipeline: Builds aus GitHub Actions können direkt nach ghcr.io pushen, GitLab CI nach der eingebauten Registry, Jenkins nach Harbor. Die richtige Registry-Wahl spart Token, Bandbreite und Konfigurationsaufwand.

7) Image-Verteilung und Pull-Mechanik

Ein Image-Pull ist nicht einfach „eine Datei runterladen". Images bestehen aus mehreren Layern, die Docker einzeln behandelt – das ist eine der mächtigsten Eigenschaften. Wenn du zwei Images vom selben Base-Image (z. B. ubuntu:22.04) abgeleitet hast, lädt Docker die Base-Layer nur einmal herunter. Die spezifischen Schichten jedes Images kommen dazu. Mehr in der Lektion Dockerfile.

Probier es interaktiv mit echten Docker-Befehlen – klick einen Befehl, sieh, was passiert:

Zusammenfassung

Docker hat eine Client-Server-Architektur mit vier Hauptkomponenten: Docker Client (CLI, sendet API-Calls), Docker Daemon (dockerd, das Herz: verwaltet Images, Container, Netzwerke, Volumes), Registry (speichert und liefert Images aus, z. B. Docker Hub, Harbor, ECR), Container Runtime (containerd + runc, erstellt die eigentlichen Container im Kernel via Namespaces und Cgroups). Kommunikation: Client ↔ Daemon über REST-API (Unix-Socket oder TCP/TLS); Daemon ↔ Registry über HTTPS; Daemon ↔ Runtime über containerd-API. Bei docker run nginx: Client schickt API-Call, Daemon prüft Image-Cache, pullt ggf. von der Registry, weist containerd an, einen Container zu starten, containerd ruft runc auf, das den Container im Kernel erstellt. Wichtige Erkenntnisse: Docker-Socket = Root-Zugriff (Sicherheit!), containerd ist heute Industriestandard auch ohne Docker (Kubernetes nutzt es direkt), OCI standardisiert Image-Format und Runtime-Schnittstelle, sodass Komponenten austauschbar sind.

Verwandte Lektionen: Container vs. VM · Docker Images & Container · Sicherheit in Docker-Umgebungen · und mehrWeitere relevante LektionenDockerfile schreibenNetzwerke in DockerDocker in CI/CDsystemd-DiensteHTTP-GrundlagenAWS/Azure/GCP VergleichWas ist CI/CD