Seite 10 - Docker

Dockerfiles, die nie statisch geprüft werden, akkumulieren stille Fehler: veraltete Basis-Images mit kritischen CVEs, ungültige Compose-Konfigurationen und strukturelle Probleme, die erst im Produktionsbetrieb sichtbar werden. Automatisches Linten und Testen schließt diese Lücke direkt in der CI-Pipeline.

Ein Container, der als root läuft, mit allen Linux-Capabilities und beschreibbarem Filesystem, ist technisch gesehen ein privilegierter Prozess mit einem dünnen Namespace-Vorhang. Docker bietet mehrere Sicherheitsschichten, die sich ergänzen: Non-root USER, minimale Capabilities, Read-Only-Filesystem und Seccomp-Profile. Dieser Artikel zeigt, wie diese Schichten funktionieren und wie sie sich in realen Dockerfiles und Compose-Konfigurationen implementieren lassen.

Magento Cron und Message Queue Consumer laufen in Containern anders als auf einem klassischen Server mit Host-Crontab. Ohne dedizierte Container, klares Locking und sauberes Signal Handling entstehen doppelte Jobs, hängende Consumer und verlorene Nachrichten. Dieser Artikel zeigt, wie Magento Cron und Consumer als eigenständige, überwachte Container zuverlässig betrieben werden.

Ein mehrstufiges Dockerfile trennt Build-Umgebung und Runtime konsequent. Builder-Stages mit Composer, npm und Build-Tools liefern ihr Ergebnis weiter – ohne selbst im finalen Image zu landen. Das Resultat: kleinere Images, weniger Angriffsfläche und reproduzierbare Builds für PHP- und Node-Projekte.

Image Scanning prüft jede Ebene eines Docker-Images gegen Datenbanken bekannter Schwachstellen, bevor ein Container überhaupt startet. Trivy und Grype sind die beiden am weitesten verbreiteten Open-Source-Scanner dafür, unterscheiden sich aber in Datenbankquellen, Geschwindigkeit und Zusatzfunktionen wie SBOM-Erzeugung und IaC-Prüfung deutlich genug, um die Wahl bewusst zu treffen.

Wer Docker-Performance-Probleme lösen will, muss verstehen, warum die drei Plattformen grundlegend unterschiedliche Architekturen haben. Auf Linux läuft Docker nativ, auf macOS und WSL2 über eine Virtualisierungsschicht – mit messbaren Konsequenzen für Builds, Bind-Mounts und I/O-intensive Anwendungen.

Docker Hub war für viele Jahre die Standardantwort auf die Frage, wo Images gespeichert werden, doch Rate Limits, Kosten und Compliance-Anforderungen bringen Teams zunehmend zu alternativen Container Registries. GitLab, GitHub, Amazon ECR und selbst gehostetes Harbor bieten unterschiedliche Antworten auf dieselbe Frage, welche Registry zu welcher Situation passt.

Composer und npm neu von null zu starten kostet in jedem Build Minuten. Die gute Nachricht: beide Package-Manager haben robuste lokale Caches, die zwischen Docker-Builds persistent gehalten werden können, ohne die Image-Größe zu erhöhen. Der Schlüssel liegt in der richtigen Trennung von Lock-File-Layer, Vendor-Layer und Cache-Mount — und in dem Verständnis, wann welcher Cache-Typ der richtige ist.

Dateien die im Container als root erstellt wurden und auf dem Host nicht bearbeitbar sind, Volume-Mounts die Lese- oder Schreibzugriff verweigern, Prozesse die mit UID 0 laufen obwohl das nicht nötig wäre – Docker Dateirechte sind eines der häufigsten Probleme in der täglichen Entwicklung und im Produktionsbetrieb. UID/GID-Mapping, fixuid und rootless Docker lösen diese Konflikte systematisch.

Container im Entwickler-Laptop-Modus und Container in der Produktion sind zwei grundlegend verschiedene Dinge. Diese Docker Checkliste deckt alle Pflichtkategorien ab: Security-Härtung, Performance-Limits, Storage-Absicherung und reproduzierbare Deployment-Verfahren – mit konkreten Kommandos für jeden Punkt.