1.4 : Premier contact : commandes ad-hoc (ansible -m ping, -a)

Avant d’écrire la moindre fiche de vol (playbook), on peut déjà donner des instructions ponctuelles à la flotte, directement en ligne de commande. C’est ce qu’on appelle une commande ad-hoc : un ordre unique, donné une fois, sans rien enregistrer nulle part.

C’est l’équivalent radio du contrôleur qui lance « Vol 204, montez à 3000 pieds » sans avoir besoin d’un plan de vol écrit. Pratique pour une vérification rapide ou une action ponctuelle, mais pas fait pour être répété ou versionné — c’est le rôle des playbooks, qu’on verra en section 3.

La structure d’une commande ad-hoc

ansible <cible> -i <inventaire> -m <module> -a "<arguments>"

• <cible> : quels hôtes contacter (all, un groupe, un nom de machine…)
• -i : le fichier d’inventaire (ou une liste tapée directement, comme en 1.3)
• -m : le module à utiliser (l’action à effectuer)
• -a : les arguments de ce module

Le module ping : vérifier le contact radio

On l’a déjà croisé en 1.3. Il ne fait rien d’autre que vérifier qu’Ansible arrive à se connecter et à exécuter du Python sur la machine cible.

ansible all -i inventaire.yaml -m ping

ansible-client1 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Notez le "changed": false. On reverra ce champ tout au long de la formation : c’est lui qui indique si Ansible a dû modifier quelque chose sur la machine. Ici, un simple ping ne change rien — logique.

Le module command : exécuter une commande

Par défaut, sans préciser de module, Ansible utilise command. On peut vérifier l’espace disque sur toute la flotte en une seule instruction :

ansible all -i inventaire.yaml -m command -a "df -h"

Ou, en version raccourcie (le module command étant celui par défaut) :

ansible all -i inventaire.yaml -a "uptime"

⚠️ Le module command n’exécute pas de commande shell complète (pas de pipe |, pas de redirection , pas de variables d’environnement). Pour ça, il existe le module shell — mais on l’évite dès qu’un module dédié existe, justement pour profiter de l’idempotence (le module shell ne sait jamais dire si quelque chose a réellement changé).

Cibler un groupe précis

Si votre inventaire contient des groupes (on détaille ça en section 2), vous pouvez cibler uniquement une partie de la flotte :

ansible webservers -i inventaire.yaml -m ping

Exemple utile : vérifier un paquet installé

ansible all -i inventaire.yaml -m apt -a "name=curl state=present" --become

Ici, on utilise le vrai module apt plutôt que command apt install curl — c’est ce module qui va vérifier si curl est déjà installé avant d’agir, et qui va donc afficher changed: false s’il l’est déjà. C’est votre première rencontre concrète avec l’idempotence, avant qu’on l’explique en détail en section 3.

--become demande l’élévation de privilèges (l’équivalent de sudo) — indispensable ici puisque l’installation de paquets nécessite les droits root.

Ce qu’il faut retenir

Les commandes ad-hoc sont parfaites pour :

• une vérification rapide sur toute la flotte ;
• un dépannage ponctuel ;
• tester un module avant de l’intégrer dans un playbook.

Elles ne remplacent pas les playbooks : rien n’est enregistré, rien n’est rejouable, rien n’est versionnable dans Git. On les utilise au quotidien, mais l’automatisation sérieuse, elle, passe toujours par un playbook.

Dans la prochaine leçon, on aborde un cas particulier : comment contacter un avion qui n’a même pas encore Python à bord, avec les commandes RAW.