Seite 13 - Docker

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.

Ein Image wächst über Monate unbemerkt von 200 Megabyte auf über ein Gigabyte, und niemand kann auf Anhieb sagen, welcher Build-Schritt dafür verantwortlich ist. docker history liefert einen ersten groben Überblick, das Tool dive zeigt exakt, welche Datei in welchem Layer wie viel Platz beansprucht.

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.

Beim React Deployment entscheidet die Wahl der Plattform über Build-Zeiten, Kosten und Kontrolle. Vercel, Netlify und ein selbst betriebener Docker-Stack lösen dasselbe Problem mit unterschiedlichen Kompromissen. Dieser Artikel zeigt konkrete Konfigurationen, eine CI/CD-Pipeline und die Entscheidungskriterien für jede Situation.

Wer in GitLab CI ploetzlich zwei Pipelines fuer denselben Commit sieht, stoesst meist auf den Unterschied zwischen Branch-Pipelines und Merge-Request-Pipelines: Erstere testen den tatsaechlichen Push-Zustand eines Branches, Letztere simulieren, wie der Code nach einem Merge aussehen wuerde. Dieser Artikel erklaert den Unterschied im Detail und zeigt, wie sich mit workflow:rules doppelte Pipelines zuverlaessig vermeiden lassen.

Die meisten GitLab-CI-Anleitungen zeigen Caching anhand von composer.lock oder package-lock.json und hoeren dort auf. Wer mehrere unabhaengige Caches pro Job braucht oder Invalidierung praeziser steuern will, muss tiefer in cache:key einsteigen.

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.

Vier verschiedene Quellen fuer Umgebungsvariablen, eine Reihenfolge, die selten dokumentiert wird: Wenn ein Wert im Container nicht ankommt oder ein anderer als erwarteter erscheint, steckt fast immer eine unklare Praezedenz zwischen Shell-Umgebung, .env-Datei, dem environment-Block und env_file dahinter.