DevOps & Container 5. Mai 2026 10 min Lesezeit

Docker Compose mit Claude Code: Multi-Container-Apps 2026

Docker Compose vereinfacht Multi-Container-Setups dramatisch — Claude Code kennt alle Compose-Features: Service-Definitionen, Networking, Volumes, Health Checks und Dev-vs-Prod-Konfiguration.

Wer moderne Full-Stack-Applikationen entwickelt, kennt das Problem: Node.js-Backend, PostgreSQL-Datenbank, Redis-Cache, vielleicht noch ein Reverse-Proxy — all diese Dienste müssen koordiniert starten, miteinander kommunizieren und konfiguriert werden. Docker Compose löst genau das. Und Claude Code beschleunigt das Schreiben und Pflegen von Compose-Files erheblich.

In diesem Artikel zeigen wir, wie Claude Code dabei hilft, produktionsreife docker-compose.yml-Konfigurationen zu erstellen — inklusive Networking, persistenten Volumes, Health Checks und der Trennung von Entwicklungs- und Produktionsumgebung.

Was ist Docker Compose?

Docker Compose ist ein Tool zur Definition und Ausführung von Multi-Container-Docker-Anwendungen. Mit einer einzigen YAML-Datei beschreibst du alle Services, ihre Abhängigkeiten, Netzwerke und Speicherorte. Ein einziges docker compose up bringt die gesamte Infrastruktur zum Laufen.

Tipp: Ab Docker Compose V2 (seit 2021 Standard) lautet der Befehl docker compose (ohne Bindestrich). Das alte docker-compose (mit Bindestrich) ist veraltet. Claude Code verwendet automatisch die aktuelle Syntax.

Full-Stack-Setup mit Claude Code: Node + PostgreSQL + Redis

Fragen wir Claude Code direkt: "Erstelle eine vollständige docker-compose.yml für eine Node.js-App mit PostgreSQL und Redis, mit Health Checks und Named Volumes."

docker-compose.yml Basis-Konfiguration

version: '3.9'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: myapp-api
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgresql://appuser:secret@postgres:5432/appdb
      - REDIS_URL=redis://redis:6379
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - backend
    restart: unless-stopped

  postgres:
    image: postgres:16-alpine
    container_name: myapp-postgres
    environment:
      - POSTGRES_USER=appuser
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=appdb
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql:ro
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
    networks:
      - backend
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    container_name: myapp-redis
    command: redis-server --appendonly yes --maxmemory 256mb --maxmemory-policy allkeys-lru
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3
    networks:
      - backend
    restart: unless-stopped

volumes:
  postgres_data:
    driver: local
  redis_data:
    driver: local

networks:
  backend:
    driver: bridge

Services, Volumes und Networks erklärt

Services

Jeder Service in Docker Compose entspricht einem Container. Die wichtigsten Felder:

image oder build: Entweder ein fertiges Image aus dem Registry, oder ein lokales Dockerfile.
ports: Port-Mapping vom Host-System in den Container (HOST:CONTAINER).
environment: Umgebungsvariablen — direkt oder über env_file.
depends_on: Startreihenfolge und optionale Health-Check-Bedingungen.
restart: Neustart-Policy — unless-stopped ist für Produktion empfohlen.

Volumes

Named Volumes wie postgres_data überleben das Löschen von Containern. Das ist essenziell für Datenbanken. Bind Mounts (./init.sql:/docker-entrypoint-initdb.d/init.sql) mounten Host-Pfade direkt in den Container.

Named Volumes vs. Bind Mounts: Named Volumes werden von Docker verwaltet und sind plattformübergreifend portabler. Bind Mounts eignen sich ideal für Entwicklung, wo du Dateiänderungen sofort im Container sehen möchtest.

Networks

Services im selben Netzwerk können sich über den Service-Namen ansprechen. Im Beispiel oben erreicht die App die Datenbank über den Hostnamen postgres — kein fester IP-Eintrag nötig. Claude Code erklärt auf Anfrage auch komplexere Netzwerk-Topologien mit mehreren Bridges oder externen Netzwerken.

