Seite 14 - Docker

Ein Container ist keine virtuelle Maschine, sondern ein isolierter Prozess, der sich denselben Kernel mit dem Host teilt. Container Escape Prävention bedeutet, genau diese Grenze konsequent zu härten: keine unnötigen Privilegien, keine gemounteten Sockets, aktive Seccomp- und AppArmor-Profile und ein aktueller Kernel, damit ein kompromittierter Container niemals zum Sprungbrett auf den Host wird.

Ein Container, der lokal funktioniert, ist noch kein produktionsreifer Container. Health-Checks, Restart-Policies, Secrets-Management, Ressourcenlimits und sauberes Logging sind die Punkte, die zwischen einem stabilen Produktionsbetrieb und nächtlichen Ausfällen entscheiden.

Ein Docker-Image ist nur so sicher wie sein Basis-Image und die darin installierten System-Pakete, und genau dort verstecken sich viele Schwachstellen, die weder SAST noch Dependency Scanning erfassen, weil beide sich auf Anwendungscode und Sprachpakete konzentrieren. GitLabs Container Scanning schliesst diese Luecke, indem es das fertig gebaute Image direkt in der Pipeline gegen eine Vulnerability-Datenbank prueft. Dieser Artikel zeigt die Integration, den Unterschied zu einem eigenstaendigen Tool wie Trivy und wie die Ergebnisse im Merge-Request-Widget landen.

Ein Framework-Upgrade, ein automatisiertes Refactoring oder eine Formatierungsumstellung kann in einem einzigen Merge Request zehntausende Zeilen veraendern, obwohl die eigentliche inhaltliche Aenderung nur einen Bruchteil davon ausmacht. Ohne Gegenmassnahmen ertrinkt jeder Reviewer in Rauschen und uebersieht genau die Zeile, die tatsaechlich ein Risiko traegt. Dieser Artikel zeigt konkrete Techniken, von .gitattributes fuer generierte Dateien ueber saubere Commit-Trennung bis zu GitLab-spezifischen Diff-Ansicht-Einstellungen, mit denen grosse, unvermeidbare Diffs trotzdem review-faehig bleiben.

„Ein Prozess pro Container" ist eines der meistzitierten Docker-Prinzipien – und eines der am häufigsten falsch angewendeten. Was das Prinzip wirklich bedeutet, wo es Sinn macht und wann Supervisor, s6-overlay oder dumb-init die bessere Entscheidung sind.

Zugangsdaten in der environment Sektion einer compose.yaml landen in docker inspect, in Prozesslisten und oft versehentlich in Log-Ausgaben. Der secrets Block in Docker Compose loest dieses Problem, indem Zugangsdaten als Dateien im Container bereitgestellt werden, statt als sichtbare Umgebungsvariablen, und schafft damit einen deutlich saubereren Umgang mit Passwoertern und API-Schluesseln.

Wer alle Umgebungen in eine einzige docker-compose.yml presst, kämpft bald mit Konfigurations-Drift, hart kodierten Passwörtern und Deploys, die lokal anders verhalten als in der CI. Profiles, Overrides und sauber getrennte .env-Dateien lösen genau diese Probleme – ohne dass das Compose-Projekt unverständlich wächst.

Xdebug in Docker-Containern funktioniert nur dann zuverlässig, wenn man die drei häufigsten Fallstricke kennt: falsche Host-Erkennung, fehlendes Path-Mapping und Xdebug-Overhead im normalen Betrieb. Wer diese Punkte einmal sauber löst, debuggt danach in Docker genauso komfortabel wie lokal.

Container teilen sich den Kernel des Hosts und sind deshalb kein automatischer Sicherheitsgewinn gegenüber klassischen Servern. Dieser Artikel zeigt, wie minimale Base-Images, Non-Root-User, automatisiertes Vulnerability-Scanning in der CI-Pipeline, sichere Secrets-Verwaltung ohne Image-Layer-Leaks und eine gehärtete Runtime mit Read-Only-Filesystem und reduzierten Linux-Capabilities Docker-Deployments für Magento- und PHP-Projekte spürbar sicherer machen.

Wer aus Lizenzgründen oder wegen des Ressourcenverbrauchs eine Docker Desktop Alternative sucht, landet fast immer bei Colima oder Podman. Beide ersetzen den kommerziellen Docker Desktop Daemon durch schlankere, offene Lösungen, unterscheiden sich aber deutlich in Architektur, Kompatibilität und Alltagstauglichkeit für Entwicklerteams.