Interpréter la sortie : `ok`, `changed`, `failed`, `skipped`

Décoder les messages d'Ansible : la clé du succès de vos playbooks

Après avoir lancé votre playbook avec la commande `ansible-playbook`, la console se remplit d'informations. Comprendre cette sortie est absolument crucial pour déterminer si votre automatisation s'est déroulée comme prévu, si des modifications ont été apportées à vos systèmes, si des erreurs se sont produites, ou si certaines tâches ont été intentionnellement ignorées. Ansible utilise un code couleur et des statuts clairs pour communiquer l'état de chaque tâche sur chaque hôte ciblé.

Les principaux indicateurs que vous rencontrerez sont `ok`, `changed`, `failed`, et `skipped`. Chacun de ces statuts, souvent accompagné d'une couleur spécifique (généralement vert pour `ok` et `changed`, rouge pour `failed`, jaune ou cyan pour `skipped`), vous renseigne sur l'issue de l'opération. Une bonne interprétation de ces messages est la base du débogage et de la validation de vos playbooks.

Cette section va détailler la signification de chaque statut, vous montrer à quoi ressemble une sortie typique, et vous expliquer comment utiliser ces informations pour affiner vos playbooks et assurer la fiabilité de vos processus d'automatisation. C'est une compétence essentielle pour passer de simple utilisateur à administrateur Ansible confiant.

Les statuts des tâches Ansible : `ok`, `changed`, `failed`, `skipped`

Lors de l'exécution d'un playbook, Ansible affiche le nom de chaque tâche (la valeur de la directive `name`) avant de l'exécuter, suivi du résultat pour chaque hôte ciblé. Voici la signification des statuts les plus courants :

• `ok` (généralement en vert) :
  • Signification : La tâche s'est exécutée avec succès sur l'hôte, et aucun changement n'a été nécessaire sur le système. L'état désiré par la tâche était déjà atteint.
  • Exemple : Si une tâche vise à s'assurer qu'un paquet est installé (`state: present`) et que le paquet est déjà présent, le statut sera `ok`. Si une tâche vérifie qu'un service est démarré (`state: started`) et qu'il l'est déjà, le statut sera `ok`.
  • Couleur typique : Vert.

• `changed` (généralement en vert ou jaune selon la configuration) :
  • Signification : La tâche s'est exécutée avec succès sur l'hôte, et un changement a été effectué sur le système pour atteindre l'état désiré.
  • Exemple : Si un paquet n'était pas installé et que la tâche l'a installé, le statut sera `changed`. Si un service était arrêté et que la tâche l'a démarré, le statut sera `changed`. Si un fichier a été copié ou modifié, le statut sera `changed`.
  • Couleur typique : Vert (indiquant le succès) ou parfois jaune pour souligner le changement.

• `failed` (généralement en rouge) :
  • Signification : La tâche a échoué sur l'hôte. Ansible n'a pas pu atteindre l'état désiré ou une erreur s'est produite pendant l'exécution du module.
  • Exemple : Une tentative d'installation d'un paquet qui n'existe pas, une erreur de permission lors de la copie d'un fichier, un service qui ne parvient pas à démarrer, une erreur de syntaxe dans les paramètres du module.
  • Conséquence : Par défaut, si une tâche échoue sur un hôte, Ansible arrête l'exécution de toutes les tâches suivantes pour cet hôte spécifique. Les autres hôtes continuent, sauf si une stratégie d'erreur différente est configurée (ex: `any_errors_fatal`).
  • Couleur typique : Rouge.

• `skipped` (généralement en jaune ou cyan) :
  • Signification : La tâche n'a pas été exécutée sur l'hôte parce qu'une condition spécifiée (par exemple, avec la directive `when`) n'a pas été remplie, ou parce que la tâche a été explicitement sautée (par exemple, via des tags ou une exécution en mode `--check` où la tâche aurait effectué un changement non souhaité en dry-run).
  • Exemple : Une tâche conditionnée par `when: ansible_os_family == "Debian"` sera `skipped` sur un hôte CentOS. Une tâche qui créerait un fichier sera `skipped` en mode `--check` si le module indique qu'il effectuerait un changement.
  • Couleur typique : Jaune ou cyan.