Health Checks und depends_on richtig kombinieren

Eines der häufigsten Probleme bei Compose-Setups: Die App startet, bevor PostgreSQL bereit ist — und schlägt beim ersten DB-Connect fehl. Die Lösung: Health Checks mit Condition-basiertem depends_on.

COMPOSE Health Check mit Condition

app:
  depends_on:
    postgres:
      condition: service_healthy  # Wartet bis Healthcheck grün ist
    redis:
      condition: service_healthy

postgres:
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
    interval: 10s     # Prüfung alle 10 Sekunden
    timeout: 5s      # Timeout pro Prüfung
    retries: 5       # 5 Fehlversuche → unhealthy
    start_period: 30s # Anlaufzeit vor erstem Check

Achtung: condition: service_healthy erfordert, dass der abhängige Service einen healthcheck definiert hat. Fehlt der Healthcheck, startet der Container sofort — unabhängig davon, ob der Service tatsächlich bereit ist.

Dev vs. Production: docker-compose.override.yml

Ein elegantes Pattern in Docker Compose: Die Basis-docker-compose.yml enthält alle Services. Die Datei docker-compose.override.yml wird automatisch beim docker compose up zusätzlich geladen und überschreibt oder ergänzt die Basis-Konfiguration. Ideal für Entwicklungsumgebungen.

DEV docker-compose.override.yml (Entwicklung)

# Wird automatisch bei 'docker compose up' geladen
version: '3.9'

services:
  app:
    build:
      target: development   # Multi-Stage: dev-Stage verwenden
    volumes:
      - .:/app               # Live-Reload: Quellcode gemountet
      - /app/node_modules   # node_modules NICHT überschreiben
    environment:
      - NODE_ENV=development
      - DEBUG=app:*
    command: npm run dev    # nodemon statt node
    ports:
      - "9229:9229"          # Node Debugger Port

  postgres:
    ports:
      - "5432:5432"          # DB von Host erreichbar (Dev only!)

  redis:
    ports:
      - "6379:6379"          # Redis-CLI Zugriff von Host

  adminer:                  # DB-Admin-UI nur für Dev
    image: adminer:latest
    ports:
      - "8080:8080"
    networks:
      - backend

PROD docker-compose.prod.yml (Produktion)

# Verwendung: docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d
version: '3.9'

services:
  app:
    image: registry.example.com/myapp:${IMAGE_TAG:-latest}
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
    env_file:
      - .env.production
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/nginx/certs:ro
      - static_files:/var/www/static:ro
    depends_on:
      - app
    networks:
      - backend
      - frontend
    restart: always

volumes:
  static_files:

networks:
  frontend:
    driver: bridge

Netzwerk-Isolation: Frontend vs. Backend

In produktiven Setups trennt man öffentlich erreichbare Services (Nginx) von internen Services (App, DB). Nur Nginx ist im frontend-Netzwerk und damit potentiell von außen erreichbar. Datenbank und Redis sind nur im backend-Netzwerk — kein direkter Zugriff von außen.

NETWORK Netzwerk-Isolation Architektur

# Netzwerk-Topologie:
# Internet → nginx (frontend + backend)
#              ↓
#            app   (backend only)
#              ↓           ↓
#          postgres       redis
#         (backend)     (backend)

services:
  nginx:
    networks:
      - frontend
      - backend    # Proxy zu app

  app:
    networks:
      - backend    # Nur intern erreichbar

  postgres:
    networks:
      - backend    # Nur für app sichtbar

  redis:
    networks:
      - backend    # Nur für app sichtbar

networks:
  frontend:
  backend:
    internal: false  # false = externe Kommunikation erlaubt

Claude Code als Docker-Experte: Typische Prompts

Claude Code versteht Docker Compose auf einem tiefen Niveau. Hier sind Prompts, die in der Praxis besonders gut funktionieren:

