Tests et debugging
Un playbook qui "fonctionne" n'est pas forcément correct. Il peut laisser des changements non voulus, ne pas être idempotent, ou échouer silencieusement sur certains hôtes. Tester et déboguer sont des compétences à part entière dans Ansible.
Vérifications avant exécution
# Vérification YAML et Jinja2 sans contacter les hôtes
ansible-playbook site.yml --syntax-check
# Dry-run : simule sans appliquer
ansible-playbook site.yml --check
# Dry-run avec diff des fichiers modifiés
ansible-playbook site.yml --check --diff
# Combiner avec --limit pour tester sur un seul hôte
ansible-playbook site.yml --check --diff --limit web01.example.com--check n'est pas parfait : certains modules ne supportent pas le mode check et retournent toujours changed. D'autres tâches qui dépendent du résultat d'une tâche précédente peuvent échouer en mode check puisque la tâche précédente n'a rien modifié réellement.
Niveaux de verbosité
-v # résultats des tâches
-vv # contenu des fichiers copiés/templates
-vvv # commandes SSH, arguments des modules
-vvvv # connexions réseau, authentification SSHEn pratique, -vv suffit pour la plupart des problèmes. -vvv est utile pour diagnostiquer les problèmes SSH.
Module debug
# Afficher la valeur d'une variable
- ansible.builtin.debug:
var: ansible_default_ipv4.address
# Afficher un message calculé
- ansible.builtin.debug:
msg: "Version installée : {{ app_version.stdout }}"
# Afficher plusieurs variables
- ansible.builtin.debug:
var: hostvars[inventory_hostname]
# Conditionnel sur verbosité
- ansible.builtin.debug:
msg: "Config : {{ config }}"
verbosity: 2 # affiché seulement avec -vv ou plusModule assert
Permet d'ajouter des assertions dans un playbook, utile pour valider des prérequis ou tester des états intermédiaires :
- name: Vérifier que la mémoire est suffisante
ansible.builtin.assert:
that:
- ansible_memtotal_mb >= 2048
- ansible_processor_vcpus >= 2
fail_msg: "Ce serveur ne dispose pas des ressources minimales requises"
success_msg: "Ressources OK : {{ ansible_memtotal_mb }}MB RAM, {{ ansible_processor_vcpus }} vCPU"
- name: Vérifier l'état du service après déploiement
ansible.builtin.assert:
that:
- health_check.status == 200
- health_check.json.status == "ok"
fail_msg: "L'application ne répond pas correctement après déploiement"Module fail
- name: Bloquer le déploiement en prod sans approbation
ansible.builtin.fail:
msg: "Déploiement en production non autorisé. Passer par le pipeline CI/CD."
when:
- target_env == "production"
- not approved | default(false)Introduction à Molecule
Molecule est le framework de test de rôles Ansible. Il permet de tester un rôle dans un environnement isolé (Docker, Vagrant, VM dédiée) de façon reproductible.
pip install molecule molecule-plugins[docker]
# Initialiser un scénario de test pour un rôle existant
cd roles/nginx
molecule init scenario
# Structure créée
# molecule/
# └── default/
# ├── molecule.yml # configuration du scénario
# ├── converge.yml # playbook de test
# └── verify.yml # assertions (optionnel)# Exécuter le cycle de test complet
molecule test
# Étapes individuelles
molecule create # créer les instances de test
molecule converge # appliquer le rôle
molecule verify # exécuter les vérifications
molecule destroy # détruire les instances
# Debugging interactif
molecule login # SSH dans l'instance de testMolecule teste automatiquement l'idempotence : après converge, il relance le playbook et vérifie que le résultat est changed=0. Les tests avancés avec Testinfra et les scénarios multi-plateformes sont couverts dans la section Expertise.
ansible-lint
pip install ansible-lint
# Analyser le projet courant
ansible-lint
# Analyser un fichier spécifique
ansible-lint playbooks/site.ymlansible-lint détecte les anti-patterns : tâches sans name, usage de shell quand un module existe, références à des modules dépréciés, indentation incorrecte. L'intégrer en pre-commit hook garantit une qualité minimale sur chaque commit.