Passer au contenu principal

Fondamentaux (Ansible)

Variables et priorité

Ansible dispose de 22 niveaux de priorité pour les variables. Ce mécanisme est puissant et source de confusion. Comprendre les niveaux essentiels évite les surcharges involontaires et les comportements inattendus en production.

Les niveaux essentiels (du moins au plus prioritaire)

En pratique, on travaille surtout avec ces niveaux :

  1. role defaults (defaults/main.yml dans un rôle) : valeurs par défaut, facilement écrasables
  2. group_vars/all : variables communes à tous les hôtes
  3. group_vars/[groupe] : variables d'un groupe spécifique
  4. host_vars/[hôte] : variables d'un hôte spécifique
  5. play vars (section vars: dans le playbook) : variables du play
  6. role vars (vars/main.yml dans un rôle) : variables de rôle, peu écrasables
  7. set_fact / register : variables définies à l'exécution
  8. extra vars (-e en ligne de commande) : priorité absolue, écrase tout

Définir des variables

Dans le playbook :

- name: Mon play
  hosts: web
  vars:
    app_port: 8080
    app_name: monapp
  vars_files:
    - vars/common.yml
    - vars/secrets.yml

Via set_fact pendant l'exécution :

- name: Calculer le nom de sauvegarde
  ansible.builtin.set_fact:
    backup_name: "backup_{{ inventory_hostname }}_{{ ansible_date_time.date }}"

Extra vars : la priorité maximale

# Passer une variable en ligne de commande
ansible-playbook site.yml -e "app_port=9090"

# Passer un fichier de variables
ansible-playbook site.yml -e "@vars/override.yml"

# JSON inline
ansible-playbook site.yml -e '{"app_port": 9090, "debug": true}'

Les extra vars écrasent tout, y compris les variables de rôle et de host_vars. Utile pour les overrides de déploiement ou les tests rapides. A utiliser avec discernement en production automatisée.

register : capturer le résultat d'une tâche

- name: Vérifier si le fichier de configuration existe
  ansible.builtin.stat:
    path: /etc/myapp/config.yml
  register: config_file

- name: Afficher le résultat
  ansible.builtin.debug:
    msg: "Config présente : {{ config_file.stat.exists }}"

- name: Créer la config si absente
  ansible.builtin.copy:
    src: config.yml.j2
    dest: /etc/myapp/config.yml
  when: not config_file.stat.exists

Pièges classiques

Surcharge involontaire par group_vars : si un hôte appartient à plusieurs groupes, les variables de chaque groupe s'appliquent. En cas de conflit, le groupe qui gagne dépend de l'ordre alphabétique des noms de groupes (et non de l'ordre dans l'inventaire). La solution est d'utiliser host_vars pour les valeurs spécifiques à un hôte.

Variables non définies : Ansible lève une erreur si une variable est utilisée sans être définie. Utiliser | default('valeur') dans les templates ou vars_prompt pour les valeurs interactives.

Types YAML : app_port: 8080 est un entier, app_port: "8080" est une chaîne. Certains modules sont sensibles à ce typage.

Inspecter les variables d'un hôte

# Toutes les variables compilées pour un hôte
ansible web01.example.com -m debug -a "var=hostvars['web01.example.com']"

# Une variable spécifique
ansible web01.example.com -m debug -a "var=app_port"