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 :
role defaults(defaults/main.yml dans un rôle) : valeurs par défaut, facilement écrasablesgroup_vars/all: variables communes à tous les hôtesgroup_vars/[groupe]: variables d'un groupe spécifiquehost_vars/[hôte]: variables d'un hôte spécifiqueplay vars(sectionvars:dans le playbook) : variables du playrole vars(vars/main.yml dans un rôle) : variables de rôle, peu écrasablesset_fact/register: variables définies à l'exécutionextra 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.ymlVia 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.existsPiè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"