Seite 3 - 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.

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.

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.

Wer mehrere Magento Stores für verschiedene Kunden oder Marken betreibt, steht vor der Frage, ob jeder Shop einen eigenen Compose Stack braucht oder ob ein gemeinsamer Stack mit klar getrennten Netzwerken, Datenbank-Schemas und Caches genügt. Dieser Artikel zeigt, wie ein einziger Docker Compose Stack mehrere Magento Stores zuverlässig isoliert, ohne dass Ressourcen mehrfach vorgehalten werden müssen.

Docker Bench Security prüft Host, Daemon und laufende Container automatisiert gegen die CIS-Docker-Benchmark und liefert in wenigen Minuten einen strukturierten Prüfbericht. Wer die Ausgabe richtig liest, priorisiert und in die CI-Pipeline einbindet, verwandelt einen einmaligen Audit in einen kontinuierlichen Sicherheitsprozess statt in eine ignorierte PDF-Datei.

Ein Devcontainer verlagert die komplette Entwicklungsumgebung in einen Container, sodass jeder Entwickler exakt dieselbe PHP-Version, dieselben Extensions und dieselben Tools nutzt, unabhängig vom eigenen Rechner. Statt stundenlanger Onboarding-Dokumentation genügt ein Klick auf "Reopen in Container".

Ohne systematischen Docker Cleanup füllen sich CI-Runner und Produktionsserver innerhalb von Wochen mit ungenutzten Images, verwaisten Volumes und veralteten Build-Caches. Das richtige Automatisierungskonzept verhindert Disk-Volllauf, ohne versehentlich wichtige Daten zu löschen.