4.1 : Variables : déclaration et priorité (aperçu)

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
2group_vars/<groupe>
3host_vars/<hôte>
4Variables vars définies dans le playbook (niveau play)
5Variables 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: 8080
ansible-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-vars est toujours le niveau le plus fort, et un group_vars/all est 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_port

Un 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 vars de 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.debug avec var: 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.