ignore_errors Ansible : usage légitime vs anti-pattern

ignore_errors: true indique à Ansible de ne pas considérer une tâche en échec comme bloquante — le play continue malgré l’erreur. C’est une directive simple à utiliser mais souvent un anti-pattern : elle masque les vraies erreurs, rend le diagnostic difficile, et peut laisser un système dans un état incohérent. Cette page liste les rares cas légitimes d’usage, et explique pourquoi failed_when: ou block/rescue/always sont presque toujours préférés.

ansible-lint profil production signale les ignore_errors: true comme problème (ignore-errors) — sauf certaines exceptions documentées.

Pressé ? `ignore_errors` est presque toujours un anti-pattern

Avant d’écrire ignore_errors: true, posez-vous la question :

• Est-ce que failed_when: <condition> ferait mieux ? (cibler quelle erreur est acceptable)
• Est-ce que block/rescue/always ferait mieux ? (gérer l’erreur explicitement)
• Est-ce que cette tâche devrait vraiment échouer mais je veux que le play continue ?

Les 3 seuls cas légitimes :

# 1. Tâche de cleanup qui peut échouer si rien à nettoyer
- name: Supprimer un lock file (peut ne pas exister)
  ansible.builtin.file:
    path: /var/lock/myapp.lock
    state: absent
  ignore_errors: true        # OK : le résultat ne change rien à la suite

# 2. Diagnostic non bloquant (logs verbeux pour debug)
- name: Lister les ports ouverts (info, pas critique)
  ansible.builtin.command: ss -tlnp
  register: ports_info
  changed_when: false
  ignore_errors: true        # OK : si ss n'est pas dispo, pas grave

# 3. Compatibilité multi-distro où une tâche n'a de sens que sur certains OS
# (préférer un when: explicite, mais ignore_errors est un fallback)

Ce qu’il NE FAUT PAS faire : ignore_errors: true sur une tâche métier (install, config, démarrage de service). Vous masquez le bug, le service est cassé, mais le PLAY RECAP affiche ok=N changed=N failed=0 — vous croyez que tout va bien.

Préférer dans 95 % des cas : failed_when: <condition> (cibler l’erreur acceptable) ou block/rescue/always (gérer explicitement).

Ce que vous allez apprendre

• L’effet de ignore_errors: true (la tâche échouée est marquée ignored, le play continue)
• Les 3 cas légitimes où c’est justifié
• Pourquoi failed_when: est souvent une meilleure réponse
• Pourquoi block/rescue/always est presque toujours plus propre
• L’impact dans le PLAY RECAP : ignored=N

🧪 Lab d'accompagnement

Cette page est jumelée au lab labs/ecrire-code/ignore-errors/ dans stephrobert/ansible-training. Détails et commandes en bas de page : Pratiquer dans le lab.

Prérequis

• Avoir lu failed_when et changed_when ;
• Avoir lu Block / rescue / always.

L’effet de ignore_errors: true

- name: Tâche qui échoue
  ansible.builtin.command: /bin/false
  ignore_errors: true

