L'inventaire en détail

L'essence de l'inventaire Ansible : votre carte maîtresse d'infrastructure

Au coeur de toute opération Ansible se trouve le fichier d'inventaire. Ce fichier, souvent nommé hosts, est bien plus qu'une simple liste ; il est la représentation textuelle de votre infrastructure, le plan directeur qu'Ansible utilisera pour savoir quelles machines gérer et comment s'y connecter. Sans un inventaire correctement configuré, Ansible est aveugle et incapable d'exécuter la moindre tâche. Sa compréhension et sa maîtrise sont donc des prérequis absolus pour quiconque souhaite exploiter la puissance de cet outil d'automatisation.

L'inventaire peut être statique, c'est-à-dire un fichier texte que vous maintenez manuellement, ou dynamique, généré à la volée par un script interrogeant une source externe comme un fournisseur cloud (AWS, Azure, GCP) ou un système de CMDB. Pour nos premiers pas, nous nous concentrerons sur l'inventaire statique, qui est le plus simple à appréhender. Le format le plus courant et historiquement utilisé est le format INI, mais Ansible supporte également le YAML, qui offre plus de flexibilité pour des structures complexes.

Par défaut, Ansible cherche un fichier d'inventaire à l'emplacement /etc/ansible/hosts. Cependant, il est très fréquent et recommandé, surtout en phase de développement ou pour des projets spécifiques, d'utiliser un fichier d'inventaire localisé dans votre répertoire de projet. Vous pouvez spécifier un fichier d'inventaire particulier lors de l'exécution d'une commande Ansible avec l'option -i ou via la variable d'environnement ANSIBLE_INVENTORY. Cette flexibilité permet d'adapter la portée des actions d'Ansible à des contextes variés sans modifier la configuration globale.

Définir des hôtes individuels et des groupes d'hôtes pour structurer votre parc

La brique de base de l'inventaire est la définition des hôtes individuels. Un hôte peut être identifié par son adresse IP ou par un nom de domaine complet (FQDN) qui peut être résolu par le noeud de contrôle Ansible. La syntaxe la plus simple pour lister des hôtes est de les écrire chacun sur une nouvelle ligne.

Par exemple, un inventaire simple pourrait ressembler à ceci :

# Fichier inventory.ini

192.168.1.10
serveurapp.mondomaine.com
serveurdb.mondomaine.com

Si Ansible peut atteindre ces adresses ou résoudre ces noms, il pourra interagir avec ces machines. Cependant, gérer une grande quantité d'hôtes individuellement devient rapidement fastidieux. C'est là qu'intervient la notion de groupes. Les groupes permettent de catégoriser vos hôtes selon des critères logiques : leur fonction (serveurs web, bases de données), leur environnement (production, développement, test), leur localisation géographique, etc.

Pour définir un groupe, on utilise une section délimitée par des crochets [], suivie de la liste des hôtes appartenant à ce groupe. Un hôte peut appartenir à plusieurs groupes. Voici un exemple plus structuré :

# Fichier inventory.ini

[webservers]
web01.example.com
web02.example.com

[dbservers]
db01.example.com

[paris]
web01.example.com
db01.example.com

[frankfurt]
web02.example.com

Dans cet exemple, web01.example.com fait partie des groupes webservers et paris. Cette organisation facilite grandement le ciblage des commandes et des playbooks. Par exemple, vous pourriez vouloir appliquer une configuration spécifique uniquement aux serveurs du groupe webservers ou redémarrer tous les serveurs situés à paris.

Comprendre les variables d'inventaire basiques : `ansible_host` et `ansible_user`

Au-delà de la simple liste d'hôtes et de leur groupement, l'inventaire Ansible permet de définir des variables qui influencent la manière dont Ansible interagit avec les noeuds gérés. Ces variables peuvent être définies au niveau d'un hôte individuel ou d'un groupe entier. Parmi les plus fondamentales, on trouve ansible_host et ansible_user.

La variable ansible_host est particulièrement utile lorsque le nom que vous utilisez pour identifier un hôte dans l'inventaire (son alias) n'est pas directement utilisable pour la connexion. Cela peut être le cas si l'alias n'est pas résolvable par DNS, ou si vous devez vous connecter via une adresse IP spécifique qui n'est pas le nom canonique de la machine. Par exemple :

# Fichier inventory.ini

mon_serveur_web ansible_host=192.168.1.100

[proxys]
proxy01 ansible_host=10.0.0.5
proxy02 ansible_host=10.0.0.6

Ici, pour l'hôte que nous appelons mon_serveur_web, Ansible tentera de se connecter à l'adresse IP 192.168.1.100. De même pour les hôtes du groupe proxys.

La variable ansible_user permet de spécifier le nom d'utilisateur distant avec lequel Ansible doit établir la connexion SSH. Si cette variable n'est pas définie, Ansible utilisera par défaut le nom de l'utilisateur exécutant la commande Ansible sur le noeud de contrôle. Ceci est souvent différent de l'utilisateur requis sur les machines distantes, notamment si vous avez besoin de vous connecter en tant qu'utilisateur avec des privilèges spécifiques (sans pour autant être root directement pour la connexion).

