Docker Compose für die lokale Entwicklung: Override-Dateien, Profile, gesunde Abhängigkeiten und Watch

Ziel

Ein einziges docker compose up, das jeder mitwirkenden Person dieselben Datenbank-, Queue- und Service-Versionen wie in der Produktion liefert, mit schnellem Code-Reload, ohne dass die committete Datei zu einem rein lokalen Artefakt wird.

Voraussetzungen

Ein Dockerfile pro Service, das aus einem sauberen Checkout baut, definierte Health-Checks für zustandsbehaftete Abhängigkeiten und eine aus Umgebungsvariablen gelesene Konfiguration.

Schritte

1. compose.yaml als produktionsnahe Basis schreiben: Images nach Tag, Servicenamen, die zu den in der Konfiguration verwendeten DNS-Namen passen, keine Host-Ports, keine Bind-Mounts. Die Docker-Dokumentation (zitiert) besagt, dass Compose standardmässig compose.yaml und eine optionale compose.override.yaml liest und zusammenführt, wobei spätere Dateien frühere überschreiben oder erweitern.
2. Lokale Annehmlichkeiten in compose.override.yaml legen: veröffentlichte Ports, einen Bind-Mount des Quellbaums, Debug-Umgebungsvariablen. Sie committen, wenn alle Entwickelnden dasselbe wollen, sonst eine .example-Datei committen und die echte ignorieren.
3. Abhängigkeiten mit Bedingungen deklarieren: depends_on: {db: {condition: service_healthy}} lässt Compose auf den Health-Check der Abhängigkeit warten statt nur auf den Start ihres Containers; service_completed_successfully wartet, bis ein einmaliger Migrations-Container mit Exit-Code 0 endet (beides in der zitierten Services-Referenz).
4. Optionale Werkzeuge (Mail-Catcher, Admin-Oberfläche, Lastgenerator) an profiles: binden, sodass ein einfaches up sie überspringt; sie mit --profile debug oder COMPOSE_PROFILES starten.
5. Einen Abschnitt develop.watch hinzufügen: sync für interpretierten Code, sync+restart, wenn der Prozess neu starten muss, um Änderungen zu übernehmen, rebuild, wenn sich Abhängigkeits-Manifeste ändern; mit docker compose up --watch ausführen oder mit docker compose watch, um Sync-Ereignisse aus den Anwendungslogs herauszuhalten. Die zitierte Compose-Watch-Seite dokumentiert diese Aktionen und weist darauf hin, dass Watch nur Services verfolgt, die mit build aus lokalem Quellcode gebaut werden, nicht solche, die ein vorgefertigtes image verwenden.
6. Nicht geheime Standardwerte für die Variableninterpolation in .env ablegen und Zugangsdaten aus committeten Dateien heraushalten; sie über env_file-Einträge einbinden, die von Git ignoriert werden.
7. docker compose config in der CI ausführen, um die zusammengeführte Datei zu rendern und Pfad- oder Interpolationsfehler zu erkennen.

Erwartetes Ergebnis

Neue Mitwirkende erreichen mit einem einzigen Befehl einen funktionierenden Stack; die Basisdatei dient zugleich als Dokumentation der Laufzeit-Topologie; Abweichungen von der Produktion sind als kleine Override-Datei sichtbar statt als verstreute Änderungen.

Grenzen und Prüfbasis

Compose beschreibt einen einzelnen Host und ist kein Produktions-Orchestrator; Ressourcenlimits, Neustart-Richtlinien und Networking unterscheiden sich von Kubernetes. Die zitierte Compose-Watch-Seite stellt Watch als Ergänzung zu Bind-Mounts dar, nicht als Ersatz: Ihre ignore-Regeln lassen einen Baum wie node_modules/ aus der Synchronisation heraus, was die Seite mit der I/O-Last vieler kleiner Dateien und mit kompilierten Artefakten begründet, die sich nicht zwischen Host- und Container-Plattform teilen lassen. Das Verhalten folgt den zitierten Referenzen; es werden keine Zeitmessungen behauptet.