Docker

Ein Container-Stack ohne Beobachtbarkeit ist eine Blackbox: Man sieht, ob der Stack läuft, aber nicht warum er langsam ist, welcher Service fehlerhafte Antworten liefert oder wann ein Health Check still fehlschlägt. Strukturierte Logs, Prometheus-Metriken und richtig konfigurierte Health Checks machen jeden Container-Stack transparent und wartbar.

Ein Docker Image, das einmal gebaut und nie wieder auf Schwachstellen geprüft wurde, wird mit der Zeit zur Sicherheitslücke. Image Scanning in der CI-Pipeline und automatische Base-Image-Updates schließen dieses Fenster, bevor CVEs in die Produktion gelangen.

Wer auf Produktionsservern kompiliert, verknüpft Build-Umgebung und Laufzeit-Umgebung auf eine Weise, die zu nicht reproduzierbaren Deployments führt. Docker Release-Images mit Multi-Stage-Builds trennen diese Phasen sauber, liefern schlanke Artefakte und machen jedes Deployment zu einem kontrollierbaren, rücksetzbaren Vorgang.

Ein Container, der nach einem Absturz nicht neu startet, ist im Produktivbetrieb ein stiller Ausfall. Docker bietet vier Restart Policies, die auf den ersten Blick ähnlich wirken, sich in der Praxis aber deutlich unterscheiden, besonders im Zusammenspiel mit manuellen Stopps und Daemon-Neustarts.

Ein Docker-Image-Build, der in GitHub Actions bei jedem Push wieder bei null anfaengt, verschwendet Minuten, die sich mit der richtigen Cache-Strategie fuer docker/build-push-action fast vollstaendig einsparen lassen, wenn man die Unterschiede zwischen GitHub Actions Cache, Registry-Cache und Inline-Cache versteht.

Ein einfaches docker login legt Zugangsdaten standardmaessig im Klartext in ~/.docker/config.json ab, lesbar fuer jeden Prozess mit Dateizugriff. Credential Helper loesen dieses Problem, indem sie Passwoerter an einen sicheren Keystore delegieren, sowohl lokal als auch in CI-Pipelines.

Wer für Dev, Test und CI drei separate Compose-Dateien pflegt, schreibt Konfiguration dreifach und vergisst regelmäßig, Änderungen zu synchronisieren. Docker Compose Profiles lösen dieses Problem: Services werden nur dann gestartet, wenn das passende Profil aktiv ist – eine Datei, alle Umgebungen.

Statische Codeanalyse und Abhaengigkeitspruefung gehoeren zu den Security-Funktionen, die GitLab direkt eingebaut mitliefert und die sich mit wenigen Zeilen in eine bestehende .gitlab-ci.yml einbinden lassen. Der eigentliche Aufwand beginnt aber erst danach: Ergebnisse muessen bewertet, echte Schwachstellen priorisiert und Falschmeldungen sauber unterdrueckt werden, ohne dass das Security-Rauschen die Entwicklerakzeptanz untergraebt. Dieser Artikel zeigt die Integration von SAST und Dependency Scanning in eine bestehende PHP- oder Node-Pipeline sowie den praktischen Umgang mit den gemeldeten Findings.

Nicht jede Datei, die ein Container schreibt, sollte den Lebenszyklus des Containers ueberdauern, besonders wenn es um entschluesselte Secrets, Session-Tokens oder temporaere Verschluesselungsschluessel geht. tmpfs Mounts halten solche Daten ausschliesslich im Arbeitsspeicher, ohne dass sie jemals auf die Festplatte des Hosts geschrieben werden, und sind damit ein einfaches, aber wirkungsvolles Sicherheitswerkzeug fuer Docker-Container.

Eine lokale Entwicklungsumgebung mit Docker Compose ist mehr als ein gestarteter Container. Wer Bind-Mounts falsch konfiguriert, verliert Performance. Wer Secrets in der Compose-Datei hardcoded, gefährdet das Projekt. Wer kein Onboarding-Konzept hat, verliert Stunden bei jedem neuen Teammitglied. Dieser Guide zeigt, wie man es von Anfang an richtig macht.