Module service_facts Ansible : auditer l'état des services systemd

ansible.builtin.service_facts: collecte l'état de tous les services systemd d'un managed node, running/stopped, enabled/disabled, masked. C'est l'outil pour conditionner une tâche ou auditer un parc sans parser à la main systemctl list-units.

Le résultat atterrit dans ansible_facts.services sous forme de dict, directement utilisable dans when: ou un template Jinja.

Ce que vous allez apprendre

• Collecter l'état de tous les services en une tâche.
• Conditionner un started: ou enabled: selon l'état actuel.
• Auditer un parc (services attendus, services en trop).
• Éviter les redémarrages inutiles sur des plays massifs.

Prérequis

• Pas besoin de become: (lecture seule).
• Fonctionne sur systemd, upstart, sysv, AIX SRC, OpenWrt.

Collecter et afficher l'état d'un service

- name: Collecter les services
  ansible.builtin.service_facts:

- name: Etat de nginx
  ansible.builtin.debug:
    msg: "{{ ansible_facts.services['nginx.service'].state }}"

Structure du dict retourné :

ansible_facts:
  services:
    nginx.service:
      state: running
      status: enabled
      source: systemd

state = running, stopped, unknown. status = enabled, disabled, static, masked.

Démarrer un service uniquement s'il est arrêté

- name: Collecter les services
  ansible.builtin.service_facts:

- name: Demarrer nginx si arrete
  ansible.builtin.systemd_service:
    name: nginx.service
    state: started
  when: ansible_facts.services['nginx.service'].state != 'running'

Avantage idempotent : sans service_facts, systemd_service: state: started reste idempotent au niveau API, mais Ansible affiche ok même quand le service n'est pas vraiment vérifié. Ici, vous lisez d'abord l'état et n'agissez que si nécessaire, utile pour des rapports ou des handlers conditionnels.

Activer un service au démarrage si besoin

- name: Collecter les services
  ansible.builtin.service_facts:

- name: Activer chronyd au boot
  ansible.builtin.systemd_service:
    name: chronyd.service
    enabled: true
  when: ansible_facts.services['chronyd.service'].status != 'enabled'

status: distingue enabled (démarrage auto), disabled, static (pas d'unit [Install], démarré seulement si dépendance), masked (interdit de démarrer).

Auditer la présence d'un service

Pattern fréquent : vérifier que tous les services attendus sont installés sur un parc.

- name: Collecter les services
  ansible.builtin.service_facts:

- name: Verifier que firewalld est installe
  ansible.builtin.assert:
    that:
      - "'firewalld.service' in ansible_facts.services"
    fail_msg: "firewalld absent : installer le paquet"

'firewalld.service' in ansible_facts.services teste juste la présence du dict, pas l'état. Service installé même si désactivé → la clé existe.

Détecter les services masked (potentiellement dangereux)

- name: Collecter les services
  ansible.builtin.service_facts:

- name: Lister les services masked
  ansible.builtin.debug:
    msg: "{{ item.key }}"
  loop: "{{ ansible_facts.services | dict2items }}"
  when: item.value.status == 'masked'

Un service masked ne peut pas être démarré, utile pour valider qu'un service n'a pas été désactivé en urgence par un opérateur et oublié.

Pièges courants

Les quatre lignes ci-dessous décrivent le même geste manquant, vérifier avant d'accéder. Une clé absente ne signale pas une panne du module mais un service non installé, un state: unknown et un status manquant trahissent un gestionnaire d'initialisation qui n'est pas systemd, et la lenteur vient d'une collecte répétée alors que les facts la conservent pour tout le play. Lire la colonne Fix donne à chaque fois le test à poser en amont.

Symptôme	Cause	Fix
KeyError: 'nginx.service'	Service pas installé, accès direct	Tester d'abord 'nginx.service' in ansible_facts.services
Service présent mais state: unknown	Service non systemd, ou lecture incomplète	Vérifier via systemctl status à la main
Lent sur grandes machines (> 200 services)	Pas de cache	Lancer une fois en début de play, réutiliser ensuite
status absent dans certains résultats	Backend non systemd (sysv)	Tester .state plutôt que .status

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• service_facts: = lecture pure, pas d'écriture, pas de state:.
• Résultat dans ansible_facts.services, dict indexé par nom complet (nginx.service).
• state : running/stopped, status : enabled/disabled/static/masked.
• Combiner avec assert pour auditer la conformité d'un parc.
• Lancer une seule fois en début de play, les facts persistent.

Pour aller plus loin

• debug, setup, add_host, group_by : La même famille d'introspection : setup pour recollecter les facts, debug pour les afficher.
• Découvrir les rôles : Ranger ces playbooks d'audit dans une unité réutilisable au lieu de les copier de projet en projet.
• Handlers et meta : L'autre façon de piloter un service : le notifier pour ne le redémarrer que si quelque chose a changé.

×

📖 Voir la documentation →