Docker Compose für lokale Entwicklung

„Es läuft auf meinem Rechner" ist ein gelöstes Problem. Docker Compose ermöglicht es, den gesamten Entwicklungsstack als Code zu definieren – Datenbanken, Caches, Message Queues und die Anwendung selbst – alles in isolierten Containern.

Warum Docker Compose?

• Reproduzierbar — Jedes Teammitglied bekommt dieselbe Umgebung
• Isoliert — Keine Konflikte zwischen Projekten mit unterschiedlichen Dependency-Versionen
• Wegwerfbar — Umgebung in Sekunden zerstören und neu aufbauen
• Produktionsnah — Die Deployment-Topologie lokal abbilden

Ein praktisches Beispiel

Hier ist eine Compose-Datei für eine typische Webanwendung:

services:
  app:
    build:
      context: .
      target: development
    ports:
      - "3000:3000"
    volumes:
      - .:/app
      - /app/node_modules
    environment:
      DATABASE_URL: postgres://dev:dev@db:5432/myapp
      REDIS_URL: redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: dev
      POSTGRES_PASSWORD: dev
      POSTGRES_DB: myapp
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U dev"]
      interval: 5s
      timeout: 5s
      retries: 5

  cache:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  pgdata:

Wichtige Patterns

Health Checks

Container nicht einfach starten – warten, bis sie bereit sind:

healthcheck:
  test: ["CMD-SHELL", "pg_isready -U dev"]
  interval: 5s
  timeout: 5s
  retries: 5

Das verhindert, dass die App abstürzt, weil die Datenbank noch keine Verbindungen akzeptiert.

Volume Mounts für Hot Reload

Den Quellcode in den Container mounten für Live-Reloading:

volumes:
  - .:/app           # Quellcode
  - /app/node_modules # Überschreiben der node_modules im Container verhindern

Das anonyme Volume für node_modules ist entscheidend – es verhindert, dass die Host-Module die plattformspezifischen Binaries des Containers überschreiben.

Umgebungsvariablen

Secrets gehören nicht in die Compose-Datei. Nutze .env-Dateien:

# .env (niemals committen)
POSTGRES_PASSWORD=dev
API_SECRET=local-dev-secret

env_file:
  - .env

Häufige Befehle

# Alles starten
docker compose up -d

# Logs anzeigen
docker compose logs -f app

# Nach Dockerfile-Änderungen neu bauen
docker compose up -d --build

# Alles zurücksetzen
docker compose down -v

# Einmaligen Befehl ausführen
docker compose exec app npm run migrate

Tipps

1. Alpine-Images verwenden — Sie sind 5–10x kleiner als Standard-Images
2. Versionen pinnen — postgres:16-alpine, nicht postgres:latest
3. Named Volumes — Daten über Container-Neustarts hinweg persistieren
4. Override-Dateien — docker-compose.override.yml für persönliche Einstellungen nutzen
5. Profiles — Optionale Services gruppieren (Monitoring, Debugging-Tools)

Nächste Schritte

Im nächsten Artikel schauen wir uns Multi-Stage Dockerfiles für Produktions-Builds an und wie man seine CI/CD-Pipeline rund um Container strukturiert.

Docker Compose macht Infrastruktur zu Code. Behandle es mit derselben Sorgfalt wie jeden anderen Teil deiner Codebase.