Introduction
Les blocs Ansible permettent de regrouper des tâches connexes. Une section rescue s'exécute lorsqu'une tâche au sein du bloc échoue, tandis qu'une section always s'exécute dans tous les cas.
Dans ce laboratoire, vous allez créer une erreur contrôlée, apprendre à la gérer, puis relancer le même playbook en désactivant l'erreur pour observer le cheminement nominal (succès).
Créer un projet de gestion des échecs
Dans cette étape, vous allez créer un petit projet avec un hôte géré localement et un répertoire de rapports pour les marqueurs des sections block, rescue et always.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory,playbooks,reports}
cd rhce-ansible
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
retry_files_enabled = False
EOF
cat > inventory/hosts <<'EOF'
[managed]
host ansible_connection=local
EOF
Le répertoire reports sert à stocker les marqueurs générés par le playbook pour chaque chemin d'exécution. Cela permet de visualiser le comportement des blocs sans dépendre uniquement de la sortie du terminal.
Écrire un bloc avec rescue et always
Dans cette étape, vous allez rédiger un playbook incluant une erreur contrôlée. Le bloc échoue lorsque simulate_failure est défini sur true, la section rescue écrit un marqueur de récupération, et la section always écrit un marqueur d'audit.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible. Cela garantit la stabilité des commandes, même si LabEx exécute chaque étape séparément.
cd /home/labex/project/rhce-ansible
cat > playbooks/block-rescue.yml <<'EOF'
---
- name: Practice block rescue and always
hosts: managed
gather_facts: false
vars:
simulate_failure: true
tasks:
- name: Remove old markers
ansible.builtin.file:
path: "/home/labex/project/rhce-ansible/reports/{{ item }}.txt"
state: absent
loop:
- block-success
- rescued
- always
- name: Protect a risky operation with rescue
block:
- name: Run a command that may fail
ansible.builtin.command: /usr/bin/false
when: simulate_failure | bool
- name: Mark block success
ansible.builtin.copy:
dest: /home/labex/project/rhce-ansible/reports/block-success.txt
content: |
block completed
mode: '0644'
rescue:
- name: Mark rescue path
ansible.builtin.copy:
dest: /home/labex/project/rhce-ansible/reports/rescued.txt
content: |
rescued controlled failure
mode: '0644'
always:
- name: Mark always path
ansible.builtin.copy:
dest: /home/labex/project/rhce-ansible/reports/always.txt
content: |
always ran
mode: '0644'
EOF
La commande risquée est /usr/bin/false, qui renvoie systématiquement une erreur. Lorsque simulate_failure est activé, le bloc s'arrête à cette tâche, la section rescue écrit rescued.txt, et la section always écrit always.txt quoi qu'il arrive.
ansible-playbook playbooks/block-rescue.yml --syntax-check
Les mots-clés block, rescue et always doivent être alignés avec le même niveau d'indentation. Une vérification de syntaxe est un moyen rapide de détecter une section mal placée avant de déclencher l'erreur contrôlée.
Exécuter le chemin d'échec contrôlé
Dans cette étape, vous allez exécuter le playbook avec l'échec activé par défaut. Le récapitulatif du play devrait indiquer une tâche secourue (rescued) plutôt qu'un échec global. Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/block-rescue.yml | tee reports/failure-path.txt
Cette exécution devrait afficher rescued=1 et failed=0 dans le récapitulatif. Cela signifie qu'Ansible a détecté l'échec d'une tâche dans le bloc, a exécuté les tâches de secours, et n'a pas considéré le play comme étant en échec.
cat reports/rescued.txt reports/always.txt
Les deux fichiers marqueurs devraient contenir rescued controlled failure et always ran. Vous ne devriez pas voir block-success.txt dans ce chemin, car le bloc n'a pas atteint la tâche de succès.
Exécuter le chemin de succès avec une variable supplémentaire
Dans cette étape, vous allez surcharger simulate_failure via la ligne de commande. Le bloc devrait se terminer normalement, la section rescue ne devrait pas s'exécuter, et la section always devrait toujours s'exécuter.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/block-rescue.yml -e simulate_failure=false | tee reports/success-path.txt
L'option -e simulate_failure=false surcharge la variable du playbook uniquement pour cette exécution. La commande false est alors ignorée, le bloc atteint normalement block-success.txt, et la section rescue n'est pas déclenchée.
cat reports/block-success.txt reports/always.txt
Le chemin de succès devrait afficher block completed et always ran. Le playbook supprime les anciens marqueurs au début, donc rescued.txt ne devrait plus exister après cette exécution.
Comparer les preuves d'échec et de succès
Dans cette étape, vous allez comparer les deux exécutions du playbook. Garder des preuves concises vous aide à identifier quel chemin a été emprunté sans avoir à lire l'intégralité de la sortie. Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
grep -E 'rescued=|failed=' reports/failure-path.txt reports/success-path.txt
Le rapport du chemin d'échec devrait contenir rescued=1, tandis que celui du chemin de succès devrait contenir rescued=0. Les deux devraient afficher failed=0, mais pour des raisons différentes.
ls -1 reports
La liste des rapports devrait inclure les deux sorties de playbook enregistrées ainsi que les marqueurs du chemin le plus récent. Conserver les deux sorties facilite la comparaison de l'impact de la section rescue sur le récapitulatif.
Résumé
Vous avez utilisé les sections block, rescue et always pour gérer une erreur contrôlée, puis vous avez exécuté le même playbook dans un scénario de succès normal et comparé les preuves enregistrées.
