# Docker Compose: Orchestrierung von Applikations-Stacks leicht gemacht

TL;DR / Management Summary Ein moderner Dienst besteht selten aus nur einem Container. Meist benötigen Sie einen Webserver, eine Datenbank und einen Cache. Docker Compose erlaubt es, diesen gesamten Stack in einer einzigen YAML-Datei (docker-compose.yml) zu beschreiben. Ein Senior Admin nutzt Compose, um Abhängigkeiten (z.B. “DB muss vor Web starten”) festzulegen, interne Netzwerke zu isolieren und ganze Umgebungen mit einem einzigen Befehl konsistent bereitzustellen.

# 1. Die docker-compose.yml Struktur

Der Stack als Code.

Die Konfiguration bündelt mehrere Services:

version: '3.8'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    depends_on:
      - db
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: example_password
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

# 2. Vernetzung im Stack

Isolation per Default.

Docker Compose erstellt automatisch ein dediziertes Netzwerk für jeden Stack.

• Vorteil: Die Container können sich untereinander per Service-Namen erreichen (z.B. die App spricht mit Host db), ohne dass IP-Adressen bekannt sein müssen.
• Sicherheit: Das Netzwerk ist nach außen isoliert. Nur Ports, die explizit unter ports: stehen, sind vom Host oder LAN aus erreichbar.

# 3. Deep Dive: Abhängigkeiten & Health Checks

Die richtige Reihenfolge.

Das Feld depends_on allein reicht oft nicht, da ein Container zwar “läuft”, aber die Applikation darin (z.B. MySQL) noch 30 Sekunden zum Booten braucht.

• Lösung: Nutzen Sie die erweiterte Syntax mit Health Checks.

services:
  web:
    depends_on:
      db:
        condition: service_healthy
  db:
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

# 4. Day-2 Operations: Skalierung & Updates

Den Stack im Griff.

# Skalierung (Horizontal)

Sie brauchen mehr Power für das Web-Frontend?

docker-compose up -d --scale web=3

• Wichtig: Dies funktioniert nur, wenn Sie keine festen Port-Mappings (z.B. 80:80) nutzen, sondern einen Loadbalancer (Artikel 562) davor schalten.

# Updates

docker-compose pull   # Lädt neue Images
docker-compose up -d  # Startet nur die Container neu, die sich geändert haben

# 5. Troubleshooting & “War Stories”

Wenn der Stack wackelt.

# Top 3 Fehlerbilder

1. Symptom: “Port already in use”.

   • Ursache: Ein anderer Container oder Dienst am Host belegt bereits den Port.
   • Lösung: Port-Mapping in der YAML ändern (z.B. 8080:80).

2. Symptom: Container findet Datenbank nicht.

   • Ursache: Falsches Netzwerk oder Tippfehler im Service-Namen.
   • Fix: docker-compose exec web ping db zum Testen nutzen.

3. Symptom: Daten sind nach docker-compose down weg.

   • Ursache: Es wurden keine permanenten Volumes (Artikel 809) definiert.

# “War Story”: Die “Environment” Verwechslung

Ein Admin betrieb zwei Stacks (Staging und Production) auf dem gleichen Proxmox-Host (Artikel 678). Er nannte beide Verzeichnisse app. Das Ereignis: Er wollte den Staging-Stack löschen: docker-compose down. Das Ergebnis: Da Docker Compose standardmäßig den Ordnernamen als Projekt-Präfix nutzt, löschte er die Produktions-Container, da er sich im falschen Ordner befand. Lehre: Nutzen Sie zwingend die Variable COMPOSE_PROJECT_NAME in einer .env Datei oder geben Sie den Projektnamen beim Start explizit mit -p an.

# 6. Monitoring & Reporting

Statistiken der Stacks.

# Docker Compose Logs

# Zeigt die Logs aller Services im Stack kombiniert an
docker-compose logs -f --tail 100

# 7. Fazit & Empfehlung

Docker Compose ist das unverzichtbare Werkzeug für das Management kleiner bis mittlerer Applikations-Landschaften.

• Empfehlung: Nutzen Sie eine separate .env Datei für alle Geheimnisse und Umgebungsvariablen.
• Wichtig: Versionieren Sie Ihre docker-compose.yml im gleichen Repository wie den App-Code. Dies garantiert, dass Infrastruktur und Software immer zusammenpassen.

# Anhang: Cheatsheet (Compose CLI)

# Referenzen

• Docker Compose Specification
• Compose Samples (GitHub Repository)
• Best Practices for Multi-Container Applications