JPKCom DB

Docker/Podman Composer — Tipps & Tricks

Grenzen des Konverters, Round-Trip-Verluste, welche Flags wegfallen und wie du den Composer mit Cheat-Sheets und anderen JPKCom-Tools kombinierst.

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 für einen Container bzw. Service. Einige Dinge fallen dabei systembedingt weg — kein Bug, sondern die Natur der beiden Formate:

  • --rm und -d/--detach haben keine sinnvolle Compose-Entsprechung und werden bei Run → Compose verworfen. detach ist in Compose ohnehin implizit; bei Compose → Run wird umgekehrt immer ein -d gesetzt.
  • --network-alias wird erkannt, aber verworfen — auf Service-Ebene gibt es dafür keine direkte Compose-Abbildung.
  • Unbekannte Flags werden stillschweigend übersprungen. Wenn im Ergebnis etwas fehlt, das du im Befehl hattest, ist das Flag entweder unbekannt oder einer der oben genannten Sonderfälle. Ein Blick in den Reference-Tab zeigt dir, welche Flags überhaupt abgebildet werden.
  • Mehrere Services in einem Run-Befehl gibt es nicht. Ein docker run startet genau einen Container, also erzeugt Run → Compose immer genau einen Service. Ein mehrteiliges Setup baust du, indem du mehrere Befehle einzeln konvertierst und die Service-Blöcke in einer Datei zusammenführst.

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

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

  • depends_on — Startreihenfolge und Health-Bedingungen zwischen Services.
  • build — Image aus einem Dockerfile bauen statt fertig zu ziehen (inkl. Build-Kontext und Argumenten).
  • profiles — Services bedingt aktivieren.
  • deploy — Swarm-, Replica- und Ressourcen-Constraints.
  • secrets / configs — Swarm-Secrets und -Configs.
  • Top-Level-volumes/networks — benannte Volumes und Netzwerke mit Treiber-Optionen. Bei Compose → Run wird nur die Referenz auf ein Netzwerk zu --network, die eigentliche Treiber-Definition entfällt.

Der praktische Kniff: Die YAML-Ausgabe im Run-Tab ist editierbar (Badge „editable"). Konvertiere zuerst deinen Run-Befehl und tippe danach direkt im Tool ein depends_on, einen build:-Block oder eine Top-Level-networks:-Definition hinzu, bevor du die Datei kopierst oder herunterlädst.

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, --network-alias 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.
  • Healthcheck-Form wandelt sich. --health-cmd "…" wird zu test: [CMD-SHELL, …]. Liest du eine Compose-Datei ein, deren test in der ["CMD", …]-Listenform (statt CMD-SHELL) steht, fasst der Konverter die Elemente zu einem --health-cmd-String zusammen — funktional ähnlich, aber nicht zeichengleich.
  • Quoting kann sich ändern. Beim Erzeugen von YAML bzw. Befehlen wird nur dort gequotet, wo es nötig ist; eine reine Zahl als String erscheint z. B. als "3". Das ist semantisch identisch, sieht aber anders aus als deine handgeschriebene Vorlage.

Fazit: Nutze den Composer als Startpunkt und Gerüst, nicht als bit-genauen Round-Trip. Das erzeugte Ergebnis ist korrekt und lauffähig, aber prüf es einmal gegen, bevor es in Produktion geht.

Kleine Kniffe

  • Lange Befehle mit Backslash umbrechen. Der Tokenizer normalisiert \-Zeilenfortsetzungen, du kannst also einen aus einem Tutorial kopierten, mehrzeiligen Befehl unverändert einfügen.
  • --flag=value und --flag value sind beide ok. Kopiere Befehle so, wie du sie findest — der Parser versteht beide Schreibweisen.
  • Datenschutz inklusive. Weil alles clientseitig läuft und nichts gesendet wird, kannst du Befehle mit Passwörtern, Tokens oder internen Hostnamen bedenkenlos konvertieren. 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, nicht nur eine vollständige Datei.

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.