Cette sous-section couvre la couche conditionnelle d’Ansible : exécuter une tâche seulement si une condition est vraie, boucler sur une liste, gérer les erreurs proprement. C’est ce qui transforme un playbook linéaire (toutes les tâches s’exécutent dans l’ordre) en un playbook adaptatif (chaque tâche s’exécute si pertinent, gère ses erreurs sans casser le reste).
Vous y apprenez when: (la condition la plus simple), loop: (la boucle moderne, qui remplace with_items:), les blocs block/rescue/always (équivalent try/catch/finally), et les redéfinitions de sémantique avec failed_when:, changed_when:, ignore_errors:, any_errors_fatal:.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »when:: conditionner une tâche sur une expression Jinja2loop:: itérer sur une liste, dict, ou résultat de lookupwith_*legacy : pourquoi privilégierloop:aujourd’huiblock / rescue / always: gestion d’erreur structurée (équivalent try/catch/finally)failed_when:etchanged_when:: redéfinir succès et changementignore_errors: true: usage légitime vs anti-patternany_errors_fatal: true: arrêter le play sur 1ère erreur cluster
Prérequis
Section intitulée « Prérequis »- Avoir lu les sous-sections Fondations et Playbooks
- Avoir lu Variables et facts (les conditions s’appuient souvent sur des variables/facts)
Le parcours en 7 pages
Section intitulée « Le parcours en 7 pages » Conditions — when Syntaxe when:, opérateurs, multi-conditions (and/or), tests Jinja, conditions sur facts
Boucles — loop loop: moderne, loop_control: label/index_var/pause, boucles sur dicts via dict2items
Boucles legacy with_* with_items, with_dict, with_subelements — pourquoi privilégier loop: et comment migrer
Block / rescue / always Gestion d'erreur structurée : équivalent try / catch / finally
failed_when et changed_when Redéfinir le succès et le statut changed sur command/shell, exemples concrets
ignore_errors Usage légitime vs anti-pattern, alternatives plus propres
any_errors_fatal Arrêter le play sur 1ère erreur cluster (rolling deploy strict)
La place dans la RHCE EX294
Section intitulée « La place dans la RHCE EX294 »| Objectif RHCE | Couvert par |
|---|---|
| Utiliser conditionnels et boucles | Conditions when + Boucles loop |
| Gérer les erreurs (block/rescue/always, failed_when) | Block-rescue-always + failed-when-changed-when |
Ces sujets sont explicites dans le blueprint EX294.
Pièges classiques
Section intitulée « Pièges classiques »when:qui pose une string au lieu d’une condition :when: "{{ var == 'prod' }}"est faux ; la bonne forme estwhen: var == 'prod'(sans Jinja, sans quotes).loop:qui ne déclenche pas le handler à chaque itération : un handler notify n’est levé qu’une fois quel que soit le nombre d’itérations changed.block:sansrescue:: les erreurs ne sont pas capturées, c’est juste un grouping visuel.ignore_errors: truepartout : masque les vraies erreurs, anti-pattern. Préférerfailed_when:ciblé.
Prochaines étapes
Section intitulée « Prochaines étapes » Conditions — when Démarrer la sous-section par la condition la plus simple
Retour à Variables et facts Si certaines notions de variable/fact vous manquent pour les conditions
Sous-section suivante : Templates Jinja2 (à venir) jinja2-base, filtres en profondeur, tests, module template, lineinfile vs template