Docker Compose
Docker Compose beschreibt einen ganzen Container-Stack in einer Datei — ein Befehl startet alles.
Links die Bauanleitung: eine compose.yaml beschreibt drei Services — app, db und mqtt. Rechts wartet ein leerer Docker-Host.
In 30 Sekunden
Docker Compose ist ein Werkzeug, das mehrere zusammengehörige Container als einen Stack verwaltet. Statt jeden Container einzeln mit langen Befehlen zu starten, beschreibt man den gewünschten Zustand in einer einzigen Textdatei (compose.yaml): welche Services laufen sollen, wie sie vernetzt sind und wo ihre Daten liegen. Der Befehl «docker compose up» baut daraus den kompletten Stack auf — immer gleich, auf jedem Rechner. Genau diese Reproduzierbarkeit hat Compose zum Standard für Anwendungen auf einem einzelnen Server gemacht, vom Heim-Server bis zum IoT-Gateway.
Eine compose.yaml ist wie ein Kochrezept mit Einkaufsliste: Es steht drin, welche Zutaten (Services, Netz, Datenspeicher) gebraucht werden und in welcher Reihenfolge sie zusammenkommen. Wer das Rezept hat, kocht das Gericht überall identisch nach — und wenn man eine Zutat austauscht, muss man nicht das ganze Menü neu kochen, sondern nur diesen einen Schritt wiederholen.
Wo trifft man Docker Compose an?
IoT- und Smart-Home-Stacks
Der Klassiker im IoT-Umfeld: MQTT-Broker, Node-RED, Datenbank und Grafana als ein Stack. Beispiel: Ein Raspberry Pi sammelt Sensordaten über Mosquitto, speichert sie in InfluxDB und zeigt sie in Grafana — alles aus einer compose.yaml gestartet.
Self-Hosting und Heim-Server
Eigene Dienste statt Cloud-Abos: Nextcloud, Home Assistant, Pi-hole oder Vaultwarden laufen typischerweise als Compose-Stacks. Beispiel: Nextcloud mit Datenbank und Reverse Proxy steht nach wenigen Minuten, weil die Anbieter fertige Compose-Dateien mitliefern.
Entwicklungsumgebungen
Entwickler starten Datenbank, Cache und Message-Broker lokal mit einem Befehl — in denselben Versionen wie auf dem Server. Beispiel: Ein neues Teammitglied klont das Projekt, tippt «docker compose up» und hat nach dem ersten Kaffee eine lauffähige Umgebung.
Kleine Produktiv-Setups auf einem Server
Website, Shop oder internes Tool auf einem einzelnen (Miet-)Server: Anwendung, Datenbank und Reverse Proxy als Stack. Beispiel: Ein CMS-Blog läuft mit Datenbank in Compose, davor ein nginx — Updates sind ein Dateiedit plus «compose up».
Test- und CI-Umgebungen
Integrationstests laufen gegen echte Dienste statt Attrappen. Beispiel: Die CI-Pipeline startet per Compose eine frische Datenbank und einen Broker, führt die Tests aus und räumt danach alles rückstandslos wieder ab.
Edge- und OT-Gateways
Am Rand des Netzwerks (Edge), etwa auf einem Industrie-PC an der Maschine, sorgt Compose für reproduzierbare Software-Stände. Beispiel: Ein Protokoll-Umsetzer von Modbus zu MQTT wird auf zwanzig Gateways mit derselben Datei identisch ausgerollt.
Gut geeignet für
- Für mehrere zusammengehörige Container auf einem einzelnen Host, weil genau das der Kernzweck ist: ein Stack, eine Datei, ein Befehl.
- Für reproduzierbare Setups, weil die compose.yaml den kompletten Soll-Zustand enthält und sich wie Code in Git versionieren lässt.
- Für Einsteiger, weil eine lesbare YAML-Datei viel verständlicher ist als eine Kette langer docker-run-Befehle mit Dutzenden Optionen.
- Für Teams, weil alle mit derselben Datei dieselbe Umgebung bekommen — das klassische «läuft bei mir» verliert seinen Schrecken.
- Für Dokumentation, weil die Datei nebenbei beschreibt, woraus ein System besteht — wer sie liest, versteht den ganzen Stack.
Weniger geeignet für
- Für Cluster über mehrere Server mit Ausfallsicherheit, weil Compose nur einen Host orchestriert und Container bei Server-Ausfall nicht woanders neu startet; besser Kubernetes oder Docker Swarm.
- Für automatisches Skalieren unter Last, weil Compose keine Lastverteilung über Maschinen hinweg und kein selbsttätiges Hoch- und Runterfahren kennt; besser Kubernetes mit Autoscaling.
- Für einen einzelnen, kurzlebigen Container, weil eine Stack-Datei dafür unnötiger Aufwand ist; besser ein einfaches «docker run».
- Für Software, die gar nicht in Containern läuft (etwa klassische Installationen oder virtuelle Maschinen), weil Compose Container voraussetzt; besser Konfigurationswerkzeuge wie Ansible.
Fakten
- Docker Compose
- Container-Orchestrierung für einen einzelnen Host
- compose.yaml (YAML, deklarativ; früher docker-compose.yml)
- docker compose up / down / ps / logs
- Services, Netzwerke, Volumes (dazu Secrets und Configs)
- eingebautes DNS — Container erreichen sich über den Service-Namen
- depends_on, optional mit condition: service_healthy (Healthcheck)
- Teil der Docker-Werkzeuge, heute als Plugin «docker compose» (v2); Open Source
Im Detail
Eine Datei beschreibt den Soll-Zustand
Compose arbeitet deklarativ: In der compose.yaml steht nicht, WIE etwas zu tun ist, sondern WAS am Ende laufen soll — welche Services, mit welchem Image, welchen Ports und welchen Umgebungsvariablen. Compose vergleicht diesen Soll-Zustand mit dem Ist-Zustand auf dem Host und führt nur die nötigen Schritte aus. Das ist der entscheidende Unterschied zu einer Sammlung von Start-Skripten, die man in der richtigen Reihenfolge ausführen muss.
Services, Netze und Volumes
Ein Stack besteht aus drei Bausteinen. Services sind die eigentlichen Container, etwa eine Web-App, eine Datenbank und ein MQTT-Broker. Netzwerke verbinden sie: Compose legt automatisch ein gemeinsames Netz an, in dem sich die Container über ihre Service-Namen erreichen — die App spricht die Datenbank einfach als «db» an, IP-Adressen spielen keine Rolle. Volumes sind benannte Datenspeicher, die Container-Neustarts und Updates überleben; ohne sie wären etwa die Datenbank-Inhalte nach jedem Neuerstellen weg.
Startreihenfolge und Healthchecks
Viele Anwendungen stürzen ab, wenn ihre Datenbank beim Start noch nicht bereit ist. Compose löst das mit depends_on (legt die Reihenfolge fest) und Healthchecks (kleine Prüfbefehle, die melden, ob ein Container wirklich einsatzbereit ist). Mit «condition: service_healthy» wartet die App, bis die Datenbank nicht nur gestartet, sondern tatsächlich ansprechbar ist. Das macht den Stack-Start robust und wiederholbar.
Idempotentes up: nur die Differenz
«docker compose up» kann man beliebig oft ausführen — es passiert nur, was nötig ist (Fachbegriff: idempotent). Ändert man in der Datei etwa die Image-Version eines einzelnen Services, wird beim nächsten «up» nur dieser eine Container neu erstellt; alle anderen laufen ungestört weiter. Updates werden damit zum Dateiedit plus einem Befehl, und über die Versionsgeschichte in Git lässt sich jede Änderung nachvollziehen und zurückdrehen.
Die Grenze: ein einzelner Host
Compose orchestriert genau einen Rechner. Fällt der Server aus, startet niemand die Container auf einer anderen Maschine neu; auch Lastverteilung über mehrere Server gibt es nicht. Wer Hochverfügbarkeit oder automatisches Skalieren braucht, greift zu Kubernetes oder Docker Swarm — bezahlt das aber mit deutlich mehr Komplexität. Für sehr viele reale Anwendungen, vom Heim-Server bis zum soliden Firmen-Setup auf einer Maschine, ist Compose der bewusst einfache und völlig ausreichende Weg.
Praxis-Tipp: Auf iotueli.ch gibt es einen visuellen Stack-Baukasten, der fertige compose.yaml-Dateien nach Best Practices erzeugt (unter /builder), sowie Schritt-für-Schritt-Anleitungen zu Docker und typischen IoT-Stacks. Damit lässt sich das hier Gezeigte direkt ausprobieren — vom ersten Container bis zum kompletten Stack mit Reverse Proxy.