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.

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

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

- 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 fact

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
    mode: "0644"
  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 :

- name: Grouper les tâches liées
  block:
    - name: Tenter une opération
      ansible.builtin.command: /usr/local/bin/risky.sh
      ignore_errors: true     # ← inutile dans un block
      changed_when: true

  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 :

Masque les vraies erreurs : un échec inattendu ne lève plus la main. Le bug se manifeste plus tard, ailleurs, sans contexte.
Pollue le diagnostic : un ignored=12 dans le PLAY RECAP est inutilement alarmant, vous devez chercher dans les logs lesquelles ont vraiment échoué.
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

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

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

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

Mettre en pratique

L'effet réel de cette directive se lit dans le PLAY RECAP, pas dans une définition. Le lab vous fait mesurer ce que ignore_errors: true produit sur les compteurs, identifier les rares situations où il se justifie, puis réécrire le même besoin avec failed_when et avec block/rescue. Vous constatez au passage qu'un ignore_errors posé dans un block empêche le rescue de se déclencher.

ignore_errors : usage légitime vs anti-pattern

$ dsoxlab run ecrire-code-ignore-errors

Environnement : VM·Durée : ~40 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 dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run ecrire-code-ignore-errors
dsoxlab check ecrire-code-ignore-errors

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Pour aller plus loin

Templates Jinja2 : générer des fichiers de configuration complets plutôt que de les rafistoler ligne à ligne.
Module template : l'option validate refuse une configuration invalide avant écriture, ce qui évite l'erreur au lieu de l'ignorer.
Quiz Écrire du code : 30 questions pour valider votre maîtrise de la gestion d'erreurs.