Docker Compose Befehle für Server: Spickzettel

Die Compose-Befehle, die Sie tatsächlich verwenden

Docker Compose veröffentlicht mehr als vierzig Unterbefehle. Für die tägliche Arbeit auf einem Server benötigen Sie etwa ein Dutzend. Diese Seite gruppiert sie nach der jeweiligen Aufgabe, nennt für jeden Befehl einen klaren Grund und verweist auf die ausführliche Erklärung, wenn ein Befehl eine Falle birgt.

Hier wird ausschließlich Compose V2 verwendet: docker compose mit einem Leerzeichen, nicht das alte docker-compose-Skript. V2 ist ein Go-Plugin, das zusammen mit Docker Engine installiert wird. V1 ist in aktuellen Paketen nicht mehr enthalten. Daher ist ein docker-compose: command not found auf einem frisch installierten Ubuntu-System im Juli 2026 erwartbar und kein Fehler. Prüfen Sie dies mit docker compose version. Wenn keine Ausgabe erscheint, installieren Sie das Paket docker-compose-plugin.

Jeder unten aufgeführte Befehl wird aus dem Verzeichnis ausgeführt, das Ihre compose.yaml enthält. Compose übernimmt den Projektnamen aus diesem Verzeichnis und sucht die Datei relativ dazu. Führen Sie denselben Befehl eine Ebene höher aus, beendet sich Compose mit no configuration file provided: not found. Wenn das Dateiformat für Sie neu ist, beginnen Sie mit einer ersten Compose-Datei auf einem VPS und kehren Sie anschließend für die Befehle hierher zurück.

Lebenszyklus: die vier Befehle, die Sie eingeben, und der eine, der Container entfernt

docker compose up -d
docker compose up -d --wait
docker compose stop
docker compose start
docker compose restart web
docker compose down

up -d erstellt das Netzwerk, erstellt die Container, startet sie und kehrt zurück. Der Befehl kehrt zurück, sobald die Container erstellt wurden. Deshalb schlägt ein Deploy-Skript, das anschließend eine curl-Prüfung ausführt, beim ersten Versuch häufig fehl. up -d --wait wartet, bis jeder Dienst, der einen Healthcheck definiert, den Status „healthy“ meldet. Der Befehl wird mit einem Fehlercode beendet, wenn ein Dienst diesen Status nie erreicht. Die Zuverlässigkeit des Flags hängt vollständig von der dahinterliegenden Prüfung ab. Schreiben Sie daher einen Healthcheck, dem Compose vertrauen kann, bevor Sie sich in der Automatisierung darauf stützen.

stop hält die Container an und behält sie bei. Dadurch startet start dieselben Container mit derselben beschreibbaren Schicht erneut. down stoppt die Container und entfernt anschließend die Container sowie das Projektnetzwerk. Alles, was innerhalb des Containers und außerhalb eines Volumes geschrieben wurde, geht dabei verloren. Dieses Missverständnis verursacht in Compose die größten Schäden. Der vollständige Unterschied zwischen down und stop zeigt, wo sich das auswirkt.

restart ist kein Reload. Der Befehl stoppt und startet denselben Container mit der vorhandenen Konfiguration neu. Eine geänderte Umgebungsvariable, ein neues Image-Tag oder eine bearbeitete Portzuordnung haben daher keinerlei Wirkung. Um eine Änderung an der Datei anzuwenden, führen Sie up -d erneut aus. Compose vergleicht jeden Dienst mit seinem laufenden Container und erstellt nur die Container neu, deren Konfiguration geändert wurde.

Eine Änderung anwenden: neu erstellen, abrufen oder neu bauen

docker compose up -d --force-recreate
docker compose pull && docker compose up -d
docker compose build --no-cache web
docker compose up -d --build web

up -d bewirkt allein nichts, wenn sich nichts geändert hat. Dadurch kann der Befehl sicher wiederholt ausgeführt werden. --force-recreate setzt diesen Vergleich außer Kraft und ersetzt jeden Container, auch wenn die Konfiguration identisch ist. Damit lässt sich ein ungewöhnlicher Zustand im Container am schnellsten beseitigen.

