ToolsOps

DevOps

Generador y validador de Docker Compose

Elige un stack y obtén un compose.yaml moderno con volúmenes, variables de entorno y healthchecks, más un .env.example. Pega un Compose existente y recibe avisos sobre secretos en texto plano, puertos de base de datos expuestos, imágenes con :latest, depends_on sin condición de salud y montajes peligrosos. Construye bloques healthcheck para Postgres, MySQL, Redis o HTTP sin buscar la sintaxis. El YAML y el .env que pegues se procesan en tu navegador y no se envían a un servidor.

Lint práctico de Docker Compose, no el validador oficial de la Compose Spec. Algunas funciones avanzadas de YAML pueden no estar cubiertas.

Opciones
compose.yaml
services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: '${POSTGRES_DB}'
      POSTGRES_USER: '${POSTGRES_USER}'
      POSTGRES_PASSWORD: '${POSTGRES_PASSWORD}'
    volumes:
      - 'postgres_data:/var/lib/postgresql/data'
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB']
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s
volumes:
  postgres_data: null
.env.example
POSTGRES_DB=app
POSTGRES_USER=app
POSTGRES_PASSWORD=CHANGE_ME

Notas sobre el resultado

  1. info.env

    Recuerda: `.env` con secretos reales NO debe commitearse. Versiona solo `.env.example`.

El YAML y el `.env` que pegues se procesan en tu navegador y no se envían a un servidor.

Docker Compose moderno: healthchecks, secretos y depends_on

Un buen compose.yaml no es solo una lista de servicios: define cómo arrancan, en qué orden esperan y cómo se gestionan los secretos. Estas son las decisiones que más errores evitan en stacks reales.

Healthchecks por servicio

Un healthcheck permite a Docker saber si un servicio está realmente listo, no solo si el proceso arrancó. Es el requisito previo para que depends_on pueda esperar de forma fiable.

  • PostgreSQL: pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB
  • MySQL: mysqladmin ping con usuario y contraseña del contenedor
  • Redis: redis-cli ping (con -a si hay contraseña)
  • HTTP: wget --spider al endpoint de salud

depends_on con condition: service_healthy

La forma corta de depends_on (una lista) solo garantiza orden de arranque. Para esperar a que la dependencia esté sana, usa la forma larga con condition: service_healthy y asegúrate de que el servicio destino tiene healthcheck.

Secretos y .env.example

Nunca pongas contraseñas literales en el compose.yaml. Usa ${VARIABLE} en environment y define los valores en un .env que no se commitea. Versiona solo un .env.example con placeholders como CHANGE_ME para que cualquiera sepa qué variables hacen falta.

Puertos de base de datos

Publicar 5432:5432 o 3306:3306 expone tu base de datos a toda la red del host. En desarrollo, si necesitas conectarte desde fuera, bindea a 127.0.0.1 (127.0.0.1:5432:5432). En producción, mantén la base de datos en la red interna de Compose y no publiques su puerto.

Preguntas frecuentes

¿Qué genera esta herramienta?
Un archivo compose.yaml práctico para stacks comunes (PostgreSQL, MySQL, MariaDB, Redis con contraseña, Nginx, Node + Postgres, WordPress + MariaDB, Prometheus + Grafana), junto con un .env.example con placeholders. Incluye volúmenes con nombre, variables de entorno por interpolación y, si lo activas, healthchecks. No es un compose listo para producción universal: es un punto de partida sensato que debes adaptar (backups, TLS, secretos reales gestionados fuera de git).
¿Cómo añado un healthcheck a Postgres o MySQL en Docker Compose?
En la pestaña Healthcheck elige el tipo de servicio y obtendrás el bloque healthcheck listo. Para Postgres se usa pg_isready; para MySQL, mysqladmin ping; para Redis, redis-cli ping; y para servicios HTTP, un wget al endpoint. Los comandos referencian las variables del propio contenedor con $$VARIABLE (Compose convierte $$ en un único $, evaluado dentro del contenedor en tiempo de ejecución). Puedes ajustar interval, timeout, retries y start_period.
¿Por qué mi depends_on no espera a que la base de datos esté lista?
depends_on en su forma corta solo espera a que el contenedor arranque, no a que el servicio esté sano. Para esperar a que la base de datos acepte conexiones necesitas un healthcheck en ese servicio y depends_on con condition: service_healthy. El validador avisa cuando un depends_on apunta a un servicio con healthcheck pero no usa la condición, y el generador de Node + Postgres ya produce la forma correcta.
¿Es seguro poner contraseñas en el compose.yaml?
No conviene. Una contraseña en texto plano dentro del compose.yaml acaba en tu repositorio y en el historial de git. La práctica recomendada es referenciar variables con ${VARIABLE} en el bloque environment y definir los valores reales en un archivo .env que NO se commitea (versiona solo un .env.example con placeholders). El validador marca como peligro cualquier secreto literal y solo muestra la clave afectada, nunca el valor.
¿El validador es el validador oficial de la Compose Spec?
No. Es un lint práctico: cubre el subset común de Docker Compose y avisa de los errores operativos más habituales (latest, secretos hardcoded, puertos de DB expuestos, montaje de docker.sock, falta de restart, etc.). Algunas funciones avanzadas de YAML (anchors, merge keys, fragmentos) pueden no estar cubiertas. Para validación estricta usa el propio `docker compose config` en tu máquina.
¿Necesito la clave version: en el compose.yaml?
No. La clave version: está obsoleta en Docker Compose moderno (Compose v2): se ignora y genera un aviso. Por eso los archivos generados no la incluyen y empiezan directamente por services:.
¿Se envía mi compose.yaml a algún servidor?
No. Tanto la generación como el lint y el healthcheck builder se ejecutan íntegramente en tu navegador. No hay llamadas a ningún backend, no se ejecuta Docker y nada de lo que pegues sale de tu equipo. El enlace para compartir solo serializa la selección de la interfaz (modo, stack, tipo de healthcheck), nunca el YAML ni el .env.