Block / rescue / always Ansible : try/catch/finally pour playbooks

block / rescue / always est l'équivalent Ansible de try / catch / finally. Vous groupez des tâches dans un block:, vous fournissez un rescue: qui s'exécute uniquement si une tâche du block échoue, et un always: qui s'exécute toujours (succès ou échec). Cette page explique le pattern, l'ordre d'exécution exact, et les cas pratiques de production : nettoyage, rollback, notification d'échec.

Sans block/rescue/always, la seule façon de gérer une erreur est ignore_errors: true (anti-pattern) ou failed_when: (souvent insuffisant). block/rescue/always est la gestion d'erreur structurée d'Ansible.

Ce que vous allez apprendre

• La syntaxe block: / rescue: / always:
• L'ordre d'exécution : block → (rescue si échec) → always
• L'usage de when: sur un block (propage à toutes les tâches enfants)
• Patterns de production : nettoyage, rollback, notification
• La différence avec ignore_errors: (anti-pattern)

Prérequis

• Avoir lu Conditions, when et Boucles, loop.

La syntaxe

- name: Démo block / rescue / always
  hosts: db1.lab
  become: true
  tasks:
    - name: Démontrer l'enchaînement block, rescue et always
      block:
        - name: Tâche A
          ansible.builtin.command: /bin/true
          changed_when: false

        - name: Tâche B (peut échouer)
          ansible.builtin.command: /bin/false
          changed_when: false

        - name: Tâche C (skippée si B échoue)
          ansible.builtin.command: /bin/true
          changed_when: false

      rescue:
        - name: Notifier l'erreur
          ansible.builtin.debug:
            msg: "Le block a échoué !"

      always:
        - name: Cleanup
          ansible.builtin.command: /bin/true
          changed_when: false

L'ordre exact :

