Docker/Podman Composer — Tipps & Tricks

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

Das Manual listet jedes Flag, die Beispiele zeigen die Durchläufe. Hier geht es um das, was beides voraussetzt: wo der Konverter bewusst Grenzen hat, was bei einem Hin-und-Zurück verloren geht und wie du das Tool sinnvoll einsetzt.

Was der Konverter NICHT abbildet

Der Composer ist ein Text-zu-Text-Übersetzer. Einige Dinge fallen dabei systembedingt weg — kein Bug, sondern die Natur der beiden Formate. Wichtig: Das meiste, was es weglässt, meldet das Tool in der Hinweisliste unter der Ausgabe — aber nicht alles. Unterschlüssel bekannter Compose-Keys wie build.cache_from oder deploy.placement und die network create-Optionen --scope, --aux-address und --ipv4 fallen ohne Hinweis weg (Details im Manual). Lies die Liste, bevor du das Ergebnis übernimmst, und vergleich bei komplexen Dateien Ein- und Ausgabe.

--rm hat keine Compose-Entsprechung — Compose behält gestoppte Container. Für Einmal-Läufe nimmst du docker compose run --rm. -d/--detach entfällt still, weil es in Compose implizit ist; bei Compose → Run wird umgekehrt immer ein -d gesetzt.
-P/--publish-all und Optionen wie --cidfile, --kernel-memory, --volume-driver oder die Podman-Optionen --pod und --systemd haben keinen Compose-Key und werden mit Hinweis verworfen.
Unbekannte Flags werden übersprungen und gemeldet. Erwartet so ein Flag einen Wert, kann das Tool diesen Wert für das Image halten — der Hinweis sagt dir dann, welches Wort betroffen ist. Schreib solche Flags in der Form --flag=wert, dann ist die Zuordnung eindeutig.
Pipes, Umleitungen und Kommandosubstitution (| tee log, > out, $(pwd)) gehören zur Shell, nicht zum Container. Der Rest der Zeile nach | oder > fällt weg, $(…) bleibt als Text stehen.

Compose-only: was du nach der Umwandlung von Hand ergänzt

Manche Compose-Konstrukte lassen sich aus einem run-Befehl nicht ableiten — und gehen umgekehrt bei Compose → Run ganz oder teilweise verloren. Der Reference-Tab führt sie als „Compose-only Features":

depends_on — bei Run → Compose ergänzt du es von Hand. In der Gegenrichtung ordnet das Tool die Befehle danach, prüft aber keine Bedingungen wie service_healthy.
build — bei Run → Compose ergänzt du es von Hand. In der Gegenrichtung entsteht daraus ein docker build -t … vor dem run.
profiles, deploy.replicas und scale — bei Compose → Run mit Hinweis ignoriert; jedes run startet genau einen Container.
secrets / configs — Varianten mit file: werden bei Compose → Run zu schreibgeschützten Mounts, Secrets unter /run/secrets/<ziel>, Configs unter /<ziel> (ein absolutes target gilt unverändert); solche aus environment:, mit content: oder aus Swarm nicht.

Top-Level-Netze und -Volumes musst du nicht mehr selbst schreiben: Das Tool deklariert sie bei Run → Compose (als external: true oder, wenn docker network create/docker volume create mit in der Eingabe steht, mit exaktem name:) und legt sie bei Compose → Run im Skript an.

