Exécuter vos premières commandes Ad-Hoc

Les commandes Ad-Hoc : l'automatisation à la volée avec Ansible

Les commandes Ad-Hoc d'Ansible sont l'un des moyens les plus directs et rapides d'interagir avec votre infrastructure. Contrairement aux playbooks, qui sont conçus pour des orchestrations complexes et réutilisables, les commandes Ad-Hoc sont destinées à des tâches uniques, simples et souvent exploratoires. Elles vous permettent d'exécuter une seule action sur un ou plusieurs noeuds gérés simultanément, directement depuis votre ligne de commande.

Imaginez devoir vérifier rapidement l'espace disque sur tous vos serveurs web, redémarrer un service spécifique sur un groupe de machines, ou installer un paquet manquant sur un seul hôte. Les commandes Ad-Hoc sont parfaites pour ces scénarios. Elles incarnent la philosophie d'Ansible : la simplicité et l'efficacité, en fournissant un moyen puissant d'agir sans la nécessité d'écrire un script ou un playbook complet.

Dans ce chapitre, nous allons décortiquer la syntaxe de base de la commande ansible pour les opérations Ad-Hoc, puis nous mettrons les mains dans le cambouis avec des exemples concrets. Vous découvrirez comment tester la connectivité, exécuter des commandes shell arbitraires (avec discernement !) et gérer des paquets logiciels, le tout en quelques frappes de clavier.

Syntaxe de la commande `ansible` pour les opérations Ad-Hoc

La structure générale d'une commande Ad-Hoc avec Ansible est la suivante :

ansible  [options]

Décortiquons les éléments principaux :

• ansible : C'est l'exécutable principal d'Ansible pour les commandes Ad-Hoc.
• : Ce motif spécifie les hôtes ou groupes d'hôtes de votre inventaire sur lesquels la commande doit être exécutée. Il peut s'agir d'un nom d'hôte individuel, d'un nom de groupe, du mot-clé all (pour cibler tous les hôtes de l'inventaire), ou de motifs plus complexes (par exemple, webservers:!production pour cibler les serveurs web qui ne sont pas en production).
• [options] : Ce sont diverses options qui modifient le comportement de la commande. Les plus courantes sont :
  • -m ou --module-name : Spécifie le module Ansible à utiliser pour l'action. C'est le coeur de la commande Ad-Hoc.
  • -a "" ou --args "" : Fournit les arguments nécessaires au module spécifié. Les arguments sont spécifiques à chaque module.
  • -i ou --inventory : Indique le chemin vers votre fichier d'inventaire si ce n'est pas celui par défaut (/etc/ansible/hosts).
  • -u ou --user : Spécifie l'utilisateur distant pour la connexion SSH (peut être surchargé par ansible_user dans l'inventaire).
  • -b ou --become : Demande à Ansible d'utiliser la montée en privilèges (par exemple, passer de l'utilisateur de connexion à root via sudo).
  • --become-user : Spécifie l'utilisateur cible pour la montée en privilèges (par défaut, root).
  • -k ou --ask-pass : Demande le mot de passe de connexion SSH (non recommandé, privilégiez les clés SSH).
  • -K ou --ask-become-pass : Demande le mot de passe pour la montée en privilèges (par exemple, le mot de passe sudo).
  • -v, -vv, -vvv, -vvvv : Augmente le niveau de verbosité de la sortie, utile pour le débogage.

Par exemple, pour exécuter le module ping sur tous les hôtes du groupe webservers défini dans un inventaire nommé myinventory.ini, la commande ressemblerait à :

ansible webservers -i myinventory.ini -m ping

Cette syntaxe concise ouvre la voie à une multitude d'actions rapides sur votre infrastructure.

Exemple 1 : Vérifier la connectivité avec le module `ping`

Le module ping est souvent la première commande Ad-Hoc que l'on exécute. Son rôle est simple mais fondamental : il vérifie si Ansible peut se connecter aux noeuds gérés spécifiés et si Python est correctement installé et accessible sur ces noeuds. Il ne s'agit pas d'un ping ICMP traditionnel, mais d'un test de la capacité d'Ansible à exécuter une opération minimale.

Si la connexion est réussie et que l'environnement Python est fonctionnel sur le noeud distant, le module ping retourne un message "pong". C'est un excellent moyen de valider votre configuration d'inventaire, vos clés SSH et les prérequis de base sur les machines cibles.

Supposons que votre inventaire (inventory.ini) contienne un groupe lab_servers :

# inventory.ini
[lab_servers]
server1 ansible_host=192.168.1.10
server2 ansible_host=192.168.1.11

Pour tester la connexion à ces serveurs :

ansible lab_servers -i inventory.ini -m ping

Une sortie réussie ressemblera à ceci :

server1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
server2 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Si vous obtenez une erreur (par exemple, "UNREACHABLE" ou "FAILED"), cela indique un problème de connectivité SSH, d'authentification, ou l'absence de Python sur la machine distante. Le module ping est donc votre premier outil de diagnostic.

Exemple 2 : Exécuter une commande simple avec le module `command` ou `shell`

Le module command est le moyen le plus direct d'exécuter une commande sur les noeuds distants, comme vous le feriez dans un terminal SSH. Il est important de noter que le module command n'exécute pas la commande via un shell. Cela signifie que les fonctionnalités du shell telles que les redirections (>, |), les variables d'environnement ($HOME), ou les jokers (*) ne fonctionneront pas. Pour cela, il faut utiliser le module shell.

Cependant, pour des commandes simples qui n'ont pas besoin de ces fonctionnalités, command est plus sûr et souvent suffisant. Par défaut, le module command est le module utilisé si vous ne spécifiez pas l'option -m. Les arguments passés avec -a sont alors directement la commande à exécuter.

Pour vérifier le temps de fonctionnement (uptime) de tous les serveurs du groupe app_servers :

ansible app_servers -i inventory.ini -m command -a "uptime"

Ou, de manière équivalente, en omettant -m command (car c'est le module par défaut) :

ansible app_servers -i inventory.ini -a "uptime"

Pour vérifier l'espace disque (df -h) :

ansible app_servers -i inventory.ini -a "df -h"

La sortie affichera le résultat de la commande pour chaque hôte ciblé. Si vous avez besoin d'utiliser des pipes ou des redirections, le module shell est plus approprié. Par exemple, pour trouver tous les fichiers .log dans /var/log :

ansible app_servers -i inventory.ini -m shell -a "find /var/log -name '*.log'"

Attention : L'utilisation des modules command et shell doit être faite avec prudence. Ils ne sont généralement pas idempotents. Si la commande modifie l'état du système, l'exécuter plusieurs fois pourrait avoir des effets secondaires non désirés. Pour la gestion de configuration, il est toujours préférable d'utiliser des modules Ansible spécifiques (comme file, service, apt, etc.) qui sont conçus pour être idempotents.

Exemple 3 : Installer un paquet avec le module `apt` ou `yum`/`dnf`

Ansible fournit des modules spécifiques pour interagir avec les gestionnaires de paquets des différentes distributions Linux. Ces modules sont préférables à l'utilisation de command ou shell pour installer des paquets, car ils sont idempotents : ils vérifient si le paquet est déjà installé dans la version souhaitée avant d'agir.

Pour les systèmes basés sur Debian/Ubuntu, on utilise le module apt. Pour les systèmes basés sur Red Hat/CentOS/Fedora, on utilise yum (pour les anciennes versions) ou dnf (pour les versions plus récentes).

Supposons que vous souhaitiez installer le paquet htop (un moniteur de processus interactif) sur un serveur nommé web01 qui tourne sous Ubuntu. Vous auriez besoin des droits root pour cette opération, donc l'option -b (pour become) est nécessaire.

ansible web01 -i inventory.ini -m apt -a "name=htop state=present" -b

Détaillons les arguments du module apt :

• name=htop : Spécifie le nom du paquet à gérer.
• state=present : Indique que nous voulons que le paquet soit présent sur le système. S'il n'est pas installé, Ansible l'installera. S'il est déjà installé, Ansible ne fera rien (idempotence). D'autres états possibles sont latest (pour s'assurer que la dernière version est installée) ou absent (pour désinstaller un paquet).

Si web01 était un serveur CentOS 7, la commande serait similaire, mais utiliserait le module yum :

ansible web01 -i inventory.ini -m yum -a "name=htop state=present" -b

Et pour un serveur Fedora récent ou RHEL 8+ :

ansible web01 -i inventory.ini -m dnf -a "name=htop state=present" -b

Ansible est suffisamment intelligent pour détecter la distribution et utiliser le bon gestionnaire de paquets si vous utilisez le module générique package. Ce module tente de déterminer quel gestionnaire de paquets sous-jacent utiliser :

ansible web01 -i inventory.ini -m package -a "name=htop state=present" -b

L'utilisation de ces modules garantit que l'action est effectuée de manière propre et répétable, conformément à l'état désiré du système. Ces quelques exemples illustrent la flexibilité et la puissance des commandes Ad-Hoc pour des interventions rapides et efficaces sur votre parc de machines.