Seite 11 - Docker

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.

ARG und ENV landen fast immer sichtbar im fertigen Image, auch wenn man sie loescht. BuildKit bietet mit --secret und --ssh einen Weg, Zugangsdaten und SSH-Keys nur fluechtig waehrend eines RUN-Schritts bereitzustellen, ohne dass sie in einer Layer landen.

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.

In einer klassischen GitLab-Pipeline wartet jede Stage darauf, dass alle Jobs der vorherigen Stage fertig sind, selbst wenn ein Job gar nicht von den anderen abhaengt. Das Keyword needs durchbricht diese starre Reihenfolge und macht aus der Pipeline einen Directed Acyclic Graph, in dem Jobs starten, sobald ihre tatsaechlichen Abhaengigkeiten erfuellt sind, was die Gesamtlaufzeit oft drastisch verkuerzt.

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.