Seite 7 - Docker

Eine unkontrollierte Flut aus latest-Tags und anonymen Docker-Hub-Pulls gefährdet jede Produktionsumgebung. Wer eine private Docker Registry betreibt, sinnvolle Image-Versionen einführt und Retention-Policies definiert, schafft nachvollziehbare, reproduzierbare Builds und reduziert Ausfallrisiken erheblich.

Wer für jede Umgebung ein eigenes Docker Image baut, verliert genau die Garantie, die Container eigentlich versprechen. Build once, deploy many trennt den Build-Schritt von der Konfiguration und sorgt dafür, dass in Produktion exakt das Artefakt läuft, das zuvor in Staging getestet wurde, ohne einen einzigen Rebuild dazwischen.

Produktionsprobleme in Docker-Containern erfordern präzises Werkzeug, nicht Raten. Mit exec, inspect, stats, top und events lassen sich Prozesse, Konfiguration, Speicher und Ereignisse eines laufenden Containers vollständig untersuchen – ohne Neustart, ohne Datenverlust.

Rootless Docker lässt den Docker-Daemon und alle Container als normaler Benutzer laufen – ohne Root-Rechte. Das reduziert die Angriffsfläche erheblich, hat aber konkrete Einschränkungen bei privilegierten Ports, Volume-Rechten und bestimmten Netzwerk-Features. Hier erfährst du, wann der Wechsel sinnvoll ist und wann er mehr Probleme schafft als löst.

Ein Macvlan-Netzwerk gibt Containern eine eigene, im physischen Netz sichtbare IP-Adresse, ganz ohne Port-Mapping über den Docker-Host. Das löst reale Probleme bei Legacy-Anwendungen und Monitoring-Systemen, bringt aber eine bekannte Einschränkung bei der Kommunikation zwischen Host und Container mit sich, die vor dem produktiven Einsatz verstanden sein muss.

Ein Varnish-, Redis- und OpenSearch-Sidecar mit Standard-Konfiguration läuft, aber liefert selten die Performance, die ein Magento-Shop unter echter Last braucht. Dieser Artikel zeigt, wie diese drei Sidecars als Container gezielt feingetunt werden, von VCL-Regeln über Eviction-Policies bis zur JVM-Heap-Dimensionierung, statt sich auf die Werksvorgaben zu verlassen.

Jedes Docker-Image beginnt mit einem Basis-Image, dem das gesamte Team blind vertraut, meist basierend auf einem Tag wie latest oder einer Versionsnummer ohne weitere Prüfung. Supply Chain Security ersetzt dieses blinde Vertrauen durch gepinnte Digests, kryptographische Signaturen und nachvollziehbare Provenance-Informationen, damit ein kompromittiertes Basis-Image nicht unbemerkt in produktiven Deployments landet.

Docker ist nicht nur eine Runtime – es ist eine portable Build-Umgebung. Wer Deployment-Artefakte aus Docker Builds erzeugt, bekommt reproduzierbare Binaries, statische Assets und Archive, ohne die Build-Toolchain auf dem CI-Server oder dem Entwicklerrechner zu installieren.

Wer alle Container im Default-Bridge-Netzwerk laufen lässt, verzichtet auf Namensauflösung, Isolation zwischen Projekten und die Möglichkeit, Container gezielt vom Internet abzuschneiden. Ein eigenes Bridge-Netzwerk pro Projekt löst genau diese drei Probleme mit wenigen Zeilen Konfiguration.

Wer DI Compile und Static Content Deploy zur Laufzeit ausführt, verlängert den Deployment-Prozess und riskiert inkonsistente Images. Der Build-Container-Ansatz verschiebt beide Schritte in die Image-Erstellung – mit reproduzierbaren Ergebnissen und deutlich schnelleren Release-Zyklen.