Réponse rapide : à quoi sert Ansible gather_facts ?

Ansible gather_facts collecte automatiquement des informations sur les hôtes Linux avant l’exécution d’un playbook : OS, noyau, réseau, mémoire, CPU, stockage et virtualisation. En production, l’intérêt n’est pas de “voir des facts”, mais de transformer ces données en inventaire fiable pour décider où déployer, quoi corriger et quels serveurs présentent un risque ou une dérive de configuration.

Pourquoi gather_facts compte en production

Dans une petite infrastructure, on peut encore croire connaître chaque serveur. Dans un parc réel, cette certitude disparaît vite : VM oubliées, distributions hétérogènes, noyaux non patchés, interfaces réseau renommées, partitions presque pleines, rôles applicatifs mal documentés. Les fichiers d’inventaire Ansible indiquent souvent le nom des machines, mais rarement leur état réel.

C’est là que gather_facts devient intéressant. Il ne remplace pas une supervision ni une CMDB complète, mais il donne une photographie technique homogène au moment où l’automatisation s’exécute. Pour une équipe DevOps ou infogérance, ces informations permettent de décider avant d’agir : appliquer une tâche uniquement sur Debian 13, exclure les serveurs avec trop peu de RAM, cibler les machines virtuelles, ou vérifier qu’un parc respecte une base de conformité.

Sur linux-man.fr, le sujet complète naturellement des pratiques d’automatisation plus larges comme la structure d’un playbook Ansible en production et l’industrialisation d’une infrastructure Linux avec Ansible.

Diagnostic : quelles données récupérer avec Ansible facts

Les facts Ansible sont stockés dans la variable ansible_facts. On y trouve beaucoup de données, mais tout n’a pas la même valeur opérationnelle. En contexte professionnel, les informations les plus utiles sont généralement celles qui répondent à une question précise : “quels serveurs sont encore en Debian 11 ?”, “quels hôtes exposent plusieurs interfaces ?”, “quels systèmes ont moins de 4 Go de RAM ?”, “quels nœuds tournent en virtualisation KVM ?”.

Pour inspecter les facts d’un hôte sans exécuter tout un playbook, le module setup reste le point de départ :

ansible all -m ansible.builtin.setup

Sur un parc complet, le résultat brut est trop volumineux. Il vaut mieux filtrer :

ansible all -m ansible.builtin.setup -a 'filter=ansible_distribution*'
ansible all -m ansible.builtin.setup -a 'filter=ansible_default_ipv4'
ansible all -m ansible.builtin.setup -a 'filter=ansible_memtotal_mb'

Ces filtres transforment une collecte massive en diagnostic ciblé. Pour un audit initial, je recommande de commencer par cinq familles : OS, kernel, réseau, ressources, stockage. Cela suffit à détecter la plupart des écarts avant de lancer des automatisations plus sensibles.

Pourquoi les inventaires Ansible deviennent peu fiables

Le problème vient rarement d’Ansible lui-même. Il vient surtout d’un mauvais usage des informations disponibles. Beaucoup d’équipes maintiennent un fichier inventory statique, puis oublient de le confronter à la réalité. Le nom d’un groupe indique “debian”, mais un hôte a été migré. Une variable annonce “prod”, mais la machine n’est plus exposée. Une adresse IP change, mais le fichier reste inchangé.

Autre cause fréquente : désactiver gather_facts partout pour gagner quelques secondes, sans stratégie alternative. C’est parfois légitime sur des playbooks très courts, mais dangereux quand les tâches dépendent du système cible. Enfin, l’absence de cache rend la collecte répétitive et lente, surtout sur des parcs distribués ou des hôtes accessibles via VPN.

Solutions : utiliser gather_facts comme base d’audit Linux

La première solution consiste à structurer un playbook d’audit minimal. Il collecte les facts, extrait les informations utiles, puis produit une sortie lisible. Exemple simple :

---
- name: Audit de base du parc Linux
  hosts: all
  gather_facts: true
  tasks:
    - name: Afficher les informations système clés
      ansible.builtin.debug:
        msg:
          host: "{{ inventory_hostname }}"
          distribution: "{{ ansible_facts.distribution }} {{ ansible_facts.distribution_version }}"
          kernel: "{{ ansible_facts.kernel }}"
          ip: "{{ ansible_facts.default_ipv4.address | default('n/a') }}"
          ram_mb: "{{ ansible_facts.memtotal_mb }}"
          vcpu: "{{ ansible_facts.processor_vcpus | default('n/a') }}"

Ensuite, on peut ajouter des contrôles conditionnels. Par exemple, détecter les serveurs Debian trop anciens :

- name: Signaler les Debian anciennes
  ansible.builtin.debug:
    msg: "{{ inventory_hostname }} doit être planifié pour migration"
  when:
    - ansible_facts.distribution == 'Debian'
    - ansible_facts.distribution_major_version | int < 12

Pour produire un fichier exploitable par une équipe ou une CMDB, on peut déléguer l’écriture au contrôleur Ansible :

- name: Générer une ligne CSV d'inventaire
  ansible.builtin.lineinfile:
    path: ./inventaire-linux.csv
    create: true
    line: "{{ inventory_hostname }},{{ ansible_facts.distribution }},{{ ansible_facts.distribution_version }},{{ ansible_facts.default_ipv4.address | default('n/a') }},{{ ansible_facts.memtotal_mb }}"
  delegate_to: localhost

Ce n’est pas une CMDB parfaite, mais c’est un excellent point de départ : rapide, versionnable, compréhensible, et surtout basé sur des données collectées au moment de l’exécution.

Prévention : performance, cache et sécurité des facts

Sur un parc important, la collecte des facts peut ralentir les exécutions. La réponse n’est pas forcément de tout désactiver, mais de maîtriser ce qui est collecté et quand. Ansible permet d’utiliser un cache de facts afin d’éviter de redemander les mêmes informations à chaque run. Exemple dans ansible.cfg :

[defaults]
gathering = smart
fact_caching = jsonfile
fact_caching_connection = .ansible_facts_cache
fact_caching_timeout = 3600

Le mode smart utilise le cache quand il est disponible et encore valide. C’est utile pour les tableaux d’inventaire, les contrôles de conformité non critiques ou les rapports réguliers. Pour une opération sensible, comme un patch kernel ou une migration, il faut au contraire forcer une collecte fraîche.

Attention également à la confidentialité. Les facts peuvent révéler des adresses IP internes, noms d’hôtes, chemins, informations de virtualisation ou détails matériels. Le cache doit rester sur le contrôleur d’administration, avec des droits restrictifs, et ne doit pas être publié dans un dépôt Git sans nettoyage.

Checklist de mise en œuvre

Erreurs courantes avec Ansible facts

Cas d’usage concrets

FAQ sur Ansible gather_facts

Conclusion

Ansible gather_facts devient vraiment puissant lorsqu’il sort du rôle de simple option technique. Utilisé avec des filtres, un cache maîtrisé et des exports propres, il aide à transformer un inventaire déclaratif en vision exploitable du parc Linux. C’est une brique simple pour mieux auditer, mieux automatiser et réduire les erreurs avant les changements de production.