On a déjà croisé --check et --diff en 3.3 pour vérifier l’idempotence. Cette leçon complète le tableau : comment obtenir plus (ou moins) de détails à l’exécution, et comment lire un résultat qui ne se comporte pas comme prévu.
Une exécution « normale », sans option
Par défaut, ansible-playbook affiche assez peu de détails : le nom de chaque tâche, et son statut (ok, changed, failed, skipped).
ansible-playbook playbook_apache.yaml -i inventaire.yamlPLAY [Installer et démarrer Apache] ********************
TASK [Gathering Facts] *********************************
ok: [nrd-web1]
TASK [Installer Apache] ********************************
changed: [nrd-web1]
TASK [Démarrer et activer Apache] **********************
ok: [nrd-web1]
PLAY RECAP **********************************************
nrd-web1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0Le PLAY RECAP en fin d’exécution est la première chose à regarder : failed=0 et unreachable=0 signifient que tout s’est bien passé. changed=1 vous dit combien de tâches ont réellement modifié quelque chose.
Les niveaux de verbosité : -v à -vvvv
Quand quelque chose ne se passe pas comme prévu, ou que vous voulez simplement comprendre ce qu’Ansible fait exactement en coulisses, on augmente la verbosité :
ansible-playbook playbook_apache.yaml -i inventaire.yaml -v| Niveau | Ce qu’il ajoute |
|---|---|
| (rien) | Statut des tâches uniquement |
-v | Résultat détaillé de chaque tâche (ce qui a été retourné par le module) |
-vv | + informations sur les fichiers/chemins utilisés par Ansible |
-vvv | + détails de connexion SSH |
-vvvv | + détails bas niveau du plugin de connexion (rarement nécessaire) |
En pratique, -v suffit dans 90% des cas pour comprendre pourquoi une tâche affiche changed alors que vous ne vous y attendiez pas — elle vous montre le contenu exact retourné par le module. -vvv devient utile quand le problème n’est même pas dans le playbook, mais dans la connexion SSH elle-même (mauvaise clé, mauvais utilisateur, port bloqué…).
Repérer une tâche qui échoue
Quand une tâche échoue, Ansible arrête l’exécution sur cet hôte précis, mais continue normalement sur les autres hôtes du play :
TASK [Installer Apache] ********************************
fatal: [nrd-web1]: FAILED! => {"msg": "No package matching 'apache-deux' is available"}
PLAY RECAP **********************************************
nrd-web1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0
nrd-web2 : ok=3 changed=1 unreachable=0 failed=0 skipped=0Le message d’erreur (msg) est presque toujours suffisant pour comprendre le problème sans avoir besoin d’augmenter la verbosité — ici, une simple faute de frappe dans le nom du paquet.
--check et --diff : le duo à connaître par cœur
On les a vus en 3.3 pour vérifier l’idempotence, mais ils servent tout autant à anticiper l’effet d’un playbook avant de le lancer pour de vrai — particulièrement utile avant une exécution en production :
ansible-playbook playbook_apache.yaml -i inventaire.yaml --check --diff--check: simule, ne modifie rien réellement.--diff: montre le contenu exact des changements prévus (particulièrement parlant avec les modulestemplateetcopy, vus en section 5, où vous voyez littéralement les lignes ajoutées/supprimées d’un fichier de configuration).
Combiner verbosité et dry-run
Rien n’empêche de cumuler les deux, pour un maximum de visibilité avant une exécution sensible :
ansible-playbook playbook_apache.yaml -i inventaire.yaml --check --diff -vCe qu’il faut retenir
- Le PLAY RECAP en fin d’exécution est le premier réflexe :
failedetunreachabledoivent rester à zéro. -vsuffit généralement à comprendre unchangedinattendu ;-vvvpour un problème de connexion SSH.--check --diffavant une exécution en production, c’est un peu comme demander une confirmation radio avant d’autoriser un décollage : ça coûte quelques secondes, ça évite bien des sueurs froides.