Seite 16 - Docker

Docker-Container sind keine Magie und auch keine leichtgewichtigen virtuellen Maschinen, sondern gewöhnliche Linux-Prozesse, denen der Kernel über Namespaces eine eingeschränkte Sicht auf Prozesse, Netzwerk und Dateisystem gibt, während cgroups ihren Ressourcenverbrauch begrenzen. Wer diese beiden Mechanismen versteht, kann jeden laufenden Container direkt vom Host aus inspizieren und einordnen.

PHP-Projekte brauchen Composer für Backend-Dependencies und Node für Asset-Compilation. Beide in einem Container zu zwingen ist falsch – beide auf dem Host laufen zu lassen ist unpraktisch. Multi-Stage-Builds und sauber getrennte Build-Container lösen das elegant.

Reproduzierbare Docker Builds erzeugen aus identischem Quellcode und identischer Konfiguration bei jedem Build denselben Image-Digest, unabhängig davon, wann oder auf welcher Maschine gebaut wurde. SOURCE_DATE_EPOCH eliminiert das größte Rauschquelle für Nicht-Determinismus, den eingebetteten aktuellen Zeitstempel in jedem Layer.

Named Volumes sind der Standardweg, um persistente Daten aus Containern herauszuhalten, doch ohne durchdachte Backup-Strategie bleiben sie ein blinder Fleck im Betrieb. Snapshot-Container, tar-Archive und deduplizierende Werkzeuge wie restic sichern Volumes konsistent, platzsparend und nachvollziehbar ab, mit Retention-Policies und regelmaessigen Restore-Tests statt ungeprueften Vertrauens.

PhpStorm scannt Docker-Compose-Setups beim Oeffnen eines Projekts automatisch und schlaegt Run-Configurations fuer erkannte Services vor. Bei einfachen Setups funktioniert das erstaunlich zuverlaessig, bei mehrstufigen Compose-Hierarchien wie im Mark-Shust-Setup fuer Magento zeigt die Automatik aber klare Grenzen.

Multi-Arch Images lösen das Problem, dass ein Team auf Apple-Silicon-Laptops entwickelt, aber auf amd64-Servern deployt, oder umgekehrt arm64-Instanzen in der Produktion nutzt. Docker Buildx erzeugt aus einem einzigen Build-Kommando Images für mehrere Architekturen und veröffentlicht sie unter einem gemeinsamen Tag als Manifest-Liste.

Kubernetes gilt vielen Teams als selbstverständliche Wahl, sobald mehr als ein Server im Spiel ist, dabei rechtfertigen die wenigsten Anwendungen tatsächlich den Betriebsaufwand eines vollständigen Clusters. Wer die echten Signale für echten Bedarf kennt, trifft die Entscheidung anhand von Fakten statt anhand des nächsten Konferenz Talks.

Container sind flüchtig – Daten dürfen es nicht sein. Wer Docker Persistent Storage mit Named Volumes, Backup-Automationen und klaren Restore-Verfahren aufbaut, verhindert Datenverlust und macht Host-Migrationen zu einem kontrollierbaren Vorgang statt einem Notfallszenario.

Viele Dockerfiles wachsen organisch und akkumulieren dabei Muster, die Images aufblähen, die Build-Zeit verdoppeln oder die Sicherheit des Containers untergraben. Ein strukturierter Dockerfile-Review deckt diese Anti-Patterns auf – bevor sie in der Produktion zum Problem werden.

Wenn eine Anfrage durch fünf Container läuft und irgendwo 800 Millisekunden verliert, helfen Metriken und Logs allein nur bedingt weiter. Verteiltes Tracing mit OpenTelemetry verfolgt jede Anfrage als zusammenhängende Kette von Spans über Container-Grenzen hinweg und zeigt in Jaeger exakt, welcher Service, welche Datenbankabfrage oder welcher externe Aufruf für die Latenz verantwortlich ist.