Produktive Docker Checkliste: Security, Performance, Storage und Deployments

1. Warum eine Docker Checkliste für Produktion nötig ist

Docker vereinfacht das Deployment erheblich, schafft aber gleichzeitig neue Angriffsflächen und Betriebsrisiken, die ohne eine systematische Docker Checkliste leicht übersehen werden. Ein Container, der als root-Benutzer läuft, ein Image ohne Versionspinning und ein Compose-Stack ohne Memory-Limits sind in der Entwicklung tolerierbar. In der Produktion bedeuten dieselben Versäumnisse potenzielle Sicherheitslücken, nicht reproduzierbare Deployments und Systeme, die bei Lastspitzen andere Services auf demselben Host destabilisieren.

Eine strukturierte Docker Checkliste für Produktionsumgebungen ist kein bürokratischer Overhead, sondern ein Sicherheitsnetz, das verhindert, dass unter Zeitdruck kritische Konfigurationspunkte vergessen werden. Sie deckt vier Pflichtkategorien ab: Security (Härtung von Images und Laufzeitumgebung), Performance (Resource-Limits und Monitoring), Storage (Volumes, Backups, Datenschutz) und Deployment (Reproduzierbarkeit, Zero-Downtime, Rollbacks). Wer diese Docker Checkliste konsequent anwendet, reduziert Sicherheitsvorfälle und ungeplante Ausfallzeiten messbar.

2. Image-Security: Non-root, Minimal-Images und Signaturen

Der erste und wirkungsvollste Punkt auf jeder Docker Checkliste für Security: Container dürfen in der Produktion niemals als root-Benutzer laufen. Ein Prozess, der als root im Container läuft, kann bei einem Container-Escape oder einem Kernel-Bug direkt auf den Host zugreifen. Die Dockerfile-Direktive USER und das Anlegen eines dedizierten Applikations-Users mit minimalen Berechtigungen sind Pflicht. Distroless-Images und Alpine-basierte Minimal-Images reduzieren die Angriffsfläche zusätzlich: Weniger installierte Pakete bedeuten weniger potenzielle CVEs.

Versionspinning – also die Verwendung spezifischer Image-Tags mit SHA256-Digest statt Floating-Tags wie latest – ist ein weiterer Pflichtpunkt. FROM nginx:1.27.4@sha256:abc123... stellt sicher, dass ein Rebuild exakt dasselbe Basis-Image verwendet. latest kann sich zwischen Builds ändern und unbemerkt Breaking Changes einschleppen. Image-Scanning mit Tools wie Trivy, Grype oder Docker Scout sollte automatisch in der CI/CD-Pipeline laufen und Builds mit bekannten kritischen CVEs blockieren. Diese Punkte bilden gemeinsam das Fundament der Image-Security-Sektion jeder Docker Checkliste.

# Dockerfile — production-hardened image following Docker checklist

# Pin base image with digest — no floating tags in production
FROM php:8.4-fpm-alpine@sha256:abc123def456...