Das Aktualisieren eines Images erfordert zwei Befehle, weil sie unterschiedliche Aufgaben erfüllen. pull lädt das aktuelle Image für jedes in der Datei angegebene Tag herunter. up -d erkennt dann, dass die Image-ID des Dienstes nicht mehr mit der des laufenden Containers übereinstimmt, und erstellt den Container neu. Wenn Sie den Pull überspringen, lässt up -d das latest des letzten Monats ohne Fehler weiterlaufen.

build gilt für Dienste, die einen Abschnitt build: statt eines Abschnitts image: deklarieren. up -d --build erstellt das Image und startet den Dienst in einem Schritt. Das ist der normale Ablauf, während Sie Code ändern. Verwenden Sie --no-cache nur, wenn eine zwischengespeicherte Ebene eindeutig veraltet ist, da der Befehl jede Ebene von Grund auf neu erstellt.

Anzeigen, was ausgeführt wird

docker compose ps
docker compose ps -a
docker compose logs -f --tail=100
docker compose logs --since 15m --timestamps db
docker compose top
docker compose ls

ps listet nur laufende Container auf. Ein Dienst, der beim Start abgestürzt ist, wird dort erst angezeigt, wenn Sie -a hinzufügen. Ein Container, der in ps fehlt, während ps -a ihn als Exited (1) anzeigt, entspricht daher dem normalen Muster eines Startfehlers. Lesen Sie den Exit-Code und anschließend die Logs.

logs -f verfolgt alle Dienste gleichzeitig und stellt jeder Zeile den Dienstnamen voran. Diese Ansicht benötigen Sie, wenn Dienste miteinander kommunizieren und die Reihenfolge der Ereignisse wichtig ist. Geben Sie einen Dienst an, um die Ausgabe einzugrenzen. --tail=100 ist bei einem Container wichtig, der seit einem Monat läuft, weil die Standardeinstellung die gesamte Historie ausgibt und das Terminal überflutet. --since 15m beantwortet die Frage, die Sie normalerweise haben: Was ist während des gerade durchgeführten Neustarts passiert?

top listet die Prozesse in jedem Container auf. Damit können Sie unterscheiden, ob der Container läuft und ob der darin ausgeführte Prozess läuft. ls verlässt das aktuelle Verzeichnis und listet alle Compose-Projekte auf dem Host mit ihrem Status auf. So finden Sie den Stack, den Sie vor drei Monaten gestartet haben.

Eine Shell innerhalb eines Service öffnen

docker compose exec web sh
docker compose exec -u root web sh
docker compose run --rm web env
docker compose run --rm --no-deps web sh

exec führt einen Befehl innerhalb eines Containers aus, der bereits läuft. run startet einen neuen Container anhand derselben Service-Definition. Das benötigen Sie, wenn der Service nicht lange genug läuft, um einen Befehl mit exec auszuführen. Verwenden Sie run immer zusammen mit --rm. Ohne diese Option hinterlässt jeder Aufruf einen gestoppten Container. Diese sammeln sich an, bis docker compose ps -a nicht mehr lesbar ist.

Probieren Sie zuerst sh und erst danach bash. Auf Alpine basierende Images enthalten kein bash. Der Fehler lautet exec: "bash": executable file not found in $PATH. Wenn Sie --no-deps zu run hinzufügen, werden die Abhängigkeiten des Service übersprungen. Dadurch wird bei einer schnellen Konfigurationsprüfung nicht die gesamte Datenbank gestartet.

Mit run --rm web env sehen Sie am schnellsten die Umgebung, die ein Service tatsächlich erhalten hat, nachdem jede .env-Datei, jeder environment:-Block und jede Shell-Variable zusammengeführt wurde. Wenn ein Wert falsch ist, liegt das meist an der Reihenfolge der Zusammenführung. Wie Compose Env-Dateien und Secrets auflöst beschreibt, welche Quelle Vorrang hat.

Netzwerke, Ports und Namensauflösung

docker compose port web 80
docker compose exec web getent hosts db
docker compose config --networks

Compose platziert alle Services in einem Projektnetzwerk. Der Name jedes Services ist darin ein DNS-Name. Wenn Sie getent hosts db in web ausführen, wird bei erfolgreicher Namensauflösung die IP-Adresse des Containers ausgegeben. Bei fehlgeschlagener Auflösung wird nichts ausgegeben. Damit lässt sich in zwei Sekunden prüfen, ob sich die Container gegenseitig erreichen können. Wird der Name aufgelöst, aber die Verbindung abgelehnt, ist der Prozess in db an 127.0.0.1 statt an 0.0.0.0 gebunden. Deshalb akzeptiert er keine Pakete von einem anderen Container. Weitere Informationen zu diesem Modell finden Sie unter Funktionsweise von Compose-Netzwerken und der DNS-Auflösung für Services.

port web 80 gibt die Hostadresse und den Port aus, unter denen ein Containerport veröffentlicht ist. Das erspart das Raten, wenn die Zuordnung aus einer Variable stammt. Durch die Veröffentlichung eines Ports wird außerdem eine von Docker selbst verwaltete Firewallregel erstellt. Diese Regel steht vor Ihren eigenen Regeln. Dadurch kann ein Service, den Sie für privat hielten, aus dem Internet erreichbar sein. Dieser Fall wird unter Warum veröffentlichte Docker-Ports ufw umgehen behandelt.

Volumes und Daten

docker compose config --volumes
docker compose cp db:/etc/postgresql/pg_hba.conf ./pg_hba.conf
docker compose down -v

config --volumes gibt die benannten Volumes aus, die das Projekt deklariert, jeweils eines pro Zeile. Diese Liste müssen Sie sichern. cp kopiert eine Datei in einen Container oder aus einem Container heraus, ohne eine Shell zu öffnen. Verwenden Sie dazu die Form service:path auf der Seite, auf der sich der Container befindet.

down -v entfernt diese benannten Volumes zusammen mit den Containern. Der Befehl eignet sich zum Entfernen eines Test-Stacks, aber nicht für etwas, das wichtige Daten enthält. Es gibt keine Bestätigung und keine Möglichkeit zum Rückgängigmachen. Bind mounts bleiben erhalten, da sie im Dateisystem des Hosts liegen. Dieser Unterschied beim möglichen Schadensumfang ist ein Grund, bewusst zwischen Bind mounts und benannten Volumes zu wählen.

Bereinigung, die Speicherplatz freigibt, ohne Daten zu verlieren

docker compose down --remove-orphans
docker system df
docker image prune -a
docker builder prune

--remove-orphans löscht Container, die zum Projekt gehören, aber nicht mehr in der Datei erscheinen. Das passiert genau nach dem Umbenennen eines Dienstes. Ohne diese Option laufen die Container weiter und sind für docker compose ps unsichtbar.

docker system df zeigt, wofür der Speicherplatz verwendet wird, bevor Sie etwas löschen. Der Befehl schlüsselt Images, Container, lokale Volumes und den Build-Cache auf und zeigt für jede Kategorie die freigebbare Größe an. image prune -a entfernt jedes Image, auf das kein Tag verweist. Auf einem System, das mehrere Versionen eines großen Images abgerufen hat, bringt das normalerweise den größten Speichergewinn. builder prune leert den Build-Cache. Dieser wächst auf jedem Server, der eigene Images erstellt, unbemerkt weiter.

Keiner dieser Befehle verändert ein benanntes Volume. Das tun nur docker volume prune und docker compose down -v.

Die Datei prüfen, bevor sie Probleme verursacht

docker compose config --quiet
docker compose config --services
docker compose --dry-run up -d

config --quiet validiert die Datei und gibt bei Erfolg nichts aus. Deshalb gehört der Befehl in einen Pre-Deploy-Schritt oder einen Git-Hook. config ohne weitere Argumente gibt die vollständig zusammengeführte und interpolierte Datei aus. Damit prüfen Sie, ob eine Variable aufgelöst wurde und eine Override-Datei wie erwartet angewendet wurde. Eine nicht gesetzte Variable erscheint dort als leerer Wert, zusammen mit der Warnung The "X" variable is not set. Defaulting to a blank string.