# Fichier inventory.ini

serveur_critique ansible_host=172.16.0.5 ansible_user=admin_ops

[applications]
app_server01 ansible_user=deployeur
app_server02 ansible_user=deployeur

Dans cet exemple, Ansible se connectera à serveur_critique en tant qu'admin_ops et aux serveurs du groupe applications en tant que deployeur. D'autres variables de connexion courantes incluent ansible_port (pour spécifier un port SSH non standard), ansible_ssh_pass (pour le mot de passe, bien que l'utilisation de clés SSH soit fortement recommandée et plus sécurisée), et ansible_ssh_private_key_file (pour indiquer le chemin vers une clé SSH privée spécifique).

Approfondir l'organisation : groupes imbriqués et alias d'hôtes

Pour gérer des infrastructures plus complexes, Ansible offre la possibilité de créer des groupes de groupes, aussi appelés groupes imbriqués ou enfants. Cela permet d'établir des hiérarchies logiques et d'appliquer des variables de manière encore plus granulaire. La syntaxe utilise le suffixe :children dans le nom du groupe parent et liste ensuite les noms des groupes enfants.

Prenons un exemple où nous avons des serveurs web et des serveurs de base de données, répartis dans deux datacenters, Paris et Londres :

# Fichier inventory.ini

[paris_webservers]
web01-par.example.com
web02-par.example.com

[paris_dbservers]
db01-par.example.com

[london_webservers]
web01-lon.example.com

[london_dbservers]
db01-lon.example.com

[paris:children]
paris_webservers
paris_dbservers

[london:children]
london_webservers
london_dbservers

[webservers:children]
paris_webservers
london_webservers

[dbservers:children]
paris_dbservers
london_dbservers

[datacenters:children]
paris
london

Avec cette structure, vous pouvez cibler tous les serveurs à Paris (paris), tous les serveurs web (webservers), ou uniquement les serveurs web à Paris (en utilisant un motif comme paris_webservers ou une intersection de groupes si votre version d'Ansible le supporte nativement ou via des playbooks). Les variables définies pour un groupe parent (ex: paris) seront héritées par ses groupes enfants et les hôtes qu'ils contiennent, sauf si elles sont surchargées à un niveau inférieur.

Les alias d'hôtes, comme vu brièvement avec ansible_host, permettent d'utiliser un nom convivial dans votre inventaire qui est différent du nom de machine réel ou de son IP. C'est utile pour la lisibilité et pour s'abstraire des détails de connexion spécifiques. L'alias est le premier nom sur la ligne, suivi des variables qui lui sont associées, y compris ansible_host si l'alias lui-même n'est pas l'adresse de connexion.

# Fichier inventory.ini

# Alias 'webprod01' pointe vers une IP spécifique avec un utilisateur dédié
webprod01 ansible_host=10.20.30.40 ansible_user=webapp ansible_port=2222

# Alias 'legacy_system' pour un FQDN long et complexe
legacy_system ansible_host=very-long-and-complex-hostname.internal.corp

Cette technique améliore la maintenabilité de vos inventaires, surtout lorsque les adresses IP ou les noms d'hôtes sous-jacents sont sujets à changement. L'alias reste stable dans vos playbooks, et seule la définition dans l'inventaire doit être mise à jour.

Bonnes pratiques pour un inventaire Ansible robuste et maintenable

La qualité de votre inventaire Ansible conditionne directement l'efficacité et la fiabilité de votre automatisation. Adopter de bonnes pratiques dès le début est donc crucial. Premièrement, utilisez des noms clairs et cohérents pour vos hôtes et vos groupes. Une nomenclature bien pensée facilite la compréhension et réduit les risques d'erreur lors du ciblage.

Maintenez votre inventaire à jour. Une infrastructure évolue : des serveurs sont ajoutés, retirés, ou leurs rôles changent. Un inventaire obsolète peut entraîner des déploiements sur des machines incorrectes ou des échecs d'exécution. Pour les environnements dynamiques, envisagez sérieusement l'utilisation d'inventaires dynamiques qui se synchronisent automatiquement avec votre source de vérité (cloud, CMDB).

Pour les projets d'envergure ou pour séparer clairement les environnements (développement, pré-production, production), n'hésitez pas à utiliser des fichiers d'inventaire distincts ou des répertoires d'inventaire. Un répertoire d'inventaire peut contenir plusieurs fichiers (hôtes, variables de groupe, variables d'hôte), permettant une organisation plus modulaire. Vous pouvez spécifier un répertoire comme source d'inventaire avec l'option -i /chemin/vers/repertoire_inventaire/.

Enfin, et c'est une pratique fondamentale en Infrastructure as Code (IaC), versionnez vos fichiers d'inventaire statique avec un système de contrôle de version tel que Git. Cela vous permet de suivre les modifications, de revenir à des versions antérieures en cas de problème, et de collaborer plus facilement au sein d'une équipe. Chaque changement apporté à l'infrastructure décrite dans l'inventaire devrait être tracé et potentiellement revu.