Docker/Podman Composer — Manual

Zurück zur Übersicht: Docker/Podman Composer · Tool live öffnen: www.jpkc.com/tools/docker/

Dieses Manual beschreibt den Docker/Podman Composer vollständig: was in jeder der beiden Konvertierungsrichtungen passiert, welche run-Flags und Compose-Keys wirklich unterstützt werden, wie das YAML-Format aussieht und wo die Grenzen liegen. Die Oberfläche des Tools ist auf Englisch — die Tab- und Button-Namen werden hier deshalb in ihrer englischen Original-Schreibweise genannt (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest.

Aufbau: drei Tabs, eine clientseitige Engine

Das Tool hat drei Reiter: Run → Compose, Compose → Run und Reference (Referenz). Die ersten beiden sind die Konverter, der dritte ist ein eingebautes Nachschlagewerk. Beide Konverter laufen vollständig im Browser — Tokenizer, Flag-Parser, YAML-Serialisierer und der js-yaml-Parser sind JavaScript. Es gibt keinen Server-Abruf und kein API; deine Eingaben verlassen den Browser nicht. Beide Editoren basieren auf dem ACE-Editor mit Syntax-Hervorhebung für Shell (sh) bzw. YAML.

Richtung 1: Run → Compose

Im Tab Run → Compose fügst du oben einen docker run- oder podman run-Befehl in das Feld Docker / Podman Run Command ein und klickst auf Convert to YAML. Darunter erscheint im Feld Docker Compose YAML das Ergebnis. Über den Example-Knopf lädst du einen Beispiel-Befehl, über Clear leerst du beide Felder.

Wie der Befehl gelesen wird

Bevor die Flags ausgewertet werden, zerlegt ein Tokenizer die Kommandozeile. Er beherrscht:

Zeilenfortsetzungen mit Backslash (\ am Zeilenende) — lange, mehrzeilige Befehle werden korrekt zu einem Befehl zusammengezogen.
Doppelte Anführungszeichen ("…") mit den üblichen Escapes (\n, \t) und einfache Anführungszeichen ('…') als literalen Text. So bleibt etwa --health-cmd "curl -fs http://localhost/" als ein Argument erhalten.

Anschließend wird ein eventuelles docker- bzw. podman-Präfix und das run-Unterkommando übersprungen, danach werden die Flags geparst. Unterstützt werden beide Schreibweisen --flag value und --flag=value. Kombinierte Kurz-Flags wie -it oder -dp werden in ihre Einzel-Flags zerlegt (dabei greifen nur die booleschen Anteile). Das erste Argument, das kein Flag ist, gilt als Image; alles danach wird zum command. Unbekannte Flags werden stillschweigend übersprungen.

Der Service-Name im YAML entsteht aus --name, falls gesetzt (kleingeschrieben, ungültige Zeichen werden zu _); ohne --name wird er aus dem Image-Namen abgeleitet (letztes Pfadsegment ohne Tag, z. B. nginx:1.27-alpine → nginx).

Unterstützte Wert-Flags (Flag → Compose-Key)

Diese Flags erwarten einen Wert und werden auf einen Compose-Key abgebildet. Mehrfach angegebene Flags (Ports, Volumes, Env …) landen als YAML-Liste.

Identität: --name → container_name; --hostname/-h → hostname; --platform → platform
Ports & Expose: -p/--publish → ports; --expose → expose
Volumes: -v/--volume → volumes; --tmpfs → tmpfs
Umgebung: -e/--env → environment; --env-file → env_file
Netzwerk: --network/--net → networks; --dns → dns; --dns-search → dns_search; --dns-opt/--dns-option → dns_opt; --add-host → extra_hosts
Lebenszyklus & Signale: --restart → restart; --stop-signal → stop_signal; --stop-timeout → stop_grace_period
Laufzeit: -u/--user → user; -w/--workdir → working_dir; --entrypoint → entrypoint
Labels: -l/--label → labels
Ressourcen: -m/--memory → mem_limit; --memory-swap → memswap_limit; --memory-reservation → mem_reservation; -c/--cpu-shares → cpu_shares; --cpus → cpus; --cpuset-cpus → cpuset; --shm-size → shm_size; --ulimit → ulimits (z. B. nofile=1024:2048)
Geräte & Sicherheit: --device → devices; --cap-add → cap_add; --cap-drop → cap_drop; --security-opt → security_opt
IPC/PID & Kernel: --ipc → ipc; --pid → pid; --sysctl → sysctls; --group-add → group_add
Logging: --log-driver → logging.driver; --log-opt → logging.options (als key=value geparst)
Healthcheck: --health-cmd → healthcheck.test (als [CMD-SHELL, …]); --health-interval, --health-timeout, --health-retries, --health-start-period → die entsprechenden healthcheck.*-Felder
Links (veraltet): --link → links

Ein Sonderfall: --network-alias wird erkannt, aber verworfen (es gibt auf Service-Ebene keine direkte Compose-Entsprechung).

Unterstützte Boolean-Flags (ohne Wert)

-t/--tty → tty: true
-i/--interactive → stdin_open: true
--privileged → privileged: true
--read-only → read_only: true
--init → init: true
--no-healthcheck → healthcheck.disable: true
-d/--detach → verworfen (in Compose implizit)
--rm → verworfen (hat keine Compose-Entsprechung)

Das YAML-Ausgabeformat

Die Ausgabe beginnt mit einem services:-Block, darunter der Service mit image: zuerst, gefolgt von den restlichen Keys in einer festen, logischen Reihenfolge (Identität, Laufzeit-Flags, Ports/Volumes, Environment, Netzwerk, Labels, Geräte/Security, Ressourcen) und am Ende command, logging, healthcheck, ulimits. Eine version:-Zeile wird nicht erzeugt (moderne Compose-Spezifikation, das Feld gilt als veraltet). Werte werden nur dann in Anführungszeichen gesetzt, wenn YAML es erfordert (z. B. eine reine Zahl als String wie "3").

Das Ergebnisfeld trägt das Badge „editable" und ist tatsächlich editierbar: Du kannst direkt im Tool die Dinge ergänzen, die der Konverter naturgemäß nicht aus einem Run-Befehl ableiten kann — etwa depends_on, einen build:-Block oder Top-Level-Netzwerk- und Volume-Definitionen. Mit Copy kopierst du die YAML, mit docker-compose.yml lädst du sie als Datei herunter (lokal erzeugter Blob).

Richtung 2: Compose → Run

Im Tab Compose → Run fügst du eine docker-compose.yml in das Feld Docker Compose YAML ein und klickst auf Convert to Commands. Darunter erscheint im Feld Generated Run Commands für jeden Service ein eigener Run-Befehl, jeweils mit einer Kommentarzeile # <servicename> davor. Dieses Ausgabefeld ist schreibgeschützt; über Copy kopierst du den Inhalt.

docker oder podman wählen

Im Fuß des Eingabefelds gibt es einen Radio-Schalter Runtime mit den Optionen docker (Standard) und podman. Er bestimmt nur, mit welchem Befehlswort die erzeugten Zeilen beginnen — docker run … oder podman run …. Die Flags selbst sind identisch, weil Podman die docker run-Optionen weitgehend kompatibel nachbildet.

Was eingelesen und erzeugt wird

Der YAML-Parser (js-yaml) akzeptiert sowohl eine vollständige Compose-Datei (mit services:-Schlüssel) als auch eine blanke Services-Map. Jeder erzeugte Befehl beginnt mit <runtime> run -d und --name (aus container_name, sonst dem Service-Namen). Danach werden die Compose-Keys in run-Flags zurückübersetzt — im Wesentlichen die Umkehrung der obigen Tabelle:

restart, hostname, platform, user (→ --user), working_dir (→ --workdir)
ports (Kurz-String oder Lang-Objekt mit host_ip/published/target/protocol), expose
volumes (String oder Objekt mit source/target/read_only → :ro), tmpfs
environment (Liste oder Objekt → KEY=VALUE), env_file
networks (Liste oder Objekt → je ein --network), dns, dns_search, dns_opt (→ --dns-option), extra_hosts (→ --add-host)
labels, cap_add, cap_drop, security_opt, devices
privileged, read_only, tty (→ -t), stdin_open (→ -i), init, entrypoint
ipc, pid, shm_size, sysctls, group_add, links
Ressourcen: mem_limit (→ --memory), memswap_limit (→ --memory-swap), mem_reservation, cpu_shares, cpus, cpuset (→ --cpuset-cpus)
logging (→ --log-driver + --log-opt key=value), healthcheck (→ --health-cmd/--health-interval/… bzw. --no-healthcheck bei disable: true), ulimits
stop_signal, stop_grace_period (→ --stop-timeout)
image (Pflicht; fehlt es, wird ein IMAGE_MISSING-Platzhalter eingesetzt) und am Ende command

Argumente mit Sonderzeichen werden automatisch shell-sicher in Anführungszeichen gesetzt. Kurze Befehle bleiben einzeilig; längere werden mit Backslash-Zeilenfortsetzungen auf mehrere, sauber eingerückte Zeilen umbrochen, wobei --flag value-Paare zusammen auf einer Zeile bleiben.

Was beim Compose-Import NICHT übersetzt wird

Diese Compose-Konstrukte haben keine docker run-Entsprechung und werden beim Erzeugen der Befehle ignoriert (der eingebaute Reference-Tab listet sie als „Compose-only Features"):

depends_on — Startreihenfolge und Health-Bedingungen zwischen Services
build — Image aus einem Dockerfile bauen
profiles — bedingte Service-Aktivierung
deploy — Swarm-/Replica-/Ressourcen-Constraints
secrets / configs — Swarm-Secrets und -Configs
Top-Level-volumes/networks-Definitionen (mit Treiber-Optionen) — nur die Service-Referenz auf ein Netzwerk wird zu --network, die eigentliche Treiber-Definition entfällt

Der Reference-Tab

Der dritte Tab ist ein eingebautes Nachschlagewerk und braucht keine Eingabe:

Flag Reference: docker run → Compose — eine nach Themen gruppierte Tabelle (Container Identity, Image & Command, Ports & Volumes, Environment, Network, Lifecycle, Runtime Flags, Security, Resources, Logging, Healthcheck, Labels) mit run-Flag, Compose-Key und einer Notiz.
Compose-only Features — die oben genannten Konstrukte ohne run-Entsprechung.
Restart Policies — no (Standard, nie neu starten), always, unless-stopped, on-failure und on-failure:3 (max. 3 Versuche).
Tips — kurze Hinweise zu Zeilenfortsetzungen, kombinierten Flags und der editierbaren YAML.

Grenzen — kompakt

Nur Single-Container-run. Aus einem Run-Befehl entsteht genau ein Service; run-Optionen ohne Compose-Entsprechung (z. B. --rm, --detach, --network-alias) sowie unbekannte Flags werden verworfen.
Compose-only-Konstrukte gehen verloren, wenn du von Compose nach run konvertierst (depends_on, build, profiles, deploy, secrets/configs, Top-Level-Netzwerke/Volumes).
Kein docker/podman im Hintergrund. Das Tool startet nichts und prüft nichts gegen eine echte Engine — es ist ein reiner Text-zu-Text-Übersetzer.

Für den Einstieg und die Zielgruppen siehe die Übersichtsseite, für konkrete Durchläufe die Beispiele. Ausprobieren kannst du alles direkt im Tool.