Commandes ad-hoc Ansible et mode check : un premier passage sûr sur un parc de machines

Objectif

Vérifier qu'Ansible peut joindre un ensemble d'hôtes gérés, puis prévisualiser une modification sur ces hôtes avant de l'appliquer réellement, en n'utilisant que des commandes ad-hoc et le mode check. Aucun playbook n'est nécessaire pour cet aperçu.

Prérequis

Ansible installé sur le nœud de contrôle ; un fichier d'inventaire listant les hôtes et groupes cibles ; un accès SSH (ou WinRM pour les cibles Windows) fonctionnel et, pour les modifications privilégiées, une méthode become telle que sudo configurée pour l'utilisateur de connexion.

Étapes

1. Vérifier la connectivité et la présence de Python sur chaque nœud géré : ansible all -m ping. all est le groupe intégré d'Ansible qui couvre tous les hôtes de l'inventaire ; un hôte en bon état répond par un résultat pong (les hôtes Windows utilisent ansible.windows.win_ping). La syntaxe générale des commandes ad-hoc d'Ansible est documentée ainsi : ansible [pattern] -m [module] -a "[module options]", où le motif (pattern) sélectionne les hôtes et -m indique le module à exécuter.
2. Restreindre à un sous-ensemble avant de tenter quoi que ce soit de plus risqué : ansible webservers --limit "*.example.com" -m ping, ou cibler un seul hôte par son nom. --limit restreint davantage un motif déjà résolu, ce qui est plus sûr que de modifier l'inventaire pour tester sur moins d'hôtes.
3. Prévisualiser une vraie modification sans l'appliquer : ansible webservers -b -m ansible.builtin.service -a "name=cron state=started" --check. Sans -b, l'aperçu s'exécute sans privilèges et peut différer de l'exécution réelle. La documentation d'Ansible indique que « In check mode, Ansible runs without making any changes on remote systems » (en mode check, Ansible s'exécute sans rien modifier sur les systèmes distants) ; les modules qui prennent en charge le mode check signalent les changements qu'ils auraient effectués au lieu de les effectuer, tandis que les modules sans prise en charge du mode check « report nothing and do nothing » (ne signalent rien et ne font rien).
4. Ajouter --diff en plus de --check pour voir le contenu avant/après pour les modules qui le prennent en charge (principalement ceux qui manipulent des fichiers). La documentation avertit que le mode diff « produces a large amount of output » (produit un volume de sortie important) et suggère de procéder hôte par hôte (--limit host1) ; les diffs peuvent en outre afficher des secrets contenus dans des fichiers.
5. Pour toute commande nécessitant des privilèges élevés sur la cible, ajouter --become (-b) : la documentation d'Ansible décrit become comme utilisant « existing privilege escalation systems to execute tasks with root privileges or with another user's permissions » (les systèmes d'élévation de privilèges existants pour exécuter des tâches avec les privilèges root ou avec les permissions d'un autre utilisateur), s'appuyant sur des outils tels que sudo, su ou doas selon la configuration de l'hôte.
6. Une fois seulement que l'aperçu en mode check semble correct, relancer la même commande sans --check pour l'appliquer, idéalement d'abord sur un petit groupe canari, toujours en la restreignant avec --limit.

Résultat attendu

ansible all -m ping renvoie un pong pour chaque hôte joignable ; l'exécution avec --check --diff montre précisément la modification qu'un module effectuerait, sans qu'aucune modification n'ait lieu ; l'exécution réelle qui suit correspond à ce que l'aperçu a montré.

Limites et base de vérification

Le mode check « is just a simulation » (n'est qu'une simulation) : dans les playbooks, les tâches dont les conditions reposent sur les résultats enregistrés de tâches précédentes ne produisent pas de sortie pertinente. Le module ad-hoc par défaut, command, ne peut pas prédire le résultat d'une commande arbitraire et est ignoré sous --check. Un module sans prise en charge du mode check ne fait rien sous --check, ce qui peut passer pour « rien n'a besoin de changer » ; il convient de vérifier l'attribut de prise en charge check_mode dans la documentation du module avant de se fier à un aperçu sans changement. Les commandes ad-hoc ne sont pas elles-mêmes des artefacts de suivi idempotents : rien n'atteste qu'une commande ad-hoc donnée a été exécutée, hormis l'historique du shell et la journalisation éventuellement configurée sur le nœud de contrôle.