Block exécution :
  Tâche A → succès
  Tâche B → ÉCHEC ! Block interrompu, on saute le reste
  Rescue exécuté (Notifier l'erreur)
Always exécuté (Cleanup) : toujours

Si toutes les tâches du block réussissent : rescue n'est pas exécuté, always l'est. Si une tâche du block échoue : rescue capture, always est exécuté quoi qu'il arrive.

L'ordre d'exécution complet

1. block:        ← exécuté en premier
   - tâche 1
   - tâche 2 (si elle échoue : passage direct au rescue)
   - tâche 3 (skippée si tâche 2 a échoué)
2. rescue:       ← UNIQUEMENT si une tâche du block a échoué
   - tâche cleanup d'erreur
3. always:       ← TOUJOURS exécuté (succès ou échec)
   - tâche finalisation

Si une tâche du rescue elle-même échoue, le play plante (sauf si failed_when: ou un autre rescue parent).

Cas pratique, capture d'échec

Voici l'exemple validé sur le lab ecrire-code-block-rescue-always :

- name: Challenge block rescue always
  hosts: db1.lab
  become: true
  tasks:
    - name: Déclencher volontairement le rescue
      block:
        - name: Tenter une commande qui echoue
          ansible.builtin.command: /bin/false
          changed_when: false

      rescue:
        - name: Marqueur rescue
          ansible.builtin.copy:
            dest: /tmp/challenge-rescue.txt
            content: "rescue triggered (block failed)\n"
            mode: "0644"

      always:
        - name: Marqueur always
          ansible.builtin.copy:
            dest: /tmp/challenge-always.txt
            content: "always executed\n"
            mode: "0644"

PLAY RECAP :

db1.lab : ok=2  changed=2  rescued=1  failed=0

rescued=1 = le block a été rescuté. failed=0 = malgré l'échec du /bin/false, le play a terminé avec succès (grâce au rescue).

Patterns de production

Pattern 1, Rollback en cas d'échec

- name: Migrer la base avec rollback en cas d'échec
  block:
    - name: Snapshotter la base
      ansible.builtin.command: btrfs subvolume snapshot /var/lib/pgsql /var/lib/pgsql/.snap
      changed_when: true

    - name: Lancer la migration
      ansible.builtin.command: /usr/local/bin/migrate.sh
      changed_when: true

  rescue:
    - name: Restaurer la base depuis le snapshot
      ansible.builtin.command: btrfs subvolume rollback /var/lib/pgsql/.snap
      changed_when: true

    - name: Notifier l'équipe
      ansible.builtin.uri:
        url: https://slack.example.com/...
        method: POST

Pattern 2, Nettoyage de fichiers temporaires

- name: Travailler dans un répertoire temporaire nettoyé quoi qu'il arrive
  block:
    - name: Créer un répertoire temporaire
      ansible.builtin.tempfile:
        state: directory
      register: tmpdir

    - name: Travailler dedans
      ansible.builtin.command: build.sh
      args:
        chdir: "{{ tmpdir.path }}"
      changed_when: true

  always:
    - name: Toujours nettoyer le tempdir
      when: tmpdir.path is defined
      ansible.builtin.file:
        path: "{{ tmpdir.path }}"
        state: absent

always: garantit que le tempdir est supprimé, même si le command: plante.

Pattern 3, when: sur un block entier

- name: Installer la pile applicative sur les distributions RHEL
  when: ansible_os_family == "RedHat"
  block:
    - name: Tâche RHEL/AlmaLinux 1
      ansible.builtin.dnf:
        name: foo

    - name: Tâche RHEL/AlmaLinux 2
      ansible.builtin.systemd:
        name: foo
        state: started

Le when: est propagé à toutes les tâches du block. Plus DRY que de répéter le when: sur chacune.

block vs autres mécanismes d'erreur

Mécanisme	Usage
block / rescue / always	Gestion d'erreur structurée (try/catch/finally)
ignore_errors: true	Ignorer une erreur ponctuelle (à éviter)
failed_when: <expr>	Redéfinir ce qui constitue un échec
any_errors_fatal: true	Arrêter le play dès la première erreur sur n'importe quel hôte

Glissez pour voir

block/rescue/always est de loin le plus puissant. Si vous écrivez ignore_errors: true, demandez-vous d'abord si un block ne ferait pas mieux.

Variables et block

vars:, become:, become_user:, tags:, when: peuvent être posés au niveau du block et propagés aux tâches du block :

- name: Exécuter un groupe de tâches en root
  become: true
  vars:
    pkg_version: "1.2"
  block:
    - name: Tâche en root
      ansible.builtin.dnf:
        name: foo

    - name: Autre tâche en root
      ansible.builtin.systemd:
        name: foo

Pièges fréquents

Symptôme	Cause	Fix
rescue: exécuté même quand block réussit	Faux : rescue ne s'exécute QUE si block échoue	Vérifier le code, ce n'est pas le comportement réel
always: non exécuté quand block échoue	Faux : always s'exécute toujours	Vérifier qu'il y a bien une section always:
Une tâche qui échoue dans rescue: plante le play	Comportement attendu : si rescue échoue, le play plante	Ajouter un autre rescue parent ou ignore_errors: sur la tâche du rescue
Variable du block non visible dans rescue:	Faux : vars: du block est visible dans rescue ET always	Vérifier la portée
failed=0 dans le PLAY RECAP malgré une erreur	Le rescue a capturé, rescued=1 apparaît à la place	Lire correctement le PLAY RECAP

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

• block / rescue / always = try / catch / finally Ansible.
• block: : tâches à exécuter ; rescue: : tâches si échec ; always: : tâches toujours exécutées.
• when: sur un block s'applique à toutes les tâches du block.
• Patterns courants : rollback sur échec, cleanup dans always, notification Slack/Teams dans rescue.
• Préférer block/rescue/always à ignore_errors: true dans 99 % des cas.

Mettre en pratique

Un rollback ne se prouve qu'en provoquant l'échec. Le lab vous fait grouper des tâches dans un block, déclencher volontairement une erreur pour entrer dans rescue et y écrire la compensation, puis vérifier que always nettoie dans les deux cas. Vous y lisez ansible_failed_task pour identifier la tâche qui a cassé, information que le PLAY RECAP seul ne donne pas.

Lab pratique

block, rescue, always : try/catch/finally

$ dsoxlab run ecrire-code-block-rescue-always

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 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-block-rescue-always
dsoxlab check ecrire-code-block-rescue-always

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

• ignore_errors : la directive que block/rescue remplace presque toujours, avec ses rares cas légitimes.
• any_errors_fatal : le cran au-dessus, quand une erreur sur un seul hôte doit arrêter tout le play.
• Quiz Écrire du code : 30 questions pour situer votre niveau sur la gestion d'erreurs et le reste du module.

×

📖 Voir la documentation →