Comprendre les variables d'inventaire basiques (ansible_host, ansible_user)

Introduction aux variables d'inventaire : personnaliser la connexion Ansible

L'inventaire Ansible ne se contente pas de lister des machines ; il permet également d'associer des données, ou variables, à ces machines. Ces variables fournissent des informations contextuelles qu'Ansible utilise pour adapter son comportement. Parmi les plus cruciales se trouvent les variables de connexion, qui dictent comment Ansible établit la communication avec vos noeuds gérés. Comprendre et maîtriser ansible_host et ansible_user est fondamental pour assurer des connexions fiables et ciblées.

Ces variables peuvent être définies directement à côté d'un nom d'hôte dans votre fichier d'inventaire ou, pour une application plus large, au niveau d'un groupe d'hôtes. Elles permettent de surcharger les comportements par défaut d'Ansible ou de fournir des informations manquantes, comme l'adresse IP réelle derrière un alias ou l'utilisateur spécifique à utiliser pour la connexion SSH.

L'utilisation judicieuse de ces variables simplifie grandement la gestion d'environnements hétérogènes où les paramètres de connexion peuvent varier d'un serveur à l'autre. Elles contribuent à rendre vos inventaires plus lisibles, plus maintenables et vos automatisations plus robustes, en évitant de coder en dur des informations de connexion dans vos playbooks.

La variable `ansible_host` : spécifier la destination de connexion réelle

La variable ansible_host est essentielle lorsque le nom que vous utilisez pour identifier un hôte dans votre inventaire (souvent appelé alias) ne correspond pas à l'adresse réseau effective (adresse IP ou FQDN) à laquelle Ansible doit se connecter. C'est une situation courante pour plusieurs raisons : l'alias peut être un nom plus convivial mais non résolvable par DNS, ou vous pourriez avoir besoin de vous connecter à une interface réseau spécifique d'une machine (par exemple, une interface de management).

En l'absence de ansible_host, Ansible tente de résoudre le nom de l'hôte tel qu'il apparaît dans l'inventaire. Si ce nom n'est pas une adresse IP valide ou un nom de domaine résolvable, la connexion échouera. ansible_host permet de dissocier l'identifiant logique de l'hôte de son adresse de connexion physique.

Voici comment l'utiliser dans un fichier d'inventaire au format INI :

# Fichier inventory.ini

# Cas 1: L'alias 'web_frontend' n'est pas un FQDN, on spécifie l'IP
web_frontend ansible_host=192.168.1.50

# Cas 2: 'db_server_prod' est un nom descriptif, on pointe vers le FQDN réel
db_server_prod ansible_host=db01.prod.internal.example.com

[dmz_servers]
firewall_ext ansible_host=10.0.0.1
gateway_srv ansible_host=10.0.0.2

Dans le premier cas, si vous ciblez web_frontend, Ansible se connectera à 192.168.1.50. Dans le second, il se connectera à db01.prod.internal.example.com. Pour les serveurs du groupe dmz_servers, les adresses IP spécifiées seront utilisées. Cette variable est donc cruciale pour la flexibilité de votre inventaire.

La variable `ansible_user` : définir l'utilisateur de connexion distant

Par défaut, Ansible tente de se connecter aux noeuds gérés en utilisant le même nom d'utilisateur que celui qui exécute la commande ansible ou ansible-playbook sur le noeud de contrôle. Cependant, il est fréquent que l'utilisateur requis sur la machine distante soit différent. La variable ansible_user permet de spécifier explicitement le nom d'utilisateur distant à utiliser pour la connexion SSH.

Cette variable est particulièrement utile lorsque vous devez vous connecter en tant qu'un utilisateur de service spécifique pour déployer une application, ou un utilisateur avec des droits limités avant d'utiliser le mécanisme de montée en privilèges d'Ansible (become) pour exécuter des tâches en tant que root ou un autre utilisateur.

Voici des exemples d'utilisation :

# Fichier inventory.ini

serveur_app_01 ansible_host=172.16.0.10 ansible_user=deploy
serveur_legacy ansible_host=172.16.0.11 ansible_user=techadmin

[monitoring_servers]
host1 ansible_host=192.168.5.5
host2 ansible_host=192.168.5.6

[monitoring_servers:vars]
ansible_user=monitor_agent

Pour serveur_app_01, Ansible se connectera en tant qu'utilisateur deploy. Pour serveur_legacy, ce sera techadmin. Pour tous les hôtes du groupe monitoring_servers (host1 et host2), Ansible utilisera l'utilisateur monitor_agent, grâce à la définition de la variable dans la section [monitoring_servers:vars]. Si ansible_user n'est pas spécifié pour un hôte ou son groupe, le comportement par défaut (utilisateur courant du noeud de contrôle) s'applique.

Application et portée des variables de connexion fondamentales

Les variables comme ansible_host et ansible_user peuvent être définies à différents niveaux, offrant une grande flexibilité. La portée la plus spécifique est directement sur la ligne de l'hôte dans l'inventaire. Cela affecte uniquement cet hôte particulier.

Pour appliquer une variable à tous les hôtes d'un groupe, vous pouvez utiliser une section spéciale [nom_du_groupe:vars]. Toutes les variables définies dans cette section seront héritées par chaque hôte membre du groupe nom_du_groupe, sauf si un hôte redéfinit explicitement cette variable sur sa propre ligne (la définition la plus spécifique l'emporte).

# Fichier inventory.ini

[webservers]
web01 ansible_host=10.1.1.1 # User spécifique pour web01
web02 ansible_host=10.1.1.2

[webservers:vars]
ansible_user=www-data
ansible_port=2222 # Une autre variable de connexion

[dbservers]
db01 ansible_host=10.2.2.1 ansible_user=postgres

[all:vars] # Variables globales à tous les hôtes
ansible_ssh_common_args='-o StrictHostKeyChecking=no'

Dans cet exemple, web01 et web02 se connecteront avec l'utilisateur www-data et sur le port 2222, car ces variables sont définies pour le groupe webservers. Cependant, si web01 avait ansible_user=admin sur sa ligne, cela surchargerait la valeur du groupe pour cet hôte spécifique. L'hôte db01 utilise postgres comme utilisateur. Le groupe spécial all permet de définir des variables qui s'appliquent à tous les hôtes de l'inventaire, sauf si elles sont surchargées à un niveau plus spécifique (groupe ou hôte).

Bien comprendre cette hiérarchie et cette précédence des variables est clé pour construire des inventaires complexes et maintenables, vous permettant d'ajuster finement les paramètres de connexion sans répétition excessive.