Etape 1 : Créer un inventaire avec au moins deux noeuds gérés

L'importance de l'inventaire dans Ansible

L'inventaire est la pierre angulaire de toute opération Ansible. C'est un fichier, ou un ensemble de fichiers, qui décrit les machines (appelées "noeuds gérés" ou "managed nodes") sur lesquelles Ansible va agir. Sans inventaire, Ansible ne sait tout simplement pas où exécuter ses tâches et playbooks. Cette première étape de notre exercice pratique consiste donc à créer un inventaire simple mais fonctionnel, qui représentera un petit parc de serveurs que nous souhaitons administrer.

L'objectif ici est de définir au moins deux noeuds gérés. Cela nous permettra de voir comment Ansible peut opérer sur plusieurs machines simultanément et comment organiser ces machines en groupes pour des actions ciblées. Nous allons utiliser le format INI, qui est le plus classique et le plus simple à appréhender pour débuter, bien qu'Ansible supporte également le format YAML et des inventaires dynamiques.

Pensez à l'inventaire comme à un annuaire de votre infrastructure. Il contient non seulement la liste des hôtes, mais peut aussi inclure des variables spécifiques à ces hôtes ou à des groupes d'hôtes, telles que l'adresse IP de connexion, l'utilisateur SSH à utiliser, ou des paramètres spécifiques à une application.

Structure et syntaxe d'un fichier d'inventaire INI

Un fichier d'inventaire au format INI est un simple fichier texte. Sa structure repose sur des sections, définies par des noms entre crochets ([nom_du_groupe]), et des listes d'hôtes sous ces sections. Chaque ligne sous une section de groupe représente un noeud géré.

Pour cet exercice, nous allons créer un fichier que nous nommerons, par convention, inventory ou hosts. Vous pouvez aussi lui donner un nom plus spécifique comme lab_inventory.ini. A l'intérieur de ce fichier, nous allons commencer par définir nos noeuds. Imaginons que nous ayons deux serveurs : srv-web-01 et srv-db-01.

La forme la plus simple pour déclarer un hôte est d'indiquer son nom d'hôte (s'il est résolvable par DNS depuis votre noeud de contrôle) ou son adresse IP :

srv-web-01
srv-db-01

Si ces noms ne sont pas directement résolvables ou si vous devez spécifier une adresse IP différente du nom d'hôte, vous pouvez utiliser la variable ansible_host :

srv-web-01 ansible_host=192.168.1.10
srv-db-01 ansible_host=192.168.1.20

Il est fortement recommandé d'organiser vos hôtes en groupes. Un groupe est défini par un nom entre crochets, par exemple [webservers] ou [databases]. Un hôte peut appartenir à plusieurs groupes, et les groupes peuvent même être imbriqués (un groupe peut contenir d'autres groupes).

[webservers]
srv-web-01 ansible_host=192.168.1.10

[databases]
srv-db-01 ansible_host=192.168.1.20

[datacenter_paris:children]
webservers
databases

Dans cet exemple, srv-web-01 appartient au groupe webservers, et srv-db-01 au groupe databases. Le groupe datacenter_paris est un méta-groupe qui inclut tous les hôtes des groupes webservers et databases.

Définir au moins deux noeuds gérés et variables de connexion

Conformément à l'objectif de cette étape, assurons-nous d'avoir au moins deux noeuds gérés dans notre inventaire. Supposons que vous ayez deux machines virtuelles ou serveurs physiques accessibles depuis votre noeud de contrôle Ansible. Appelons-les node1 et node2, avec les adresses IP respectives 10.0.0.5 et 10.0.0.6.

Voici comment pourrait se présenter votre fichier d'inventaire, que vous pouvez nommer my_inventory.ini :

# Fichier my_inventory.ini

[lab_servers]
node1 ansible_host=10.0.0.5
node2 ansible_host=10.0.0.6

# Variables applicables à tous les hôtes de cet inventaire
[all:vars]
ansible_user=your_ssh_user
ansible_ssh_private_key_file=~/.ssh/id_rsa_ansible

Dans cet exemple :

• Nous avons créé un groupe nommé lab_servers.
• node1 et node2 sont les noms que nous donnons à nos serveurs dans Ansible.
• ansible_host spécifie l'adresse IP à utiliser pour la connexion SSH. Si vos noms d'hôtes (node1, node2) étaient directement résolvables par DNS en ces IP, ansible_host serait optionnel.
• La section [all:vars] permet de définir des variables qui s'appliquent à tous les hôtes de l'inventaire.
• ansible_user spécifie le nom d'utilisateur à utiliser pour la connexion SSH. Remplacez your_ssh_user par le nom d'utilisateur réel.
• ansible_ssh_private_key_file indique le chemin vers la clé privée SSH à utiliser. Si vous utilisez la clé par défaut (~/.ssh/id_rsa) et que l'agent SSH est configuré, cette variable peut ne pas être nécessaire. Adaptez le chemin si votre clé porte un nom différent ou est stockée ailleurs.

Assurez-vous que l'utilisateur your_ssh_user existe sur node1 et node2, et que la clé publique correspondante à ansible_ssh_private_key_file est bien présente dans le fichier ~/.ssh/authorized_keys de cet utilisateur sur les deux noeuds gérés. C'est essentiel pour permettre à Ansible de se connecter sans mot de passe.

Vérification de la configuration de l'inventaire

Une fois votre fichier d'inventaire créé avec au moins deux noeuds, il est bon de vérifier qu'Ansible l'interprète correctement. Vous pouvez utiliser la commande ansible-inventory pour cela.

ansible-inventory -i my_inventory.ini --list

Cette commande affichera une structure JSON représentant la manière dont Ansible voit votre inventaire, y compris les groupes, les hôtes et les variables associées. Vous devriez y retrouver vos deux noeuds et les variables de connexion définies.

Une autre vérification rapide et utile est d'utiliser le module ping d'Ansible pour tester la connectivité à tous les hôtes de votre inventaire ou à un groupe spécifique :

ansible all -i my_inventory.ini -m ping

Ou pour cibler uniquement le groupe lab_servers :

ansible lab_servers -i my_inventory.ini -m ping

Si tout est correctement configuré (fichier d'inventaire, connectivité réseau, configuration SSH et clés), chaque hôte devrait répondre par un "pong" vert. Si vous rencontrez des erreurs, elles sont souvent liées à des problèmes de résolution de nom, de pare-feu bloquant le port SSH (par défaut 22), ou d'authentification SSH (clé incorrecte, mauvais utilisateur, permissions de fichiers SSH incorrectes). Prenez le temps de déboguer ces problèmes avant de passer à l'étape suivante, car un inventaire fonctionnel est la base de tout le reste.