docker run zu Compose: Container-Befehle in eine saubere compose.yaml umwandeln

Viele Projekte dokumentieren ihre Installation als langen docker run-Befehl. Zum Ausprobieren reicht das, für den Dauerbetrieb aber nicht: Beim nächsten Update muss der Befehl exakt gleich wiederholt werden, und niemand weiß mehr, welche Ports und Volumes einmal gesetzt waren. Das Tool docker run zu Compose auf s-edv.com wandelt einen oder mehrere solcher Befehle in eine saubere compose.yaml um und erklärt dabei, welche Option wohin gewandert ist und was nicht übernommen werden konnte. Diese Anleitung richtet sich an Admins, die Container auf einem Linux-Server, einer VM oder einem NAS dauerhaft betreiben wollen. Sie zeigt jede Funktion des Tools, die wichtigsten Hinweise und die Prüfung der Datei vor dem ersten Start.

Voraussetzungen

• Einen aktuellen Browser für das Tool.
• Einen Linux-Host mit Docker Engine und dem Compose-Plugin (docker compose, nicht das alte docker-compose). Zum Zeitpunkt dieser Anleitung ist Docker Compose 5.5.1 die aktuelle Version auf GitHub. Für einzelne Dienste wie nginx, Uptime Kuma oder Vaultwarden genügen 2 CPU-Kerne und 4 GB RAM, x86 oder ARM.
• Shell-Zugang mit sudo oder Mitgliedschaft in der Gruppe docker.
• Den bisherigen docker run-Befehl, etwa aus der Projektdokumentation oder aus Ihrer Shell-History (history | grep "docker run").
• Grundwissen zu Compose. Den Aufbau von Stacks erklärt Docker Compose: Multi-Container-Stacks aufbauen.

Schritt 1: Tool öffnen und Befehl einfügen

Öffnen Sie docker run zu Compose. Links steht der Bereich „docker run einfügen“ mit dem Feld „Ein oder mehrere Befehle“ (Zusatz „auch mehrzeilig mit \“) und der Schaltfläche „Leeren“. Fünf Beispiele lassen sich per Klick laden: „nginx“, „Portainer“, „Vaultwarden“, „Uptime Kuma“ und „Ollama mit GPU“. Darunter gibt es zwei Schalter: „container_name übernehmen“ ist aktiv, „restart: unless-stopped ergänzen, falls nicht angegeben“ ist zunächst aus.

Das Tool weist darauf hin, dass der Befehl nur gelesen und nicht ausgeführt wird; Variablen wie $VAR bleiben stehen. Laut Seite läuft die Umwandlung vollständig im Browser, im Test kamen beim Einfügen keine Netzwerkanfragen hinzu. Trotzdem gilt die Grundregel: Passwörter gehören nicht in Befehle, die Sie in fremde Werkzeuge kopieren. Ersetzen Sie Geheimnisse vorher durch Variablen wie $DB_PW.

Praxisbeispiel: Ein Handwerksbetrieb betreibt Uptime Kuma seit Monaten mit

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Verifizieren: Rechts erscheint unter „compose.yaml“ der Hinweis „1 Dienst erzeugt“, die Kachel „Nicht übernommen“ zeigt 0 mit dem Zusatz „alles erkannt“.

Schritt 2: Die erzeugte compose.yaml lesen

Für das Beispiel erzeugt das Tool:

services:
  uptime-kuma:
    image: "louislam/uptime-kuma:1"
    container_name: uptime-kuma
    restart: always
    ports:
      - "3001:3001"
    volumes:
      - "uptime-kuma:/app/data"

volumes:
  uptime-kuma:

Der Dienstname stammt aus --name; ohne Namen verwendet das Tool den Image-Namen, aus docker run -d nginx wird also der Dienst nginx. Benannte Volumes trägt es zusätzlich auf oberster Ebene unter volumes: ein. Eine version:-Zeile fehlt bewusst, weil die Compose-Spezifikation sie nicht mehr auswertet.

Portangaben setzt das Tool immer in Anführungszeichen. Der Grund ist YAML 1.1: Ein Parser liest 22:22 ohne Anführungszeichen als Zahl zur Basis 60. In der Gegenprobe mit PyYAML ergab 22:22 den Wert 1342, no den Wahrheitswert False. Das Tool quotet deshalb auch Werte wie restart: "no" oder user: "1000:1000".

Verifizieren: Die Kachel „Übernommen“ nennt dieselbe Zahl an Optionen, die Sie im Befehl gesetzt haben (ohne -d), und jede Zeile des Befehls taucht in der Tabelle „Zuordnung der Optionen“ auf.

Schritt 3: Hinweise auswerten

Die Liste „Hinweise“ ist der wertvollste Teil des Tools. Im Test erschienen unter anderem:

