Les inventaires (inventories en anglais) représentent les serveurs cibles sur lesquels déployer des actions.
Creusons ce sujet pour comprendre et mieux maitriser le concept.
Le format de fichier
L’inventory regroupe le aprc de serveurs où déployer des taches. On y liste tous les serveurs à contrôler avec plus ou moins d’informations techniques et utilisateur.
On retrouve les inventaires au format .ini
ou .yaml
. Les 2 formats ont leurs avantages et leurs inconvénients, se référer au tableau comparatif en fin de fichier.
Le reste de l’article utilisera le format .ini
.
Lister les serveurs à cibler
On liste tous les serveurs à cibler, les uns en dessous des autres.
# inventories/hosts 192.168.0.10 192.168.0.20
L’utilisation des adresses IP pose très un problème de lisibilité.
Généralement, on utilise des alias pour afficher la fonctions du serveurs plutot que son adresse IP.
# inventories/hosts front01 ansible_host=192.168.0.10 api01 ansible_host=192.168.0.20
On voit maintenant l’utilisation de chaque serveur.
Cette pratique apporte lisibilité et compréhension du parc de serveurs en un coup d’oeil.
Les alias sont massivement utilisés en entreprise, ils donnent du sens à l’inventaire.
N’hésitez pas à en faire de même !
L’inventaire permet également de contrôler d’autres aspects techniques d’Ansible :
- Mode de connexion :
ansible_connection
(ssh) - Adresse de connexion :
ansible_host
(exemple : 192.168.0.10) - Port de connexion :
ansible_port
(exemple : 22) - Utilisateur de connexion au serveur :
ansible_user
(exemple : ubuntu) - Mode d’élévation des droits :
become_method
(exemple : su) - Utilisateur pour l’élévation des droits :
become_user
(exemple : root)
# inventories/hosts front01 ansible_host=192.168.0.10 ansible_user=admin ansible_port=2222 api01 ansible_host=192.168.0.20 ansible_user=admin ansible_port=2222
Regrouper les serveurs
Lors du déploiement des actions, vous devrez différencier les serveurs où déployer les actions. Par exemple, notre serveur front utilisera un serveur Node.js alors que le back du Java. On doit différencier l’installation des 2 stacks, en fonction du type de serveurs.
C’est ici que les groupes ont toute leur importance.
Les groupes s’inscrivent dans le même fichier d’inventaire que les hosts, et sont représentés par une section au format .ini
.
On liste dans le groupes tous les serveurs à y rattacher.
# inventories/hosts front01 ansible_host=192.168.0.10 [front] front01
Et les groupes peuvent être multiples, aussi bien dans un sens que dans l’autre.
# inventories/hosts front01 ansible_host=192.168.0.10 front02 ansible_host=192.168.0.11 [front] front01 front02 [ubuntu] front01 [debian] front02
Et on peut faire hériter les groupes entre eux.
# inventories/hosts front01 ansible_host=192.168.0.10 front02 ansible_host=192.168.0.11 [front] front01 front02 [ubuntu:children] front
Découpez bien vos groupes par fonction. Cela vous aidera à associer les fonctions de chaque serveur et à rendre votre travail modulaire.
Héritage et modularité !
Variables de groupe
Chaque groupe peut se voir associer des variables.
# inventories/hosts front01 ansible_host=192.168.0.10 [front] front01 [front:vars] website_path=/var/www/html
Comparatif des 2 formats d’inventaire
INI | YAML | |
---|---|---|
Organisation des serveurs | En ligne | Dans une structure sous l’attribut all |
Lisibilité des serveurs | Très lisible | Peu lisible (structure yaml) |
Lisibilité des groupes | Moyen (imbrication des groupes) | Peu lisible (doublons des serveurs et imbrication des groupes) |
Factorisation des serveurs | Oui | Non |
Itération programmatique | Difficile | Oui |
.ini
et .yaml
Comparatif de l’inventaire aux formats .ini
et .yaml
# inventories/hosts.ini host1 ansible_host=192.168.0.2 host1 ansible_host=192.168.0.3 [atlanta] host1 host2 [raleigh] host2 host3 [southeast:children] atlanta raleigh [southeast:vars] some_server=foo.southeast.example.com halon_system_timeout=30 self_destruct_countdown=60 escape_pods=2 [usa:children] southeast northeast southwest northwest
# inventories/hosts.yaml all: children: usa: children: southeast: children: atlanta: hosts: host1: 192.168.0.2 host2: 192.168.0.2 raleigh: hosts: host2: 192.168.0.2 host3: 192.168.0.2 vars: some_server: foo.southeast.example.com halon_system_timeout: 30 self_destruct_countdown: 60 escape_pods: 2 northeast: northwest: southwest:
Vous l’aurez compris, j’ai adopté le format .ini
pour des raisons de lisibilité et de factorisation, malgré les difficultés de parsing avec des outils externes.
Les autres articles autour d’Ansible :