Déclaration de variable avec Ansible Part 1.3.3

Ce dessin illustre la hiérarchie des déclarations de variables en Ansible, montrant comment elles peuvent être organisées dans les dossiers inventaire, playbook, et roles.
Chaque flèche représente une relation de portée, montrant où les variables sont accessibles.

Ansible utilise la syntaxe YAML pour déclarer des variables. Le format YAML est simple, facile à lire et écrit en utilisant une indentation. Voici une liste exemple de déclaration de variable dans un playbook Ansible.

Méthode de déclaration de variable

Nous vous partagerons quelque méthodes les plus utilisées.

1. Syntaxe YAML dans le Playbook :

Utilisons un exemple de playbook qui définit des variables dans la section vars :

---
- name: Exemple de Playbook avec Définition de Variables
  hosts: localhost
  gather_facts: false
  vars:
    toto_copine: tutu
    toto_path: /home/toto/
    toto_config: Toto.cfg
    toto_vm: localhost
  tasks:
    - name: Afficher les Variables
      debug:
        msg: "Toto Copine: {{ toto_copine }}, Toto Path: {{ toto_path }}, Toto Config: {{ toto_config }}, Toto VM: {{ toto_vm }}"

Dans cet exemple, nous définissons quatre variables (toto_copine, toto_path, toto_config, toto_vm) dans la section vars du playbook. La tâche suivante utilise le module debug pour afficher ces variables.

2. Utilisation de vars_file dans le Playbook :

Considérons le second exemple où les variables sont définies dans un fichier externe et incluses dans le playbook :

---
- name: Exemple de Playbook avec vars_file
  hosts: localhost
  gather_facts: false
  vars_files:
    - /vars/external_vars.yml
  tasks:
    - name: Afficher les Variables Externes
      debug:
        msg: "Toto Copine: {{ toto_copine }}, Toto Path: {{ toto_path }}, Toto Config: {{ toto_config }}, Toto VM: {{ toto_vm }}"

Le contenu du fichier externe /vars/external_vars.yml serait le suivant :

---
toto_copine: tata
toto_path: /home/tutu/
toto_config: tete.cfg
toto_vm: localhost

Nous pouvons combiner les deux déclaration de variable ensemble (vars: & vars_file:)

3. Utilisation d’une Arborescence group_vars et host_vars pour la déclaration de variable :

Les fichiers définit dans vars_file, group_vars et host_vars dans Ansible sont utilisés pour stocker des variables dans des fichiers externes plutôt que de les définir directement dans le playbook. Cela peut être utile dans plusieurs cas :

  1. Réutilisation des Variables : Si vous avez des variables qui sont utilisées dans plusieurs playbooks ou rôles, vous pouvez les stocker dans un fichier vars_file et les inclure chaque fois que nécessaire. Cela favorise la réutilisation du code et maintient la cohérence des variables.
  2. Séparation des Données et de la Logique : En stockant les variables dans des fichiers distincts, vous séparez les données de la logique de votre automatisation. Cela rend les playbooks plus clairs et plus faciles à comprendre, car la logique opérationnelle est séparée des valeurs de configuration.
  3. Gestion Centralisée des Configurations : En stockant des variables dans des fichiers externes, vous pouvez centraliser la gestion des configurations. Cela facilite les mises à jour et les modifications, car vous pouvez effectuer des ajustements dans un fichier plutôt que de parcourir plusieurs playbooks.
  4. Sécurité : Dans certains cas, les fichiers vars_file peuvent être utilisés pour stocker des informations sensibles telles que des mots de passe ou des clés API. Ces fichiers peuvent ensuite être chiffrés à l’aide d’Ansible Vault pour renforcer la sécurité.

Nous pouvons imager une arborescence organisée pour les variables, notamment dans les dossiers group_vars et host_vars qui est possible :

playbook/
│
├── group_vars/
│   ├── preproduction_server/
│   │   ├── database_vars.yml
│   │   └── info.yml
│   ├── rabbitmq.yml
│   └── info.yml
│
├── host_vars/
│   ├── newyork/
│   │   └── info.yml
│   ├── pekin.yml
│   └── ...
│
└── playbook.yml

