🐳 Generador docker-compose.yml

Genera un docker-compose.yml completo desde un formulario. Multiples servicios, puertos, volumenes, environment, depends_on, networks.

100% Gratis Sin registro Solo navegador 5 idiomas Modo oscuro

🔒 Sobre la privacidad

・Todas las entradas se procesan en el navegador
・Sin envio al servidor, sin registros, sin base de datos

Preajustes

version del archivo compose fijada a 3.9

🌐 Definiciones top-level

Volumenes (uno por linea)

Networks (uno por linea)

Secrets (NAME=path)

📄 docker-compose.yml

📖 Dónde se suele tropezar

Indica servicios, puertos, volumenes, variables de entorno, dependencias, redes y secretos en el formulario y se ensambla un docker-compose.yml listo para usar. Todo se ejecuta en el navegador y nada se transmite. Lo que esta herramienta garantiza es la sintaxis y la estructura del YAML, nada mas: no puede verificar que una imagen exista, que la aplicacion que contiene arranque, ni que tus servicios se alcancen entre si. La mayoria de los fallos de docker compose up no tienen que ver con el formato del YAML, sino con tres cosas que vienen despues: el orden, el enrutado y los permisos. De esas tres trata lo que sigue.

Caso	Qué ocurre	Qué hacer
`depends_on` solo espera a que arranque, no a que este listo	Lo unico que garantiza `depends_on` es el orden de arranque de los contenedores; no comprueba si el proceso de dentro esta listo para aceptar conexiones. Una base de datos tarda de segundos a decenas de segundos tras arrancar en terminar su inicializacion y recuperacion, de modo que tu aplicacion se conecta a un puerto que aun no escucha y muere. El sintoma es caracteristico: solo falla el primer `up` y, si vuelves a lanzarlo, funciona, porque en el segundo intento la base de datos ya esta caliente. Esa intermitencia hace que pase inadvertido en local y aparezca por primera vez en CI. No es un error irreproducible: es una condicion de carrera.	Pon un `healthcheck` en el servicio del que se depende y, en el que depende, indica `condition: service_healthy`. Para PostgreSQL, `test: ["CMD-SHELL", "pg_isready -U postgres"]` con `interval: 5s`, `retries: 10` y `start_period: 10s` es un punto de partida practico. Ni siquiera eso es completo: si la base de datos se reinicia con todo en marcha, la aplicacion vuelve a perder la conexion. La respuesta de fondo es reintentar la conexion dentro de la aplicacion. Un diseno que no dependa del orden de arranque se comporta igual en compose, en Kubernetes y contra una base de datos gestionada. Considera el healthcheck una comodidad que mejora la experiencia de desarrollo.
Invertir los dos lados de `ports` y `volumes`	En ambos, el lado izquierdo es el anfitrion y el derecho el contenedor (`"8080:80"` mapea el 8080 del anfitrion al 80 del contenedor). De aqui nacen tres accidentes. Primero, `ports` publica por defecto en todas las interfaces: escribe `"3306:3306"` y cualquiera en la misma LAN alcanza tu base de datos. Segundo, los servicios de la misma red de compose se hablan por nombre de servicio sin publicar ningun puerto; `db:5432` resuelve, asi que por lo general no necesitas `ports` para tu propia aplicacion. Tercero, un bind mount tapa lo que contiene la imagen: escribir `./:/app` hace que el `/app/node_modules` que construyo la imagen deje de verse, y aparecen errores de modulo no encontrado que solo ocurren bajo compose.	Pon en `ports` solo aquello que de verdad deba ser accesible desde fuera y deja el resto sin publicar. Si quieres conectarte a la base de datos desde tu maquina, escribe `"127.0.0.1:3306:3306"` para limitarlo al bucle local. La solucion habitual al problema de node_modules es superponer un volumen anonimo: enumera dos lineas bajo `volumes:`, `./:/app` y `/app/node_modules`; la segunda se coloca encima del bind mount y el contenido de la imagen sobrevive. Los desajustes de permisos (UID del anfitrion distinto del UID del contenedor, con lo que no se puede escribir o aparecen archivos de root) se alinean con `user: "${UID}:${GID}"`, pero esto solo muerde en Linux: Docker Desktop en macOS y Windows lo absorbe en la capa de virtualizacion, asi que alli no se reproduce.
Perder la pista de donde viene una variable de entorno	Compose tiene tres mecanismos de nombre parecido que hacen cosas distintas, y de ahi viene la confusion. (1) `environment:` pasa valores al contenedor. (2) `env_file:` hace lo mismo desde un archivo. (3) `${VAR}` dentro del YAML es una variable que compose sustituye al leer el archivo, y su valor solo puede venir del shell del anfitrion o del `.env` de la raiz del proyecto. Ahi esta la trampa mayor: los valores escritos en `env_file:` no se usan para resolver `${VAR}`. Y como un `${VAR}` sin definir se convierte en cadena vacia en lugar de dar error, `image: myapp:${TAG}` pasa en silencio a ser `myapp:` y descarga `latest`.	No adivines: lee `docker compose config`. Imprime el YAML final con todas las sustituciones resueltas y es el unico sitio donde puedes ver que se esta pasando de verdad. Cualquier valor que salga vacio es un `${VAR}` sin definir. Decide tambien una politica para los secretos: un valor escrito directamente en `environment:` es legible por cualquiera con `docker inspect` y acaba en Git. `env_file:` mejora eso porque el archivo puede figurar en `.gitignore`, pero dentro del contenedor sigue siendo una variable de entorno corriente. En produccion usa el mecanismo `secrets:` de compose o un servicio de gestion de secretos: el primero se monta como archivo, de modo que no lo heredan automaticamente los procesos hijo como si fuera una variable de entorno.

El version: '3.9' que emite esta herramienta lo ignora el Compose V2 actual. Veras el aviso the attribute version is obsolete, pero no afecta al comportamiento: borra esa linea si te molesta. El numero de version existia en la epoca de Compose V1 para elegir un conjunto de funciones; V2 interpreta siempre el archivo contra la ultima especificacion. Vale la pena nombrar dos trampas operativas mas. restart: always reiniciara para siempre un contenedor que muere nada mas arrancar: los registros se llenan de repeticiones y el mensaje de error real solo sobrevive en la primera iteracion, lo que dificulta encontrarlo. Quitalo mientras investigas. Y docker compose down no borra los volumenes con nombre. Cuando un script de inicializacion de base de datos "no funciona", casi siempre queda un volumen antiguo, porque la mayoria de las imagenes solo ejecutan la inicializacion si el directorio de datos esta vacio. Recrearlo exige docker compose down -v, y ese comando destruye los datos de verdad.

📖 Cómo usar

1

Elige un preset o anade un servicio

Comienza con uno de los seis presets o anade una tarjeta de servicio vacia.
2

Completa los campos del servicio

Introduce image, ports, volumes, environment, depends_on, restart, networks. Salida en tiempo real.
3

Copia o descarga

Copia el YAML generado o descargalo como docker-compose.yml.

❓ Preguntas frecuentes

Que version de compose se genera?

Genera version 3.9, el default moderno de docker compose v2. Funciona con Docker Engine 19.03+.

Se envian contrasenas y API keys?

No. Todo se ejecuta en tu navegador; nada se envia por red.

Se puede usar el YAML directamente con docker compose up?

Si. Los presets usan imagenes oficiales y arrancan tal cual. En produccion, separa variables a .env o secrets.

🔗 Herramientas relacionadas

🐛 ¿Encontró un problema con esta herramienta?

Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.