4.2 : Facts : gather_facts, ansible_facts

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.setup

Vous obtiendrez un résultat JSON assez long — plusieurs centaines de lignes sur un serveur Linux classique. Parmi les facts les plus utiles au quotidien :

FactContenu
ansible_distributionLa distribution (Debian, Ubuntu, RHEL…)
ansible_distribution_versionSa version
ansible_default_ipv4.addressL’adresse IP principale
ansible_hostnameLe nom d’hôte de la machine
ansible_memtotal_mbLa mémoire totale en Mo
ansible_processor_vcpusLe nombre de vCPU
ansible_os_familyLa 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 si gather_facts: no.
  • Ils s’utilisent comme n’importe quelle variable, avec {{ }}.
  • ansible_os_family, ansible_distribution, ansible_default_ipv4.address reviennent très souvent dans des playbooks réels.
  • ansible.builtin.setup en 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.