• Benannte Volumes: Compose stellt dem Volume-Namen den Projektnamen voran, aus uptime-kuma wird etwa projekt_uptime-kuma. Ohne Anpassung startet der Dienst mit einem neuen, leeren Volume. Wollen Sie die bestehenden Daten weiterverwenden, ergänzen Sie name: uptime-kuma oder external: true beim Volume.
• Offene Ports: Ports ohne IP-Adresse sind auf allen Schnittstellen erreichbar. Für Dienste hinter einem Reverse Proxy schreiben Sie "127.0.0.1:3001:3001".
• Kein restart: Ohne restart startet der Container nach einem Neustart des Hosts nicht von selbst.
• Image ohne Tag oder mit latest: Ein fester Versions-Tag macht Updates planbar.
• Docker-Socket: Beim Portainer-Beispiel warnt das Tool, dass wer den Container kontrolliert, den ganzen Host kontrolliert.
• privileged: gibt dem Container nahezu vollen Zugriff auf den Host; prüfen Sie, ob cap_add oder devices genügen.

Für den Weiterbetrieb des Beispiels ergänzen Sie also:

volumes:
  uptime-kuma:
    name: uptime-kuma

Verifizieren: Sie haben jeden Hinweis entweder umgesetzt oder bewusst verworfen. Prüfen Sie auf dem Host mit docker volume ls, ob der Name des bestehenden Volumes mit dem in der Datei übereinstimmt.

Schritt 4: Nicht übernommene Optionen und Sonderfälle

Optionen ohne sichere Entsprechung verschwinden nicht still, sondern stehen in der Zuordnungstabelle mit „nicht übernommen“. Beispiele aus dem Test:

• --rm: „kein Gegenstück in Compose“. Container bleiben bis docker compose down erhalten.
• -P: Compose kennt kein Gegenstück; Ports einzeln mit -p angeben.
• -d: hat keine Entsprechung in der Datei, gestartet wird mit docker compose up -d.
• Unbekannte Optionen wie --foo-bar 3: „nicht übernommen: unbekannte Option“, dazu der Hinweis, dass das folgende Wort als Wert gelesen wurde.

Das Beispiel „Ollama mit GPU“ zeigt die schwierigeren Übersetzungen: --gpus all wird zu deploy.resources.reservations.devices mit count: all, --health-cmd zu healthcheck.test mit CMD-SHELL, --ulimit nofile=65535:65535 zu soft und hard, -it zu stdin_open und tty. Ein benutzerdefiniertes Netz wie --network ki-netz trägt das Tool als external: true ein, weil es bei docker run bereits existieren muss. Wörtliche Dollarzeichen aus einfachen Anführungszeichen, etwa in einem Traefik-Passwort-Hash, schreibt es als $$, damit Compose sie nicht als Variable auswertet. Kombinieren Sie --network host mit einem eigenen Netz, meldet das Tool, dass sich beides ausschließt und Portfreigaben ignoriert werden.

Verifizieren: Für jede Zeile mit „nicht übernommen“ haben Sie eine Entscheidung getroffen, etwa Ports bei -P einzeln eingetragen.

Schritt 5: Mehrere Container zu einem Stack zusammenfassen

Fügen Sie mehrere Befehle untereinander ein, entstehen mehrere Dienste in einer Datei. Ein Beispiel mit Datenbank und Anwendung:

docker run -d --name db --network app -e POSTGRES_PASSWORD=$DB_PW -v pgdata:/var/lib/postgresql/data postgres:16
docker run -d --name app --network app -p 8080:8080 --user 1000:1000 myorg/app:2.1

Das Tool meldet „2 Dienste erzeugt“, die Zuordnungstabelle erhält eine zusätzliche Spalte „Dienst“. Die Variable $DB_PW bleibt stehen; Compose setzt sie beim Start aus der Shell oder aus einer .env-Datei im Projektordner ein. Da Compose für ein Projekt ohnehin ein gemeinsames Netz anlegt, in dem sich Dienste über ihre Namen erreichen, können Sie das externe Netz app in vielen Fällen streichen. Entfernen Sie dann die Netzangaben bei beiden Diensten und den Block networks: am Ende.

# .env im Projektordner, Rechte 600
DB_PW=hier-ein-langes-zufaelliges-passwort

Verifizieren: In der Ausgabe von docker compose config steht beim Dienst db der eingesetzte Wert statt $DB_PW. Fehlt die Variable, warnt Compose, dass sie nicht gesetzt ist.

Schritt 6: Datei speichern, prüfen und alten Container ersetzen

