Lire changed et ok dans la sortie

Après chaque tâche, Ansible affiche un statut pour chaque hôte. Les deux que vous verrez le plus souvent sont ok et changed, et ils racontent des choses différentes.

Le statut ok signifie que l'hôte correspondait déjà à l'état souhaité. La tâche a effectué sa vérification, mais n'a absolument rien modifié.

Le statut changed signifie que l'hôte ne correspondait pas à l'état souhaité ; le module a donc modifié quelque chose pour l'y amener.

Par défaut, Ansible affiche la sortie changed en jaune et la sortie ok en vert. Une mer de vert lors d'une deuxième exécution est exactement ce que vous recherchez.

À la fin, le PLAY RECAP comptabilise, pour chaque hôte, les valeurs ok, changed, unreachable et failed. C'est votre vérification de santé en une ligne.

Exécutez deux fois un livre de procédures idempotent : le deuxième récapitulatif doit afficher changed=0. Toute modification lors d'une nouvelle exécution mérite d'être examinée.

Le statut changed indique une réussite, pas un problème. Il signale simplement que l'hôte avait besoin d'une intervention et que la tâche l'a effectuée correctement.

Vous pouvez également voir skipping, ce qui signifie qu'une condition when était fausse : la tâche n'a donc pas été exécutée sur cet hôte.

Le statut failed signifie que la tâche a rencontré une erreur ; unreachable signifie qu'Ansible n'a même pas pu se connecter via SSH. Les deux arrêtent l'exécution pour cet hôte.

Le nombre de changements est votre indicateur d'idempotence. Si une exécution répétée continue de signaler des modifications, cela signifie qu'une tâche n'est pas réellement idempotente.

Ajoutez -v (ou -vv) à ansible-playbook pour obtenir une sortie détaillée indiquant exactement ce que chaque tâche a modifié et pourquoi.

Interprétez ok comme « déjà conforme » et changed comme « vient d'être corrigé ». Le PLAY RECAP et une deuxième exécution affichant changed=0 prouvent que votre exécution est idempotente. ✅