Der praktische Kniff: Die YAML-Ausgabe im Run-Tab ist editierbar (Badge „editable"). Konvertiere zuerst deine Run-Befehle und tippe danach direkt im Tool ein depends_on oder einen build:-Block hinzu, bevor du die Datei kopierst oder als compose.yaml herunterlädst. Aber Vorsicht: Änderst du danach die Eingabe oder den Projektnamen, rechnet das Tool neu und überschreibt deine Ergänzungen.

Round-Trip ist nicht verlustfrei

Wenn du einen Befehl nach Compose und dann wieder zurück nach run konvertierst, bekommst du nicht zwingend exakt deine Eingabe:

Verworfene Flags kommen nicht wieder. --rm, -P und unbekannte Flags sind nach dem ersten Schritt weg.
-d wird neu gesetzt. Compose → Run stellt jedem Befehl ein -d voran, auch wenn das Original keines hatte.
Das Netz ändert sich. Ein docker run ohne --network läuft im Default-Bridge-Netz. Auf dem Rückweg landet der Container wie bei Compose im Netz <projekt>_default und bekommt seinen Service-Namen als --network-alias. Ohne --name heißt er <projekt>-<service>-1.
Healthcheck-Form wandelt sich. --health-cmd "…" wird zu test: [CMD-SHELL, …]. Liest du eine Compose-Datei mit ["CMD", …] ein, setzt das Tool die Wörter einzeln gequotet zu einem --health-cmd zusammen und weist darauf hin, dass docker run nur die Shell-Form kennt — das Image braucht dafür /bin/sh.
Reihenfolge und Quoting ändern sich. Flags erscheinen in fester Reihenfolge, jedes auf einer eigenen Zeile. In YAML stehen Ports und Zahlen-Strings in Anführungszeichen ("8080:80", "3600"), im Skript wörtliche Werte in einfachen Anführungszeichen. Das ist semantisch identisch, sieht aber anders aus als deine Vorlage.

Fazit: Nutze den Composer als Startpunkt und Gerüst, nicht als bit-genauen Round-Trip. Prüf das Ergebnis einmal gegen, bevor es in Produktion geht.

Kleine Kniffe

Mehrere Befehle auf einmal. Kopier ein ganzes Setup-Snippet aus einer Anleitung in das Eingabefeld — inklusive docker network create und docker volume create. Jeder run wird zum Service, die Netze und Volumes landen sauber deklariert in derselben Datei. sudo, Kommentare und Befehle wie docker ps stören nicht.
Lange Befehle mit Backslash umbrechen. Der Tokenizer versteht \-Zeilenfortsetzungen und Shell-Quoting, du kannst also einen kopierten, mehrzeiligen Befehl unverändert einfügen. --flag=value, --flag value und Bündel wie -dp 80:80 funktionieren alle.
Projektnamen setzen. Trag im Feld Compose project name den Namen ein, unter dem du docker compose später startest (sonst nimmt Compose den Ordnernamen). Dann stimmen im Skript die Netz-, Volume- und Containernamen mit dem überein, was Compose anlegen würde — wichtig, wenn du Compose und von Hand gestartete Container mischst.
Ergebnis prüfen. docker compose config meldet undefinierte Netze und Volumes und zeigt die Datei so, wie Compose sie versteht. Das erzeugte Skript kannst du mit sh -n run.sh auf Syntaxfehler prüfen, bevor du es ausführst.
run.sh statt Copy. Der Download bringt #!/bin/sh und set -e mit — das Skript bricht beim ersten Fehler ab, statt mit dem nächsten Container weiterzumachen. Netze legt es nur an, wenn sie noch fehlen (network inspect … || network create …), ein vorhandenes Netz bricht den Lauf also nicht ab.
Variablen exportieren. Bleibt ${VAR} im Skript stehen, setzt die Shell den Wert ein — Compose hätte ihn auch aus .env gelesen. Exportiere die Variablen vorher, etwa mit set -a; . ./.env; set +a.
Datenschutz inklusive. Weil alles clientseitig läuft und nichts gesendet wird, kannst du Befehle mit Passwörtern, Tokens oder internen Hostnamen bedenkenlos konvertieren. Gespeichert werden nur Projektname und Runtime-Wahl. Trotzdem gilt: Solche Werte gehören in der echten Compose-Datei in eine .env-Datei oder in secrets, nicht im Klartext ins Repository.
Compose-Snippet ohne services:-Wrapper geht auch. Der Parser akzeptiert in der Gegenrichtung auch eine blanke Services-Map, solange jeder Service image oder build hat.

Mit anderen JPKCom-Tools kombinieren

Run-Befehl von Hand bauen oder verstehen? Das Docker-Cheat-Sheet erklärt den Container-Lebenszyklus und die wichtigsten docker-Flags — gutes Nachschlagewerk, bevor du einen Befehl in den Composer wirfst.
Mit der erzeugten YAML weiterarbeiten? Das Docker-Compose-Cheat-Sheet zeigt, wie du die Datei mit docker compose up, down, logs & Co. betreibst — und welche Felder (depends_on, build …) du noch ergänzen kannst.
Auf Podman umsteigen? Das Podman-Cheat-Sheet ordnet die podman-Befehle ein, die das Tool im Podman-Modus erzeugt.
Container-Job zeitsteuern? Mit dem Cron-Generator baust du die passende Crontab-Zeile, etwa für einen regelmäßigen docker run-Wartungsjob.

Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jedes Flag und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.