Dans cet exemple, chaque groupe de serveurs (preproduction_server, rabbitmq, newyork, pekin, etc.) a son propre dossier avec des fichiers YAML définissant les variables spécifiques à ce groupe exactement comme le dossier inventaire. Alors vous me direz quel est la différence de mettre dans l’un ou dans l’autre ?

La différence fondamentale entre mettre les variables dans le dossier inventaire et dans le dossier playbook réside dans le contexte d’utilisation et la portée des variables. Voici quelques distinctions clés :

  1. Dossier Inventaire (inventaire/group_vars et inventaire/host_vars):
    • Contexte d’Utilisation : Principalement utilisé pour définir des variables liées à la topologie de l’infrastructure, telles que des adresses IP, des noms d’hôte ou des informations spécifiques à la configuration réseau.
    • Portée : Les variables définies ici sont généralement accessibles à tous les playbooks et rôles utilisant cet inventaire.
  2. Dossier Playbook (playbook/group_vars et playbook/host_vars):
    • Contexte d’Utilisation : Utilisé pour définir des variables liées à la logique d’exécution du playbook, telles que des paramètres de configuration spécifiques à un playbook particulier.
    • Portée : Les variables définies ici sont spécifiques à un playbook ou à un ensemble de playbooks situés dans le même dossier, offrant une séparation plus fine des préoccupations.
  3. Dossiers Role (roles/my_role/vars):
    • Contexte d’Utilisation : Les rôles ont généralement leurs propres variables définies dans le dossier vars. Ces variables sont spécifiques à la logique du rôle.
    • Portée : Les variables du dossier vars d’un rôle sont spécifiques à ce rôle et peuvent être utilisées dans tous les playbooks qui incluent ce rôle.

Le choix entre le dossier inventaire et le dossier playbook dépend souvent de la nature des variables et de l’organisation du projet Ansible. En règle générale, les variables liées à la topologie de l’infrastructure et à la configuration des serveurs sont souvent définies dans le dossier inventaire, tandis que les variables liées à la logique d’exécution d’un playbook spécifique sont définies dans le dossier playbook. Cette séparation permet une gestion plus modulaire et une meilleure organisation des variables en fonction de leur contexte d’utilisation.

Ce dessin illustre la hiérarchie des déclarations de variables en Ansible, montrant comment elles peuvent être organisées dans les dossiers inventaire, playbook, et roles.
Chaque flèche représente une relation de portée, montrant où les variables sont accessibles.

4. Hiérarchie des Déclarations de Variables :

Dans Ansible, la hiérarchie des déclarations de variables suit un ordre spécifique, ce qui signifie que certaines déclarations peuvent prévaloir sur d’autres. Voici la hiérarchie générale des déclarations de variables, de la plus basse à la plus haute priorité :

  1. Command Line: Les variables spécifiées via l’option -e ou --extra-vars lors de l’exécution du playbook. Ces variables ont la priorité la plus élevée.
    • ansible-playbook playbook.yml -e "ma_variable=valeur_obligatoire"
  2. Fichiers d’Inventory: Les variables spécifiées dans les fichiers d’inventaire (inventory.ini dans notre cas). Ces variables peuvent être définies pour des groupes de serveurs ou des serveurs individuels.
    • [preproduction_server]
      oslo ma_variable=42
  3. Fichiers de Variables Groupées (group_vars): Les variables définies dans les fichiers YAML situés dans le répertoire group_vars. Ces fichiers peuvent être spécifiques à un groupe ou communs à tous les groupes.
    • # playbook/group_vars/preproduction_server/info.yml
      ma_variable: "valeur_personnalisée"
  4. Fichiers de Variables d’Hôte (host_vars): Les variables définies dans les fichiers YAML situés dans le répertoire host_vars. Ces fichiers sont spécifiques à des serveurs individuels.
    • # playbook/host_vars/oslo/info.yml
      ma_variable: "valeur_oslo"
  5. Fichiers YAML du Playbook (vars): Les variables définies directement dans le playbook, à l’intérieur des sections vars ou vars_files.
    • # playbook.yml
      - hosts: all
      vars: ma_variable: "valeur_playbook"
      tasks: # ...
    • # playbook.yml
      - hosts: all
      vars_files: - /vars/external_vars.yml
      tasks: # ...
  6. Dossiers Role (vars): Si vous utilisez des rôles dans Ansible, vous pouvez définir des variables spécifiques dans le dossier vars à l’intérieur du rôle.
    • # roles/my_role/vars/main.yml
      ma_variable: "valeur_role"

