Ansible est un outil très puissant qui vous permet d'automatiser une grande variété de plates-formes sur des serveurs, des clouds, des réseaux, des conteneurs, etc.
Souvent, vous pourrez automatiser ce que vous voulez en réutilisant simplement les rôles et collections existants.
Et vous pouvez choisir parmi de nombreux modules que vous pouvez utiliser dans vos playbooks.
Mais lorsque vous commencerez à développer et à tester des playbooks plus complexes, vous aurez éventuellement besoin de méthodes de dépannage. Des choses comme :
- Vérification du flux des tâches Ansible.
- Confirmation des types de données de vos variables.
- Même s'arrêter à un moment donné pour inspecter leurs valeurs.
Certains des conseils abordés dans cet article ne s'appliqueront qu'à l'exécution d'Ansible via la ligne de commande. D'autres sont également valables lors de l'exécution à partir d'Ansible Tower.
1. Votre environnement et vos paramètres Ansible
Si vous devez déterminer pourquoi quelque chose ne se comporte pas comme prévu dans vos playbooks, il est généralement préférable de commencer par vérifier votre environnement Ansible.
Quels versions et chemins des binaires Ansible et Python utilisez-vous ?
Si vous avez ajouté des packages de système d'exploitation ou des modules Python requis par vos playbooks, l'interpréteur Ansible les "voit-il" ?
Vous pouvez obtenir ces informations de base de différentes manières. À partir de la ligne de commande, exécutez le ansible --version commande.
❯ ansible --version
ansible 2.9.10
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/admin/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.6/site-packages/ansible
executable location = /usr/bin/ansible
python version = 3.6.8 (default, Mar 18 2021, 08:58:41) [GCC 8.4.1 20200928 (Red Hat 8.4.1-1)]
Vous pouvez obtenir les mêmes informations en exécutant d'autres commandes Ansible telles que ansible-playbook ou ansible-config avec le --version option.
Dans Ansible Tower, ces informations sont affichées si le modèle de tâche est exécuté avec VERBOSITY 2 (plus détaillé) ou supérieur.
Outre les versions et l'emplacement des binaires Ansible et Python, il est toujours bon de revérifier les chemins utilisés pour les modules, y compris si l'exécution utilise un ansible.cfg fichier qui n'est pas la valeur par défaut (c'est-à-dire, pas /etc/ansible/ansible.cfg ).
Pour étudier les options provenant d'un ansible.cfg personnalisé fichier, vous pouvez exécuter ce qui suit à partir de la ligne de commande :
❯ ansible-config dump --only-changed
DEFAULT_BECOME(/home/admin/ansible/ansible.cfg) = True
DEFAULT_BECOME_USER(/home/admin/ansible/ansible.cfg) = root
DEFAULT_FORKS(/home/admin/ansible/ansible.cfg) = 10
DEFAULT_HOST_LIST(/home/admin/ansible/ansible.cfg) = ['/home/admin/ansible/inventory']
DEFAULT_ROLES_PATH(/home/admin/ansible/ansible.cfg) = ['/home/admin/ansible/roles']
HOST_KEY_CHECKING(/home/admin/ansible/ansible.cfg) = False Comme son nom l'indique, cela listera les paramètres qui sont différents parmi ceux par défaut.
2. Exécution en mode verbeux
L'exécution des playbooks en mode débogage peut être la prochaine étape pour obtenir plus de détails sur ce qui se passe dans les tâches et les variables.
Depuis la ligne de commande, vous pouvez ajouter -v (ou -vv , -vvv , -vvvv , -vvvvv ). Les niveaux de verbosité les plus élevés peuvent parfois contenir trop d'informations, il est donc préférable d'augmenter progressivement en plusieurs exécutions jusqu'à ce que vous obteniez ce dont vous avez besoin.
Le niveau 4 peut aider à résoudre les problèmes de connectivité et le niveau 5 est utile pour les problèmes WinRM.
Depuis Tower, vous pouvez sélectionner la VERBOSITY niveau de la définition du modèle de tâche.
Remarque :N'oubliez pas de désactiver le mode de débogage après avoir résolu la situation, car les informations détaillées ne sont utiles que pour le dépannage.
De plus, en mode débogage, les valeurs de certaines variables (mots de passe par exemple) seront affichées sauf si vous utilisez le no_log option dans la tâche, donc effacez les sorties lorsque vous avez terminé.
3. Utiliser le débogage pour afficher les variables
Si vous avez une bonne idée de où les problèmes pourraient être, vous pouvez utiliser une approche plus chirurgicale :affichez uniquement les variables que vous devez voir.
(...)
- name: Display the value of the counter
debug:
msg: "Counter={{ counter }} / Data type={{ counter | type_debug }}"
(...)
TASK [Display the value of the counter] ****************************************************************************
ok: [node1] => {
"msg": "Counter=42 / Data type=AnsibleUnicode"
}
Ceci c'est pourquoi je n'ai pas pu incrémenter le compteur. Le filtre type_debug indique que le type de données est texte et non int comme je le supposais.
[ Vous pourriez également aimer : Guide de démarrage rapide d'Ansible pour les administrateurs système Linux ]
4. S'assurer que les vars ont le bon contenu et le bon type de données
Vous pouvez utiliser l'affirmation module pour confirmer que les variables ont le contenu/type attendu et faire échouer la tâche si quelque chose ne va pas.
Le playbook suivant illustre cela :
---
- name: Assert examples
hosts: node1
gather_facts: no
vars:
var01: 13
tasks:
- debug:
msg: "Parameter 01 is {{ (param01 | type_debug) }}"
- name: Make sure that we have the right type of content before proceeding
assert:
that:
- "var01 is defined"
- "(var01 | type_debug) == 'int' "
- "param01 is defined "
- "(param01 | type_debug) == 'int' " Si j'exécute le playbook à partir de la ligne de commande, sans fournir les extra-vars :
❯ ansible-playbook xassert.yml
PLAY [Assert examples] ****************************************************************************
TASK [debug] ****************************************************************************
ok: [node1] => {
"msg": "Parameter 01 is AnsibleUndefined"
}
TASK [Make sure that we have the right type of content before proceeding] ****************************************************************************
fatal: [node1]: FAILED! => {
"assertion": "param01 is defined ",
"changed": false,
"evaluated_to": false,
"msg": "Assertion failed"
}
PLAY RECAP ****************************************************************************
node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 Si j'exécute le playbook à partir de la ligne de commande, avec la variable supplémentaire :
❯ ansible-playbook xassert.yml -e "param01=99"
PLAY [Assert examples] ****************************************************************************
TASK [debug] ****************************************************************************
ok: [node1] => {
"msg": "Parameter 01 is str"
}
TASK [Make sure that we have the right type of content before proceeding] ****************************************************************************
fatal: [node1]: FAILED! => {
"assertion": "(param01 | type_debug) == 'int' ",
"changed": false,
"evaluated_to": false,
"msg": "Assertion failed"
}
PLAY RECAP ****************************************************************************
node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 Voir le type de données venir en tant que str a été une surprise pour moi, mais il y a une explication et une solution ici.
De plus, si vous exécutez le même playbook à partir de Tower, en passant le paramètre en tant qu'extra-vars ou en tant que champ d'une enquête, le type de données du paramètre sera int .
Oui, cela peut être délicat... mais si vous savez ce qu'il faut rechercher, ces "fonctionnalités" ne vous poseront aucun problème.
5. Obtenir une liste des faits et des variables
Que vous ayez défini des variables dans votre inventaire (pour les hôtes et/ou les groupes) ou que vous ayez créé et attribué des variables supplémentaires lors de l'exécution de votre playbook, il peut être utile à un moment donné d'inspecter leurs valeurs.
---
- name: vars
hosts: node1,node2
tasks:
- name: Dump vars
copy:
content: "{{ hostvars[inventory_hostname] | to_nice_yaml }}"
dest: "/tmp/{{ inventory_hostname }}_vars.txt"
delegate_to: control
- name: Dump facts
copy:
content: "{{ ansible_facts | to_nice_yaml }}"
dest: "/tmp/{{ inventory_hostname }}_facts.txt"
delegate_to: control Cela enregistrera les variables et les faits (si vous rassemblez des faits) dans des fichiers individuels que vous pourrez analyser.
Pour l'exécution de la ligne de commande, j'ai délégué la tâche à mon hôte de contrôle (localhost) pour que les fichiers soient enregistrés localement au lieu d'avoir les fichiers enregistrés dans chaque nœud séparément. Si vous partez de Tower, vous devrez également en sélectionner un serveur où stocker les fichiers (sauf si vous n'avez qu'un seul nœud cible et que cela ne vous dérange pas d'y analyser le fichier).
6. Utilisation du débogueur de tâches pour le dépannage à partir de la ligne de commande
Vous pouvez également utiliser le débogueur Ansible pour exécuter des playbooks en mode étape par étape et pour examiner le contenu des variables et des arguments de manière interactive.
En plus de cela, vous pouvez également modifier les valeurs des variables à la volée et poursuivre l'exécution.
Le débogueur peut être activé au niveau de la tâche ou au niveau du jeu, comme dans l'exemple suivant :
---
- name: Example using debugger
hosts: localhost
gather_facts: no
vars:
radius: "5.3"
pi: "3.1415926535"
debugger: on_failed
tasks:
- name: Calculate the area of a circle
debug:
msg:
- "Radius.............: {{ radius }}"
- "pi................: {{ pi }}"
- "Area of the circle: {{ (pi * (radius * radius)) }}" Spoiler alert :j'ai défini les variables comme des chaînes, ce qui provoquera évidemment une erreur lorsque j'essaierai de faire le calcul.
❯ ansible-playbook xdebugger.yml
PLAY [Example using debugger] ****************************************************************************
TASK [Calculate the area of a circle] ****************************************************************************
fatal: [localhost]: FAILED! => {"msg": "Unexpected templating type error occurred on (Area of the circle: {{ (pi * (radius * radius)) }}): can't multiply sequence by non-int of type 'AnsibleUnicode'"}
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['pi']
'3.1415926535'
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['radius']
'5.3'
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['pi']=3.1415926535
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['radius']=5.3
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['radius']
5.3
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['pi']=3.1415926535
[localhost] TASK: Calculate the area of a circle (debug)> redo
ok: [localhost] => {
"msg": [
"Radius............: 5.3",
"pi................: 3.1415926535",
"Area of the circle: 88.247337636815"
]
}
PLAY RECAP ****************************************************************************
localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Que s'est-il passé ici :
- Au départ, la tâche a échoué, se plaignant des variables non int.
- Le débogueur a été appelé.
- J'ai utilisé l'impression (p ) commande pour afficher les valeurs des variables.
- Dans ce cas, je savais que le problème était dans le type de données, mais on pourrait penser que les valeurs sont correctes (si l'on ne fait pas attention aux guillemets autour des valeurs).
- Plus tard, j'ai mis à jour le contenu des variables, en leur attribuant des numéros.
- Ensuite, j'ai utilisé le
redocommande pour ré-exécuter la tâche avec les nouvelles valeurs, et elle s'est terminée avec succès.
C'était un scénario simple, car nous savons que personne utiliserait vraiment Ansible pour calculer l'aire d'un cercle. Mais dans une situation plus complexe, il pourrait être utile de trouver le contenu d'une variable au milieu d'une longue exécution de playbook, et de pouvoir continuer à partir de ce point sans recommencer à zéro.
[ Obtenez cet ebook gratuit :Gérer vos clusters Kubernetes pour les nuls. ]
Récapitulez
L'intégration d'un bon arsenal d'options de dépannage peut vous aider à identifier plus rapidement les problèmes dans vos playbooks Ansible. Selon où vous en êtes dans l'enquête, certaines méthodes sont plus adaptées.
Par exemple, lorsque vous essayez simplement d'avoir une idée de quoi peut être erroné, et où , vous pouvez commencer par augmenter progressivement le niveau de débogage.
Une fois que vous avez une meilleure idée de l'emplacement du problème, il peut être pratique de diminuer le niveau de débogage (afin d'avoir moins de sortie devant vous) et d'utiliser des options spécifiques à la tâche que vous analysez.
Le dépannage d'Ansible peut être délicat, mais en utilisant une approche méthodique combinée aux outils de résolution de problèmes intégrés, vous pouvez vous faciliter la tâche. Confirmez l'environnement Ansible et le flux de tâches, puis recherchez les types de données appropriés, et enfin envisagez de faire une pause et de parcourir chaque tâche.