Écrire du code Ansible : variables, facts, contrôle de flux, templates Jinja2

Cette section couvre la couche cœur métier d’Ansible : tout ce qui transforme un assemblage de tâches en code maintenable, lisible et réutilisable. Au programme : structure de projet 2026, playbooks avec pre_tasks/tasks/handlers/tags, 22 niveaux de précédence des variables (objectif RHCE explicite), contrôle de flux (when, loop, block/rescue/always), et templates Jinja2. C’est la section la plus volumineuse du parcours et celle qui pèse ~70 % de l’examen RHCE EX294.

Aller droit au but

🚀 YAML & structure de projet Pièges YAML 1.2, ansible.cfg, group_vars, inventory — la base avant tout

📚 Playbooks (pré/post/handlers/tags) Structurer un play, déclencher des handlers, scoper avec des tags

🎯 Variables & facts (RHCE) 22 niveaux de précédence, magic vars, register, set_fact, lookups

🔥 Contrôle de flux & Jinja2 when, loop, block/rescue, templates Jinja2, filtres essentiels

Pressé ? L'ordre d'attaque en 30 secondes

1. YAML : maîtriser les booléens (true/false jamais yes/no), les multilines (| vs >), les ancres.
2. Structure : ansible.cfg à la racine, inventory/, group_vars/all.yml, roles/, collections/ — un projet propre dès le départ.
3. Playbook minimal : un play avec tasks: + handlers: + tags: + module dédié (jamais command:).
4. Variables : connaître les 3 niveaux qui comptent en pratique (defaults rôle / group_vars / --extra-vars).
5. Jinja2 : un template: avec validate: qui valide la conf avant écriture (nginx -t -c %s).

Ce que vous allez apprendre

• Structurer un projet Ansible avec ansible.cfg, inventory/, group_vars/, host_vars/, roles/, collections/, playbooks/ ;
• Maîtriser YAML 1.2 et ses pièges (booléens, multilines, ancres) sans tomber dans les classiques ;
• Écrire des plays multiples par playbook avec pre_tasks, tasks, post_tasks, handlers, roles ;
• Manipuler variables, facts, magic vars et la précédence officielle Ansible (22 niveaux) ;
• Contrôler le flux avec when:, loop:, block/rescue/always, failed_when, changed_when, any_errors_fatal ;
• Générer des fichiers via le module template + Jinja2 (filtres, tests, whitespace control).

Prérequis

Avant d’attaquer cette section, vous devez avoir :

• Validé le quiz Découvrir Ansible (idempotence, push SSH, ansible.cfg) ;
• Validé le quiz Premiers pas (lab opérationnel, premier playbook, debug) ;
• Un lab fonctionnel avec ansible all -m ping qui répond pong sur les 4 hôtes.

C'est ici que l'IA ment le mieux

Les copilots produisent du Jinja2 confiant qui ressemble à du code Ansible. Mais 80 % des bugs en prod viennent de cette section : un booléen YAML mal cité, un loop sur un dict mal compris, une variable qui surcharge silencieusement à cause de la précédence. Le YAML qui passe le linter n’est pas du YAML qui tient en prod. Cette section vous apprend à anticiper les pièges, pas seulement à produire du code qui démarre.

---

Mon retour d’expérience — pour ceux qui veulent comprendre

Si l’une des cartes en haut de page vous a déjà orienté, vous êtes parti sur le bon pied. La suite de cette page s’adresse à ceux qui veulent comprendre la philosophie de cette section : pourquoi je m’attarde sur la précédence des variables, pourquoi je préfère loop: même quand with_items marche, pourquoi un playbook lisible bat toujours un playbook concis.

C’est dans cette section que se jouent les plus gros bugs subtils d’une infra Ansible. J’ai passé des nuits à débugger des playbooks où une variable group_vars/all.yml était silencieusement écrasée par un --extra-vars mal documenté. Ce sont les sujets que la doc officielle expédie en deux paragraphes alors qu’ils méritent une heure de pratique. Les sections qui suivent compilent les habitudes que je n’aurais jamais relâchées sur un projet sérieux.

Ce que je défends pour le code Ansible

Cinq positions tranchées que cette section assume :

• YAML 1.2 strict, jamais YAML 1.1. true/false partout, jamais yes/no/on/off. Une casse de version YAML peut transformer enable_https: yes en string. Le pipeline de lint doit refuser les booléens YAML 1.1.
• FQCN obligatoire (ansible.builtin.copy, jamais copy). Le module non qualifié peut être shadowé par une collection installée plus tard. Lisibilité + future-proofing — c’est aussi un objectif RHCE explicite.
• loop: partout, plus de with_items/with_dict sauf cas exotique justifié en commentaire. La syntaxe moderne est plus expressive et c’est la norme RHCE 2026.
• Précédence connue par cœur des 5 niveaux qui comptent : defaults rôle (1) < group_vars (5–6) < host_vars (7) < task vars: (16) < --extra-vars (22). Le reste, on le retrouve dans la doc — mais ces 5 sont vitaux.
• changed_when + failed_when pour toute tâche command:/shell:. Sans ça, command: est changed: true à chaque exécution et casse l’idempotence. Si vous écrivez command:, écrivez immédiatement changed_when:.

