Docker-Engine-Hostadministration: daemon.json, Speicherplatzbelegung und live-restore

Ziel

Logging- und Speicherverhalten des Docker-Engine-Daemons konfigurieren, die Speicherplatzbelegung prüfen und Platz freigeben, ohne noch benötigte Ressourcen zu löschen.

Voraussetzungen

Root-Rechte oder Mitgliedschaft in der Gruppe docker auf dem Host. Die Mitgliedschaft in der Gruppe docker ist auf diesem Host gleichbedeutend mit Root, weil der Daemon als Root läuft und die Gruppe ihn beliebige Host-Pfade per Bind-Mount einbinden lassen kann. Die Mitgliedschaft in der Gruppe docker ist daher mit derselben Sorgfalt zu behandeln wie sudo-Zugriff.

Schritte

1. Der Daemon liest beim Start /etc/docker/daemon.json (JSON). Die dockerd-Referenz dokumentiert seine Kommandozeilenoptionen, von denen die meisten einen entsprechenden JSON-Schlüssel haben. Gängige Schlüssel auf Host-Ebene:

{
  "data-root": "/var/lib/docker",
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" },
  "live-restore": true
}

2. data-root verlegt den Speicherort von Images, Containern und Volumes. Für das Verschieben ist der Daemon zu stoppen (docker.service und docker.socket, sonst startet ihn die Socket-Aktivierung neu). Anschliessend wird das bestehende Verzeichnis kopiert, wobei Besitzer, Berechtigungen und erweiterte Attribute erhalten bleiben, der Schlüssel angepasst und der Daemon wieder gestartet. Dabei werden alle Container gestoppt, auch wenn live-restore aktiv ist.
3. log-driver/log-opts legen den Standard-Logging-Treiber für neue Container fest. Ohne max-size/max-file für den Treiber json-file können Container-Logs auf der Platte unbegrenzt wachsen. Bestehende Container behalten ihre bisherige Log-Konfiguration, bis sie neu erstellt werden.
4. live-restore: true hält eigenständige Linux-Container am Laufen, während der Daemon gestoppt ist, abstürzt oder auf ein neueres Patch-Release (YY.MM.x) aktualisiert wird. Über Major-Upgrades (YY.MM) hinweg wird es nicht unterstützt, es gilt nicht für Swarm-Services und kann fehlschlagen, wenn sich Daemon-Optionen wie der Storage-Treiber oder die Bridge-Adressen geändert haben. Solange der Daemon nicht läuft, blockiert ein Container bei der Ausgabe, sobald sein 64-K-Log-Pipe-Puffer voll ist. Aktiviert wird die Option mit sudo systemctl reload docker (SIGHUP) und nicht mit einem Neustart, denn dieser würde die laufenden Container stoppen, da live-restore noch nicht aktiv ist. Prüfen lässt sich der Zustand mit docker info --format '{{.LiveRestore}}'.
5. Änderungen nicht interaktiv anwenden: daemon.json sichern, mit sudo dockerd --validate --config-file /etc/docker/daemon.json validieren (Docker 23.0 und neuer), dann sudo systemctl restart docker ausführen (stoppt die Container, sofern live-restore nicht bereits aktiv ist) oder bei neu ladbaren Optionen reload verwenden. Wird eine Einstellung sowohl in daemon.json als auch als Flag in der Service-Unit angegeben (häufig hosts/-H), verweigert der Daemon den Start; hier hilft journalctl -u docker --no-pager. Rückgängig gemacht wird die Änderung durch Wiederherstellen der Sicherung.
6. Die Speicherplatzbelegung nach Kategorien prüfen: docker system df (-v für eine Aufschlüsselung nach Einzelelementen, einschliesslich freigebbarem Speicherplatz).
7. Speicherplatz vorsichtig freigeben: docker system prune entfernt alle gestoppten Container, nicht von einem Container verwendete Netzwerke, Dangling Images und ungenutzten Build-Cache. -a entfernt zusätzlich jedes Image, das nicht von einem Container verwendet wird, und --volumes zusätzlich anonyme Volumes, die kein Container verwendet (benannte Volumes bleiben erhalten). Der Befehl fragt nach einer Bestätigung; -f unterdrückt die Abfrage für Skripte. Zuerst docker system df ausführen und ohne -a/--volumes bereinigen, solange nicht bestätigt ist, dass nichts Benötigtes ausschliesslich von einem gestoppten Container referenziert wird.

Erwartetes Ergebnis

docker info zeigt die neuen Werte für data-root und live-restore. docker system df weist nach einem Prune weniger freigebbaren Speicherplatz aus, wobei aktive Container und ihre Images unangetastet bleiben.

Grenzen und Prüfbasis

Der genaue Umfang von docker system prune hängt von den übergebenen Flags ab und hat sich zwischen Releases geändert (ältere Engines entfernten mit --volumes auch ungenutzte benannte Volumes). Wird der Befehl ausgeführt, ohne vorher docker system df zu prüfen, kann dabei ein gestoppter Container gelöscht werden, der für einen geplanten Job noch benötigt wird.