Begriff
Docker Daemon (dockerd)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Wenn du Docker installierst, installierst du eigentlich einen Server-Dienst.
Dieser Dienst heißt Docker Daemon (dockerd).
Er läuft im Hintergrund (Systemd Service) und schläft nie.
Er ist der Boss.
Er verwaltet alle Container, Images, Netzwerke und Volumes.
Wenn du docker run tippst, sendest du nur einen Wunsch an den Daemon.
Der Daemon redet dann mit dem Linux-Kernel, um den Wunsch zu erfüllen.
Wenn der Daemon abstürzt, sterben (oft) alle Container.
Merksatz: Der persistente Hintergrundprozess, der Docker-Objekte verwaltet und Container-Runtimes anweist, Container zu erstellen und auszuführen.
Du siehst ihn selten, aber konfigurierst ihn in /etc/docker/daemon.json.
Wichtige Settings:
"log-driver": "json-file": Wie Logs gespeichert werden (und Log-Rotation!)."insecure-registries": [...]: Erlaube HTTP (statt HTTPS) für private Regstries."data-root": "/mnt/große-platte/docker": Verschiebe Images von/var/lib/dockerauf eine größere Partition. Nach Änderung:systemctl reload docker.
Praxisroutine
In der Praxis lernst du Docker Daemon (dockerd), indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.
Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.
1. Monolith vs. Modular (Refactoring)
Früher war dockerd ein riesiger Monolith.
Heute ist er modular zerlegt (das Moby Projekt):
- dockerd: Die API-Schicht.
- containerd: Standardisierte Runtime (CNCF). Verwaltet den Lifecycle -> überlebt
dockerdRestart! - runc: Das Low-Level Tool, das wirklich mit dem Kernel (cgroups, namespaces) spricht.
- shim: Ein winziger Prozess, der am Container klebt, damit
dockerdnicht der Parent ist. Ziel: Live Restore. Der Daemon kann geupdated werden, ohne dass die Container stoppen (Feature:live-restore: true).
2. Root Privilegien
Der Daemon läuft als Root. Das ist das größte Sicherheitsrisiko von Docker. Ein Bug im Daemon = Root-Zugriff auf dem Server. Gegenmaßnahmen:
- Rootless Mode: Docker im User-Space laufen lassen (viele Einschränkungen bei Networking).
- User Namespaces (
userns-remap): Mappe Root im Container auf User 1000 am Host.
3. OOM Score Adjust
Der Daemon ist kritisch.
Linux hat einen Mechanismus (OOM Score), um Prozesse zu töten, wenn RAM voll ist.
Dockerd setzt seinen eigenen Score automatisch auf -500 (sehr sicher).
Er sagt dem Kernel: "Töte lieber Chrome oder die Datenbank, aber töte nicht MICH (den Manager)."
Die Docker API und /var/run/docker.sock
Der Daemon hört standardmäßig auf einen lokalen "UNIX Domain Socket" (/var/run/docker.sock), nicht auf einen TCP-Port.
Wenn du docker ps tippst, macht das CLI nur einen HTTP GET-Request an http://unix:/var/run/docker.sock/v1.41/containers/json.
Das Geniale, aber Gefährliche: Du kannst diesen Socket per Bind-Mount in Container hineinreichen (-v /var/run/docker.sock:/var/run/docker.sock).
Dann kann ein Container den Daemon auf dem Host steuern, also weitere Container starten (Prinzip von CI-Runnern oder Portainer). Wenn der Container jedoch gehackt wird, hat der Angreifer Vollzugriff auf den Host. Wer den Socket hat, ist effektiv root.
TCP Bindings & TLS Mutual Auth
Willst du den Daemon remote per TCP (Port 2375 // 2376) steuern (z. B. aus einer fernen CI/CD Pipeline), darfst du niemals den Socket nackt ins Internet hängen. Crawler wie Shodan finden offene Docker-Daemons innerhalb von Minuten, und Krypto-Miner fliegen auf deinen Maschinen ein.
Die Lösung ist mTLS (Mutual TLS Authentication).
Du generierst private Keys für den Daemon (Server) und für dich (Client). Der Daemon signiert Zertifikate, und nur Requests, die von einem kryptografisch zertifizierten Docker-Client kommen, dürfen eine Verbindung aufbauen. Selbst eine korrekte Authentifizierungsmethode verhindert allerdings keinen Root-Ausbruch, wenn der Angreifer den korrekten Key stiehlt.
Storage Drivers & OverlayFS-2
Dockerd verwaltet den Festplattenplatz nicht plump per Dateikopien.
Für das Image-Layering nutzt der Daemon Storage Drivers, heute quasi universell overlay2.
OverlayFS nutzt Features des Linux-Kernels, wodurch Dateien nicht dubliziert werden. 10 Container, die alle ubuntu als Basis haben, verbrauchen zusammen nur 70MB (für das Base-Image), da Layers Copy-On-Write sind. Der Daemon orchestriert die Layer-Idempotenz.
Vorsicht bei ext4 vs. xfs: Ohne d_type (Directory Entry Type)-Support im Dateisystem verschluckt sich der Daemon extrem beim Kopieren und baut kaputte Layer.
Quick-Check
Was ist
containerd?Eine High-Level Runtime, die von Docker ausgekoppelt wurde. Kubernetes nutzt heute oftcontainerddirekt (ohne Docker Daemon dazwischen), um Ressourcen zu sparen. Docker ist "nur noch" UI für containerd.Kann ich den Daemon überwachen?
Ja. In derdaemon.jsonkannst du"metrics-addr": "0.0.0.0:9323"setzen. Das öffnet einen Prometheus-Endpunkt mit internen Metriken (Anzahl Container, Go-Routines, Failures).Warum stirbt alles bei
kill -9 dockerd?Weil SIGKILL dem Daemon keine Chance gibt, die Child-Prozesse ansystemdzu übergeben. Die Pipe bricht,shimsverlieren die Verbindung -> Chaos. Nutze immersystemctl stop docker.