Ce que je vous interdis

Cinq anti-patterns que cette section refuse — chacun vu plusieurs fois en revue de code :

• command: dnf install -y nginx alors que ansible.builtin.dnf existe. Cas typique du « ça marche une fois ». Le module dédié gère l’idempotence, le check mode, le diff. Toujours chercher le module dédié avant command:/shell:.
• Variables critiques dans vars/main.yml d’un rôle. Précédence trop haute, l’utilisateur ne peut pas surcharger. Toute variable destinée à être customisée va dans defaults/main.yml — vars/ réservé aux constantes internes.
• ignore_errors: true pour faire taire un bug. Le bug ne disparaît pas, il devient invisible — et explose 6 mois plus tard sur une autre task qui dépend implicitement du résultat. block/rescue/always ou failed_when ciblé, jamais ignore_errors global.
• Templates Jinja2 sans validate:. Générer un nginx.conf cassé sur 50 serveurs en parallèle, c’est 50 nginx qui refusent de redémarrer. validate: 'nginx -t -c %s' valide avant écriture — non négociable pour toute conf critique.
• Playbooks « clever » qui exploitent 4 niveaux de Jinja2 imbriqués pour économiser 3 lignes. Le code que vous lirez à 2 h du matin doit être trivial. Privilégier la lisibilité, toujours.

Le parcours en 5 sous-sections

Le parcours est séquentiel : chaque sous-section suppose acquis ce qui précède.

1. Fondations

Mise au point sur YAML, structure de projet, conventions de style — la base avant de coder le moindre playbook avancé.

YAML pour Ansible YAML 1.2, types, ancres et alias, multiline (|, >), pièges yes/no/octets non-cités

Structure d'un projet Ansible ansible.cfg, inventory/, group_vars/, host_vars/, roles/, collections/, requirements.yml

Style guide Ansible Conventions de nommage, FQCN, indentation, commentaires — la cohérence sur une équipe

2. Playbooks

Le format de référence : plays multiples, pre/post-tasks, handlers, tags, parallélisme, asynchrone, délégation.

Sous-section en cours de rédaction

Cette sous-section est planifiée mais pas encore livrée. Les pages arriveront page par page selon la roadmap.

3. Variables et facts

La couche la plus dense pour la RHCE : les 22 niveaux de précédence, les magic vars, le register:/set_fact, les lookups, les filtres Jinja2 essentiels.

Sous-section en cours de rédaction

Cette sous-section est planifiée. La page sur la précédence des variables est explicitement dans les objectifs RHCE EX294.

4. Contrôle de flux

when:, loop:, block/rescue/always, failed_when, changed_when, ignore_errors, any_errors_fatal.

Sous-section en cours de rédaction

Cette sous-section est planifiée.

5. Templates Jinja2

Génération de fichiers : syntaxe Jinja2, filtres profonds, tests, module template, comparaison avec lineinfile.

Sous-section en cours de rédaction

Cette sous-section est planifiée.

La place dans la RHCE EX294

Cette section couvre environ 70 % des objectifs RHCE EX294 :

Objectif RHCE	Couvert par
Créer playbooks simples et avancés	Playbooks/Plays et tasks
Utiliser variables (host, group, register, facts, magic)	Variables-facts (8 pages)
Utiliser conditionnels et boucles	Contrôle de flux (7 pages)
Utiliser handlers	Playbooks/Handlers
Utiliser tags	Playbooks/Tags
Manipuler les facts	Variables-facts/Facts et magic vars
Gérer le parallélisme	Playbooks/Parallélisme et stratégies
Gérer les erreurs (block/rescue, failed_when)	Contrôle de flux/Block-rescue-always + failed_when
Templates Jinja2	Templates Jinja2 (5 pages)
Mode check et diff	Playbooks/check et diff

Glissez pour voir

Ce qui n’est pas dans cette section : Modules (section dédiée modules/), Rôles (section dédiée roles/), Collections (section dédiée collections/), Vault (section dédiée securite-vault/).

Quiz de la section

Le quiz ecrire-code/quiz (à venir) totalise environ 50 questions sur les 5 sous-sections, alignées sur les objectifs RHCE EX294. Chaque question pointe vers le guide unitaire qui justifie la réponse.

Prochaines étapes

Une fois ecrire-code/ validé, vous attaquez Modules (les modules de base pour la RHCE : dnf, yum, service, systemd, file, copy, template, user, group, firewalld, selinux, mount, lvol, parted, cron, git, archive, unarchive, uri, wait_for).

Retour à Premiers pas Revenir à la base si certaines notions de cette section vous ont surpris

Index Ansible (vue d'ensemble du parcours) Toutes les sections : découvrir, premiers pas, écrire du code, modules, rôles, collections, Vault

×

📖 Voir la documentation →