D'autres statuts moins fréquents existent, comme `unreachable` (généralement en rouge), qui indique qu'Ansible n'a pas pu se connecter à l'hôte (problème SSH, hôte éteint, etc.).

Anatomie d'une sortie de playbook et le récapitulatif `PLAY RECAP`

Au fur et à mesure de l'exécution, vous verrez des lignes comme celles-ci pour chaque tâche :

TASK [Nom descriptif de la tâche] ***************************************************
ok: [webserver01.example.com]
changed: [webserver02.example.com]
failed: [database01.example.com] => {"msg": "Message d'erreur détaillé..."}
skipped: [testserver01.example.com]

A la toute fin de l'exécution du playbook, Ansible affiche un récapitulatif appelé `PLAY RECAP`. Ce résumé est crucial car il agrège les résultats pour chaque hôte qui a été ciblé par au moins un jeu :

PLAY RECAP *********************************************************************
webserver01.example.com    : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
webserver02.example.com    : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
database01.example.com     : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
testserver01.example.com   : ok=1    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

Ce récapitulatif vous donne une vue d'ensemble rapide de l'état de votre infrastructure après l'exécution du playbook :

• `ok=X` : Nombre de tâches qui se sont terminées avec succès sans rien changer.
• `changed=Y` : Nombre de tâches qui se sont terminées avec succès en apportant un changement.
• `failed=Z` : Nombre de tâches qui ont échoué. Si ce nombre est supérieur à 0 pour un hôte, cela signifie qu'il y a eu un problème.
• `skipped=S` : Nombre de tâches qui ont été sautées.
• `unreachable=U` : Indique si l'hôte était injoignable.
• `rescued=R` et `ignored=I` sont liés à des stratégies de gestion d'erreurs plus avancées (blocs `rescue` et `ignore_errors`).

Un `failed` supérieur à zéro est généralement un indicateur que quelque chose ne va pas et nécessite une investigation. L'objectif est souvent d'atteindre `failed=0` et `unreachable=0` pour tous les hôtes. Le nombre de `changed` vous indique l'ampleur des modifications apportées. Si vous exécutez le même playbook une seconde fois sans aucune modification manuelle sur les serveurs entre-temps, vous devriez idéalement voir `changed=0` pour toutes les tâches idempotentes, ce qui confirme que l'état désiré est maintenu.

Utiliser la sortie pour le diagnostic et l'amélioration continue

L'interprétation correcte de la sortie d'Ansible est une compétence qui s'affine avec l'expérience. Voici quelques pistes pour l'utiliser efficacement :

• Priorité aux `failed` : Toute tâche en échec doit être examinée en premier. Le message d'erreur (`msg`) associé est votre meilleur point de départ. Les options de verbosité (`-v`, `-vvv`) peuvent être nécessaires pour obtenir plus de contexte.
• Analyser les `changed` : Surtout lors des premières exécutions ou après des modifications du playbook, les tâches `changed` confirment que votre playbook a eu l'effet escompté. Si une tâche que vous attendiez `changed` est `ok`, cela peut signifier que la condition était déjà remplie ou que votre tâche n'est pas formulée correctement.
• Comprendre les `skipped` : Assurez-vous que les tâches `skipped` le sont pour les bonnes raisons (conditions `when` attendues, mode `--check`). Un `skipped` inattendu peut indiquer un problème dans la logique de vos conditions.
• Le pouvoir de l'idempotence : Exécutez plusieurs fois votre playbook (surtout après des modifications ou en phase de développement). Si des tâches continuent d'apparaître en `changed` à chaque exécution sans raison apparente, cela peut indiquer un problème d'idempotence dans votre module ou votre logique. L'idéal est d'atteindre un état où les exécutions répétées ne montrent que des `ok`.
• Utiliser `--check` : Avant d'appliquer des changements majeurs, utilisez toujours le mode "dry run" (`--check`). La sortie vous indiquera quels changements seraient faits (`changed` ou `skipped` si la tâche modifie l'état), vous permettant d'anticiper l'impact.

En devenant familier avec ces indicateurs et en apprenant à lire les messages d'erreur, vous serez en mesure de développer des playbooks Ansible robustes, de diagnostiquer rapidement les problèmes et de maintenir votre infrastructure de manière fiable et prévisible. La sortie d'Ansible est votre principal outil de feedback ; apprenez à l'écouter attentivement.