Un playbook qui échoue vous dit rarement pourquoi du premier coup. Cette section couvre les outils qui répondent à la question : augmenter la verbosité pour voir ce qu'Ansible envoie vraiment, ouvrir un débogueur au moment de l'échec plutôt que de tout rejouer, et traquer les tâches qui se disent modifiées à chaque exécution alors qu'elles ne changent rien.
Prérequis
Section intitulée « Prérequis »Il faut avoir écrit et lancé plusieurs playbooks, ce que couvrent les sections Premiers pas et Écrire du code. On ne diagnostique bien que ce dont on connaît le fonctionnement normal.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Doser la verbosité pour obtenir l'information utile sans noyer la sortie, et savoir à quel niveau apparaît quoi.
- Ouvrir un débogueur au moment précis de l'échec, corriger une valeur et relancer la tâche seule.
- Diagnostiquer une idempotence cassée, en identifiant la tâche qui se déclare modifiée sans raison.
- Mesurer où part le temps d'un playbook, avant de chercher à l'accélérer.
Un réflexe à garder de cette section : une trace verbeuse contient vos variables, donc potentiellement vos secrets. Elle ne se colle pas dans un ticket public sans relecture.
Diagnostiquer
Section intitulée « Diagnostiquer »Vérifier vos acquis
Section intitulée « Vérifier vos acquis »Cette section n'a pas encore sa page de quiz dédiée, mais ses 50 questions existent déjà dans la banque commune.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Débogueur interactif : Le prompt qui s'ouvre sur la tâche en échec, avec ses variables et la possibilité de la rejouer.
- Idempotence et tuning : Le playbook qui affiche changed à chaque run, et les trois leviers qui divisent son temps d'exécution.