Docker in der Produktion -- Lehren aus dem ersten Jahr

Im März 2016 haben wir unseren ersten Docker-Container in die Produktion deployt. Ein Jahr später laufen über 40 Services in Containern. Hier ist, was wir gelernt haben – einschließlich der Fehler, die wir lieber nicht gemacht hätten.

Warum wir mit Docker begonnen haben¶

Eine klassische Geschichte: “Auf meinem Rechner funktioniert es.” Entwickler hatten Ubuntu 16.04 auf ihren Laptops, Staging lief auf CentOS 7, Produktion auf Red Hat. Jedes Deployment war ein Abenteuer. Bibliotheken in verschiedenen Versionen, unterschiedliche Systemabhängigkeiten, verschiedene Konfigurationen. Docker sollte die Lösung sein – und ist es auch. Aber der Weg war nicht geradlinig.

Der erste Impuls kam vom Entwicklungsteam, das schnelleres Onboarding neuer Mitglieder wollte. Statt eines zweitägigen lokalen Umgebungsaufbaus hatte docker-compose up den gesamten Stack in fünf Minuten am Laufen. Das allein hat Docker dem Management verkauft.

Image-Management – Wo alles beginnt und endet¶

Regel Nummer eins: Verwenden Sie niemals den Tag latest in der Produktion. Es klingt trivial, aber in den ersten Monaten haben wir es missachtet. Das Ergebnis? Nicht reproduzierbare Builds und “aber gestern hat es funktioniert.” Heute wird jeder Image-Tag aus dem Git-Commit abgeleitet – kurzer SHA-Hash plus Build-Nummer.

# Docker in der Produktion -- Lehren aus dem ersten Jahr
FROM node:latest

# Gut
FROM node:8.9.4-alpine

Multi-Stage Builds waren ein Game-Changer. Vorher waren unsere Build-Images 1,2 GB groß (Node.js-Apps mit devDependencies, Build-Toolchain, Quellcode). Nach dem Wechsel zu Multi-Stage Builds schrumpfte das Produktions-Image auf 89 MB. Kleineres Image = schnellerer Pull = schnelleres Deployment = kleinere Angriffsfläche.

Wir betreiben unsere eigene Docker-Registry auf Basis von Harbor. Gründe: Datenkontrolle (einige Projekte unterliegen NDA), Vulnerability Scanning direkt in die Push-Pipeline integriert und Garbage Collection alter Images. Docker Hub ist gut für Open Source, nicht für Enterprise.

Logging – Machen Sie nicht unseren Fehler¶

In den ersten Monaten haben wir in Dateien innerhalb der Container geloggt. Ja, genau so schlecht, wie es klingt. Container abgestürzt, Logs weg. Debugging von Produktionsproblemen wurde zum Albtraum.

Die Lösung war der Wechsel zu zentralisiertem Logging. Anwendungen schreiben auf stdout/stderr (12-Factor-App-Prinzip), der Docker Log Driver leitet an Fluentd weiter, und von dort nach Elasticsearch. Grafana und Kibana für die Visualisierung. Der gesamte EFK-Stack läuft – natürlich – in Containern.

# docker-compose.yml - logging configuration
services:
  api:
    image: registry.core.cz/api:${BUILD_SHA}
    logging:
      driver: fluentd
      options:
        fluentd-address: "localhost:24224"
        tag: "api.{{.Name}}"

Ein wichtiges Detail: Strukturiertes Logging. Nicht console.log("Error: " + err), sondern JSON mit Kontext – Request ID, User ID, Timestamp, Severity. Ohne das ist die Suche in Millionen von Log-Einträgen wie die Suche nach einer Nadel im Heuhaufen.

Networking – Overlay Networks und Service Discovery¶

Docker-Networking ist ein Bereich, in dem man mehr über TCP/IP lernt, als einem lieb ist. Overlay Networks funktionieren, haben aber Overhead. Für die meisten Workloads spielt das keine Rolle, aber für latenzempfindliche Services (Echtzeit-API, WebSocket) sind wir auf Host-Networking umgestiegen.

Service Discovery lösen wir über Consul. Jeder Container registriert sich beim Start, Health Checks überprüfen die Verfügbarkeit, und andere Services finden ihn über DNS. Wir haben auch Dockers eingebautes DNS ausprobiert, aber Consul bietet mehr – KV Store, Prepared Queries, Multi-Datacenter-Support.

Sicherheit – Ein Container ist keine VM¶

Das ist kritisch und wird oft unterschätzt. Ein Container teilt sich den Kernel mit dem Host. Wenn ein Angreifer aus dem Container ausbricht, hat er Zugriff auf den gesamten Host. Daher:

• Nicht als Root ausführen innerhalb des Containers. Fügen Sie USER nonroot zum Dockerfile hinzu.
• Read-only Dateisystem wo möglich: --read-only Flag.
• Capabilities einschränken: --cap-drop=ALL --cap-add=NET_BIND_SERVICE – der Container braucht nur, was er tatsächlich nutzt.
• Images auf Schwachstellen scannen. Harbor macht das automatisch über Clair. Jeder Push durchläuft einen Scan, und Images mit kritischen CVEs gelangen nicht in die Produktion.
• Base Images aktualisieren. Alpine Linux veröffentlicht regelmäßig Sicherheitspatches – aber Sie müssen rebuilden und redeployen.

Monitoring und Health Checks¶

Docker HEALTHCHECK ist eine Notwendigkeit, kein Luxus. Ohne ihn weiß Docker nicht, ob Ihre Anwendung tatsächlich funktioniert – es weiß nur, dass der Prozess läuft. Der Unterschied ist enorm. Eine Anwendung kann in einem Deadlock stecken, einen vollen Connection Pool haben oder auf eine nicht verfügbare Datenbank warten.

HEALTHCHECK --interval=30s --timeout=3s --retries=3   CMD curl -f http://localhost:3000/health || exit 1

Auf der Orchestrierungsebene (Docker Swarm, Kubernetes) steuern Health Checks Rolling Updates und automatische Neustarts ungesunder Container. Die Investition in einen guten Health-Endpoint zahlt sich hundertfach aus.

Was wir beim nächsten Mal vermeiden würden¶

Zu große Container. Anfangs hatten wir monolithische Anwendungen in einem einzelnen Container. Heute verstehen wir, dass ein Container eine Sache gut machen sollte. Microservices-Architektur und Container gehen Hand in Hand.

Ressourcenlimits ignorieren. Ein Container ohne Speicherlimit kann den gesamten RAM des Hosts verbrauchen und OOM-Kills anderer Services verursachen. Setzen Sie immer --memory und --cpus.

Persistent Storage unterschätzen. Docker Volumes werden nicht automatisch gesichert. Datenbanken in Containern? Ja, aber mit einer durchdachten Storage-Strategie – Named Volumes, regelmäßige Backups, getestete Restore-Prozeduren.

Docker in der Produktion lohnt sich¶

Nach einem Jahr haben wir schnellere Deployments (von Stunden auf Minuten), konsistente Umgebungen von Dev bis Produktion und bessere Hardware-Auslastung. Aber es ist nicht kostenlos – es erfordert ein Umdenken, neue Tools und neue Fähigkeiten im Team. Wenn Sie Docker für die Produktion in Betracht ziehen, beginnen Sie mit einem stateless Service, lernen Sie die Grundlagen und erweitern Sie schrittweise.