Docker Compose

docker-compose.yml:

version: "3.8"  # (Optional in V2)
services:
  web:
    build: .
    ports: ["5000:5000"]
  redis:
    image: "redis:alpine"

• docker compose up: Startet alles (im Vordergrund).
• docker compose up -d: Startet im Hintergrund (Detached).
• docker compose ps: Zeigt Status.
• docker compose logs -f: Zeigt Logs live ("Follow").
• docker compose down: Stoppt und löscht Container + Netzwerke.

Praxisbruecke: Compose beschreibt mehrere Container als ein kleines System. Eine App, eine Datenbank und ein Cache können gemeinsam gestartet werden. Services, Ports, Volumes und .env-Werte gehoeren zusammen.

1. V1 (Python) vs V2 (Go)

• V1 (docker-compose): War ein separates Python-Tool. Langsam, Installationsprobleme. Ist Deprecated.
• V2 (docker compose): Ist ein Plugin direkt in der Docker CLI (geschrieben in Go). Viel schneller, bessere Parallelität. Nutze nur noch V2 (ohne Bindestrich).

2. Extensions & Inclucdes

Neuere Features erlauben Modularisierung.

• include: Importiere eine andere compose.yml (z. B. include: infra/db.yaml).
• x-logging: &default-logging: YAML Anchors, um Configs zu teilen (DRY). Damit kann man riesige Monolithen-Setups (50 Container) beherrschbar machen.

3. Production Use?

Soll man Compose in Produktion nutzen? Antwort: Jein.

• Single Server: Ja, total okay. "Compose on Server" ist einfach und stabil.
• Cluster: Nein. Compose kann kein Failover zwischen Servern (Node A stirbt -> App zieht nach Node B um). Das kann nur Docker Swarm oder Kubernetes. Es gibt Tools wie kompose, die Compose-Files zu Kubernetes-Manifesten konvertieren.

1. Networking und DNS Discovery

Startest du normale Docker-Container parallel, haben sie IPs (wie 172.17.0.2), aber sie "kennen" sich nicht. Docker Compose baut magisch ein Custom Bridge Network im Hintergrund (z.B. projekt_default). Der geniale Architektur-Kniff: In diesem Netz läuft ein winziger, eingebetteter DNS-Server von Docker. Dadurch kann dein Django-Code im Container A DATABASES_HOST = "db" schreiben. Der Compose-DNS fängt die Anfrage ab, löst das Wort db zur dynamischen IP des Containers B auf (Service Discovery). Das abstrahiert IP-Adressen für Entwickler völlig weg.

2. Startup Orders (Depends_on Conditions)

Ein riesiges Problem: Dein Node.js Backend bootet in 1 Sekunde, aber die PostgreSQL Datenbank braucht 5 Sekunden zum Initialisieren. Das Backend feuert seine queries und crasht ("Connection refused"), weil Compose alle Container stupide zeitgleich startet. Profis nutzen tiefes depends_on:

  backend:
    depends_on:
      db:
        condition: service_healthy

Hier wartet Docker Compose stur und hält den Backend-Start zurück, bis der db Container den in seiner Sektion definierten healthcheck erfolgreich zurückmeldet.

3. Overrides (Die docker-compose.override.yml)

Wie teilt man sich eine komplexe YAML im Team, wenn der Local-Entwickler "Hot-Reloading" Mappen will, aber der Staging-Server das Image kompilieren soll? Docker Compose liest automatisch immer zwei Dateien, wenn sie existieren:

1. docker-compose.yml (Das absolute Basis-Set, für alle gültig).
2. docker-compose.override.yml (Entwickler-Spezifisch). Im Override überschreibt der Programmierer lokal Ports oder mountet seinen Code (./app:/app), während die Datei via .gitignore gar nicht in Git eingecheckt wird. Im Staging läuft nur die Basis-Datei ohne Volumes. Das löst das fatale "It works on my machine" Problem tief in der Infrastruktur.