¿Odias los anuncios? Ir Sin publicidad Hoy 

Formateador de YAML de Docker Compose

DatosDesarrollador

ANUNCIO · ¿ELIMINAR?

APORTE

Proceso automático

PROD.

Lado cliente

ANUNCIO · ¿ELIMINAR?

Guía

Formateador de YAML de Docker Compose

Pegar un docker-compose.yml y obtener inmediatamente un archivo limpio y consistentemente formateado con servicios, redes y volúmenes ordenados según lo que espera la convención de Docker Compose. El formateador valida el archivo contra la Especificación moderna de Compose, marca claves obsoletas como el antiguo campo de nivel superior version campo o legacy links, y advierte sobre opciones de servicio desconocidas antes de que causen fallos en tiempo de ejecución.

Cómo Usar

Pega tu docker-compose.yml en el área de entrada, o haga clic en uno de los enlaces de ejemplo para cargar una pila de muestra.
Elige un orden de claves — Convención de Compose ordena los servicios en el orden que esperan los usuarios de Compose (imagen, reinicio, entorno, puertos, volúmenes, …), Alfabético ordena estrictamente de A a Z, o Preservar mantiene tu orden original.
Elige un identado de 2 o 4 espacios y activa o desactiva la validación contra la Especificación de Compose.
Lee el panel de validación para errores, advertencias sobre claves obsoletas y notificaciones informativas sobre referencias implícitas a redes.
Copia el resultado o descárgalo como docker-compose.yml.

Características

Validación contra Especificación de Compose – Reconoce el campo de nivel superior services, networks, volumes, configs, secrets, profiles, include, y campos de extensión (x-*); marca cualquier otro elemento.
Advertencias de obsolescencia – Destaca la clave de nivel superior legacy version , links, external_links, y los límites de recursos de la era v2 que deberían moverse bajo deploy.resources.
Orden de claves consciente del servicio – Reordena cada servicio para que las claves identificativas (image, build, container_name) estén primero, la configuración de ejecución (environment, ports, volumes) esté en medio y las preocupaciones operativas (healthcheck, logging, deploy) estén al final.
Verificación de referencias – Detecta servicios que dependen de servicios no definidos y advierte cuando un servicio utiliza una red que no está declarada en el nivel superior.
Requisitos de servicio – Verifica que cada servicio tenga al menos uno de image, build, extends, o provider, y que restart utilice una de las cuatro políticas válidas.
Sanidad de puertos + healthcheck – Captura cadenas de puertos mal formadas, falta de target en puertos en formato largo, y healthchecks sin un test.
Tres ejemplos funcionales – Una aplicación web con Node y Postgres, una pila de WordPress + MySQL + Redis, y una construcción de múltiples servicios con perfiles y límites de recursos.
Local + privado – Todos los procesos de análisis, ordenación y validación se realizan en su navegador. Su archivo de Compose nunca abandona la página.

 Preguntas frecuentes

¿Por qué se ha obsoletado la clave de versión en el nivel superior?

La clave de versión se utilizaba en las versiones antiguas de Compose (v1, v2 y v3) para seleccionar un esquema para la herramienta de línea de comandos docker-compose. La Especificación actual de Compose ha integrado esos esquemas en una sola especificación en evolución continua, por lo que una declaración de versión ya no cambia nada. Las últimas versiones de Docker Compose simplemente la ignoran y muestran una advertencia. Eliminarla reduce el tamaño del archivo y evita confusiones cuando los lectores asumen que las características de v3 están bloqueadas por dicha declaración.
¿Qué es la Especificación de Compose y cómo difiere de los formatos anteriores de archivos de Compose?

La Especificación de Compose es el esquema abierto y neutral de fabricantes que reemplaza los esquemas por versión que utilizó Docker Compose hasta 2020. Está mantenido en github.com/compose-spec/compose-spec y es implementado por Docker Compose, Podman Compose y otros ejecutadores. En comparación con v2 y v3, la especificación elimina el campo de versión, hace que los servicios sean la clave requerida en el nivel superior y absorbe campos exclusivos de Swarm como deploy como metadatos opcionales que los orquestadores pueden consumir.
¿Por qué prefiere una red compartida sobre el campo links?

links se heredó de la era anterior a las redes de Docker y solo establece alias de DNS entre contenedores en la red predeterminada. Las redes definidas por el usuario modernas ya proporcionan resolución DNS automática por nombre de servicio para cada servicio, permiten múltiples redes aisladas por pila y permiten controlar los alias de DNS con la opción aliases. Por esta razón, la Especificación de Compose marca links como obsoleta y recomienda el uso explícito de pertenencia a redes.
¿Qué hace exactamente cada política de reinicio?

no nunca reinicia el contenedor. siempre reinicia el contenedor cada vez que se detiene, incluyendo tras un reinicio del demonio. on-failure reinicia solo cuando el contenedor finaliza con un código de estado no cero, opcionalmente limitado por un número máximo de intentos. unless-stopped se comporta como siempre, excepto que un contenedor que fue detenido manualmente antes de un reinicio del demonio permanece detenido. Los cuatro valores son cadenas sensibles a mayúsculas y minúsculas — cualquier otro valor es rechazado por el motor de Compose.
¿Cómo decide Compose si debe descargar o construir una imagen?

Compose analiza pull_policy, build y image juntos. Con pull_policy: always, Compose descarga antes de cada up. Con ausencia o if_not_present (el valor predeterminado cuando solo se establece image) descarga solo si la imagen no está localmente. Con never nunca descarga. Cuando build está presente junto con image, pull_policy: build fuerza una reconstrucción y etiqueta el resultado como image, mientras que pull_policy: missing reconstruye solo cuando la imagen aún no está presente localmente.