--dry-run ist ein globales Flag und kein Flag des Subcommands. Deshalb steht es vor up. Der Befehl gibt jede Aktion aus, die Compose ausführen würde, und nimmt keine Änderungen vor. Diese dreißig Sekunden sind vor einem down für einen wichtigen Stack sinnvoll investiert.

Arbeiten über Dateien, Profile und Projekte hinweg

docker compose -f compose.yaml -f compose.prod.yaml up -d
docker compose --profile debug up -d
docker compose -p staging up -d

Mehrere -f-Flags werden in der angegebenen Reihenfolge zusammengeführt. Spätere Dateien überschreiben frühere Dateien Schlüssel für Schlüssel. So behalten Sie eine Basisdatei mit einer kleinen Produktionsüberschreibung. Für Listen und Maps gelten jedoch andere Regeln. Lesen Sie daher wie Compose mehrere Dateien zusammenführt, bevor Sie eine unerwartete Abweichung untersuchen.

--profile startet Dienste mit diesem Profil zusätzlich zu den Diensten ohne Profil. So bleiben Debugging-Tools aus einer normalen up heraus. -p legt den Projektnamen fest. Dadurch können zwei Kopien desselben Stacks parallel mit getrennten Netzwerken und getrennten Volume-Namen ausgeführt werden. Damit der Stack nach einem Neustart wiederhergestellt wird, geben Sie keinen Befehl manuell ein. Stattdessen übernimmt dies eine Unit, wie unter Compose-Stacks beim Systemstart starten beschrieben.

FAQ

Was hat docker-compose mit einem Bindestrich ersetzt?

Compose V2, aufgerufen als docker compose mit einem Leerzeichen. Es ist ein mit Docker Engine gebündeltes Plugin. Das Python-Tool der V1 wird von aktuellen Paketen nicht mehr installiert. Wenn die Schreibweise mit Leerzeichen nichts ausgibt, installieren Sie das Paket docker-compose-plugin für Ihre Distribution. Aktualisieren Sie alte Skripte auf die Schreibweise mit Leerzeichen, statt einen Alias hinzuzufügen, da V2 über Flags verfügt, die es in V1 nicht gab.

Warum übernimmt docker compose restart meine Konfigurationsänderung nicht?

restart stoppt und startet den vorhandenen Container mit der Konfiguration, mit der er erstellt wurde. compose.yaml wird dabei nicht erneut eingelesen. Änderungen an Umgebungsvariablen, Ports, Volumes oder am Image-Tag erfordern docker compose up -d. Dieser Befehl vergleicht jeden Service mit seinem laufenden Container und erstellt abweichende Container neu. Fügen Sie --force-recreate hinzu, wenn der Ersatz auch dann erfolgen soll, wenn sich an der Datei nichts geändert hat.

Wie aktualisiere ich einen Service auf ein neueres Image?

Führen Sie docker compose pull und anschließend docker compose up -d aus. Der Pull lädt das aktuelle Image für jeden Tag in der Datei. up -d erstellt jeden Service neu, dessen Image-ID nicht mehr mit der seines Containers übereinstimmt. Wenn Sie up -d allein ausführen, wird das bereits lokal gespeicherte Image wiederverwendet. Dadurch kann ein auf latest festgelegter Stack weiterhin ein Monate altes Build verwenden, ohne einen Fehler auszugeben.

Welche Bereinigungsbefehle sind auf einem aktiven Server sicher?

docker system df, docker image prune -a und docker builder prune entfernen nur Images und den Cache. Laufende Services funktionieren daher weiter, und benannte Volumes bleiben unverändert. Das gefährliche Paar besteht aus docker compose down -v und docker volume prune. Diese Befehle löschen benannte Volumes ohne Rückfrage. Führen Sie zuerst docker compose config --volumes aus, damit Sie wissen, was gefährdet ist.

Kann ich einen einzelnen Befehl ausführen, ohne den gesamten Stack zu starten?

Ja. docker compose run --rm --no-deps web sh startet einen einzelnen Container anhand der web-Servicedefinition, überspringt dessen Abhängigkeiten und entfernt den Container beim Beenden. Verwenden Sie stattdessen exec, wenn der Container bereits läuft. exec verbindet sich mit dem laufenden Prozess und zeigt den tatsächlichen Zustand des Services.