Ansible par la pratique (7) – Commandes Ad-hoc

Voici le septième article de la formation Ansible. Dans mon précédent article, nous nous sommes intéressés à la configuration de base avec la confection d’un premier inventaire. Aujourd’hui nous allons découvrir les premières commandes en mode interactif ou ad hoc.

Les commandes Ad-Hoc

Placez-vous dans le répertoire du septième atelier pratique :

$ cd ~/formation-ansible/atelier-07

Voici les quatre machines virtuelles de cet atelier :

Démarrez les VM :

$ vagrant up

Connectez-vous au Control Host :

$ vagrant ssh ansible

L’environnement de cet atelier est préconfiguré et prêt à l’emploi :

• Ansible est installé sur le Control Host.
• Le fichier /etc/hosts du Control Host est correctement renseigné.
• L’authentification par clé SSH est établie sur les trois Target Hosts.
• Le répertoire du projet existe et contient une configuration de base et un inventaire.

Rendez-vous dans le répertoire du projet :

$ cd ansible/projets/ema/
$ ls
ansible.cfg  inventory

Une commande ad hoc, c’est l’utilisation spontanée et interactive d’une fonctionnalité Ansible par le biais de la commande ansible. Vous en connaissez déjà au moins une, le test ping :

$ ansible all -m ping

• Dans ce contexte, ping n’est qu’un seul parmi les très (!) nombreux modules Ansible.
• L’option -m est la forme courte de --module-name.
• L’identificateur all détermine l’ensemble des hôtes auxquels s’applique la commande.
• Une commande ad hoc est donc l’appel d’un seul module, avec ou sans paramètres.

Dans la pratique quotidienne avec Ansible, vous utiliserez très peu le mode ad hoc, étant donné que vous travaillerez presque essentiellement avec des playbooks et la commande correspondante ansible-playbook.

Le module command

Le module command est sans doute l’un de ceux que l’on utilisera le plus dans le contexte des commandes ad hoc. Son paramètre est tout simplement une commande Linux à exécuter. Faisons un premier test en affichant l’espace utilisé de la partition principale sur tous les Target Hosts :

$ ansible all -m command -a "df -h /"
debian | CHANGED | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda3       124G  1.8G  116G   2% /
rocky | CHANGED | rc=0 >>
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rl_rocky9-root   70G  2.0G   68G   3% /
suse | CHANGED | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       124G  2.2G  118G   2% /

Ce module est tellement populaire qu’il constitue d’ailleurs le module par défaut d’Ansible. Si vous n’explicitez pas son utilisation par -m command, vous obtiendrez le même résultat :

$ ansible all -a "df -h /"
debian | CHANGED | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda3       124G  1.8G  116G   2% /
rocky | CHANGED | rc=0 >>
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rl_rocky9-root   70G  2.0G   68G   3% /
suse | CHANGED | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       124G  2.2G  118G   2% /

L’option -o (comme --one-line) peut augmenter la lisibilité du résultat si celui-ci tient en une seule ligne :

$ ansible all -a "hostname" -o
debian | CHANGED | rc=0 | (stdout) debian
suse | CHANGED | rc=0 | (stdout) suse
rocky | CHANGED | rc=0 | (stdout) rocky

Le module shell

Vous ne pourrez pas utiliser le module command si votre commande ad hoc utilise des mécanismes du shell comme | ou > etc. Dans ce cas il vous faudra passer par le module shell.

Ici par exemple, j’utilise la combinaison des deux commandes ps et wc pour afficher le nombre de processus en cours sur chacun des Target Hosts :

$ ansible all -m shell -a "ps -ef | wc -l" -o
debian | CHANGED | rc=0 | (stdout) 91
suse | CHANGED | rc=0 | (stdout) 103
rocky | CHANGED | rc=0 | (stdout) 116

Dans sa configuration par défaut, le module shell envoie la commande vers /bin/sh. Sur la majorité des systèmes cela équivaudra à un shell Bash, mais ce n’est pas toujours le cas, et vous risquez d’avoir des surprises. Pour être sûr que la commande soit exécutée dans un shell spécifique, vous pouvez expliciter ce dernier à l’aide du paramètre executable comme ceci par exemple :

$ ansible all -m shell -a 'echo $RANDOM executable=/bin/bash' -o
debian | CHANGED | rc=0 | (stdout) 20304
suse | CHANGED | rc=0 | (stdout) 10828
rocky | CHANGED | rc=0 | (stdout) 7461

• La variable RANDOM n’existe pas dans un shell sh.
• Veillez à utiliser des apostrophes simples. Si vous utilisez des apostrophes doubles, votre variable sera interprétée sur le Control Host, et vous serez probablement surpris d’obtenir quatre fois le même résultat.

Au-delà de command et shell

En théorie, rien ne vous empêche d’invoquer n’importe quel module Ansible par le biais d’une commande ad hoc, ce qui vous permet d’effectuer toute une série de tâches administratives. Voyons ce que ça peut donner dans la pratique.

Créez un répertoire /tmp/test sur tous vos Target Hosts :

$ ansible all -m file -a "dest=/tmp/test state=directory"

Copiez le fichier /etc/passwd du Control Host vers tous les Target Hosts sous forme d’un fichier /tmp/test2.txt :

$ ansible all -m copy -a "src=/etc/passwd dest=/tmp/test2.txt"

Créez un utilisateur kevin qui utilise le shell Bash par défaut :

$ ansible all -m user -a "name=kevin shell=/bin/bash"

Installez le paquet cowsay sur toutes les cibles :

$ ansible all -m package -a "name=cowsay"

Pour des raisons évidentes, cela fonctionnera uniquement avec des paquets qui ont le même nom sur les différentes distributions : cowsay, tree, git, nmap, etc.

Vous pouvez même vous amuser à redémarrer toutes vos cibles :

$ ansible all -m reboot

Et maintenant ?

Nous venons d’utiliser une série de modules comme ping, command, shell, file, copy, user, package et reboot. Vous vous demandez peut-être comment vous allez faire pour mémoriser tous ces noms de modules avec la syntaxe de leurs paramètres respectifs.

Soyez rassurés ici, il s’agit là des mêmes modules que vous utiliserez au quotidien dans vos playbooks. Au bout d’un certain temps, vous finirez par être tellement familiarisés avec leur syntaxe et les principaux paramètres à appliquer que vous n’y penserez plus.

Lire la suite : Idempotence

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.