Seite 4 - Docker

Kubernetes wird als Lösung für Probleme vermarktet, die viele Teams noch gar nicht haben. Docker Compose löst lokale Entwicklung und kleinere Produktions-Deployments elegant – Kubernetes löst Cluster-Skalierung, Selbstheilung und Multi-Tenant-Isolation. Der Unterschied liegt nicht in der Technologie, sondern in der Problemgröße.

GitLab CI mit Docker ist mächtig, aber die Konfiguration hat viele Fallstricke: falsche Runner-Typen, unsicheres Docker-in-Docker, Build-Caches die nicht treffen und Artifacts, die unnötige Megabytes transferieren. Wer die Mechanismen versteht, baut Pipelines, die in drei Minuten fertig sind statt in dreißig.

Ein generisches Blue-Green-Deployment tauscht einfach zwei Container-Versionen aus. Bei Magento reicht das nicht, weil Indexer, Cache, Sessions und Datenbank-Migrationen den Farbwechsel verkomplizieren. Dieser Artikel zeigt, wie Blue-Green-Deployments für Magento in Containern so gebaut werden, dass der Traffic-Switch tatsächlich ohne Downtime und ohne inkonsistente Daten funktioniert.

Eine Test Matrix mit Docker prüft eine Anwendung gleichzeitig gegen mehrere PHP- oder Node-Versionen, statt sich auf eine einzige lokale Entwicklerversion zu verlassen. Container machen jede Kombination reproduzierbar, parallel ausführbar und klar getrennt auswertbar, ganz ohne mehrere physische Testmaschinen zu pflegen.

Image Signing beweist, dass ein Container Image tatsächlich aus der eigenen Pipeline stammt und seit dem Build nicht verändert wurde. Eine Software Bill of Materials listet jede einzelne Komponente im Image auf und macht Supply-Chain-Risiken sichtbar, bevor sie zum Sicherheitsvorfall werden. Cosign und Syft aus dem Sigstore-Ökosystem setzen beides ohne eigene PKI-Infrastruktur um.

Wer Docker Logs nur mit docker logs liest, verliert im Produktionsbetrieb jeden Überblick. Strukturiertes Logging über stdout und stderr, der richtige Log-Treiber und ein zentrales Log-Management-System machen Container-Logs beobachtbar, durchsuchbar und alarmierbar.

Ein offener Port bedeutet nicht, dass eine Anwendung wirklich bereit ist. Docker Healthchecks geben Containern eine eigene Stimme – sie melden, wann ein Service tatsächlich Anfragen verarbeiten kann, wann er degradiert ist und wann ein Neustart nötig wird. Ohne diesen Mechanismus bleibt Container-Orchestrierung blind.

Ein offener Datenbank-Port bedeutet noch lange nicht, dass MySQL bereit ist, Verbindungen zu verarbeiten. depends_on mit condition service_healthy verknuepft die Startreihenfolge von Docker Compose Services direkt mit dem Healthcheck-Status, statt sich auf ein reines Erreichbarkeits-Signal zu verlassen, und beseitigt damit eine der haeufigsten Fehlerquellen in Multi-Service-Stacks.

Seed-Daten unterscheiden sich fundamental von reinen Init-Skripten: Init-Skripte legen das Schema an, Seed-Daten füllen es mit realistischen, wiederholbaren Testdaten. Wer beide Konzepte vermischt, endet entweder mit leeren Entwicklungsdatenbanken oder mit inkonsistenten Testständen zwischen Teammitgliedern.

Ein Serverwechsel, ein Hosting-Anbieterwechsel oder eine Konsolidierung mehrerer Docker-Hosts erfordert frueher oder spaeter, einen laufenden Datenbank-Container von einer Maschine auf eine andere zu bringen. Je nach Datenmenge, Toleranz fuer Downtime und Netzwerkverbindung zwischen den Hosts eignen sich logische Dumps, rohe Volume-Kopien per rsync oder ein Replikations-Cutover unterschiedlich gut, mit jeweils eigenen Fallstricken bei Konsistenz und Integritaet.