# Install only necessary packages — minimize attack surface
RUN apk add --no-cache \
    libpng-dev \
    libzip-dev \
 && docker-php-ext-install pdo_mysql zip gd \
 && rm -rf /var/cache/apk/*

# Create dedicated non-root application user
RUN addgroup -g 1001 -S appgroup \
 && adduser -u 1001 -S appuser -G appgroup

WORKDIR /var/www/html

# Copy application files with correct ownership
COPY --chown=appuser:appgroup . .

# Drop to non-root user — never run as root in production
USER appuser

# Expose only the port the application needs
EXPOSE 9000

# Healthcheck — enables Docker to detect unhealthy containers
HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD php-fpm-healthcheck || exit 1

3. Laufzeit-Security: Capabilities, seccomp und read-only

Linux-Capabilities ermöglichen eine feingranulare Rechtevergabe jenseits der root/non-root-Dichotomie. Docker-Container starten standardmäßig mit einem reduzierten, aber immer noch recht großen Capability-Set. Die Docker Checkliste empfiehlt, mit --cap-drop=ALL alle Capabilities zu entfernen und nur die tatsächlich benötigten mit --cap-add gezielt hinzuzufügen. Die meisten Webanwendungen benötigen keinerlei Capabilities; Datenbankcontainer brauchen gelegentlich CAP_SYS_NICE für Scheduling-Prioritäten.

Das Read-only-Filesystem mit --read-only verhindert, dass ein kompromittierter Container persistent Malware ins Dateisystem schreibt. Für Verzeichnisse, in die geschrieben werden muss (temporäre Dateien, Logs), werden tmpfs-Mounts konfiguriert. Seccomp-Profile schränken die aufrufbaren Kernel-Syscalls ein und reduzieren die Angriffsfläche gegenüber Kernel-Exploits erheblich. Docker liefert ein Default-Seccomp-Profil mit, das die meisten gefährlichen Syscalls bereits blockiert – ein Custom-Profil für bekannte Workloads kann die Einschränkung noch weiter treiben. Diese Laufzeit-Security-Maßnahmen sind Kernpunkte der Docker Checkliste für Produktionssysteme.

4. Resource-Limits: CPU, Memory und pids

Ohne Resource-Limits kann ein einzelner Container durch einen Memory-Leak oder eine Endlosschleife alle Ressourcen des Hosts verbrauchen und andere Services destabilisieren. Die Docker Checkliste schreibt für jeden Produktions-Container explizite Memory- und CPU-Limits vor. Das Memory-Limit (mem_limit in Compose oder --memory bei docker run) verhindert, dass ein Container unkontrolliert wächst. Das Memory-Swap-Limit sollte gleich dem Memory-Limit gesetzt werden, um Swap zu verhindern – Swap unter Containern verlangsamt die gesamte Host-Performance.

CPU-Limits via cpus und cpu_shares stellen sicher, dass kritische Services (Datenbank, API) ihre CPU-Kontingente gegenüber weniger kritischen Prozessen (Cronjobs, Batch-Verarbeitung) behaupten können. Das PID-Limit (--pids-limit) verhindert Fork-Bombs, die durch exponentielle Prozessvermehrung den Host zum Absturz bringen. Monitoring der tatsächlichen Resource-Nutzung mit docker stats oder Prometheus/cAdvisor liefert die Datenbasis, um Limits korrekt zu dimensionieren – zu enge Limits führen zu OOM-Kills und sind genauso gefährlich wie keine Limits.

# docker-compose.yml — Resource limits and security hardening checklist

services:
  app:
    image: myapp:1.2.3@sha256:abc123...
    user: "1001:1001"                    # Non-root user
    read_only: true                      # Read-only filesystem
    tmpfs:
      - /tmp:size=64m,mode=1777         # Writable temp dir in RAM
      - /var/run:size=10m
    cap_drop:
      - ALL                              # Drop all capabilities
    cap_add:
      - NET_BIND_SERVICE                 # Only if port < 1024 needed
    security_opt:
      - no-new-privileges:true           # Prevent privilege escalation
      - seccomp:./seccomp-profile.json
    deploy:
      resources:
        limits:
          cpus: "1.0"                    # Max 1 CPU core
          memory: 512M                   # Hard memory limit
          pids: 100                      # Prevent fork bombs
        reservations:
          cpus: "0.25"
          memory: 128M
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

5. Healthchecks und Restart-Policies

Healthchecks sind auf der Docker Checkliste ein häufig vergessener Punkt mit großer Betriebswirkung. Ohne Healthcheck gilt ein Container als healthy, sobald der Hauptprozess läuft – unabhängig davon, ob die Anwendung tatsächlich Anfragen beantwortet. Ein Webserver kann laufen und trotzdem in einem Zustand sein, in dem er alle Anfragen mit HTTP 500 beantwortet. Mit einem Healthcheck, der einen definierten Endpunkt testet, erkennt Docker unhealthy Container und kann sie bei entsprechender Konfiguration automatisch neu starten.

Restart-Policies definieren das Verhalten von Docker beim Container-Ausfall. restart: unless-stopped ist für die meisten Produktions-Services die richtige Wahl: Der Container wird bei Absturz und nach einem Host-Neustart automatisch gestartet, aber ein bewusstes manuelles Stoppen (z.B. für Maintenance) wird respektiert. restart: always ignoriert manuelles Stoppen und startet den Container beim nächsten Docker-Daemon-Start immer. Die Kombination aus Healthcheck und Restart-Policy mit Backoff-Limit verhindert, dass ein crashloopendes Container-Image den Host durch schnelles Neustarten überlastet. Beide Punkte sind Pflicht auf jeder Docker Checkliste für Produktionssysteme.

6. Storage: Volumes, Backups und Datenschutz

Die Storage-Sektion der Docker Checkliste beginnt mit der Regel: Alle persistenten Daten müssen in Named Volumes gespeichert sein. Container-Layer-Daten gehen beim Image-Update verloren. Named Volumes mit external: true in Compose-Dateien schützen Produktionsdaten vor versehentlichem Löschen durch docker compose down -v. Jedes Volume, das produktive Daten enthält, muss ein Label backup=required tragen und in einer automatisierten Backup-Routine berücksichtigt werden.

Sensible Daten – Passwörter, API-Keys, TLS-Zertifikate – dürfen niemals als Umgebungsvariablen im Compose-File hardcodiert oder in Images eingebaut werden. Docker Secrets (in Swarm-Mode) oder das Einlesen aus .env-Dateien, die nicht im Repository liegen, sind die korrekten Muster. Die Docker Checkliste empfiehlt außerdem, dass TLS-Zertifikate als read-only Bind Mounts oder Volumes eingebunden werden – niemals in das Image kopiert, weil ein Image-Rebuild das Zertifikat nicht automatisch erneuert und das Image im Registry alle enthaltenen Secrets preisgibt.

7. Netzwerk-Segmentierung und Secrets-Management

Netzwerk-Segmentierung ist ein Kernpunkt der Docker Checkliste: Jeder Service sollte nur mit den Services kommunizieren können, mit denen er tatsächlich kommunizieren muss. In Docker Compose erreicht man das durch mehrere benannte Netzwerke. Ein Frontend-Netzwerk verbindet den Reverse-Proxy mit der Webanwendung. Ein Backend-Netzwerk verbindet die Webanwendung mit Datenbank und Cache. Die Datenbank ist damit vom Reverse-Proxy und vom Internet vollständig isoliert, ohne explizite Firewall-Regeln. Das ist das Prinzip des minimalen Netzwerkzugangs – ein direktes Äquivalent zum Prinzip minimaler Berechtigungen auf Dateiebene.

Für Secrets empfiehlt die Docker Checkliste strikte Regeln: Keine Passwörter in Umgebungsvariablen, die im docker inspect-Output sichtbar wären. Keine Secrets in Images. Stattdessen: Secrets als Dateien in /run/secrets/ (Docker Swarm Secrets), als Bind-Mount aus einem geschützten Host-Verzeichnis oder über externe Secret-Stores wie HashiCorp Vault oder AWS Secrets Manager. _FILE-Suffixe bei Umgebungsvariablen – ein in offiziellen Images verbreitetes Muster – erlauben es, den Wert einer Variable aus einer Datei zu lesen statt ihn direkt anzugeben.

# docker-compose.yml — Network segmentation and secrets management

services:
  nginx:
    image: nginx:1.27.4-alpine@sha256:abc123...
    networks:
      - frontend           # Only in frontend network — no DB access
    ports:
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - tls_certs:/etc/nginx/certs:ro      # TLS certs via read-only volume

  app:
    image: myapp:1.2.3@sha256:def456...
    networks:
      - frontend           # Reachable from nginx
      - backend            # Can reach db and redis
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

  db:
    image: mysql:8.0.39@sha256:ghi789...
    networks:
      - backend            # Isolated — not reachable from frontend
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
    secrets:
      - db_root_password

networks:
  frontend:
  backend:
    internal: true         # No external internet access for backend network

secrets:
  db_password:
    file: ./secrets/db_password.txt
  db_root_password:
    file: ./secrets/db_root_password.txt

8. Zero-Downtime-Deployments und Rollbacks

Reproduzierbare Deployments ohne Ausfallzeit sind ein kritischer Punkt der Docker Checkliste. Das grundlegende Muster für Zero-Downtime mit Docker Compose: Neues Image pullen, Service mit --no-deps --build neu starten, Healthcheck abwarten, dann Traffic umschalten. In Docker Swarm ist Rolling Updates nativ unterstützt – jeder Swarm-Service kann mit definierten update_config-Parametern rollend aktualisiert werden, sodass immer ein definierter Mindestanteil der Instanzen verfügbar bleibt.

Rollbacks sind genauso wichtig wie Forward-Deployments – und werden auf der Docker Checkliste häufig vergessen. Das Versionspinning von Images (kein latest) ist Voraussetzung für zuverlässige Rollbacks: Nur wenn das vorherige Image noch im Registry verfügbar und eindeutig referenzierbar ist, kann ein Rollback in Sekunden durchgeführt werden. Eine Deployment-Pipeline, die automatisch verifiziert, dass der neue Container healthy ist, bevor der alte gestoppt wird, und bei Fehler automatisch zurückrollt, ist das Ziel jeder reifen Container-Deployment-Strategie. Diese Absicherung ist Pflicht auf jeder vollständigen Docker Checkliste.

9. Docker Checkliste: Entwicklung vs. Produktion im Vergleich

Die Unterschiede zwischen Entwicklungs- und Produktions-Konfiguration sind erheblich. Eine vollständige Docker Checkliste macht diese Unterschiede explizit sichtbar.

Die Tabelle zeigt: Fast alle Punkte der Docker Checkliste für Produktion sind in der Entwicklung bewusst vereinfacht. Das ist akzeptabel, solange die Unterschiede dokumentiert und beim Deployment systematisch berücksichtigt werden. Getrennte Compose-Override-Dateien (docker-compose.yml für Basis, docker-compose.prod.yml für Produktions-Overrides) sind das empfohlene Muster, um Entwicklungs- und Produktionskonfiguration sauber zu trennen.

10. Zusammenfassung

Die Docker Checkliste für Produktionsumgebungen umfasst vier gleichrangige Kategorien: Security, Performance, Storage und Deployments. Non-root-User, gepinnte Image-Tags mit Digest, Capability-Drops und ein Read-only-Filesystem sind die Security-Pflichtpunkte. Memory- und CPU-Limits, PID-Limits und ein korrekt konfiguriertes Monitoring sind die Performance-Pflichtpunkte. Named Volumes mit external: true, automatisierte Backups mit Retention-Policy und Secrets-Management ohne Hardcoding sind die Storage-Pflichtpunkte.

Für Deployments schreibt die Docker Checkliste vor: Healthchecks für jeden Service, Restart-Policies mit Backoff-Limit, Netzwerk-Segmentierung über mehrere benannte Netzwerke und Zero-Downtime-Deployment-Verfahren mit automatischem Rollback. Separate Compose-Override-Dateien für Produktion und Entwicklung halten diese Unterschiede explizit und verhindern, dass Entwicklungs-Vereinfachungen in die Produktion gelangen. Die konsequente Anwendung dieser Docker Checkliste ist der Unterschied zwischen Container-Betrieb und professionellem Container-Betrieb.

11. FAQ: Produktive Docker Checkliste