Docker/Podman Composer — Anwendungsbeispiele

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

Das Manual erklärt beide Richtungen und alle unterstützten Flags im Detail. Diese Seite zeigt konkrete Konvertierungen mit Eingabe und tatsächlichem Ergebnis. Die Oberfläche ist auf Englisch — Tab- und Button-Namen stehen deshalb im Original.

Beispiel 1: Einfacher nginx-Container (Run → Compose)

Der Klassiker — ein kurzer Run-Befehl wird zur Compose-Datei. Eingabe im Tab Run → Compose:

docker run -d --name web -p 8080:80 nginx:alpine

Nach Klick auf Convert to YAML:

services:
  web:
    image: nginx:alpine
    container_name: web
    ports:
      - 8080:80

Beachte: Das -d (detach) verschwindet — in Compose ist das implizit. Der Service-Name web kommt aus --name; ohne --name hätte das Tool ihn aus dem Image abgeleitet (nginx).

Beispiel 2: Volumes, Ports, Environment und Healthcheck

Ein realistischer Datenbank-Container mit mehreren Flag-Typen. Eingabe:

docker run -d \
  --name db \
  -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data \
  -p 5432:5432 \
  --restart unless-stopped \
  --health-cmd "pg_isready -U postgres" \
  --health-interval 10s \
  --memory 512m \
  postgres:16

Ergebnis:

services:
  db:
    image: postgres:16
    container_name: db
    restart: unless-stopped
    ports:
      - 5432:5432
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=secret
    mem_limit: 512m
    healthcheck:
      test:
        - CMD-SHELL
        - pg_isready -U postgres
      interval: 10s

Zwei Dinge lohnen die Aufmerksamkeit: Der --health-cmd wird zu einer test-Liste in der CMD-SHELL-Form, und --memory landet als mem_limit. Der per Anführungszeichen geklammerte Healthcheck-Befehl bleibt dank Tokenizer als ein Argument erhalten.

Beispiel 3: Multi-Flag-Befehl mit kombinierten Kurz-Flags

Hier kommen kombinierte Flags und ein nachgestelltes Kommando ins Spiel. Eingabe:

docker run -it --rm -p 3000:3000 node:20 bash

Ergebnis:

services:
  node:
    image: node:20
    tty: true
    stdin_open: true
    ports:
      - 3000:3000
    command: bash

Was hier passiert: -it wird in -i und -t zerlegt und ergibt stdin_open: true und tty: true. Das --rm wird verworfen (es hat keine Compose-Entsprechung), ebenso wäre ein -d verschwunden. Das bash nach dem Image-Namen wird zum command. Da kein --name gesetzt ist, leitet das Tool den Service-Namen aus dem Image ab: node.

Beispiel 4: Voller Funktionsumfang (der Example-Knopf)

Der Example-Knopf im Run-Tab lädt einen nginx-Webserver mit fast allem auf einmal:

docker run -d \
  -p 8080:80 \
  -p 443:443 \
  -v /var/www:/usr/share/nginx/html:ro \
  -v nginx-logs:/var/log/nginx \
  -e NGINX_HOST=example.com \
  -e NGINX_PORT=80 \
  --name webserver \
  --restart unless-stopped \
  --network mynet \
  --label app=webserver \
  --label env=production \
  --memory 256m \
  --health-cmd "curl -fs http://localhost/" \
  --health-interval 30s \
  --health-retries 3 \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  nginx:1.27-alpine

Ergebnis:

services:
  webserver:
    image: nginx:1.27-alpine
    container_name: webserver
    restart: unless-stopped
    ports:
      - 8080:80
      - 443:443
    volumes:
      - /var/www:/usr/share/nginx/html:ro
      - nginx-logs:/var/log/nginx
    environment:
      - NGINX_HOST=example.com
      - NGINX_PORT=80
    networks:
      - mynet
    labels:
      - app=webserver
      - env=production
    mem_limit: 256m
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "3"
    healthcheck:
      test:
        - CMD-SHELL
        - curl -fs http://localhost/
      interval: 30s
      retries: 3

Mehrfach genannte Flags (-p, -v, -e, --label, --log-opt) sammeln sich zu Listen bzw. zum logging.options-Block. Beachte das "3" bei max-file: Der Serialisierer setzt eine reine Zahl, die als String gemeint ist, in Anführungszeichen, damit YAML sie nicht als Integer liest.

Beispiel 5: Die Gegenrichtung — Compose → Run mit mehreren Services

Wechsle in den Tab Compose → Run und füge eine Compose-Datei mit zwei Services ein:

services:
  web:
    image: nginx:alpine
    container_name: web
    ports:
      - "8080:80"
    restart: unless-stopped
  app:
    image: node:20-alpine
    container_name: app
    restart: always
    working_dir: /app
    volumes:
      - ./app:/app
    environment:
      NODE_ENV: production
      PORT: "3000"
    ports:
      - "3000:3000"
    networks:
      - mynet
    depends_on:
      - web

Nach Convert to Commands (Runtime: docker) entsteht je Service ein Befehl:

# web
docker run -d \
  --name web \
  --restart unless-stopped \
  -p 8080:80 \
  nginx:alpine

# app
docker run -d \
  --name app \
  --restart always \
  --workdir /app \
  -p 3000:3000 \
  -v ./app:/app \
  -e NODE_ENV=production \
  -e PORT=3000 \
  --network mynet \
  node:20-alpine

Wichtig: Das depends_on: [web] taucht im erzeugten Befehl nicht auf — docker run kennt keine Start-Abhängigkeiten, also fällt es weg. Auch eine Top-Level-networks:-Definition mit Treiber-Optionen würde ignoriert; nur die Service-Referenz mynet wird zu --network mynet. Das environment-Objekt wird zu einzelnen -e KEY=VALUE-Flags aufgelöst.

Beispiel 6: Befehle für Podman erzeugen

Dieselbe Compose-Eingabe, aber im Runtime-Schalter podman gewählt. Aus dem web-Service wird dann:

# web
podman run -d \
  --name web \
  --restart unless-stopped \
  -p 8080:80 \
  nginx:alpine

Der einzige Unterschied ist das Befehlswort podman statt docker — die Flags bleiben gleich, weil Podman die docker run-Optionen kompatibel nachbildet. Praktisch, wenn du eine vorhandene Compose-Datei auf einem Podman-Host von Hand testen willst.

Noch tiefer: das Manual für jedes Flag, die Tipps & Tricks für die Grenzen und Kniffe. Ausprobieren kannst du alles direkt im Tool.