Validador de YAML Docker Compose

Pega un archivo Compose para ver el inventario de servicios y los avisos de un linter estructural local. El YAML se analiza en tu navegador: no se sube nada, no se contacta con el daemon de Docker y Compose no se ejecuta.

Se ejecuta localmente en tu navegador
YAML de Compose

Pega compose.yaml o docker-compose.yml. El análisis y las comprobaciones se ejecutan localmente en el navegador.

Es un linter estructural local. No descarga imágenes, no inspecciona el daemon de Docker, no resuelve variables de entorno ni ejecuta Compose.

Avisos
  • Valida un archivo Compose para ver las comprobaciones locales.
Inventario de servicios
ServicioImagen / buildPuertosDepende de
Todavía no se ha validado ningún archivo Compose.

Cómo validar un archivo Compose antes de ejecutar docker compose up

Pega un compose.yaml o docker-compose.yml y pulsa Validar archivo Compose. La página analiza el documento en el navegador y muestra dos resultados: la lista de avisos agrupada por gravedad, con la ruta de la clave problemática en cada fila (por ejemplo services.db.ports[0]), y un inventario de servicios con la imagen o el origen de build, los puertos publicados y los destinos de depends_on.

El ejemplo integrado (api y db, cada uno con un volumen con nombre) termina en «listo para revisar», porque nada impide un docker compose up. Un puerto reutilizado por dos servicios, un depends_on que apunta a un servicio inexistente o un ciclo como a → b → a sí se marcan como errores.

  1. Pega el archivo Compose en el panel izquierdo. Se lee un solo documento YAML; también se acepta el JSON equivalente y se admiten anclas, alias y claves de fusión.
  2. Pulsa Validar archivo Compose, o Cargar ejemplo para partir del ejemplo con dos servicios y Limpiar para vaciar ambos paneles antes del siguiente archivo.
  3. Lee primero los Avisos: cada fila lleva una insignia de gravedad, la ruta dentro del archivo y una frase que explica el problema. Los errores impiden una ejecución normal de Compose, los avisos merecen una revisión y la información es solo orientativa.
  4. Consulta el Inventario de servicios para ver la imagen resuelta o el origen de build, los puertos publicados y la lista depends_on de cada servicio, incluidos los que solo heredan la imagen mediante una clave de fusión.
  5. Corrige el archivo, valida otra vez y fíjate en el resumen: «listo para revisar» significa que las comprobaciones implementadas no han encontrado errores estructurales.

Qué comprueba el linter de Compose y qué no llega a leer

Qué cubren las comprobaciones

Estructura: services debe ser un mapa con al menos un servicio, cada servicio debe ser un objeto y los nombres solo admiten letras, números, puntos, guiones bajos y guiones; Compose rechaza el resto. image debe ser una cadena no vacía y build una ruta o un objeto; un servicio sin ninguno de los dos se señala porque no puede ejecutarse.

Puertos: el puerto del contenedor debe estar entre 1 y 65535, y el puerto publicado puede ser un número suelto o un rango como 8000-8005. El linter marca puertos fuera de rango o no numéricos, protocolos distintos de tcp, udp o sctp, y cualquier puerto duplicado o solapado, tanto si se repite en un servicio como si aparece en dos. Usar network_mode: host con puertos publicados genera un aviso, porque esos mapeos se ignoran en tiempo de ejecución.

Dependencias, volúmenes y claves de fusión

depends_on puede ser una lista o un mapa; cada destino debe existir y el grafo no puede tener ciclos, así que a → b → a o un servicio que depende de sí mismo se reportan con el ciclo completo. container_name y privileged: true se marcan como avisos porque limitan el escalado o amplían el acceso al host más de lo que la mayoría de servicios necesita.

Los volúmenes con nombre que monta un servicio deben declararse en el mapa volumes de nivel superior. El analizador local resuelve anclas y alias, y <<: *common se fusiona en el servicio cuando apunta a un mapa, de modo que una imagen que solo llega por la clave de fusión aparece igualmente en el inventario; si la fusión no se puede resolver, la fila lo indica en lugar de dar por hecho que falta la imagen.

Qué no hace el linter

No se ejecuta nada: la página nunca lanza docker compose, no contacta con el daemon de Docker ni descarga imágenes. Variables como ${POSTGRES_PASSWORD} no se resuelven, los archivos .env no se leen y el comportamiento de profiles o extends solo se revisa como estructura. Las diferencias entre versiones de Compose no se simulan, así que confirma el archivo final con la versión que uses al desplegar.

El documento se analiza en tu navegador: el texto pegado no se sube y la validación sigue funcionando sin conexión. Los archivos muy grandes están limitados por la memoria de tu dispositivo y se lee un solo documento a la vez; un archivo con un segundo documento --- se rechaza indicando la línea.

Herramientas recientes: