Docker-Homelab-Fallen: Speicherplatz, Logs und Konfigurationsdrift

Ein kürzlich veröffentlichter technischer Beitrag beschreibt mehrere betriebliche Gefahren, die bei der Verwaltung einer selbst gehosteten Docker-Umgebung auf Proxmox und Network-Attached Storage (NAS) auftreten. Der Autor erläutert, wie Standard-Diagnosebefehle Administratoren in die Irre führen können, sodass sie aktive Dienste löschen oder kritische Konfigurationsdrifts übersehen. Diese Vorfälle verdeutlichen die Kluft zwischen dem Gesundheitsstatus von Containern und der tatsächlichen Funktionsfähigkeit von Diensten in komplexen Homelab-Setups.

Was passiert ist

Die Untersuchung begann, als ein Docker-Host eine Speicherauslastung von 82 Prozent erreichte. Erste Diagnosen mit docker system df deuteten auf 6,67 GB freigebbaren Speicher hin, doch genauere Untersuchungen zeigten, dass die Übersichtsansichten irreführend waren. Der Befehl docker ps zeigte für einige Container nur reine SHA-Kennungen anstelle von Image-Namen, wodurch das aktive Image unclecode/crawl4ai scheinbar verwaist wirkte. Der Container war gesund, lief seit zwei Wochen und bediente Traffic. Der Administrator vermied es nur durch den Abgleich lauschender Ports mit Container-Inspektionen, ihn zu löschen.

Weitere Analysen ergaben, dass der Druck auf den Speicherplatz von Images und Build-Caches stammte, nicht von Benutzerdaten. Ein Gast hielt 16 GB an Images bereit, während ein anderer 11,4 GB an Images und 11,3 GB an Build-Cache besaß. Das Entfernen von sechzehn obsoleten Tags einer benutzerdefinierten Anwendung gab nur 60 MB frei, obwohl jeder Tag mit 240 MB angegeben wurde, aufgrund gemeinsamer Layer. Ein separater Vorfall betraf einen anderen Host, der eine Speichernutzung von 100 Prozent erreichte, weil dem Docker-Daemon eine Konfigurationsdatei fehlte, um die Log-Größen zu begrenzen. Eine einzelne Home-Assistant-Logdatei war auf 1,9 GB angewachsen, was zum Ausfall von fünf systemd-Einheiten führte, ohne dass jemand alarmiert wurde.

Konfigurationsdrift verursachte auch längere Ausfälle. Ein Datei-Browser-Container blieb sechs Tage lang offline, weil seine Neustart-Richtlinie auf no zurückgesetzt worden war, obwohl die Compose-Datei unless-stopped vorsah. Dies geschah, weil der Container vor der Änderung der Richtlinie erstellt und nie neu erstellt wurde. Darüber hinaus führten Probleme bei der Interpolation von Umgebungsvariablen dazu, dass ein Argon2-Passwort-String verstümmelt wurde, was Authentifizierungsfehler zur Folge hatte, während hartcodierte Standards in einem Tracing-Stack zu Datenbankverbindungsfehlern führten. Es wurden Sicherheitslücken im Netzwerk gefunden, bei denen veröffentlichte Ports direkten Zugriff auf private Instanzen ermöglichten und Reverse-Proxies umgingen.

Wichtige Details

• Werkzeuge zur Speicherbereinigung wie docker system df können die Speichernutzung aufgrund gemeinsamer Image-Layer und Build-Caches falsch darstellen.
• Die standardmäßige Docker-Protokollierung hat keine Größenbegrenzung, sodass einzelne Logdateien ganze Dateisysteme füllen können, wenn daemon.json nicht konfiguriert ist.
• Änderungen an .env-Dateien oder Compose-Konfigurationen erfordern docker compose up -d --force-recreate, um wirksam zu werden, nicht nur einen Neustart.
• Container, die vor einer Aktualisierung der Neustart-Richtlinie erstellt wurden, behalten ihre ursprüngliche Richtlinie bei, bis sie explizit neu erstellt oder aktualisiert werden.
• Health Checks zeigen den Prozessstatus an, überprüfen aber nicht die funktionale Konnektivität, wie z. B. Tunnelverbindungen oder GPU-Verfügbarkeit.
• Firewall-Regeln für veröffentlichte Ports müssen die ursprünglichen Zieladressen unter Verwendung von --ctorigdst abgleichen, aufgrund des DNAT-Verhaltens.

Hintergrund

