Seite 7 - 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.

Kubernetes entscheidet anhand von Health-Checks, ob ein Pod neu gestartet oder aus dem Load-Balancing herausgenommen werden muss, doch beide Entscheidungen brauchen unterschiedliche Informationen. Ein Liveness-Check beantwortet nur die Frage, ob der PHP-Prozess überhaupt noch läuft, während ein Readiness-Check prüfen muss, ob die Anwendung tatsächlich Traffic sinnvoll verarbeiten kann, etwa weil die Datenbankverbindung steht. Wer beide Checks über denselben Endpoint beantwortet, riskiert entweder unnötige Neustarts oder Traffic auf Pods, die eigentlich nicht bereit sind.

Jedes Mal, wenn ein Container mit einer Port-Weiterleitung gestartet wird, verändert Docker im Hintergrund das iptables-Regelwerk des Hosts. Diese automatische Manipulation ist praktisch, sorgt aber regelmäßig für schwer nachvollziehbare Konflikte, sobald eigene Firewall-Regeln oder andere Tools wie firewalld ins Spiel kommen.

Ein schlecht sortiertes Dockerfile kann bei jedem Build sämtliche Layer neu aufbauen, selbst wenn sich nur eine einzige Zeile Anwendungscode geändert hat. Wer versteht, wie Docker sein Layer-Caching anhand der Dockerfile-Reihenfolge invalidiert, kann Build-Zeiten in CI-Pipelines drastisch verkürzen, ohne an der Hardware zu sparen.

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.

docker system prune raeumt nur lokal auf, das Wachstum einer eigenen Docker Registry mit Tausenden gepushten Images bleibt davon unberuehrt. Registry-seitige Garbage Collection und durchdachte Retention-Policies sind der eigentliche Hebel gegen ausufernden Speicherverbrauch.

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.

Der --squash Build-Flag fasst alle Layer eines Images zu einem einzigen zusammen und schafft damit kleinere, aufgeraeumte Images, kostet dabei aber das Layer-Caching zwischen Builds, das viele CI-Pipelines beschleunigt.