Le mode `--check` (dry run) pour tester sans appliquer

Tester avant d'agir : la puissance prédictive du mode `--check`

Dans le monde de l'automatisation, surtout lorsqu'on gère des configurations critiques ou des déploiements sur de multiples serveurs, la capacité à prévoir l'impact d'un script avant son exécution réelle est inestimable. Ansible offre cette capacité grâce à son mode "check", également connu sous le nom de "dry run" (simulation). En utilisant l'option --check (ou sa forme courte -C) avec la commande ansible-playbook, vous demandez à Ansible de parcourir votre playbook et de rapporter les changements qu'il aurait effectués, sans réellement modifier quoi que ce soit sur les systèmes cibles.

Ce mode est un outil essentiel pour la validation des playbooks, la détection précoce d'erreurs de logique, et pour gagner en confiance avant d'appliquer des changements, en particulier dans des environnements de production. Il permet de s'assurer que le playbook se comporte comme prévu et qu'il ne causera pas d'effets de bord indésirables.

Cette section explore en détail le fonctionnement du mode `--check`, ses avantages, ses limitations, et comment l'intégrer efficacement dans votre flux de travail Ansible.

Comprendre le fonctionnement et les bénéfices du mode `--check`

Lorsque vous exécutez un playbook avec l'option --check, Ansible se connecte toujours aux noeuds gérés et exécute les modules spécifiés dans vos tâches. Cependant, la plupart des modules Ansible sont conçus pour supporter ce mode. Lorsqu'ils sont exécutés en mode check, au lieu d'appliquer les changements (par exemple, installer un paquet, modifier un fichier, redémarrer un service), ils se contentent de vérifier si un changement serait nécessaire pour atteindre l'état désiré.

Par exemple, si une tâche vise à s'assurer qu'un paquet est installé et que le paquet est déjà présent, le module rapportera ok. Si le paquet n'est pas installé, en mode check, il rapportera changed (indiquant qu'une installation aurait eu lieu) mais ne procédera pas à l'installation réelle. La sortie d'Ansible en mode check reflète ces changements potentiels, vous donnant un aperçu clair de ce qui se passerait lors d'une exécution normale.

• Validation des playbooks : C'est le moyen le plus simple de vérifier la logique de votre playbook et de s'assurer qu'il cible les bons hôtes et effectue les bonnes actions.
• Prévention des erreurs : Il aide à identifier les erreurs potentielles ou les conséquences inattendues avant qu'elles n'impactent vos systèmes. Vous pourriez découvrir qu'une tâche modifierait plus de fichiers que prévu, ou redémarrerait un service critique à un mauvais moment.
• Confiance accrue : Exécuter un playbook en mode check avant de l'appliquer "pour de vrai" donne une plus grande assurance, surtout pour des opérations complexes ou sur des environnements sensibles.
• Démonstration et communication : Il peut être utilisé pour montrer à d'autres membres de l'équipe ou à des responsables quels changements un playbook va apporter.
• Idempotence : Le mode check est un excellent moyen de vérifier l'idempotence de vos tâches. Si vous exécutez un playbook en mode check une première fois et qu'il signale des changements, une seconde exécution en mode check (sans aucune modification manuelle des systèmes entre-temps) devrait idéalement ne plus signaler ces mêmes changements (ou signaler ok), car l'état désiré aurait été atteint.

Pour utiliser le mode check, ajoutez simplement l'option à votre commande :

ansible-playbook mon_playbook.yml --check

ansible-playbook mon_playbook.yml -C

Interpréter la sortie en mode `--check`

La sortie d'un playbook exécuté avec --check ressemble beaucoup à une exécution normale, mais le statut des tâches est interprété différemment :

• ok : Signifie que la tâche a été exécutée et que l'état actuel du système correspond déjà à l'état désiré. Aucun changement n'aurait été nécessaire.
• changed : C'est l'indicateur clé en mode check. Il signifie que si le playbook avait été exécuté normalement, cette tâche aurait modifié l'état du système pour atteindre l'état désiré. Aucun changement réel n'a été appliqué.
• failed : La tâche aurait échoué même en exécution normale (par exemple, une erreur de syntaxe dans un template, un service dépendant non trouvé).
• skipped : La tâche a été ignorée en raison d'une conditionnelle (when) non satisfaite.
• unreachable : L'hôte n'a pas pu être contacté.

Il est important de noter que la mention DRY RUN ou CHECK MODE apparaît souvent en début de sortie pour rappeler que vous êtes en mode simulation. Le résumé final du playbook indiquera également le nombre de changements qui auraient été effectués.

Par exemple, si vous avez une tâche pour installer `nginx` et qu'il n'est pas installé :

- name: Installer Nginx
  apt:
    name: nginx
    state: present

Limitations et considérations importantes du mode `--check`

Bien que le mode --check soit extrêmement utile, il a certaines limitations qu'il est important de connaître :

• Support par les modules : Tous les modules Ansible ne supportent pas le mode check de la même manière. La grande majorité des modules principaux (comme apt, copy, template, service, file) le gèrent très bien. Cependant, certains modules, en particulier ceux qui exécutent des commandes arbitraires (command, shell, script), peuvent ne pas être capables de prédire avec précision si un changement se produira, ou pire, pourraient quand même effectuer des actions (si la commande exécutée n'est pas elle-même idempotente ou consciente du mode check). Lisez toujours la documentation du module pour connaître son comportement en mode check. Certains modules ont un paramètre spécifique comme _ansible_check_mode que vous pouvez utiliser dans vos scripts pour les rendre conscients du dry run.
• Dépendances entre tâches : Le mode check évalue chaque tâche isolément. Si une tâche dépend du résultat d'une tâche précédente qui aurait dû créer un fichier ou un utilisateur, le mode check pourrait ne pas le simuler correctement. Par exemple, si la tâche 1 crée un répertoire et que la tâche 2 y copie un fichier, en mode check, la tâche 1 ne créera pas le répertoire. La tâche 2 pourrait alors signaler une erreur (ou un changement incorrect) car le répertoire n'existe pas.
• Faits collectés (gather_facts) : La collecte des faits se produit normalement en mode check, car ces informations sont souvent nécessaires pour évaluer les conditions des tâches.
• Handlers : Les handlers ne sont pas déclenchés en mode check, car les tâches qui les notifieraient ne font que signaler un état changed sans effectuer réellement le changement.
• Certaines opérations ne sont pas simulables : Des actions très complexes ou dépendant d'états externes difficiles à simuler pourraient ne pas être prédites avec une fiabilité de 100%.

Malgré ces limitations, le mode --check reste un outil de première ligne pour la validation. Pour des tests plus approfondis, des environnements de staging ou des outils de test d'infrastructure comme Molecule sont recommandés.

En intégrant systématiquement l'utilisation de ansible-playbook --check dans votre routine avant toute application réelle, vous réduirez considérablement les risques d'erreurs et augmenterez la fiabilité de vos automatisations.