- name: Tâche suivante (s'exécute quand même)
  ansible.builtin.debug:
    msg: "Le play continue"

PLAY RECAP : ok=1 changed=1 failed=0 ignored=1. La tâche en échec est marquée ignored=1 (visible dans le RECAP), le play continue.

Les 3 cas légitimes

Cas 1 — Cleanup best-effort

Une opération de cleanup où l’échec n’est pas critique :

- name: Tenter de stopper un service (peut ne pas exister)
  ansible.builtin.systemd:
    name: legacy-service
    state: stopped
  ignore_errors: true

Si le service n’existe pas, on s’en fiche — c’est exactement ce qu’on voulait. Mais mieux :

# ✅ Plus propre avec failed_when:
- name: Tenter de stopper un service legacy
  ansible.builtin.systemd:
    name: legacy-service
    state: stopped
  failed_when: false

failed_when: false est explicite : “ne jamais marquer cette tâche comme failed”.

Cas 2 — Test conditionnel sur un fait

Vérifier la présence d’un binaire pour conditionner les tâches suivantes :

- name: Vérifier la présence de docker
  ansible.builtin.command: which docker
  register: docker_check
  ignore_errors: true
  changed_when: false

- name: Configurer Docker (si présent)
  ansible.builtin.copy:
    src: daemon.json
    dest: /etc/docker/daemon.json
  when: docker_check.rc == 0

Mieux : failed_when: false ou block/rescue :

# ✅ failed_when: false plus explicite
- name: Vérifier la présence de docker
  ansible.builtin.command: which docker
  register: docker_check
  changed_when: false
  failed_when: false

Cas 3 — Opération attendue d’échouer dans un block/rescue

Très rarement utile, car block/rescue capture déjà les erreurs proprement :

- block:
    - name: Tenter une opération
      ansible.builtin.command: /usr/local/bin/risky.sh
      ignore_errors: true     # ← inutile dans un block

  rescue:
    - name: Cleanup
      ansible.builtin.debug:
        msg: "Erreur capturée"

ignore_errors: à l’intérieur d’un block empêche le rescue de se déclencher (puisque la tâche n’est plus marquée failed). À éviter.

Pourquoi ignore_errors: true est un anti-pattern

Trois raisons :

1. Masque les vraies erreurs : un échec inattendu ne lève plus la main. Le bug se manifeste plus tard, ailleurs, sans contexte.

2. Pollue le diagnostic : un ignored=12 dans le PLAY RECAP est inutilement alarmant — vous devez chercher dans les logs lesquelles ont vraiment échoué.

3. Empêche block/rescue : si vous mettez ignore_errors: true dans un block, le rescue n’est jamais déclenché. Vous perdez le bénéfice de la gestion structurée.

Cas pratique — ignore_errors dans un play simple (lab ecrire-code/ignore-errors)

Voici l’exemple validé sur le lab 24-ecrire-code-ignore-errors :

- name: Challenge ignore errors
  hosts: db1.lab
  become: true
  tasks:
    - name: Stopper un service inexistant
      ansible.builtin.systemd:
        name: ce-service-nexiste-pas
        state: stopped
      ignore_errors: true

    - name: Marqueur post ignore
      ansible.builtin.copy:
        dest: /tmp/ignore-after.txt
        content: "play continued\n"
        mode: "0644"

PLAY RECAP : ok=1 changed=1 failed=0 ignored=1. La tâche suivante s’est bien exécutée.

Réécriture préférée sans ignore_errors: :

- name: Stopper un service legacy si présent
  ansible.builtin.systemd:
    name: ce-service-nexiste-pas
    state: stopped
  failed_when: false       # ← explicite, pas de "ignored" dans RECAP

Comparatif des alternatives

Mécanisme	Avantage	Inconvénient
ignore_errors: true	Simple à écrire	Masque les erreurs ; pollue PLAY RECAP
failed_when: false	Explicite : “jamais d’échec”	À utiliser avec parcimonie aussi
failed_when: <expr>	Précis : on définit ce qui constitue un échec	Plus verbeux
block / rescue / always	Capture + réagit (notification, cleanup)	Plus de structure

Glissez pour voir

Règle pratique : si vous écrivez ignore_errors: true, demandez-vous d’abord si l’une des 3 alternatives ne ferait pas mieux. Dans 99 % des cas, oui.

Pièges fréquents

Symptôme	Cause	Fix
ignored=N dans PLAY RECAP, on ne sait pas quoi a échoué	C’est par design	Préférer failed_when: ou block/rescue qui montrent le détail
ignore_errors: true dans un block, le rescue ne se déclenche pas	C’est attendu	Retirer ignore_errors: ; laisser le rescue capturer
ansible-lint signale ignore-errors	Anti-pattern détecté	Migrer vers failed_when: ou block/rescue
ignore_errors: true cumulé avec failed_when:	Comportement ambigu	Choisir l’un ou l’autre, pas les deux

Glissez pour voir

À retenir

• ignore_errors: true marque la tâche ignored=1 mais ne fait pas planter le play.
• 3 cas légitimes — mais dans 99 % des cas, failed_when: ou block/rescue sont préférés.
• failed_when: false est plus explicite que ignore_errors: true pour “ne jamais échouer”.
• ignore_errors: true dans un block empêche le rescue — anti-pattern.
• ansible-lint profil production signale ignore-errors comme un problème.

Pratiquer dans le lab

Cette page a un lab d’accompagnement : labs/ecrire-code/ignore-errors/ dans stephrobert/ansible-training. Il contient un README.md guidé, un Makefile (make verify lance les tests), et un challenge final auto-évalué : continuer un play malgré l’échec d’une tâche grâce à ignore_errors: true.

Premier accès au lab ?

Avant la première utilisation, il faut cloner le dépôt et provisionner les 4 VMs (control-node + web1, web2, db1) — opération à faire une seule fois. Suivez la page Préparer le lab KVM qui couvre git clone, make bootstrap, make provision.

Une fois le lab provisionné :

cd ~/Projets/ansible-training/labs/ecrire-code/ignore-errors/

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

any_errors_fatal Arrêter le play dès la 1ère erreur cluster (l'inverse d'ignore_errors)

Block / rescue / always Alternative recommandée à ignore_errors dans la plupart des cas

failed_when et changed_when Redéfinir précisément ce qui constitue un échec

×

📖 Voir la documentation →