Mit „Kopieren“ oder „Herunterladen“ übernehmen Sie die Datei. Legen Sie einen Projektordner an, etwa /opt/uptime-kuma, und speichern Sie sie dort als compose.yaml. Mit der Option „restart: unless-stopped ergänzen“ setzt das Tool den restart-Wert für alle Dienste, die keinen haben; mit abgeschaltetem „container_name übernehmen“ entfällt container_name, was Skalierung erlaubt.

cd /opt/uptime-kuma
docker compose config            # Syntax prüfen, Variablen aufgelöst anzeigen
docker stop uptime-kuma && docker rm uptime-kuma   # alten Container entfernen, Volume bleibt
docker compose up -d
docker compose ps
docker compose logs -f

Der alte Container muss vorher weg, sonst scheitert der Start am bereits vergebenen container_name. Bind-Mounts und benannte Volumes bleiben bei docker rm erhalten. Wer ohne Docker auf dem Arbeitsplatz vorab prüfen will, kann die YAML-Syntax mit Python testen:

python3 -c 'import yaml,sys; print(yaml.safe_load(open(sys.argv[1])))' compose.yaml

Die Datei funktioniert laut Tool auch in Portainer als Stack und im Synology Container Manager als Projekt; dort sollten Sie relative Pfade wie ./html im Zweifel durch absolute Pfade ersetzen. Schritt für Schritt zeigt das Container Manager: Compose-Projekt auf dem Synology NAS.

Verifizieren: docker compose config endet ohne Fehler, docker compose ps zeigt den Dienst als „running“ bzw. „healthy“, und die Anwendung zeigt die alten Daten, etwa die bestehenden Monitore in Uptime Kuma.

Typische Fehler

• Kein docker-run-Befehl: Bei ls -la oder docker compose up -d meldet das Tool „Kein docker-run-Befehl gefunden. Erwartet wird z. B. docker run -d -p 8080:80 nginx.“
• Image fehlt: „Befehl 1: Es wurde kein Image gefunden.“ Meist fehlt das letzte Wort oder eine Option mit Wert hat es verschluckt.
• Ungültiger Port: Bei 99999:80 erscheint „Ports müssen zwischen 1 und 65535 liegen“. Die Zeile steht trotzdem in der YAML, korrigieren Sie sie vor dem Start.
• Leeres Volume nach dem Umstieg: Projektnamen-Präfix übersehen, siehe Schritt 3.
• Netz nicht gefunden: Externe Netze müssen vorher mit docker network create existieren, oder Sie entfernen external: true.
• Passwort mit $ verändert: Ein in doppelten Anführungszeichen übergebenes $ wertet schon die Shell aus. Im Zweifel einfache Anführungszeichen verwenden.

Häufige Fragen

compose.yaml oder docker-compose.yml?

Beides funktioniert. Die Spezifikation bevorzugt compose.yaml, Docker Compose findet aber auch die älteren Namen.

Sollte ich container_name behalten?

Er hilft, wenn Skripte einen festen Namen erwarten. Ein Dienst mit festem Namen lässt sich aber nicht skalieren, und innerhalb des Projekts reicht der Dienstname. Das Tool lässt Sie die Übernahme abschalten.

Wie sichere ich die Datei weiter ab?

Healthchecks, Secrets und Container ohne Root-Rechte beschreibt Docker Compose absichern.

Testumfang

Getestet wurde das Tool am 1. Oktober 2026 im Browser mit allen fünf Beispielen, beiden Schaltern, einem Stack aus zwei Diensten, rund zwanzig weiteren Optionen und mehreren Fehleingaben. Alle erzeugten Dateien haben wir mit PyYAML eingelesen; sie waren gültiges YAML und enthielten die erwarteten Werte. Ein Start mit Docker war auf dem Testsystem nicht vorgesehen, die Prüfung mit docker compose config gehört deshalb auf Ihren Host.

Fazit

Das Tool docker run zu Compose erspart das fehleranfällige Abtippen und macht sichtbar, was beim Umstieg schiefgehen kann, vor allem beim Volume-Präfix, bei offenen Ports und bei Dollarzeichen. Die Zuordnungstabelle dokumentiert jede Entscheidung, sodass Sie nichts übersehen. Nehmen Sie sich nach der Umwandlung fünf Minuten für die Hinweise und docker compose config; danach ist der Dienst mit einer versionierbaren Datei deutlich leichter zu pflegen.

Weiterführende Anleitungen und Quellen

• Docker Compose: Multi-Container-Stacks aufbauen
• Docker Compose absichern: Secrets, Healthchecks, Non-Root und Read-Only
• Container Manager auf dem Synology NAS: Compose-Projekt anlegen
• Portainer auf Synology NAS installieren
• Docker Docs: Compose file reference
• Docker Docs: docker container run
• Docker Docs: Variablen-Interpolation in Compose
• Docker Compose Releases auf GitHub