Seite 6 - Docker

Wer lokale Entwicklungsumgebungen mit Docker Compose betreibt, kennt das Problem: Ein Bind Mount spiegelt alles, aber node_modules, Vendor-Verzeichnisse und Build-Artefakte sorgen fuer Performance-Probleme und Konflikte zwischen Host und Container. Docker Compose Watch loest das gezielt mit drei Aktionen, sync, rebuild und sync und restart, und macht Live Reload endlich vorhersehbar.

Ein 1,2-GB-Docker-Image ist kein Zeichen von Vollständigkeit, sondern von fehlender Optimierung. Multi-Stage Builds, präzise Layer-Reihenfolge, eine durchdachte .dockerignore und die richtige Wahl der Basis-Images machen den Unterschied zwischen einem schlanken, schnellen CI-Build und einem Deployment-Flaschenhals.

Docker Swarm und Kubernetes lösen dasselbe Grundproblem, nämlich Container über mehrere Hosts hinweg zuverlässig zu betreiben, aber mit völlig unterschiedlichem Betriebsaufwand. Wer die Entscheidung allein am Bekanntheitsgrad von Kubernetes festmacht, baut sich oft unnötige Komplexität ein, die kein Team im Alltag braucht.

Sobald eine compose.yaml mehr als drei oder vier Services enthaelt, wiederholen sich Logging-Konfiguration, Umgebungsvariablen und Healthcheck-Definitionen fast identisch in jedem Block. YAML Anchors, Aliases und Merge Keys erlauben es, diese Bloecke einmal zu definieren und ueberall wiederzuverwenden, ohne dass Docker Compose selbst dafuer eine eigene Funktion braucht.

Ein Docker Image ist keine Blackbox. Es ist eine geordnete Sequenz von Read-only-Layers, die zusammen das Dateisystem des Containers bilden. Wer versteht, wie Layers aufgebaut werden, warum der Build-Cache invalidiert wird und wie Registries Images effizient distribuieren, schreibt Dockerfiles, die schnell bauen und kleine Images erzeugen.

Port-Konflikte zwischen Projekten, fehlendes HTTPS in der Entwicklung und unübersichtliche Hostnamen sind klassische Pain Points beim Docker-Networking im Team. Mit Traefik als zentralem Reverse Proxy, mkcert für lokale HTTPS-Zertifikate und sauber isolierten Docker-Netzwerken lassen sich diese Probleme ein für alle Mal lösen.

Bevor ein Service in Kubernetes oder Docker Swarm mit mehreren Replicas produktiv laeuft, lohnt sich ein lokaler Test mit deploy.replicas in Docker Compose. So lassen sich Port-Konflikte, geteilte Volumes und Lastverteilungsverhalten schon auf dem Entwicklungsrechner aufdecken, statt sie erst nach einem produktiven Rollout zu bemerken.

Docker Compose kann mehr als Hauptservices starten. Sidecar-Container liefern Logs weiter und exportieren Metriken. Utility-Container stellen CLI-Tools bereit ohne lokale Installation. Init-Container laufen vor dem Hauptservice und führen Datenbank-Migrationen aus. Einmal-Jobs erledigen Wartungsaufgaben auf Anforderung. Dieser Beitrag erklärt alle vier Muster mit dem richtigen Werkzeug für den richtigen Zweck.

Jeder Deployment-Vorgang ohne klare Strategie ist ein Glücksspiel mit der Verfügbarkeit. Blue-Green und Rolling Deployments lösen das unterschiedlich – aber beide verlassen sich auf Container-Health-Checks, sauberes Routing und atomares Umschalten. Dieser Artikel zeigt, wann welche Strategie passt und wie sie sich mit Docker Compose und Traefik konkret implementieren lässt.

Wer Logs mit docker logs auf jedem Host einzeln durchsucht, verliert bei einem Ausfall wertvolle Minuten. Zentrales Logging mit Loki und Promtail sammelt jede Container-Ausgabe strukturiert ein, indexiert nur Labels statt des vollen Textes und macht Fehlersuche über die gesamte Docker-Flotte mit einer einzigen LogQL-Abfrage möglich.