Ceci reste une liste exhaustive, pour tout savoir consultez le site officiel d’Ansible .

Manipulation de Variable dans Ansible

a. Appeler une Variable :

Dans Ansible, vous pouvez appeler une variable en utilisant la syntaxe {{ ma_variable }}. Par exemple, pour afficher la variable toto_copine, vous écririez {{ toto_copine }}.

Si vous souhaitez concaténer deux variables, vous pouvez utiliser le tilde (~) comme dans l’exemple suivant :

{{ serveur ~ '.' ~ domaine }}

b. Obtenir une Valeur Spécifique dans une sortie en dictionnaire :

Supposons que vous ayez une variable de type dictionnaire, par exemple :

server:
  id: 5
  info_supp:
    service: false
    archi: "3tier"
    log: true
  domaine: "toto.fr"

Vous pouvez accéder à une valeur spécifique dans ce dictionnaire comme suit :

{{ server.id }}
{{ server['id'] }}
{{ server.info_supp.archi }}
{{ server['info_supp']['archi'] }}
{{ server.info_supp['archi'] }}

c. Déclaration de Variable avec la Sortie d’une Exécution :

Si vous souhaitez déclarer une variable avec la sortie d’une tâche, vous pouvez utiliser register. Par exemple, pour enregistrer le statut d’un redémarrage de service :

- name: Redémarrer Nginx
  service:
    name: nginx
    state: restarted
  register: status
- debug:
    var: status

d. Afficher une Variable dans un Playbook :

Vous pouvez utiliser le module debug pour afficher une variable dans un playbook. Par exemple, pour afficher la sortie de la tâche précédente :

- debug:  var: status

Ansible Facts :

Les Ansible Facts permettent de récupérer de nombreux informations système à partir de chaque machine. Vous pouvez les consulter en utilisant des variables spéciales comme ansible_facts suivi de la clé de la valeur rechercher :

{{ ansible_facts.os_family }}
{{ ansible_facts.distribution }}
{{ ansible_facts.kernel }}

Par exemple, en mode ad-hoc :

ansible all -m setup

En mode playbook, vous pouvez les appeler par la variable ansible_facts, et même les redéfinir si nécessaire :

- name: Renommer ansible_facts.distribution_version en distrib_version
  when: ansible_facts.distribution_version is defined
  set_fact:
    distrib_version: "{{ ansible_facts.distribution_version }}"

Variables d’Hôte et Inventory :

Lorsque vous avez un grand nombre de serveurs, vous pouvez utiliser hostvars et inventory_hostname pour récupérer des informations sur chaque machine, en particulier dans le cas de variables définies pour le serveur.

Par exemple, pour récupérer une variable du facts d’une machine nommée toto dans un groupe web on ferait :

{{ hostvars['toto'].ansible_facts.distribution_version }}

N’oubliez pas de distinguer hostvars (variable interne dans un playbook) et host_vars/ (répertoire playbook ou d’inventaire) dans votre organisation.

Conclusion :

Ces différentes approches et exemples devraient vous aider à mieux comprendre comment définir et manipuler des variables dans Ansible, en tenant compte de la hiérarchie et de la flexibilité offertes par cette puissante plateforme d’automatisation. Il est recommandé de suivre une structure hiérarchique et organisée, en utilisant les bonnes pratiques telles que group_vars et host_vars, pour simplifier la maintenance et garantir une configuration fiable.

N’hésitez pas à adapter ces techniques en fonction de la complexité et des besoins de votre infrastructure.

Automation Experts

Rejoignez-nous pour une newsletter exclusive sur l'automatisation des experts informatique !

Obtenez les dernières tendances, astuces et outils pour optimiser vos processus, accélérer vos projets et libérer tout le potentiel de l'automatisation dans le monde de la technologie. Abonnez-vous dès maintenant pour rester à la pointe de l'innovation et transformer votre manière de travailler."

Comments

No comments yet. Why don’t you start the discussion?

    Alors tu en pense quoi de cette article ? Dis-moi tous..