On a déjà manipulé des variables sans vraiment les nommer ainsi : ansible_host, ansible_user, ou encore docker_stacks en section 2. Prenons maintenant le temps de voir toutes les façons de déclarer une variable, et surtout, ce qui se passe quand la même variable est définie à plusieurs endroits à la fois.
Déclarer une variable dans un playbook
La méthode la plus directe, via une clé vars au niveau du play :
---
- name: Installer Apache avec un port personnalisé
hosts: webservers
become: yes
vars:
apache_port: 8080
tasks:
- name: Afficher le port configuré
ansible.builtin.debug:
msg: "Apache va écouter sur le port {{ apache_port }}"On utilise la variable avec la syntaxe {{ }}, propre à Jinja2 (le moteur de templating qu’on détaillera en section 5). Partout où Ansible attend une valeur, vous pouvez injecter une variable de cette façon.
Rappel : les variables d’inventaire
On l’a vu en détail en section 2 : host_vars, group_vars, ou un bloc vars directement dans l’inventaire. Ces variables sont disponibles automatiquement dans tous les playbooks qui ciblent les hôtes concernés, sans rien avoir à réimporter.
Passer une variable en ligne de commande avec --extra-vars
Pratique pour une valeur ponctuelle, sans modifier ni le playbook ni l’inventaire :
ansible-playbook playbook_apache.yaml -i inventaire.yaml --extra-vars "apache_port=9090"On peut aussi passer plusieurs variables via un fichier JSON ou YAML :
ansible-playbook playbook_apache.yaml -i inventaire.yaml --extra-vars "@variables.yaml"Variables au niveau d’une tâche
Certaines variables n’ont de sens que pour une tâche précise plutôt que tout le play. On peut alors les déclarer directement au niveau de la tâche :
- name: Créer un dossier temporaire
ansible.builtin.file:
path: "{{ dossier_temp }}"
state: directory
vars:
dossier_temp: /tmp/nordika-{{ ansible_date_time.epoch }}L’ordre de précédence : qui gagne quand tout le monde parle en même temps
C’est le moment d’aller plus loin que ce qu’on avait esquissé en section 2. Ansible a une hiérarchie précise (une vingtaine de niveaux existent réellement, mais voici les niveaux qui couvrent l’immense majorité des cas concrets, du moins prioritaire au plus prioritaire) :
| Priorité | Source |
|---|---|
| 1 (la plus faible) | group_vars/all |
| 2 | group_vars/<groupe> |
| 3 | host_vars/<hôte> |
| 4 | Variables vars définies dans le playbook (niveau play) |
| 5 | Variables définies au niveau d’une tâche |
| 6 (la plus forte) | --extra-vars en ligne de commande |
Retenez surtout cette logique : plus une variable est déclarée près du point d’exécution, plus elle gagne — et --extra-vars gagne toujours, quoi qu’il arrive, ce qui en fait l’outil parfait pour tester une valeur ponctuelle sans toucher à aucun fichier.
# group_vars/all.yml
apache_port: 80# host_vars/nrd-web1.yml
apache_port: 8080ansible-playbook playbook_apache.yaml -i inventaire.yaml --extra-vars "apache_port=9090"Dans cet exemple, la valeur réellement utilisée sera 9090 : --extra-vars écrase tout le reste, peu importe ce qui est défini ailleurs.
💡 On parle ici d’un aperçu volontairement simplifié. L’ordre complet de précédence Ansible compte davantage de niveaux (rôles,
set_fact, faits, valeurs par défaut de rôle…). Ce qu’il faut retenir à ce stade : en cas de doute sur « quelle valeur va vraiment être utilisée »,--extra-varsest toujours le niveau le plus fort, et ungroup_vars/allest toujours le plus faible.
Diagnostiquer une variable dont la valeur surprend
Le réflexe à prendre quand une variable ne semble pas avoir la valeur attendue :
- name: Afficher la valeur réelle d'une variable
ansible.builtin.debug:
var: apache_portUn simple debug suffit souvent à comprendre quelle source a réellement gagné, sans avoir à deviner.
Ce qu’il faut retenir
- Une variable peut venir de l’inventaire, d’un
varsde playbook, d’une tâche, ou de--extra-vars. - La règle simple : plus c’est déclaré près de l’exécution (et en particulier
--extra-vars), plus ça l’emporte. ansible.builtin.debugavecvar:est votre meilleur ami pour vérifier la valeur réellement utilisée à l’exécution.
Dans la prochaine leçon, on regarde les facts : des variables un peu particulières, qu’Ansible collecte lui-même sur chaque machine, sans que vous ayez à les déclarer.