Docker Client

Das wichtigste Prinzip: Context. Standardmäßig spricht der Client mit unix:///var/run/docker.sock (lokaler Daemon). Du kannst das ändern: docker context create remote-server --docker "host=ssh://user@remote-ip" docker context use remote-server Jetzt passiert jedes docker ps auf dem entfernten Server! Extreme Vorsicht: Ein docker system prune löscht nicht deinen Laptop, sondern den Production-Server.

Praxisroutine

In der Praxis lernst du Docker Client, 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. The Docker Socket

Der Client kommuniziert über eine REST API. Lokal läuft das über einen Unix Socket /var/run/docker.sock. Wer Schreibrechte auf diesen Socket hat, ist faktisch Root. Warum? docker run -v /:/host alpine rm -rf /host Das löscht das Host-System. Deshalb darf der User docker (Gruppe) alles. In Kubernetes wird oft der Socket in den Container gemountet ("Docker-in-Docker" light). Gefährlich! Ein Container kann dann den Host übernehmen.

2. API Version Negotiation

Client und Server haben Versionen. Client v24 redet mit Server v20. Der Client sendet im Header Warning: API version mismatch. Er versucht, sich "dumm zu stellen" (Downgrade), damit er mit dem alten Server reden kann. Manchmal fehlen dann Features (docker buildx geht nicht mit altem Daemon).

3. Alternativen (Podman)

Podman hat keinen Daemon. Der podman Befehl ist Client und Server in einem (fork/exec). Das Sicherheitsmodell ist anders (Rootless by default). Aber für den User fühlt es sich gleich an (alias docker=podman).

1. Die Architektur der Control-Plane

Der docker CLI Binarity ist faktisch ein reines REST/gRPC-Frontend (mittlerweile oft in Go geschrieben, das externe Plugins wie buildx in ~/.docker/cli-plugins/ nachlädt). Er enthält absolut null Containerisierung-Logik (cgroups, namespaces). Er parst nur User-Flags (wie --rm) und transliert sie in ein HTTP POST JSON auf den Endpoint /containers/create. Es gibt in Architekturen Fälle, wo der Client auf dem CI-Runner (GitHub Actions) sitzt und der Daemon auf EC2 in AWS (oder minikube) rennt. Sie trennen die Ausführungsschicht von der Bedienschicht.

2. Socket-Mounts: Das Rooting-Dilemma

Oft muss ein CI/CD Tool wie Jenkins. Dessen Container muss neue Images für das Hauptprojekt bauen. Der Admin reicht den Unix Socket per Volume an Jenkins durch: -v /var/run/docker.sock:/var/run/docker.sock. (Docker-Out-of-Docker Ansatz). Das ist extrem gefährlich. Der Jenkins Container redet als Docker-Client mit dem Docker-Daemon des nackten physischen Host-Systems. Jenkins kann nun tippen: docker run -v /:/host_root alpine rm -rf /host_root. Er löscht das gesamte Betriebssystem aus, oder startet privilegierte (Root) Container auf dem Host, die SSH-Keys auslesen. Jeder Socket-Mount ist ein absoluter Privilege Escalation Vektor (Instant-System-Root-Zugriff).

3. Alternative Clients & CRI API

Seit Docker den Engine modifiziert hat, können sogar unzählige Dritte-Clients denselben Socket füttern. In Kubernetes ist Docker (dockershim) mittlerweile als Laufzeit tot. Kubernetes nutzt nicht den Docker Client und nicht dockerd. Kubernetes nutzt das CRI (Container Runtime Interface) und spricht direkt mit containerd (dem Unterbau von Docker). Ein anderer Client als Alternative zu Docker CLI ist nerdctl. Er verhält sich vom Kommando exakt wie Docker (nerdctl run), baut aber ohne den riesigen Daemon Overhead nativ in containerd, was Ressourceneffizienter im Cluster (für ContainerD-basierte Nodes) arbeitet und Funktionen liefert, die das "fette" Docker-Ökosystem nie umsetzen wollte (z.b. natives eStargz Lazy Image Pulling).