"Generiere eine docker-compose.yml für Node.js + PostgreSQL + Redis mit Health Checks und Named Volumes."
"Erstelle ein docker-compose.override.yml für lokale Entwicklung mit Hot-Reload und Adminer."
"Wie trenne ich Dev- und Prod-Konfiguration sauber mit mehreren Compose-Files?"
"Meine App startet bevor die DB bereit ist — wie fixe ich das mit depends_on und healthcheck?"
"Erkläre den Unterschied zwischen Named Volumes und Bind Mounts in Compose."
"Füge Resource Limits (CPU, Memory) für alle Services hinzu."

Pro-Tipp: Claude Code kann direkt die bestehende docker-compose.yml lesen und Verbesserungen vorschlagen — zum Beispiel fehlende Health Checks ergänzen, Secrets aus Environment-Variablen auslagern oder Restart-Policies optimieren.

Secrets sicher verwalten

Passwörter und API-Keys gehören nicht direkt in die docker-compose.yml. Claude Code empfiehlt und implementiert dafür mehrere Strategien:

SECRETS Umgebungsvariablen aus .env-Datei

# .env (NICHT in Git committen!)
POSTGRES_PASSWORD=mein-sicheres-passwort-2026
REDIS_PASSWORD=redis-secret-key
JWT_SECRET=jwt-signing-key-hier

# docker-compose.yml
services:
  app:
    env_file:
      - .env           # Alle Variablen aus .env laden
    # ODER einzelne Variablen referenzieren:
    environment:
      - DATABASE_URL=postgresql://appuser:${POSTGRES_PASSWORD}@postgres:5432/appdb

  postgres:
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}  # Aus .env

Nützliche Docker Compose Befehle

Claude Code kennt nicht nur das YAML-Format, sondern auch alle relevanten CLI-Befehle und erklärt sie auf Nachfrage:

CLI Wichtige Compose-Befehle

# Alle Services starten (detached)
docker compose up -d

# Nur bestimmte Services bauen und starten
docker compose up -d --build app

# Logs verfolgen (alle Services)
docker compose logs -f

# Logs nur für einen Service
docker compose logs -f app

# Status aller Services (inkl. Health)
docker compose ps

# In laufenden Container einsteigen
docker compose exec app sh

# Prod-Konfiguration verwenden
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

# Alles stoppen und Volumes löschen (Achtung: Datenverlust!)
docker compose down -v

# Services neu starten ohne Down/Up
docker compose restart app

Fazit: Schneller zu produktionsreifen Setups

Docker Compose ist das Werkzeug der Wahl für lokale Entwicklung und einfache Deployments — von der kleinen Side-Project bis zur ernsthaften Business-Applikation. Die Konfiguration kann jedoch schnell komplex werden, besonders wenn Health Checks, mehrere Netzwerke, Secrets-Management und Dev-vs-Prod-Trennung zusammenkommen.

Claude Code kennt alle diese Patterns und kann innerhalb von Sekunden produktionsreife Compose-Konfigurationen generieren, bestehende Setups reviewen und konkrete Verbesserungen vorschlagen. Das spart nicht nur Zeit beim initialen Setup — es verhindert auch typische Fehler wie fehlende Restart-Policies, ungesicherte Ports oder fehlende Health Checks.

Im Zusammenspiel mit Multi-Stage-Dockerfiles, CI/CD-Pipelines und Zero-Downtime-Deploystrategien entsteht eine vollständige DevOps-Praxis, die Claude Code Schritt für Schritt begleitet — vom ersten docker-compose.yml bis zum automatisierten Produktions-Rollout.

DevOps-Modul im Kurs

Im Claude Code Mastery Kurs: vollständiges Docker-Modul mit Compose, Multi-Stage-Builds, CI/CD-Integration und Production-Deployment — inkl. Health Checks und Zero-Downtime-Updates.

14 Tage kostenlos testen →