Module 2 — Ansible avancé : boucles, conditions, faits système

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 8 minutes

Les faits système (facts)

Avant chaque playbook, Ansible exécute automatiquement une étape Gathering Facts : il interroge chaque machine cible et collecte des dizaines d’informations (distribution, version, adresses IP, mémoire, interfaces réseau…) qu’on peut ensuite utiliser dans le playbook. Cette collecte a réellement identifié la cible de ce cours :

TASK [Vérifier la distribution cible (fait collecté automatiquement)]
ok: [target] => {
    "msg": "Distribution détectée : Ubuntu 24.04"
}

Boucles : répéter une tâche sur une liste

vars:
  paquets_supplementaires:
    - htop
    - tree
    - jq

tasks:
  - name: Installer plusieurs paquets via une boucle
    apt:
      name: "{{ item }}"
      state: present
    loop: "{{ paquets_supplementaires }}"

Exécution réelle :

TASK [Installer plusieurs paquets via une boucle] *******
changed: [target] => (item=htop)
changed: [target] => (item=tree)
changed: [target] => (item=jq)

Une seule tâche déclarée, trois paquets installés — sans dupliquer trois fois le même bloc apt.

Conditions : adapter le comportement à la cible

- name: Installer ufw uniquement sur Debian/Ubuntu
  apt:
    name: ufw
    state: present
  when: ansible_os_family == "Debian"

Utile pour un playbook qui doit gérer un parc hétérogène (certains serveurs Debian/Ubuntu, d’autres RedHat/CentOS) sans écrire deux playbooks séparés — la même logique when: peut aussi filtrer sur la version d’OS, la présence d’une variable, ou le résultat d’une tâche précédente.

Un vrai avertissement rencontré en exécutant ce playbook

[DEPRECATION WARNING]: INJECT_FACTS_AS_VARS default to `True` is deprecated,
top-level facts will not be auto injected after the change. This feature
will be removed from ansible-core version 2.24.
Use `ansible_facts["fact_name"]` (no `ansible_` prefix) instead.

Cet avertissement est apparu réellement en exécutant ansible_distribution et ansible_os_family directement (comme dans les exemples ci-dessus) sur la version d’Ansible utilisée pour ce cours (ansible-core 2.21.4). Il documente un vrai changement en cours dans Ansible : historiquement, chaque fait collecté (ansible_distribution, ansible_os_family…) est injecté comme variable de premier niveau en plus d’être rangé dans le dictionnaire ansible_facts. Ce comportement redondant sera retiré en version 2.24 — la forme à privilégier dès maintenant, pour ne pas avoir à réécrire ses playbooks plus tard, est :

# À éviter (fonctionne encore, mais dépréciée)
when: ansible_os_family == "Debian"

# À préférer
when: ansible_facts["os_family"] == "Debian"

La leçon à en tirer : un avertissement de dépréciation dans la sortie d’un outil n’est pas du bruit à ignorer — c’est un préavis concret, avec la version exacte où le comportement disparaîtra. Un playbook écrit aujourd’hui avec ansible_os_family continuera de fonctionner sur cette version, mais cassera silencieusement de préoccupation en préoccupation à mesure qu’Ansible est mis à jour, si personne ne migre vers ansible_facts["os_family"] entre-temps.

Vérifier un résultat sans modifier l’état

- name: Vérifier que les paquets demandés sont bien installés
  command: dpkg -l {{ item }}
  loop: "{{ paquets_supplementaires }}"
  register: verif_paquets
  changed_when: false

changed_when: false indique explicitement à Ansible que cette tâche est une vérification en lecture seule — même si le module générique command ne peut pas le déterminer lui-même (contrairement à apt ou service, qui savent nativement détecter s’ils ont changé quelque chose). Sans cette ligne, Ansible marquerait la tâche changed à chaque exécution, cassant l’idempotence apparente du rapport final.

Rôles : structurer un playbook qui grossit

Un seul fichier playbook.yml devient vite ingérable au-delà de quelques dizaines de tâches. Un rôle Ansible impose une structure de dossiers standard, réutilisable d’un projet à l’autre :

roles/
  nginx/
    tasks/main.yml       # les tâches (ce qu'on a vu jusqu'ici)
    handlers/main.yml    # les handlers
    templates/           # fichiers Jinja2 (ex: nginx.conf.j2)
    defaults/main.yml     # valeurs par défaut, surchargeables
    vars/main.yml         # variables propres au rôle

- hosts: webservers
  become: true
  roles:
    - nginx
    - monitoring

L’intérêt : le rôle nginx de cet exemple pourrait être publié et réutilisé tel quel sur n’importe quel projet — c’est exactement le principe d’Ansible Galaxy, la place de marché communautaire de rôles Ansible prêts à l’emploi (l’équivalent, pour Ansible, du Terraform Registry ou de l’Actions Marketplace de GitHub).

Prochaine étape

Observabilité : Prometheus, Grafana et ELK Stack