En 4.1, on a vu comment déclarer soi-même une variable. Mais Ansible connaît déjà, sans que vous ayez rien écrit, une quantité impressionnante d’informations sur chaque machine gérée : son adresse IP, sa distribution, sa mémoire disponible, ses interfaces réseau… Ce sont les facts.
D’où viennent les facts ?
Souvenez-vous de la toute première ligne qui s’affiche quand vous lancez un playbook :
TASK [Gathering Facts] *********************************
ok: [nrd-web1]Cette tâche, ajoutée automatiquement en tout début de play, c’est Ansible qui interroge la machine cible pour collecter une véritable fiche d’identité : c’est exactement l’équivalent du contrôleur qui demande à l’avion « identifiez-vous, indiquez votre altitude, votre vitesse, votre carburant restant » avant même de donner la première instruction.
Consulter les facts d’une machine
Pour voir absolument tout ce qu’Ansible sait sur un hôte, sans écrire de playbook :
ansible nrd-web1 -i inventaire.yaml -m ansible.builtin.setupVous obtiendrez un résultat JSON assez long — plusieurs centaines de lignes sur un serveur Linux classique. Parmi les facts les plus utiles au quotidien :
| Fact | Contenu |
|---|---|
ansible_distribution | La distribution (Debian, Ubuntu, RHEL…) |
ansible_distribution_version | Sa version |
ansible_default_ipv4.address | L’adresse IP principale |
ansible_hostname | Le nom d’hôte de la machine |
ansible_memtotal_mb | La mémoire totale en Mo |
ansible_processor_vcpus | Le nombre de vCPU |
ansible_os_family | La famille d’OS (Debian, RedHat…) |
Utiliser un fact dans un playbook
Les facts s’utilisent exactement comme n’importe quelle autre variable, avec {{ }} :
---
- name: Afficher des informations système
hosts: all
tasks:
- name: Afficher la distribution et son adresse IP
ansible.builtin.debug:
msg: "{{ ansible_hostname }} tourne sur {{ ansible_distribution }} {{ ansible_distribution_version }}, IP {{ ansible_default_ipv4.address }}"Un cas très utile : adapter une tâche selon l’OS
C’est justement ce type de fact qui permet d’écrire un playbook capable de s’adapter à plusieurs distributions différentes, plutôt que d’en écrire un par OS :
- name: Installer le bon paquet web selon la distribution
ansible.builtin.apt:
name: apache2
state: present
when: ansible_os_family == "Debian"
- name: Installer le bon paquet web selon la distribution
ansible.builtin.dnf:
name: httpd
state: present
when: ansible_os_family == "RedHat"On détaille la syntaxe when dans la prochaine leçon — retenez pour l’instant que c’est un fact (ansible_os_family) qui rend cette adaptation possible.
gather_facts: no : désactiver la collecte
Sur un playbook très simple, ou dans certains cas de performance (des dizaines de machines, une tâche unique et rapide), la collecte des facts peut représenter un coût de temps inutile. On peut la désactiver explicitement :
---
- name: Playbook rapide sans collecte de facts
hosts: all
gather_facts: no
tasks:
- name: Simple vérification
ansible.builtin.ping:⚠️ On avait déjà croisé ce réglage en 1.5, avec le module
raw: sans Python sur la cible, la collecte de facts est de toute façon impossible, d’où l’obligation de la désactiver dans ce cas précis.
Les « magic vars » : un aperçu
En plus des facts propres à chaque machine, Ansible expose aussi des variables dites « magiques », qui donnent des informations sur l’exécution elle-même plutôt que sur la machine :
- name: Afficher le nom du groupe en cours d'exécution
ansible.builtin.debug:
msg: "Cet hôte fait partie du groupe : {{ group_names }}"group_names liste tous les groupes auxquels appartient l’hôte en cours de traitement — pratique dans un playbook qui cible plusieurs groupes à la fois et qui a besoin d’adapter son comportement selon le groupe concerné.
Ce qu’il faut retenir
- Les facts sont collectés automatiquement par Ansible (
Gathering Facts) au début de chaque play, sauf sigather_facts: no. - Ils s’utilisent comme n’importe quelle variable, avec
{{ }}. ansible_os_family,ansible_distribution,ansible_default_ipv4.addressreviennent très souvent dans des playbooks réels.ansible.builtin.setupen ligne de commande permet d’explorer tous les facts disponibles sur un hôte avant même d’écrire un playbook.
Dans la prochaine leçon, on aborde justement le when qu’on vient d’entrevoir : les conditions, pour qu’une tâche ne s’exécute que dans certains cas précis.