Lendo changed versus ok na saída

Depois de cada tarefa, o Ansible exibe um status para cada máquina. Os dois que você verá com mais frequência são ok e changed, e eles contam histórias diferentes.

Um status ok significa que a máquina já correspondia ao estado desejado. A tarefa executou sua verificação, mas não fez alteração alguma.

Um status changed significa que a máquina não correspondia ao estado desejado, então o módulo modificou algo para aproximá-la do estado declarado por você.

Por padrão, o Ansible exibe a saída changed em amarelo e a saída ok em verde. Uma tela inteira em verde na segunda execução é exatamente o que você deseja.

Ao final, o PLAY RECAP contabiliza os resultados por máquina: ok, changed, unreachable e failed. É sua verificação de integridade em uma única linha.

Execute um manual de execução idempotente duas vezes, e a segunda recapitulação deverá mostrar changed=0. Vale investigar qualquer alteração em uma execução repetida.

Um status changed indica sucesso, não um problema. Ele simplesmente registra que a máquina precisava de trabalho e que a tarefa o realizou corretamente.

Você também poderá ver skipping, o que significa que uma condição when era falsa e, por isso, a tarefa não foi executada nessa máquina.

Um status failed significa que ocorreu um erro na tarefa; unreachable significa que o Ansible não conseguiu sequer se conectar por SSH. Ambos interrompem a execução nessa máquina.

A quantidade de changed é seu medidor de idempotência. Uma execução repetida que continua informando alterações significa que uma tarefa não é realmente idempotente.

Adicione -v (ou -vv) ao ansible-playbook para obter uma saída detalhada que mostre exatamente o que cada tarefa alterou e por quê.

Você executa o mesmo manual de execução uma segunda vez, e a recapitulação mostra ok=5 changed=0.

Interprete ok como “já estava correto” e changed como “acabou de ser corrigido”. O PLAY RECAP e uma execução repetida com changed=0 comprovam que sua execução é idempotente. ✅