Exécution du playbook avec `ansible-playbook`

Passer à l'action : la commande `ansible-playbook`

Une fois votre playbook méticuleusement écrit, comme notre `nginx_setup.yml`, l'étape suivante consiste à le faire exécuter par Ansible sur vos serveurs cibles. L'outil principal pour cela est la commande `ansible-playbook`. Cette commande est le coeur de l'orchestration dans Ansible ; elle lit votre playbook, interprète les instructions, se connecte aux hôtes spécifiés et applique les tâches définies.

Comprendre comment utiliser `ansible-playbook` est aussi crucial que de savoir écrire un playbook. La commande offre une panoplie d'options pour contrôler son comportement, gérer les connexions, fournir des informations d'identification, et obtenir des retours plus ou moins détaillés sur l'exécution. Nous allons explorer la syntaxe de base et les options les plus courantes pour lancer notre playbook Nginx.

Avant de lancer la commande, assurez-vous d'être dans le répertoire où se trouve votre fichier playbook (`nginx_setup.yml`) ou de spécifier le chemin complet vers celui-ci. De même, Ansible a besoin de connaître votre inventaire d'hôtes. Par défaut, il cherche un fichier nommé `hosts` ou `inventory.ini` dans le répertoire courant, ou `/etc/ansible/hosts`. Si votre inventaire est ailleurs, vous devrez l'indiquer explicitement.

Lancer votre playbook `nginx_setup.yml` : la commande de base

La syntaxe la plus simple pour exécuter un playbook est `ansible-playbook nom_du_playbook.yml`. Pour notre scénario, en supposant que votre fichier d'inventaire est correctement configuré et accessible par Ansible (par exemple, un fichier `hosts` dans le même répertoire que votre playbook, ou le fichier `/etc/ansible/hosts`), la commande serait :

ansible-playbook nginx_setup.yml

Cependant, il est fréquent de devoir spécifier explicitement le fichier d'inventaire, surtout lorsque l'on travaille sur plusieurs projets ou environnements. L'option `-i` (ou `--inventory`) est utilisée à cet effet. Si votre inventaire se nomme `mon_inventaire.ini` et se trouve dans le même répertoire :

ansible-playbook -i mon_inventaire.ini nginx_setup.yml

Notre playbook `nginx_setup.yml` utilise `become: true`, ce qui signifie qu'Ansible tentera d'utiliser `sudo` (par défaut) pour exécuter les tâches. Si l'utilisateur avec lequel Ansible se connecte via SSH n'a pas de droits `sudo` configurés sans mot de passe (NOPASSWD) sur les machines cibles, `sudo` demandera un mot de passe. Pour fournir ce mot de passe à Ansible de manière interactive, vous devez utiliser l'option `--ask-become-pass` ou sa forme courte `-K` :

ansible-playbook -i mon_inventaire.ini nginx_setup.yml -K

Si vous utilisez un utilisateur de connexion SSH autre que votre utilisateur local actuel, vous pouvez le spécifier avec l'option `-u ` (ou `--user=`). Si la connexion SSH nécessite un mot de passe (ce qui est moins sécurisé et moins recommandé que l'utilisation de clés SSH), vous pouvez utiliser `--ask-pass` (ou `-k`) pour qu'Ansible vous demande le mot de passe SSH.

Options utiles pour affiner l'exécution et le débogage

La commande `ansible-playbook` dispose de nombreuses options pour affiner son comportement. Voici quelques-unes des plus utiles, notamment pour le test et le débogage :

• `--check` ou `-C` (Dry Run) : C'est l'une des options les plus importantes pour tester vos playbooks. En mode "dry run", Ansible exécute le playbook et rapporte les changements qu'il ferait, mais sans réellement les appliquer sur les systèmes cibles. C'est excellent pour vérifier la logique de votre playbook et anticiper son impact avant une exécution réelle.
• Niveaux de verbosité (`-v`, `-vv`, `-vvv`, `-vvvv`) : Par défaut, la sortie d'Ansible est concise. Si vous voulez plus de détails sur ce qu'Ansible fait, notamment en cas d'erreur, utilisez les options de verbosité. `-v` affiche des informations de base sur les résultats des modules. `-vv` donne un peu plus de détails. `-vvv` affiche des informations de connexion SSH et les détails complets des modules. `-vvvv` active le log de débogage de la connexion, très utile pour les problèmes SSH.
• `--list-hosts` : Affiche la liste des hôtes qui seraient ciblés par le playbook, sans exécuter aucune tâche. Utile pour vérifier que votre directive `hosts` et votre inventaire ciblent bien les bonnes machines.
• `--list-tasks` : Affiche toutes les tâches qui seraient exécutées par le playbook, dans leur ordre d'exécution, sans les lancer.
• `--start-at-task "Nom de la tâche"` : Si un playbook long a échoué à une certaine tâche, vous pouvez, après avoir corrigé le problème, relancer le playbook à partir de cette tâche spécifique. Le nom de la tâche doit correspondre exactement à la directive `name` de la tâche.
• `--tags ` ou `-t ` : Exécute uniquement les jeux et les tâches qui portent le tag spécifié. Vous pouvez spécifier plusieurs tags séparés par des virgules.
• `--skip-tags ` : Exécute toutes les tâches sauf celles qui portent le tag spécifié.
• `--limit ` : Permet de restreindre l'exécution du playbook à un sous-ensemble des hôtes définis dans la directive `hosts` du playbook. Par exemple, si `hosts: webservers` cible 10 serveurs, `--limit web01.example.com` n'exécutera le playbook que sur ce serveur spécifique (s'il fait partie du groupe `webservers`).

Par exemple, pour tester notre playbook Nginx en mode dry run, avec une verbosité accrue et en demandant le mot de passe `sudo` :

ansible-playbook -i mon_inventaire.ini nginx_setup.yml -K --check -vv

Après avoir lancé votre playbook, l'étape suivante est d'analyser attentivement sa sortie pour comprendre ce qui s'est passé. C'est ce que nous aborderons dans la section suivante. La maîtrise de `ansible-playbook` et de ses options est essentielle pour une utilisation efficace et sécurisée d'Ansible au quotidien.