Pega un comando docker run y obten una definicion de servicio Compose lista para usar: puertos, volumenes, entorno, redes, healthcheck y politica de reinicio, convertidos en tu navegador.
Convierte un comando docker run largo en un archivo Compose que puedes versionar. Pega el comando tal como lo escribirias, incluidas las continuaciones de linea. Las opciones sin equivalente en Compose se listan como notas en lugar de descartarse en silencio.
Un comando docker run y un servicio de Compose describen el mismo contenedor, pero responden a preguntas distintas. El comando dice que hacer ahora mismo. El archivo dice que debe ser cierto siempre que ese servicio este en marcha. La mayoria de opciones se trasladan sin problemas, y las que no lo hacen suelen ser precisamente las que describen el acto de ejecutar y no el contenedor.
El ejemplo mas claro es detach. Escribir -d indica al demonio que no ocupe tu terminal, lo cual es una propiedad de esa invocacion y no del servicio. En Compose la misma intencion se expresa en la linea de comandos con docker compose up -d, asi que la opcion desaparece del archivo. Lo mismo ocurre con --rm, que pide limpieza tras esa ejecucion concreta; el equivalente es ejecutar docker compose down al terminar.
Las opciones interactivas quedan en medio. Tanto -i como -t si tienen claves en Compose, stdin_open y tty, porque mantener una shell conectada puede ser una propiedad real de un servicio. Por eso se convierten en lugar de descartarse, aunque la mayoria de servicios de larga duracion no las necesiten.
La causa mas habitual de una conversion incorrecta es una comilla de shell que se perdio antes de pegar el comando. Piensa en un healthcheck: todo el comando de prueba debe llegar como un unico argumento, y por eso va entre comillas. Si lo pegas sin ellas, las palabras se convierten en argumentos sueltos, el nombre de la imagen se lee en la posicion equivocada y el resultado no tiene sentido.
El conversor tokeniza la entrada como lo haria una shell, respetando comillas simples, comillas dobles, escapes con barra invertida y continuaciones de linea, de modo que un comando copiado de un script conserva su estructura. Despues vuelve a entrecomillar los valores segun las reglas de YAML, algo mas importante de lo que parece. Un mapeo de puertos como 8080:80 debe ir entre comillas en YAML, porque un par separado por dos puntos sin comillas es ambiguo y algunos parsers han leido historicamente valores como 22:00 como un numero sexagesimal.
La gestion de redes es el unico punto donde una conversion fiel sigue necesitando una decision tuya. Si el comando se une a host, none o bridge, eso es un modo y se convierte en network_mode. Cualquier otro nombre se refiere a una red que ya existe, asi que el servicio recibe una entrada networks y el archivo declara esa red como externa.
Esa declaracion es una afirmacion sobre tu entorno: dice que la red se gestiona fuera de este archivo. Si prefieres que Compose la cree y la posea, elimina la marca external y definela con normalidad. El conversor no puede saber cual quieres, porque el comando original solo demuestra que la red existia en el momento de ejecutarse.
La misma precaucion se aplica a los bind mounts. Una ruta como /srv/site funciona en la maquina donde se escribio el comando y en ninguna otra. Cuando el servicio pasa a vivir en un archivo que se versiona y se comparte, las rutas relativas o los volumenes con nombre suelen ser mejor opcion.