Un Tour Complet de l’Inventaire Ansible – Inventory – Part 1.3

Définition de l’Inventaire Ansible

L’inventaire Ansible est le point central pour définir les serveurs sur lesquels vous allez exécuter vos tâches d’automatisation. La manière la plus simple pour démarrer est de l’utiliser en mode ad-hoc, sans fichier d’inventaire. Cela vous permet d’indiquer directement les serveurs dans la commande, comme suit:

ansible all -i 'localhost,' -a date

Dans cet exemple, nous exécutons la commande date sur le serveur local (localhost).

Configuration Ansible

Pour activer tous les plugins dans Ansible, modifiez le fichier ansible.cfg avec les configurations suivantes :

[defaults] inventory = inventaire 
[inventaire] enable_plugins = host_list, script, auto, yaml, ini, toml

Inventaire via le Mode serveur.ini

Une autre manière est de créer un dossier « inventaire » (grâce à la configuration ☝️) contenant un fichier ini avec la liste de vos serveurs en attribuant des variables aux machines(couleurs, IP, user) ou pas pour les différencier. Ces serveurs devront être accessible depuis le réseau et avoir une connexion ssh établie sur la machine ansible.

frankfurt.exemple.com
oslo.exemple.com
newyork.exemple.com 
seoul.exemple.com color=purple
sydney.exemple.com color=blue
server1 ansible_host=192.168.1.10 ansible_user=deploy_user ansible_password=tata ansible_port=5569 color=green
server2 ansible_host=192.168.1.11 ansible_user=deploy_user color=pink
database1 ansible_host=192.168.1.20 ansible_user=db_admin color=red

⚠️ Les alias dans l’inventaire sont des noms qui regroupe de nombreux variable. Nous pouvons dire que Serveur1, Serveur2, Database1 sont des alias et non pas des nom de serveur sur le réseau (comme Oslo ou Seoul). Il est également possible d’écrire des alias comme tels :

[Production_server]
moscou.exemple.com alias=moscou
berlin.exemple.com alias=berlin
pekin.exemple.com alias=pekin
jerusalem.exemple.com alias=jerusalem

Voyons comment enrichir l’exemple de l’inventaire via le mode serveur.ini en ajoutant des [groupes] voir des groupes de groupe ( :children) , des lots de serveurs ( [01:100]) et pour finir des variables de groupe ( :vars).

# serveur et alias
frankfurt.exemple.com
oslo.exemple.com alias=oslo
newyork.exemple.com alias=newyork
seoul.exemple.com color=purple
sydney.exemple.com color=blue
server1 ansible_host=192.168.1.10 ansible_user=deploy_user ansible_password=tata ansible_port=5569 color=green
server2 ansible_host=192.168.1.11 ansible_user=deploy_user color=pink
database1 ansible_host=192.168.1.20 ansible_user=db_admin color=red
# Group de serveurs contenant nos alias et serveurs
[primary_web_servers]
oslo
server2 
frankfurt.exemple.com
[secondary_web_servers]
newyork
server2 
sydney.exemple.com
# Groupe de groupes
[web:children]
primary_web_servers
secondary_web_servers
# Lot de serveurs avec de type paris1, paris2, paris3 ou paris01, paris02, paris03
[app]
paris[1:20].exemple.com
#ou
paris[01:20].exemple.com
# Lot de serveurs avec de type rera, rerb, rerc
[rer]
rer[a:e].exemple.com
#  Lot de serveurs avec de type metro1, metro2, metro3
[metro]
metro[1:].exemple.com
# Variables de groupe
[all:vars]
parc="Domaine de l'automation hub"
mon_numero_prefere=12
variable1="valeur1"
[db_primary:vars]
Db_primary_host="tata"
Db_primary_user="dbadmin"
Db_password="mon_secure_password"
db_port=5432
[rabbitmq:vars]
rabbitmq_primary_host="rera"
rabbitmq_primary_user="rabbit"
rabbitmq_primary_port=2233
rabbitmq_primary_password="reratp"

Dans cet exemple amélioré, nous avons ajouté des sections pour illustrer différentes fonctionnalités de l’inventaire Ansible.

• Alias et serveurs individuels :
  • Les alias tels que oslo, newyork, etc., peuvent être utilisés pour simplifier l’écriture.
  • Les serveurs individuels tels que frankfurt.exemple.com, server2, et database1 sont également inclus dans des groupes.
• Groupes de serveurs :
  • primary_web_servers et secondary_web_servers sont des groupes de serveurs qui incluent des alias ainsi que des serveurs individuels. Cela peut être utile pour organiser vos serveurs en fonction de leur rôle.
• Groupe de groupes :
  • [web:children] est un groupe de groupes qui inclut les groupes primary_web_servers et secondary_web_servers uniquement. Cela permet de regrouper tous les serveurs web sous un seul groupe.
• Lots de serveurs :
  • Les groupes app, rer, et metro définissent des lots de serveurs selon des modèles spécifiques. Cela permet une gestion plus efficace des serveurs en utilisant des expressions.
• Variable de groupe :
  • [all:vars] définit des variables qui s’appliqueront à tous les serveurs dans l’inventaire.
  • [db_primary:vars] définit des variables spécifiques au groupe db_primary.
  • [rabbitmq:vars] définit des variables spécifiques au groupe rabbitmq.

Ces ajouts offrent une flexibilité supplémentaire lors de la configuration de l’inventaire selon les besoins spécifiques de votre infrastructure.

Inventaire via le Mode serveur.yml

Vous pouvez également utiliser le format YAML pour définir votre inventaire, avec des variables incluses directement dans le fichier YAML. Voici un exemple de inventaire/serveur.yml:

