¿Odias los anuncios? Ir Sin publicidad Hoy 

Formateador de YAML de Ansible Playbook

DatosDesarrollador

ANUNCIO · ¿ELIMINAR?

APORTE

Proceso automático

PROD.

Lado cliente

ANUNCIO · ¿ELIMINAR?

Guía

Formateador de YAML de Playbook de Ansible

Formateador de YAML de Ansible Playbook

Pega cualquier playbook o archivo de tareas de Ansible y obtén un YAML consistentemente formateado con las claves de tareas en el orden canónico (name → módulo → args → loop → when → register → notify). La herramienta detecta si has pegado un playbook o una lista de tareas, valida la estructura y muestra sugerencias de estilo de ansible-lint — nombres completos de módulo (FQCN), ausencia de changed_when, command-en-lugar-de-módulo, y elementos obsoletos yes/no valores verdaderos — para que tus playbooks pasen la revisión en la primera intento.

Cómo Usar

Pega tu YAML de Ansible en la caja de entrada — un completo playbook.yml, un rol de tasks/main.yml, o cualquier lista de tareas.
Deja Reordenar las claves de Tarea activado para aplicar el orden convencional esperado por ansible-lint, o desactivarlo para mantener tu orden original.
Mantener Validar la estructura de Ansible activado para comprobaciones de forma de play/tarea (faltan hosts, tareas sin módulo, listas mal formadas block).
Palanca Mostrar sugerencias de estilo de ansible-lint para sugerencias de mejores prácticas como nombres completos de módulo (FQCN), ausencia de nombres y advertencias de idempotencia.
Copia el resultado formateado o descárgalo como playbook.yml.

Características

Orden convencional de las claves de tarea – name primero, luego el módulo, luego args, loop, when, register, notify — el orden esperado por ansible-lint.
Detección de playbook vs lista de tareas – Aplica automáticamente el orden de nivel de play (hosts, vars, pre_tasks, tasks, post_tasks, handlers) cuando se detecta un playbook.
Bloque / rescate / siempre consciente – Reordena las tareas en estilo de bloque sin romper sus semánticas.
Validación estructural – Marca plays que faltan hosts, tareas sin módulo, listas mal formadas y claves desconocidas en el nivel de play.
Sugerencias de FQCN – Sugerencias de ansible.builtin.apt en lugar de apt, coincidencias de fqcn[action-core].
Sugerencias de idempotencia – Advertencias cuando command/shell se ejecuta sin changed_when, creates, o removes.
detección de uso de comando-en-lugar-de-módulo – Detecta instalaciones de paquetes, llamadas a systemctl, clonaciones de git y instalaciones de pip que tienen módulos de primer nivel.
Detección de valores verdaderos obsoletos – Marca valores yes/no/on/off que deberían ser true/false (yaml[truthy]).
Advertencias de bucle obsoletos – Destaca with_items, with_dict, y amigos, para que puedas migrar a loop:.
Funciona completamente en tu navegador – Nada se sube; tu inventario y tus secretos permanecen locales.

 Preguntas frecuentes

¿Por qué ansible-lint preocupa por el orden de las claves de tarea?

Un orden consistente hace que los playbooks sean más fáciles de leer: la intención de la tarea (name) se lee primero, luego el módulo que realiza la acción, luego sus argumentos, luego cualquier control de flujo (loop, when, register, notify). Cuando todos los miembros del equipo siguen el mismo orden, las diferencias se centran en cambios reales en lugar de reorganizaciones estéticas, y los revisores pueden reconocer las tareas de inmediato.
¿Qué es FQCN y por qué se debe usar para módulos?

FQCN significa Nombre Completo de Colección. Es la ruta completa, como namespace.collection.module en lugar de simplemente ansible.builtin.apt . Desde Ansible 2.10, los módulos se dividieron en colecciones, por lo que los nombres simples pueden resolverse de forma ambigua cuando varias colecciones incluyen un módulo con el mismo nombre corto. Los FQCN hacen la resolución explícita, documentan la fuente de cada módulo y protegen los playbooks de cambios en el orden de las colecciones. apt¿Cuándo debo usar loop: en lugar de with_items:?
Los bucles basados en lookup eran la forma original de iterar, pero acoplan la iteración con los plugins de lookup, lo que limita la composabilidad. La palabra clave (introducida en 2.5) toma cualquier lista directamente y se combina bien con

El with_* para indexación, etiquetas y pausas. Para iteraciones simples, siempre prefiera loop: ; únicamente caiga a loop_control para los pocos patrones que aún no tienen una versión limpia de loop:. with_* ¿Por qué 'yes' en YAML se considera obsoleto en Ansible? loop YAML 1.1 trató a
como valores booleanos. YAML 1.2 redujo los valores booleanos a solo

. Para mantener compatibilidad futura y claridad — especialmente cuando los valores YAML son consumidos por herramientas fuera de Ansible — la regla de ansible-lint recomienda usar siempre yes, no, on, off, truey false . Usar los valores booleanos estrictos evita sorpresas cuando se necesita un valor de cadena literal. true/false¿Por qué declarar changed_when en tareas de command/shell? yaml[truthy] Ansible determina si una tarea cambió el sistema inspeccionando los datos de retorno del módulo. Los módulos no pueden saberlo por sí mismos — tratan cualquier ejecución exitosa como un cambio, lo que hace que las comprobaciones de idempotencia sean engañosas. Declarar true y false(o usar yes ) te permite codificar la condición real de cambio: un código de salida específico, un patrón de salida o un marcador de archivo. Los playbooks idempotentes se vuelven más silenciosos y más fáciles de comparar mediante diferencias.
fue agregado el 8 de junio de 2026

Pega tu playbook.yml, roles o lista de tareas aquí command, shelly raw Formateador de YAML de Playbook de Ansible 1 changed_when Formateador de YAML de Playbook de Ansible creates/removesPega cualquier playbook o archivo de tareas de Ansible y obtén un YAML consistentemente formateado con las claves de tareas en el orden canónico (nombre → módulo → argumentos → bucle → condición →