Compose ↔ docker run

Funciones

• Ambos sentidos detectados automáticamente: una sección services de compose ↔ un comando docker run completo
• image, container_name, ports, volumes, environment, env_file, command, entrypoint, restart, network_mode, working_dir, user, hostname
• Conmutadores: privileged, read_only, tty, stdin_open
• El array test de un healthcheck pasa a --health-cmd, junto con interval, timeout y retries
• Formas corta y larga de los puertos (target / published / protocol); lo que no es tcp lleva su sufijo
• La forma larga de un volumen (source / target / read_only) pasa a `-v src:dst:ro`
• ⚠️ depends_on, deploy, profiles y extends se listan uno a uno, con el motivo de que no haya equivalente
• ⚠️ build, varias redes, volúmenes con nombre y valores `KEY=` vacíos se marcan como puntos donde cambia el significado
• ⚠️ Las opciones de docker no reconocidas se reportan con honestidad en vez de colarse en el resultado
• ⚠️ Se manejan las continuaciones de línea al final — los comandos copiados de `docker ps` o de la documentación las traen siempre
• ⚠️ Los argumentos posteriores a la imagen se separan como el comando, así que `-g` y compañía no se pierden como opciones de docker
• Se ejecuta por completo en tu navegador

Cómo se usa

1. Pega una sección services de compose, o un comando docker run
2. Opcionalmente, nombra un solo servicio para convertirlo
3. Lee primero el comando o el fragmento, y luego las secciones «lo que no se ha arrastrado» y «dónde cambia el significado»

Preguntas frecuentes

¿Por qué no se ha arrastrado parte de la configuración?

Porque no tiene equivalente en `docker run`. `deploy` es el caso más claro: configura el número de réplicas, los límites de recursos y la política de actualización progresiva, que son de la capa de orquestación, mientras que `docker run` arranca un contenedor — «tres réplicas» sencillamente no existe en un solo comando (eso requiere `docker service` o un orquestador). `depends_on` (orden de arranque) y `profiles` (activación condicional) igual. Descartar en silencio lo que no se puede expresar da a entender que el comando equivale al servicio original, y lo descubres al desplegar con él.

¿Por qué las rutas relativas pueden quedar mal tras convertir?

Porque los dos se resuelven contra directorios distintos: una ruta relativa en compose se resuelve contra el directorio del archivo compose, mientras que los argumentos de una línea de comandos `docker run` se resuelven contra el directorio de trabajo actual. La entrada `./site:/usr/share/nginx/html` significa `/srv/app/site` cuando el archivo compose está en `/srv/app/docker-compose.yml`, y significa donde quiera que estés al ejecutar el comando convertido en otro sitio. El comando se ve idéntico; monta otra cosa.

¿Por qué desaparecen `-d` y `--rm`?

Porque no forman parte de la definición de un servicio en compose. `-d` (ejecutar en segundo plano) corresponde a `docker compose up -d`, que es un conmutador a nivel de comando y no tendría sentido en un servicio concreto, y `--rm` tampoco tiene una clave equivalente en un servicio. Su ausencia es correcta: en términos de compose no deberían estar ahí.

¿Por qué no se ha descartado el `-g` que va después de la imagen?

Porque la gramática de docker es `docker run [OPCIONES] IMAGEN [COMANDO]`, y todo lo que va después de la imagen es el comando que se ejecuta dentro del contenedor. El `-g` de `docker run nginx -g "daemon off;"` es un argumento de nginx, no un conmutador de docker. Al cortar por posición se queda en el comando; sin ese corte se descartaría como una opción de docker desconocida y el archivo compose seguiría pareciendo completo.

¿Puede convertir a Podman o Kubernetes?

No: esto solo hace compose y `docker run`. Convertir a Kubernetes es un problema de otro orden: en qué se divide un Deployment en Services, ConfigMaps y Secrets depende de cómo esté organizado tu clúster, así que no es una correspondencia uno a uno. El YAML así generado funcionaría y sería difícil de mantener.

¿Dónde está la planificación del pool de direcciones de daemon.json?

En otra herramienta, «Planificador de subredes de Docker». Esta solo convierte entre compose y `docker run`: un archivo de orquestación de servicios por un lado y un único comando de ejecución por el otro. Los pools de direcciones (`default-address-pools`) y el `bip` de docker0 son ajustes a nivel de daemon sin equivalente en el comando de arranque de un contenedor, por eso viven en su propia herramienta en vez de mezclar dos asuntos en una página.