Définir des hôtes individuels et des groupes d'hôtes

La fondation de l'inventaire : les hôtes individuels

Au coeur de toute infrastructure gérée par Ansible se trouvent les hôtes individuels. Un hôte représente une machine spécifique – qu'elle soit physique, virtuelle ou un conteneur – sur laquelle Ansible peut exécuter des tâches. La manière la plus simple de déclarer un hôte dans votre fichier d'inventaire (généralement au format INI) est de lister son nom de domaine pleinement qualifié (FQDN) ou son adresse IP, chaque hôte sur une nouvelle ligne.

Par exemple, pour déclarer trois serveurs, votre fichier d'inventaire pourrait contenir :

# Mon fichier d'inventaire (par exemple, inventory.ini)

serveur1.example.com
192.168.1.100
serveur-backup

Dans cet exemple, serveur1.example.com est un FQDN, 192.168.1.100 est une adresse IP, et serveur-backup est un alias. Pour que Ansible puisse se connecter à serveur1.example.com et serveur-backup, ces noms doivent être résolubles par le noeud de contrôle Ansible, soit via DNS, soit via le fichier /etc/hosts local. Si un nom n'est pas directement une adresse IP ou un FQDN résolvable, vous devrez utiliser la variable ansible_host pour spécifier l'adresse de connexion, comme nous le verrons plus tard.

Il est crucial de s'assurer que le noeud de contrôle Ansible peut effectivement atteindre ces hôtes via SSH (par défaut). Toute erreur de frappe dans le nom d'hôte, une adresse IP incorrecte, ou un problème de résolution de nom empêchera Ansible de gérer la machine concernée.

Organiser pour mieux régner : la puissance des groupes d'hôtes

Gérer une poignée d'hôtes individuellement est faisable, mais lorsque votre infrastructure grandit, cette approche devient rapidement inefficace et source d'erreurs. C'est ici qu'interviennent les groupes d'hôtes. Les groupes vous permettent de rassembler des hôtes partageant des caractéristiques ou des fonctions communes, facilitant ainsi l'application de configurations ou l'exécution de tâches sur plusieurs machines simultanément.

La syntaxe pour définir un groupe dans un fichier d'inventaire au format INI est simple : vous utilisez un nom de groupe entre crochets [nom_du_groupe], suivi des hôtes appartenant à ce groupe, listés chacun sur une nouvelle ligne. Un hôte peut appartenir à plusieurs groupes, vous offrant une grande flexibilité dans l'organisation.

Considérons un exemple où nous avons des serveurs web et des serveurs de base de données :

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

[dbservers]
db01.example.com
db02.example.com

[all_servers:children]
webservers
dbservers

Ici, nous avons défini deux groupes : webservers et dbservers. Si vous souhaitez appliquer une mise à jour de sécurité à tous vos serveurs web, vous pouvez cibler le groupe webservers dans votre commande Ansible ou votre playbook. Le groupe spécial all_servers (que vous pouvez nommer autrement) utilise la directive :children pour indiquer qu'il englobe d'autres groupes. Ainsi, cibler all_servers affecterait tous les hôtes listés sous webservers et dbservers.

Flexibilité et granularité : appartenance multiple et groupes imbriqués

La force des groupes réside également dans la possibilité pour un hôte d'appartenir à plusieurs groupes. Imaginons que vos serveurs soient répartis dans différents datacenters ou environnements (production, staging, développement). Un serveur web en production dans le datacenter de Paris pourrait appartenir aux groupes webservers, production, et paris.

web01-prod-par ansible_host=10.0.1.10
db01-prod-par ansible_host=10.0.1.20
web01-stag-lon ansible_host=10.0.2.10

[webservers]
web01-prod-par
web01-stag-lon

[dbservers]
db01-prod-par

[production]
web01-prod-par
db01-prod-par

[staging]
web01-stag-lon

[paris]
web01-prod-par
db01-prod-par

[london]
web01-stag-lon

Cette structure permet un ciblage très précis. Par exemple, pour déployer une nouvelle version de votre application uniquement sur les serveurs web de production à Paris, vous pourriez cibler les hôtes qui sont à l'intersection des groupes webservers, production, et paris (la syntaxe exacte pour cela peut varier, mais l'idée est de pouvoir sélectionner des sous-ensembles très spécifiques).

Ansible permet également les groupes imbriqués, où un groupe peut être défini comme l'enfant d'un autre groupe. Cela est utile pour créer des hiérarchies. Un groupe parent peut contenir des groupes enfants, et les variables définies au niveau du parent sont héritées par les enfants (sauf si surchargées). Par exemple, le groupe datacenters pourrait avoir pour enfants les groupes paris et london.

[paris_servers]
# ... hôtes de Paris ...

[london_servers]
# ... hôtes de Londres ...

[datacenters:children]
paris_servers
london_servers

Si vous appliquez une configuration au groupe datacenters, elle s'appliquera à tous les serveurs dans paris_servers et london_servers. Cette imbrication aide à organiser logiquement des infrastructures complexes et à appliquer des configurations ou des politiques de manière hiérarchique.

Cas d'usage et bonnes pratiques pour la définition d'hôtes et de groupes

La manière dont vous structurez vos hôtes et vos groupes dépendra largement de la taille et de la complexité de votre infrastructure, ainsi que de vos workflows d'automatisation. Pour une petite infrastructure de quelques serveurs, une liste simple et quelques groupes fonctionnels (ex: web, db) peuvent suffire. Pour des parcs plus importants, une stratégie de nommage et de groupement bien pensée devient essentielle.

Nommage cohérent : Utilisez une convention de nommage claire et cohérente pour vos hôtes (par exemple, fonction-environnement-localisation-index comme web-prod-par-01). Cela rendra votre inventaire plus lisible et plus facile à gérer. De même, choisissez des noms de groupes explicites.

Séparation par environnement : Il est courant de séparer les environnements (développement, staging, production) en utilisant des groupes distincts. Cela permet d'éviter les erreurs coûteuses, comme appliquer accidentellement une configuration de développement en production.

Groupement par fonction : Regroupez les serveurs qui remplissent des rôles similaires (serveurs web, serveurs d'application, bases de données, serveurs de cache, load balancers). Cela simplifie l'application de configurations spécifiques à ces rôles.

Utilisation des alias : Si les noms DNS ou les IP de vos machines sont longs ou peu mnémotechniques, utilisez des alias plus simples dans votre inventaire et spécifiez l'adresse de connexion réelle via ansible_host. Par exemple :

# Utilisation d'alias pour plus de clarté

[webservers]
primary_web_server ansible_host=web01.verylong.domain.name.example.com
secondary_web_server ansible_host=172.16.23.105

En adoptant ces pratiques, vous construirez un inventaire Ansible qui n'est pas seulement une liste de machines, mais un modèle organisé et puissant de votre infrastructure, prêt à être piloté par l'automatisation. Un inventaire bien structuré est la pierre angulaire d'une utilisation efficace et sereine d'Ansible.