all:
  children:
    primary_web_servers:
      hosts:
        oslo:
          ansible_host: oslo.exemple.com
          alias: oslo
        server2:
          ansible_host: 192.168.1.11
        frankfurt.exemple.com:
          ansible_host: frankfurt.exemple.com
    secondary_web_servers:
      hosts:
        newyork:
          ansible_host: newyork.exemple.com
          alias: newyork
        server2:
          ansible_host: 192.168.1.11
        sydney.exemple.com:
          ansible_host: sydney.exemple.com
    web:
      children:
        - primary_web_servers
        - secondary_web_servers
    app:
      hosts:
        paris1:
          ansible_host: paris1.exemple.com
          ansible_password: "pantheonsorbonne"
        paris2:
          ansible_host: paris2.exemple.com
          ansible_password: "Paris-Panthéon-Assas"
        # ... continue jusqu'à paris20 si variable différent
    rer:
      hosts:
        rer[a:e]: #si pas de variable différent
    metro:
      hosts:
        metro[1:]
          
  vars:
    parc: "Domaine de l'automation hub"
    mon_numero_prefere: 12
    variable1: "valeur1"
db_primary:
  vars:
    Db_primary_host: "tata"
    Db_primary_user: "dbadmin"
    Db_password: "mon_secure_password"
    db_port: 5432
rabbitmq:
  vars:
    rabbitmq_primary_host: "rera"
    rabbitmq_primary_user: "rabbit"
    rabbitmq_primary_port: 2233
    rabbitmq_primary_password: "reratp"

Dans cette représentation YAML :

• Les serveurs sont définis avec leurs détails sous les groupes correspondants (primary_web_servers, secondary_web_servers, app, rer, metro).
• Les variables de groupe sont regroupées sous les groupes correspondants (all, db_primary, rabbitmq).

Meilleur méthode d’inventaire avec group_vars et host_vars

La meilleur méthode mais aussi la plus répandue consiste à

• utiliser notre fichier ini pour lister nos serveurs
• utiliser un second fichier ini pour lister nos groupes de serveurs
• Utiliser group_vars et host_vars pour nos variables qui seront des fichiers en .yml

Définition group_vars et host_vars

Dans Ansible, les group_vars et host_vars sont des mécanismes permettant de définir des variables spécifiques pour des groupes de serveurs ou des serveurs individuels, respectivement. Ces variables peuvent être utilisées dans vos playbooks pour personnaliser la configuration et le comportement d’Ansible.

Pour une organisation plus structurée, vous pouvez définir des variables dans des fichiers distincts, stockés dans les dossiers group_vars ou host_vars. Il est important de respecter l’orthographe (group_varsou host_vars) car c’est de là que Ansible reconnaît les variables de groupe et de serveur

group_vars (Variables de groupe) :

• Emplacement : Les fichiers group_vars sont des fichiers YAML ou JSON situés dans un dossier spécifique (inventaire/group_vars) à la racine de votre répertoire d’inventaire.
• Portée : Les variables définies dans ces fichiers s’appliquent à l’ensemble du groupe de serveurs.
• Utilisation : Les variables de groupe peuvent être utilisées pour définir des paramètres communs à un ensemble de serveurs, comme des configurations spécifiques à un rôle ou à un environnement.

Exemple : Contenu du fichier inventaire/group_vars/all.yml :

parc: "Domaine de l'automation hub" mon_numero_prefere: 12 variable1: "valeur1"

host_vars (Variables d’hôte) :

• Emplacement : Les fichiers host_vars sont des fichiers YAML ou JSON situés dans un dossier spécifique (inventaire/host_vars) à la racine de votre répertoire d’inventaire.
• Portée : Les variables définies dans ces fichiers s’appliquent à un serveur spécifique.
• Utilisation : Les variables d’hôte sont utiles pour définir des paramètres spécifiques à un serveur, comme des adresses IP, des clés SSH, des mots de passe, etc.

Exemple : Contenu du fichier inventaire/host_vars/paris1.exemple.com.yml :

ansible_host: paris1.exemple.comansible_password: "pantheonsorbonne"

Fichier .ini (inventory.ini):

[primary_web_servers]
oslo
server2
frankfurt.exemple.com
[secondary_web_servers]
newyork
server2
sydney.exemple.com
[web:children]
primary_web_servers
secondary_web_servers
[app]
paris[01:20]
[rer]
rer[a:e]
[metro]
metro[1:]

Structure des dossiers pour group_vars et host_vars :

.
├── group_vars #variable groupées
│   ├── all.yml
│   ├── db_primary.yml
│   └── rer.yml
│   └── app.yml
│   └── metro.yml
│   └── rabbitmq.yml
│  
├── host_vars #variable spécifique 
│   ├── frankfurt.exemple.com.yml
│   ├── metro1.yml
│   ├── newyork.yml
│   ├── oslo.yml
│   ├── paris1.yml
│   ├── rera.yml
│   ├── rerb.yml
│   ├── rerc.yml
│   ├── rerd.yml
│   ├── rere.yml
│   ├── server2.yml
│   └── sydney.exemple.com.yml
└── inventory.ini

Tous ces dossiers et fichiers ne sont pas obligatoire. En fonction de vos besoin vous privilégiez la solutions qui vous correspond le mieux.

Pour en savoir plus sur l’inventaire

5) Inventaire Dynamique

La dernière méthode, particulièrement utile pour le scaling horizontal, consiste à utiliser un inventaire dynamique. Cela permet d’ajouter dynamiquement des serveurs en fonction des besoins, idéal pour les architectures en constante évolution. Pour aller plus loin.

Avec ces différentes approches, vous avez maintenant une vision complète de la puissance de l’inventaire Ansible et des différentes manières de le configurer selon vos besoins spécifiques.