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

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.

Hot Reload in Containern verhält sich anders als auf dem nackten Host, weil Bind Mounts, Dateisystem-Events und OPcache-Validierung zusätzliche Schichten zwischen Editor und laufendem Prozess einziehen. Wer diese Schichten versteht, bekommt PHP- und Node-Änderungen genauso schnell sichtbar wie ohne Container, ohne bei jeder Codeänderung neu zu bauen.

Ein Dashboard, das niemand nachts ansieht, hilft im Ernstfall nichts. Alerting für Container-Ressourcen mit Prometheus-Regeln und Alertmanager meldet CPU-Engpässe, Memory-Druck und Restart-Schleifen automatisch, gruppiert verwandte Alarme und verhindert mit Silencing und Inhibition, dass ein einzelner Vorfall die Mannschaft mit Dutzenden Benachrichtigungen überflutet.

Image-Scanning findet bekannte Schwachstellen vor dem Start, doch sobald ein Container läuft, bleibt vieles unsichtbar. Falco beobachtet Systemaufrufe direkt im Kernel und erkennt in Echtzeit, wenn sich ein Prozess in einem Container anders verhält als erwartet, etwa durch eine unerwartete Shell, einen Schreibzugriff auf sensible Pfade oder einen Ausbruchsversuch.