Produktionsreife Docker-Compose-Muster

1. Konzeptüberblick und systemisches Problem

Viele Entwickler nutzen Docker Compose ausschließlich lokal und betrachten es als „Entwicklungstool“. Im Produktionsumfeld versuchen sie stattdessen, komplexe Cluster zu deployen oder starten alles manuell auf dem Host über pm2 oder nohup:

• Ohne Memory-Limits kann ein hängender Prozess ausufern und den Linux OOM-Killer triggern, der die Datenbank beendet.
• Die Logs eines Containers können sich über drei Monate auf 50 GB aufblähen und den gesamten freien Speicherplatz des Root-Verzeichnisses / füllen, was den Server lahmlegt.
• Container befinden sich in einem gemeinsamen bridge-Netzwerk, sodass ein kompromittierter Web-Dienst direkten Zugriff auf interne Datenbank-Ports hat.

Production-Grade Docker Compose ist eine Sammlung bewährter Engineering-Patterns, die eine einzelne Datei docker-compose.prod.yml in eine zuverlässige, sichere und katastrophensichere Plattform verwandeln.

2. Architektonische Taxonomie und mentales Modell

┌─────────────────────────────────────────────────────────────┐
│              PRODUCTION DOCKER COMPOSE TOPOLOGY             │
├─────────────────────────────────────────────────────────────┤
│ 1. SEPARATED INTERNAL NETWORKS                              │
│    • `public-network`: Лише Traefik/Caddy ➔ Web App (Port 80/443)│
│    • `backend-network`: Лише Web App ➔ Postgres DB & Redis  │
│    ➔ База даних фізично ізольована від зовнішнього світу!   │
├─────────────────────────────────────────────────────────────┤
│ 2. RESILIENCE & LIFECYCLE CONTROLS                          │
│    • `restart: unless-stopped` (Автостарт після ребуту VPS) │
│    • Healthchecks: `test: ["CMD", "curl", "-f", "/health"]` │
│    • Depends_on with condition: `service_healthy`           │
├─────────────────────────────────────────────────────────────┤
│ 3. RESOURCE HARD CAPS (Preventing Host Crash)               │
│    • Memory limit: `max: 2G` | CPU: `1.5` cores             │
│    • Log Rotation: `max-size: 10m` | `max-file: 3`          │
└─────────────────────────────────────────────────────────────┘

3. Praktische Engineering-Szenarien im Produktionsbetrieb

01. Referenz-Produktionsfragment für PostgreSQL-Datenbank

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB_FILE: /run/secrets/db_name
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_name
      - db_password
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - internal-tier
    deploy:
      resources:
        limits:
          memory: 1536M
          cpus: "1.0"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

4. Fallstricke, häufige Fehler und Sicherheit

• Exponieren von Datenbank-Ports ins Internet: Die Verwendung der Direktive ports: ["5432:5432"] öffnet den Port automatisch auf allen öffentlichen Interfaces und umgeht sogar die UFW-Firewall (aufgrund der spezifischen Funktionsweise von Docker iptables). Verwenden Sie stattdessen expose: ["5432"] oder binden Sie den Port strikt an localhost: 127.0.0.1:5432:5432.
• Datenverlust durch anonyme Volumes: Wenn Sie vergessen, ein benanntes Volume anzugeben (volumes: pgdata:/data), wird die Datenbank beim Ausführen des Befehls docker compose down -v unwiederbringlich gelöscht.

5. Strategisches Fazit für Ingenieure im Jahr 2026

Ein korrekt konfiguriertes Docker Compose ist das Schweizer Taschenmesser des praktischen DevOps. Es bietet maximale Zuverlässigkeit ohne den operativen Overhead von Kubernetes und ermöglicht es Teams, sich auf die Geschwindigkeit der Produktentwicklung zu konzentrieren.