Anúncios incomodam? Ir Sem anúncios Hoje 

Formatação YAML do Playbook Ansible

DadosDesenvolvedor

ANUNCIADO Remover?

ENTRADA

Processo Automático

SAÍDA

Lado cliente

ANUNCIADO Remover?

Guia

Formatação de YAML do Playbook do Ansible

Formatação YAML do Playbook Ansible

Cole qualquer playbook ou arquivo de tarefa do Ansible e obtenha YAML consistentemente formatado com chaves de tarefa na ordem canônica (name → módulo → args → loop → when → register → notify). A ferramenta detecta se você colou um playbook ou uma lista de tarefas, valida a estrutura e apresenta sugestões de estilo do ansible-lint — nomes completos de coleção (FQCN), ausência de changed_when, command-em-lugar-de-módulo e elementos legados yes/no valores verdadeiros — para que seus playbooks passem pela revisão na primeira tentativa.

Como usar

Cole seu YAML do Ansible no campo de entrada — um completo playbook.yml, um role’s tasks/main.yml, ou qualquer lista de tarefas.
Deixe Reordenar Chaves de Tarefa para aplicar a ordem convencional esperada pelo ansible-lint, ou desativá-la para manter a sua ordem original.
Manter Validar a Estrutura do Ansible ativado para verificações de forma de play/tarefa (falta de hosts, tarefas sem módulo, listas malformadas block).
Alternar Mostrar sugestões de estilo do ansible-lint para orientações de boas práticas como nomes completos de coleção (FQCN), ausência de nomes e avisos de idempotência.
Copie a saída formatada ou baixe como playbook.yml.

Características

Ordem convencional de chaves de tarefa – name primeiro, depois o módulo, depois args, loop, when, register, notify — a ordem esperada pelo ansible-lint.
Detecção de playbook versus lista de tarefas – Aplica automaticamente a ordenação de nível de play (hosts, vars, pre_tasks, tasks, post_tasks, handlers) quando um playbook é detectado.
Consciência de bloco / resgate / sempre – Reorganiza tarefas em estilo de bloco sem quebrar suas semânticas.
Validação estrutural – Identifica plays faltando hosts, tarefas sem módulo, listas malformadas e chaves desconhecidas no nível de play.
Sugestões de FQCN – Sugere ansible.builtin.apt em vez de apt, correspondendo fqcn[action-core].
Sugestões de idempotência – Adverte quando command/shell executa sem changed_when, creates, ou removes.
detecção de uso de comando-em-lugar-de-módulo – Identifica instalações de pacotes shell, chamadas systemctl, clonagem git e instalações pip que têm módulos de primeira classe.
Detecção de valores verdadeiros legados – Identifica valores yes/no/on/off que deveriam ser true/false (yaml[truthy]).
Avisos sobre loops obsoletos – Destaca with_items, with_dicte amigos, para que você possa migrar para loop:.
Executa totalmente no navegador – Nada é enviado; seu inventário e segredos permanecem locais.

 Perguntas frequentes

Por que o ansible-lint se preocupa com a ordem das chaves de tarefa?

A ordem consistente das chaves torna os playbooks mais fáceis de ler: a intenção da tarefa (name) é lida primeiro, seguida pelo módulo que realiza a ação, depois pelos argumentos, e depois por qualquer fluxo de controle (loop, when, register, notify). Quando todos os membros da equipe seguem a mesma ordem, as diferenças permanecem focadas em mudanças reais em vez de reorganizações estéticas, e os revisores conseguem identificar tarefas rapidamente por padrão.
O que é FQCN e por que usá-lo para módulos?

FQCN significa Nome Completo da Coleção Qualificada — o caminho completo, como namespace.collection.module em vez de apenas ansible.builtin.apt . Desde a versão 2.10 do Ansible, os módulos foram divididos em coleções, e nomes brutos podem se resolver de forma ambígua quando múltiplas coleções fornecem um módulo com o mesmo nome curto. Os FQCNs tornam a resolução explícita, documentam a origem de cada módulo e protegem os playbooks contra mudanças na ordem das coleções. apt. Desde a versão 2.10 do Ansible, os módulos foram divididos em coleções, o que faz com que nomes brutos possam ser ambíguos quando múltiplas coleções possuem um módulo com o mesmo nome curto. Os nomes completos (FQCN) tornam a resolução explícita, documentam a origem de cada módulo e protegem os playbooks contra mudanças na ordem das coleções.
Quando devo usar loop: em vez de with_items:?

O with_* Os loops baseados em lookup eram a forma original de iterar, mas eles ligam a iteração com plugins de lookup, o que limita a composibilidade. A palavra-chave loop: (introduzida na versão 2.5) aceita qualquer lista diretamente e se combina bem com loop_control para indexação, rótulos e pausas. Para iterações simples de lista, prefira sempre loop:; apenas recorra a with_* para os poucos padrões que ainda não têm uma versão limpa de loop equivalente.
Por que 'sim' no YAML é considerado obsoleto no Ansible?

O YAML 1.1 tratava yes, no, on, off, truee, e false como booleans. O YAML 1.2 reduziu os booleans apenas a true/false. Para manter compatibilidade com o futuro e clareza — especialmente quando valores YAML são consumidos por ferramentas fora do Ansible — a regra do ansible-lint recomenda usar apenas yaml[truthy] . O uso de booleans estritos evita surpresas quando um valor de string literal true e falseé necessário como dado. yes é necessária como dados.
Por que declarar changed_when em tarefas command/shell?

O Ansible determina se uma tarefa alterou o sistema inspecionando os dados de retorno do módulo. Os módulos não conseguem saber isso por si só — eles tratam qualquer execução bem-sucedida como uma mudança, o que faz com que os testes de idempotência falem mentiras. Ao declarar command, shelle, e raw (ou usando changed_when ), você pode codificar a condição real de mudança: um código de saída específico, um padrão de saída ou um marcador de arquivo. Os playbooks idempotentes tornam-se mais silenciosos e mais fáceis de comparar em diffs como resultado. creates/removes) permite codificar a condição real de mudança: um código de saída específico, um padrão de saída ou um marcador de arquivo. Playbooks idempotentes tornam-se mais silenciosos e mais fáceis de comparar com diferenças como resultado.