Seite 5 - Docker

Wer Container-Metriken nur über docker stats beobachtet, verliert Verlaufsdaten und Alarmierung. cAdvisor liest CPU, Memory, Netzwerk und I/O jedes Containers aus, Prometheus speichert die Zeitreihen dauerhaft, und PromQL macht daraus belastbare Kennzahlen für Kapazitätsplanung und Fehlersuche im laufenden Betrieb.

Wer CPU- und Speicherlimits für Magento-Container nach Bauchgefühl setzt, überprovisioniert entweder teuer oder riskiert Ausfälle bei Lastspitzen. Dieser Artikel zeigt, wie Magento Container Größen systematisch aus PHP-FPM Pool-Sizing, realem Speicherbedarf pro Worker und tatsächlichen Traffic-Mustern abgeleitet und per Lasttest validiert werden.

Distroless Images enthalten weder Shell noch Paketmanager noch überflüssige Systembibliotheken und reduzieren dadurch die Angriffsfläche eines PHP-Containers drastisch. Mit Static-PHP-CLI oder FrankenPHP als Basis lässt sich eine komplette PHP-Laufzeit in ein Distroless-Image kompilieren, ohne die klassische PHP-FPM-Distribution zu benötigen.

Ein Magento-Docker-Stack besteht aus mindestens fünf Services: PHP-FPM, Nginx, MySQL, Redis und OpenSearch. Dazu kommen RabbitMQ für Message Queues und Varnish für Full-Page-Cache. Wie diese Services korrekt vernetzt, persistent gespeichert und in der richtigen Reihenfolge gestartet werden, entscheidet über Stabilität und Wartbarkeit.

CI-Builds, die fünf Minuten dauern, weil jeder Run Composer-Pakete und npm-Module komplett neu herunterlädt, sind kein Naturgesetz. Docker BuildKit Cache Mounts halten Package-Caches persistent zwischen Builds, ohne sie ins Image zu baken. Dieser Artikel zeigt, wie RUN --mount=type=cache funktioniert und wie Layer-Strategie, parallele Stages und Registry-Cache zusammenspielen, um CI-Laufzeiten drastisch zu kürzen.

Die Wahl des minimalen Basis-Images entscheidet über Kompatibilität, Debugging-Fähigkeit und Wartungsaufwand für die gesamte Lebensdauer eines Docker-Images. Alpine mit musl-libc, Debian-Slim mit vollem glibc-Ökosystem, Distroless ohne jede Shell und Scratch als komplett leeres Fundament lösen unterschiedliche Probleme und passen jeweils zu unterschiedlichen Projektanforderungen.

Wer mehrere Feature-Branches gleichzeitig prüfen muss, stößt schnell an die Grenzen eines einzelnen Docker-Compose-Stacks: Portkonflikte, geteilte Datenbanken und Namenskollisionen bei Containern und Netzwerken. COMPOSE_PROJECT_NAME in Kombination mit Profiles löst genau dieses Problem, indem jede Umgebung sauber isoliert nebeneinander läuft.

docker stack deploy verwandelt eine gewohnte Compose Datei in einen vollständigen, hochverfügbaren Swarm Stack, inklusive Netzwerke, Volumes, Secrets und Configs in einem einzigen Rollout. Wer die Feinheiten zwischen lokalem Compose und Stack Deployment kennt, vermeidet die häufigsten Stolperfallen beim Übergang von Entwicklung zu Produktion.

Passwörter in Dockerfiles, API-Keys als ENV-Variablen, Zertifikate in Image-Layern – das sind reale Sicherheitslücken in Tausenden von Container-Setups. Docker Secrets, BuildKit Mount-Secrets und ein durchdachtes Credentials-Management eliminieren diese Risiken, ohne den Entwicklungsworkflow zu belasten.

Self-signed Zertifikate erzeugen ständig Browser-Warnungen und lassen sich nicht für APIs und Service-Worker nutzen. mkcert kombiniert mit einem Docker-Reverse-Proxy löst das Problem vollständig: lokale Domains mit echtem vertrauenswürdigen HTTPS – ohne Cloud, ohne Let's Encrypt, ohne Klickorgien.