Seite 15 - Docker

Hot Reload in Containern verhält sich anders als auf dem nackten Host, weil Bind Mounts, Dateisystem-Events und OPcache-Validierung zusätzliche Schichten zwischen Editor und laufendem Prozess einziehen. Wer diese Schichten versteht, bekommt PHP- und Node-Änderungen genauso schnell sichtbar wie ohne Container, ohne bei jeder Codeänderung neu zu bauen.

Wer in CI-Pipelines regelmaessig gegen Docker-Hub-Rate-Limits laeuft, kann mit einer lokalen Registry als Pull-Through-Cache Pull-Zeiten senken und Ausfaelle vermeiden, ohne Images manuell zu spiegeln.

Ein Dashboard, das niemand nachts ansieht, hilft im Ernstfall nichts. Alerting für Container-Ressourcen mit Prometheus-Regeln und Alertmanager meldet CPU-Engpässe, Memory-Druck und Restart-Schleifen automatisch, gruppiert verwandte Alarme und verhindert mit Silencing und Inhibition, dass ein einzelner Vorfall die Mannschaft mit Dutzenden Benachrichtigungen überflutet.

Image-Scanning findet bekannte Schwachstellen vor dem Start, doch sobald ein Container läuft, bleibt vieles unsichtbar. Falco beobachtet Systemaufrufe direkt im Kernel und erkennt in Echtzeit, wenn sich ein Prozess in einem Container anders verhält als erwartet, etwa durch eine unerwartete Shell, einen Schreibzugriff auf sensible Pfade oder einen Ausbruchsversuch.

Wer ein TypeScript-Projekt ohne Multi-Stage-Build in ein Docker-Image packt, verschifft den kompletten TypeScript-Compiler, alle devDependencies und den Quellcode in die Produktion. Ein sauberer Multi-Stage-Build trennt Kompilierung, Dependency-Bereinigung und Runtime in drei Stufen und reduziert Image-Größe, Angriffsfläche und Deployment-Zeit spürbar.

docker exec und docker attach wirken auf den ersten Blick austauschbar, beide verschaffen Zugriff auf einen laufenden Container. Technisch handelt es sich jedoch um zwei grundverschiedene Mechanismen. Wer den Unterschied nicht kennt, riskiert im produktiven Betrieb, den Hauptprozess versehentlich zu beenden, nur weil ein Terminal geschlossen wurde.

Bevor Docker Named Volumes offiziell unterstuetzte, loeste die Community das Problem persistenter Daten mit einem Workaround: einem eigenen, nie laufenden Container, der ausschliesslich Datenverzeichnisse deklarierte und ueber --volumes-from an andere Container weitergab. Dieses Data-Only-Container-Pattern war jahrelang Standard, ist heute aber in den allermeisten Faellen durch Named Volumes ersetzt worden, mit nur wenigen verbliebenen Nischen, in denen der alte Ansatz noch eine Rolle spielt.

Named Volumes, Bind Mounts und tmpfs lösen unterschiedliche Probleme – und die falsche Wahl kostet Datenverlust, Rechtechaos oder Produktionsausfälle. Dieser Artikel zeigt die genauen Unterschiede, die Entscheidungslogik hinter Docker Volumes und Bind Mounts sowie die Compose-Konfigurationen, die in echten Projekten wirklich funktionieren.

Die in GitLab eingebaute Container Registry spart einen externen Registry-Dienst, verlangt aber eine bewusste Tag-Strategie, automatische Cleanup-Policies gegen ausufernden Speicherverbrauch und klar definierte Zugriffsrechte pro Projekt und Gruppe.

Bevor eine Matrix-Konfiguration in GitHub Actions oder GitLab CI live geht, lohnt sich ein Prototyp in Bash: dieselbe Kombinatorik aus Versionen, Betriebssystemen und Umgebungen lokal per Schleife durchlaufen, Fehler direkt in der Shell debuggen und erst danach die endgültige YAML-Matrix schreiben. Das spart teure Trial-and-Error-Commits und macht sichtbar, welche Kombinationen überhaupt sinnvoll sind.