Commandes Ad-Hoc : actions rapides et ponctuelles

Les commandes Ad-Hoc : l'outil de l'administrateur pour des interventions ciblées

Bien que les playbooks soient la méthode privilégiée pour l'automatisation structurée et reproductible avec Ansible, il existe des situations où vous avez besoin d'exécuter une tâche simple et rapide sur un ou plusieurs noeuds gérés sans pour autant créer un playbook complet. C'est là qu'interviennent les commandes Ad-Hoc d'Ansible. Le terme "Ad-Hoc" signifie "pour cela" ou "à cette fin spécifique", indiquant que ces commandes sont destinées à des actions ponctuelles et non récurrentes.

Les commandes Ad-Hoc utilisent la ligne de commande `ansible` (à ne pas confondre avec `ansible-playbook`) pour invoquer directement un module Ansible sur un ensemble d'hôtes cibles de votre inventaire. Elles sont particulièrement utiles pour des tâches comme la vérification de l'état d'un service, la collecte d'informations (uptime, espace disque), le redémarrage rapide d'un serveur, ou la copie d'un fichier unique.

Imaginez que vous souhaitiez rapidement vérifier si tous vos serveurs web répondent à un ping, ou connaître l'espace disque disponible sur vos serveurs de base de données. Plutôt que d'écrire un petit playbook pour chacune de ces actions, une commande Ad-Hoc vous permet d'obtenir le résultat immédiatement. C'est un excellent moyen d'explorer votre infrastructure, de dépanner des problèmes ou d'effectuer des modifications mineures à la volée.

Syntaxe et utilisation des commandes Ad-Hoc

La syntaxe de base d'une commande Ad-Hoc est la suivante :

ansible [pattern_hotes] -i [fichier_inventaire] -m [nom_module] -a "[arguments_module]" [options_ansible]

Décortiquons les principaux éléments :

• `ansible`: La commande elle-même.
• `[pattern_hotes]`: Spécifie les hôtes ou groupes d'hôtes de votre inventaire sur lesquels la commande doit s'exécuter. Cela peut être `all`, un nom de groupe, un nom d'hôte spécifique, ou un pattern plus complexe (ex: `webservers:!prod`, `dbservers:&staging`).
• `-i [fichier_inventaire]`: (Optionnel si l'inventaire est à l'emplacement par défaut) Spécifie le chemin vers votre fichier d'inventaire. Si omis, Ansible cherche `/etc/ansible/hosts` puis un fichier `inventory` ou `hosts` dans le répertoire courant.
• `-m [nom_module]`: Spécifie le module Ansible à utiliser pour cette commande. Si omis, le module `command` est utilisé par défaut, ce qui est souvent déconseillé au profit de modules plus spécifiques et idempotents.
• `-a "[arguments_module]"`: (Optionnel) Fournit les arguments à passer au module. Les arguments sont généralement passés sous forme d'une chaîne de caractères unique, avec des paires clé=valeur si nécessaire, comme vous le feriez dans la forme condensée d'une tâche de playbook.
• `[options_ansible]`: D'autres options Ansible peuvent être ajoutées, telles que :
  • `-u [utilisateur_distant]`: Pour spécifier l'utilisateur avec lequel se connecter aux noeuds gérés.
  • `-b` ou `--become`: Pour exécuter la commande avec des privilèges élevés (sudo).
  • `--become-user [utilisateur_sudo]`: Pour spécifier l'utilisateur à devenir avec `become`.
  • `-K` ou `--ask-become-pass`: Pour demander le mot de passe sudo.
  • `-k` ou `--ask-pass`: Pour demander le mot de passe de connexion SSH (si l'authentification par clé n'est pas configurée).
  • `-f [nombre_forks]` ou `--forks=[nombre_forks]`: Pour définir le nombre de processus parallèles à utiliser (par défaut 5).
  • `-v`, `-vv`, `-vvv`: Pour augmenter le niveau de verbosité de la sortie.

Exemples pratiques de commandes Ad-Hoc

Voici quelques exemples concrets pour illustrer la puissance et la simplicité des commandes Ad-Hoc :

Le module `ping` est idéal pour cela. Il ne s'agit pas d'un ping ICMP, mais d'un test pour vérifier qu'Ansible peut se connecter au noeud géré, y exécuter du Python, et recevoir une réponse.

ansible all -m ping

Si vous avez un inventaire nommé `myinventory.ini` :

ansible all -i myinventory.ini -m ping

Le module `command` (par défaut si `-m` est omis, mais il est bon de l'expliciter) exécute une commande simple. Le module `shell` permet d'utiliser des fonctionnalités du shell comme les pipes et les redirections.

ansible webservers -m command -a "uptime"
ansible dbservers -m shell -a "df -h | grep /data"

Le module `setup` collecte des informations détaillées (facts) sur les noeuds gérés (OS, adresses IP, mémoire, CPU, etc.).

ansible appservers -m setup

Vous pouvez filtrer les faits pour n'afficher que certaines informations :

ansible appservers -m setup -a "filter=ansible_distribution*"

Utilisez le module `package` ou ses équivalents spécifiques (`apt`, `yum`, `dnf`).

# S'assurer que 'htop' est installé sur tous les serveurs Debian/Ubuntu
ansible debian_servers -m apt -a "name=htop state=present" -b

# Vérifier la version installée de 'openssl' sur les serveurs Red Hat/CentOS
ansible rhel_servers -m yum -a "name=openssl state=present list=installed" | grep openssl

Notez l'utilisation de `-b` pour `become` (sudo) car l'installation de paquets nécessite des privilèges élevés.

# Redémarrer le service Nginx sur les serveurs web
ansible webservers -m service -a "name=nginx state=restarted" -b

# Vérifier le statut du service cron sur tous les hôtes
ansible all -m service -a "name=cron state=started enabled=yes" -b

Le module `copy` permet de transférer des fichiers du noeud de contrôle vers les noeuds gérés.

# Copier un fichier de configuration local vers tous les serveurs d'application
ansible appservers -m copy -a "src=/local/path/to/app.conf dest=/etc/app/app.conf owner=appuser group=appgroup mode=0644" -b

Ces exemples ne sont qu'un aperçu. Presque tous les modules Ansible peuvent être utilisés avec des commandes Ad-Hoc, ce qui en fait un outil extrêmement polyvalent pour l'administration quotidienne. Cependant, dès que vos actions deviennent plus complexes, répétitives, ou nécessitent une logique conditionnelle, il est préférable de les formaliser dans un playbook.