any_errors_fatal Ansible : arrêter le play sur 1ère erreur cluster

Par défaut, si une tâche échoue sur un hôte mais réussit sur les autres, Ansible continue le play sur les hôtes restants. Avec any_errors_fatal: true au niveau du play, dès qu’une tâche échoue sur n’importe quel hôte, le play s’arrête net pour tous les hôtes. C’est l’inverse philosophique d’ignore_errors: — ici on veut une opération atomique sur le cluster : soit toutes les machines sont OK, soit on arrête tout.

C’est l’outil pour les rolling updates stricts ou les migrations cluster où une moitié-réussite est pire qu’un échec total.

# Rolling update strict : 1 host à la fois, arrêt total au 1er échec
- hosts: webservers
  become: true
  serial: 1
  any_errors_fatal: true        # tout s'arrête au 1er échec, même les autres hôtes
  tasks:
    - name: Drainer du load-balancer
      ansible.builtin.command: /usr/local/bin/lb-drain {{ inventory_hostname }}
      delegate_to: lb1.lab

    - name: Upgrade applicatif
      ansible.builtin.dnf:
        name: myapp
        state: latest

    - name: Healthcheck après upgrade
      ansible.builtin.uri:
        url: http://localhost:8080/health
        status_code: 200
        timeout: 30

    - name: Réintégrer dans le LB
      ansible.builtin.command: /usr/local/bin/lb-enable {{ inventory_hostname }}
      delegate_to: lb1.lab

Sécurité non négociable :

any_errors_fatal: true sur les migrations cluster (etcd, Galera, MongoDB) — une moitié-réussite est pire qu’un échec total, parce qu’elle laisse le cluster dans un état non supporté.
serial: 1 + any_errors_fatal: true = rolling update strict : 1 host à la fois, arrêt immédiat au premier échec → le 2ᵉ host n’est jamais touché. État connu et récupérable.
max_fail_percentage: 0 est une variante : tolère un % d’échec acceptable (max_fail_percentage: 25 = 25 % max). any_errors_fatal: est le cas particulier 0 %.
Les handlers ne s’exécutent PAS quand any_errors_fatal: arrête le play sur échec — utiliser block/rescue/always si vous voulez un nettoyage forcé.

Ce que vous allez apprendre

L’effet de any_errors_fatal: true au niveau du play
La différence avec max_fail_percentage: 0
Cas d’usage : rolling update strict, migration de schéma, opération all-or-nothing
Combinaison avec serial:

Prérequis

Avoir lu Plays et tasks (notion de play multi-hôtes) ;
Avoir lu Parallélisme et stratégies (serial:, max_fail_percentage:).

La syntaxe

- name: Migration cluster atomique
  hosts: webservers
  any_errors_fatal: true
  tasks:
    - name: Tâche critique
      ansible.builtin.command: /usr/local/bin/migrate.sh

Si migrate.sh échoue sur n’importe quel webserver, le play s’arrête immédiatement — même les hôtes qui ont réussi voient leurs tâches suivantes non exécutées.

Différence avec `max_fail_percentage:`

Les deux directives sont liées mais subtilement différentes :

Directive	Effet
`any_errors_fatal: true`	Arrête le play dès la 1ère erreur sur n’importe quel hôte
`max_fail_percentage: 0`	Arrête le play si plus de 0% des hôtes du batch courant ont échoué (= dès la 1ère erreur du batch, pour le batch courant)
`max_fail_percentage: 30`	Arrête si plus de 30% du batch a échoué

Avec serial:, la nuance compte : max_fail_percentage: 0 arrête seulement le batch courant, any_errors_fatal: true arrête tout immédiatement.

# Rolling update : arrêter dès qu'un hôte échoue, pas continuer sur les autres
- name: Déploiement cluster strict
  hosts: webservers
  serial: 1
  any_errors_fatal: true
  tasks: [...]

Sur 5 webservers en serial: 1, si web2 échoue, web3, web4, web5 ne sont pas déployés (au lieu de l’être avec un comportement par défaut).

Cas d’usage

Migration de schéma DB cluster

- name: Migrer le schéma sur tous les replica
  hosts: dbservers
  any_errors_fatal: true
  tasks:
    - name: Lancer la migration
      ansible.builtin.command: /usr/local/bin/migrate-schema.sh

Si la migration échoue sur un seul replica, vous voulez arrêter immédiatement plutôt que continuer et créer des replica désynchronisés.

Renouvellement de certificats simultané

- name: Renouveler les certificats sur tout le cluster
  hosts: all
  any_errors_fatal: true
  tasks:
    - name: Lancer certbot
      ansible.builtin.command: /usr/bin/certbot renew --no-self-upgrade

Si un nœud échoue, on arrête plutôt que de partager des certificats expirant à des moments différents.

Arrêt synchrone de service

- name: Arrêter un service partout en même temps (maintenance)
  hosts: webservers
  any_errors_fatal: true
  tasks:
    - name: Stopper le service
      ansible.builtin.systemd:
        name: app
        state: stopped

Avant une maintenance globale, vous voulez soit tout arrêter, soit rien — un état partiel laisse des hôtes inutilisables tandis que d’autres tournent.

Cas pratique — validation syntaxe (lab `ecrire-code/any-errors-fatal`)

Voici l’exemple validé sur le lab 25-ecrire-code-any-errors-fatal :

- name: Challenge any errors fatal
  hosts: webservers
  become: true
  any_errors_fatal: true
  tasks:
    - name: Marqueur sans erreur
      ansible.builtin.copy:
        dest: "/tmp/anyfatal-{{ inventory_hostname }}.txt"
        content: "any_errors_fatal OK\n"

Sans erreur réelle, le play tourne normalement et pose 2 fichiers (web1 + web2). Pour prouver que any_errors_fatal: true arrête tout, il faudrait injecter une erreur — ce qui casserait le test (le play s’arrête en failed).

Le comportement réel se vérifie en injectant volontairement un échec : on observe alors que tous les webservers ont leurs tâches suivantes non exécutées.

`any_errors_fatal` au niveau task ou block

any_errors_fatal: est une directive de play par défaut. Depuis Ansible 2.7, on peut aussi la poser au niveau block :

- block:
    - name: Tâche critique 1
      ...
    - name: Tâche critique 2
      ...
  any_errors_fatal: true

Effet : l’échec d’une tâche du block sur n’importe quel hôte arrête le play. Hors du block, le comportement par défaut reprend.

Pièges fréquents

Symptôme	Cause	Fix
`any_errors_fatal: true` au niveau task	Pas supporté	Le mettre au niveau play ou block
Play s’arrête trop vite avec une erreur “secondaire”	C’est le comportement attendu	Considérer `max_fail_percentage:` plus permissif si la tolérance est OK
Combiné avec `ignore_errors: true`	`ignore_errors:` neutralise l’effet	Choisir l’un ou l’autre
Combiné avec `block/rescue`	Le rescue peut “capturer” et neutraliser any_errors_fatal	Bien réfléchir à l’interaction
`serial: 1` + `any_errors_fatal: true` mais le play continue après échec	Vérifier qu’il n’y a pas un block/rescue qui capture	Logiquement, `any_errors_fatal` doit gagner sauf rescue

À retenir

any_errors_fatal: true au niveau play : arrête le play dès la 1ère erreur sur n’importe quel hôte.
Différent de max_fail_percentage: 0 qui agit sur le batch courant (avec serial:).
Cas d’usage : migration cluster atomique, renouvellement de certificats, arrêt synchrone de service.
Combiné avec serial: strict : un seul échec arrête tout le rolling update.
Disponible aussi au niveau block depuis Ansible 2.7.

Pratiquer dans le lab

Cette page a un lab d’accompagnement : labs/ecrire-code/any-errors-fatal/ dans stephrobert/ansible-training. Il contient un README.md guidé, un Makefile (make verify lance les tests), et un challenge final auto-évalué : play avec any_errors_fatal: true sur webservers (validation de la syntaxe sans erreur).

Une fois le lab provisionné :

cd ~/Projets/ansible-training/labs/ecrire-code/any-errors-fatal/

cat README.md           # tuto pas à pas
cat challenge/README.md # consigne du challenge final
pytest -v challenge/tests/   # lancer les tests testinfra

Si les tests passent, vous maîtrisez les concepts couverts dans ce guide. En cas de blocage, docs/troubleshooting.md à la racine du repo couvre les pièges fréquents (rate-limit SSH, clé absente, collection manquante).

Prochaines étapes

Retour à la sous-section Contrôle de flux Index pivot des 7 pages (when, loop, with_*, block/rescue, failed_when, ignore_errors, any_errors_fatal)

Parallélisme et stratégies Combiner serial:, max_fail_percentage:, any_errors_fatal: pour les rolling updates stricts

Sous-section suivante : Templates Jinja2 (à venir) jinja2-base, filtres en profondeur, tests, module template, lineinfile vs template