APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um playbook organiza plays e tarefas; cada tarefa chama uma ação com argumentos. Muitos módulos verificam o estado atual antes de alterar o destino, permitindo repetir a execução sem produzir novas mudanças quando o estado já corresponde ao pedido. Isso não torna qualquer comando arbitrário idempotente. Um script que acrescenta uma linha em cada execução continua a fazê-lo mesmo que changed_when seja false. Essa opção controla o relatório e pode influenciar handlers; não apaga os efeitos do processo. Escolhe um módulo adequado quando consegue representar o estado desejado e reserva comandos para necessidades que esse módulo não cobre.
Aplicação guiada
Num exemplo fictício, um script de configuração apresenta changed em todas as execuções. Investiga se altera realmente o ficheiro, apenas mede estado ou devolve um código especial. Define changed_when e failed_when a partir desse contrato, sem esconder erros. ansible.builtin.command não interpreta pipes ou redirecionamentos de shell; argv ajuda a separar argumentos. A expansão de certas variáveis pelo módulo não o transforma num shell. Se precisares de shell, controla entradas e quoting. Para reutilizar a configuração, uma role organiza tarefas, templates e handlers. Coloca valores que os consumidores devem poder substituir em defaults, documenta os inputs e usa nomes qualificados de módulos para evitar colisões entre collections.
Um comando de leitura pode usar changed_when=false; um script de alteração precisa de comportamento e evidência coerentes.
Armadilhas comuns
Changed como saúde; relatório false como ausência de efeitos; shell para qualquer comando; vars como defaults.
Tópicos relacionados: Inventário e contexto de execução · Validação e handlers · Orquestração por lotes
Faz o relatório corresponder ao contrato real da ação.
Referência: Ansible playbooks · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation