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.

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
      changed_when: true

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é

Glissez pour voir

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:
    - name: Déployer la version cible de l'application
      ansible.builtin.dnf:
        name: "app-{{ app_version }}"
        state: present

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
      changed_when: true

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
      changed_when: true

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

Voici l'exemple validé sur le lab 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"
        mode: "0644"

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 :

- name: Grouper les tâches liées
  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

Un seul symptôme revient plus que tous les autres : un play déclaré any_errors_fatal: true poursuit sa route après un échec visible. Avant de soupçonner la directive, cherchez un rescue:. Un rescue: traite l'échec et rend la main, donc du point de vue du play la tâche n'a plus échoué et rien ne se propage aux autres hôtes. C'est la première chose à relire, avant le serial: et avant la version d'Ansible. Le tableau reprend ce cas et les quatre autres, chacun avec la cause qui ne se devine pas depuis la sortie.

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

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

• 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.

Mettre en pratique

Un arrêt immédiat se juge sur un play réel, pas sur un extrait. Le lab vous fait activer any_errors_fatal: true sur un play multi-hôtes, comparer le résultat au comportement par défaut puis à max_fail_percentage, et observer ce que donne la combinaison avec serial:. La validation porte sur l'état des hôtes à la fin du play, donc sur la propagation réelle de l'échec plutôt que sur la syntaxe écrite.

Lab pratique

any_errors_fatal : arrêter le play à la première erreur

$ dsoxlab run ecrire-code-any-errors-fatal

Environnement : VM·Durée : ~50 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run ecrire-code-any-errors-fatal
dsoxlab check ecrire-code-any-errors-fatal

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Pour aller plus loin

• Quiz Écrire du code : 30 questions pour valider tout le bloc « Écrire du code » avant d'attaquer les inventaires.
• Inventaires statiques : any_errors_fatal raisonne sur un ensemble d'hôtes, et l'inventaire est ce qui le définit.
• Patterns d'hôtes : réduire le périmètre d'un play avec --limit avant de le rendre bloquant à la moindre erreur.

×

📖 Voir la documentation →