# Docker/Podman Composer — Manual

> Vollständige Funktionsbeschreibung: beide Konvertierungsrichtungen, alle unterstützten run-Flags und Compose-Keys, das YAML-Format und die podman-Besonderheiten.

Source: https://www.jpkc.com/db/tools/docker/manual/

Zurück zur Übersicht: [Docker/Podman Composer](https://www.jpkc.com/db/tools/docker/) · Tool live öffnen: [www.jpkc.com/tools/docker/](https://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](https://www.jpkc.com/db/tools/docker/), für konkrete Durchläufe die [Beispiele](https://www.jpkc.com/db/tools/docker/examples/). Ausprobieren kannst du alles direkt im [Tool](https://www.jpkc.com/tools/docker/).