Docker-Container sind leichtgewichtige virtualisierte Umgebungen, die den Kernel des Host-Betriebssystems teilen. Wenn ein Container erstellt wird, erfasst Docker die Konfiguration, einschließlich Umgebungsvariablen, Neustart-Richtlinien und Logging-Treiber, in einem spezifischen Runtime-Zustand. Nachfolgende Änderungen an Quelldateien, wie Compose-YAML-Dateien oder Definitionen von Umgebungsvariablen, aktualisieren laufende Container nicht automatisch. Administratoren müssen Container explizit neu erstellen, um diese Änderungen anzuwenden. Dieses Verhalten führt oft zu "Konfigurationsdrift", bei dem das Live-System vom deklarierten Infrastrukturcode abweicht.

Das Protokollieren in Docker verwendet standardmäßig typischerweise einen JSON-File-Treiber, der alle Standardausgabe- und Fehlerströme ohne Rotation auf die Festplatte schreibt, sofern nichts anderes konfiguriert ist. In Produktions- oder langlaufenden Homelabs kann dies zu schnellem Verbrauch des Speicherplatzes führen. Ebenso umfasst das Image-Management Layer, die über mehrere Tags und Versionen hinweg geteilt werden. Das Löschen eines bestimmten Tags entfernt nicht unbedingt die zugrunde liegenden Datenblöcke, wenn andere Images darauf verweisen, was die Freigabe von Speicherplatz weniger vorhersagbar macht als einfache Datei-Löschungen.

Warum es wichtig ist

Für Teams, die selbst gehostete Software betreiben, stellen diese Fallen erhebliche Zuverlässigkeitsrisiken dar. Das Verlassen auf oberflächliche Health Checks kann Dienstausfälle verschleiern, wie z. B. einen laufenden, aber nicht verbundenen Tunnel-Agenten oder einen Machine-Learning-Container, der aufgrund von Hardware-Inkompatibilität auf CPU zurückgreift. Ohne robustes Monitoring der tatsächlichen Dienstfunktionalität können Ausfälle tagelang unbemerkt bleiben. Der Vorfall, bei dem ein Datei-Browser sechs Tage lang offline blieb, zeigt, wie stille Fehler Workflows stören können, ohne sofortige Alarme auszulösen.

Erschöpfung des Speicherplatzes ist eine weitere kritische Bedrohung für die Verfügbarkeit. Unbegrenztes Log-Wachstum kann ganze Hosts zum Absturz bringen und alle kolokierten Dienste gleichzeitig lahmlegen. Das Fehlen einer standardmäßigen Log-Rotation bedeutet, dass jede neue Bereitstellung dieses Risiko erbt, es sei denn, es wird explizit gemildert. Darüber hinaus untergräbt Konfigurationsdrift die Reproduzierbarkeitsvorteile von Infrastructure-as-Code-Praktiken. Wenn Umgebungsvariablen oder Neustart-Richtlinien nicht zwischen dem Code-Repository und den laufenden Containern synchronisiert sind, wird das Debugging schwierig und Bereitstellungen werden unberechenbar.

Die Netzwerksicherheit ist ebenfalls gefährdet, wenn Standard-Veröffentlichungsverhalten nicht sorgfältig verwaltet wird. Das Exponieren privater Dienste auf allen Schnittstellen ermöglicht unbefugte laterale Bewegung innerhalb des Netzwerks. Eine ordnungsgemäße Firewall-Konfiguration erfordert das Verständnis der Network Address Translation-Mechaniken von Docker, die sich vom standardmäßigen host-basierten Routing unterscheiden. Falsch konfigurierte Regeln können sensible interne Dienste für weniger vertrauenswürdige Segmente zugänglich machen und gegen das Least-Privilege-Prinzip verstoßen.

Was Sie tun können

• Überprüfen Sie die Image-Nutzung mit docker inspect und prüfen Sie lauschende Ports, bevor Sie Images oder Container entfernen.
• Konfigurieren Sie daemon.json mit max-size- und max-file-Limits für Logs und erstellen Sie bestehende Container neu, um die Einstellungen anzuwenden.
• Verwenden Sie docker compose up -d --force-recreate nach Änderungen an Umgebungsdateien, um sicherzustellen, dass neue Werte geladen werden.
• Auditiere Neustart-Richtlinien regelmäßig mit docker inspect, um zu bestätigen, dass sie der beabsichtigten Compose-Konfiguration entsprechen.
• Implementieren Sie Firewall-Regeln in der DOCKER-USER-Kette unter Verwendung von --ctorigdst, um den Zugriff auf veröffentlichte Ports einzuschränken.
• Testen Sie die Dienstfunktionalität über Health Checks hinaus, indem Sie externe Konnektivität und interne Abhängigkeiten periodisch überprüfen.