Seite 5 - Docker

Der häufigste Fehler bei Multi-Service-Docker-Stacks: eine Anwendung startet und versucht, sich mit der Datenbank zu verbinden, bevor diese bereit ist. depends_on ohne condition löst nur die Startreihenfolge der Container — nicht die Bereitschaft des Services dahinter. Dieser Artikel zeigt alle Patterns, die das Problem zuverlässig lösen: von Health-Check-Abhängigkeiten über wait-for-it bis zu robuster applikationsseitiger Retry-Logik.

Die Standardeinstellung von Docker ist selten die richtige Wahl für produktive Umgebungen. Der Log-Driver json-file rotiert Logs erst nach expliziter Konfiguration und liegt als reine Textdatei vor, während journald Logs direkt in die systemd-Journal-Infrastruktur integriert, mit strukturierten Metadaten und zentraler Abfrage über journalctl.

Ein Symfony Docker Image, das lokal läuft, ist noch lange nicht produktionsreif. Multi-Stage-Builds trennen Build- und Laufzeitumgebung, Composer-Caching verkürzt jeden Build, ein Non-Root-User und ein Healthcheck machen den Container betriebssicher. Dieser Artikel zeigt Schritt für Schritt, wie ein schlankes, gehärtetes Symfony Docker Image entsteht.

Lokale Docker-Entwicklungsumgebungen mit mehreren Projekten brauchen einen Reverse Proxy, der Domains auf Container leitet und HTTPS-Zertifikate verwaltet. Traefik und nginx-proxy lösen dasselbe Problem mit fundamental unterschiedlichen Ansätzen. Dieser Beitrag zeigt, welcher Proxy in welchem Szenario die bessere Wahl ist.

Der Docker-Socket wird gern als bequemer Trick gemountet, damit ein Container selbst Container starten kann. Was dabei meist übersehen wird: Wer diesen Socket erreicht, hat faktisch Root-Rechte auf dem gesamten Host, ganz ohne --privileged.

GitLab Auto DevOps generiert beim Aktivieren automatisch eine komplette Build-, Test- und Deploy-Pipeline, ganz ohne eigene .gitlab-ci.yml. Fuer zustandslose Microservices funktioniert das erstaunlich gut, fuer ein komplexes System wie Magento mit Composer-Abhaengigkeiten, Datenbankmigrationen und mehrsprachigem Static Content Deployment stoesst die Automatik jedoch schnell an ihre Grenzen. Dieser Artikel zeigt, wie Auto DevOps intern funktioniert, wo genau es bei Magento hakt und wie ein Hybrid-Ansatz aus generierten und eigenen Jobs aussieht.

Named Volumes reichen fuer einen einzelnen Docker-Host aus, stossen aber an Grenzen, sobald Container auf mehreren Hosts denselben Datenbestand teilen sollen. Volume Plugins fuer Cloud Storage wie REX-Ray, s3fs oder rclone-Mounts binden Object Storage direkt als Volume ein, bringen dabei jedoch eigene Latenz- und Konsistenzeigenschaften mit, die vor dem produktiven Einsatz verstanden werden muessen.

Container kommunizieren nicht automatisch miteinander. Docker-Netzwerke definieren, wer wen erreichen kann – und wer nicht. Bridge-Netzwerke, eingebettetes DNS, Service Discovery in Compose und sichere Netzwerktrennung sind die Bausteine jeder belastbaren Container-Infrastruktur.

Wer auf einem Produktionsserver Debugging-Tools installiert, schafft permanente Angriffsfläche für temporäre Aufgaben. Temporäre Shell-Container bieten die Alternative: Diagnose-Tools nur für die Dauer der Diagnose, in der richtigen Netzwerk-Perspektive, ohne Rückstände auf dem Host. Mit docker run --rm und Namespace-Sharing ist das in Sekunden erledigt.

Wenn docker run --memory=512m --cpus=1.5 ausgeführt wird, schreibt Docker im Hintergrund schlicht ein paar Werte in Textdateien unterhalb von /sys/fs/cgroup. Wer diese Dateien einmal selbst gelesen hat, versteht Ressourcenlimits nicht mehr als Docker-Magie, sondern als das, was sie sind: Kernel-Mechanik.