Введение
Блоки (blocks) в Ansible позволяют группировать связанные задачи. Секция rescue выполняется, если одна из задач в блоке завершается с ошибкой, а секция always выполняется в любом случае, независимо от результата.
В этой лабораторной работе вы создадите контролируемый сбой, восстановитесь после него, а затем повторно запустите тот же плейбук с отключенным сбоем, чтобы увидеть путь успешного выполнения.
Создание проекта для обработки сбоев
На этом этапе вы создадите небольшой проект с одним локальным управляемым узлом и каталогом reports для маркеров block, rescue и 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
Каталог reports используется плейбуком для записи маркеров каждого пути выполнения. Это позволяет визуализировать поведение блока, не полагаясь только на вывод терминала.
Написание блока с секциями rescue и always
На этом этапе вы напишете плейбук с контролируемым сбоем. Блок завершается ошибкой, когда simulate_failure имеет значение true, секция rescue записывает маркер восстановления, а секция always записывает маркер аудита.
Перед выполнением команд на этом этапе вернитесь в каталог проекта Ansible. Это обеспечит стабильность команд, даже если LabEx запускает каждый этап отдельно.
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
Рискованная команда — /usr/bin/false, которая всегда завершается с ошибкой. Когда simulate_failure имеет значение true, блок останавливается на этой задаче, секция rescue записывает rescued.txt, а секция always записывает always.txt в любом случае.
ansible-playbook playbooks/block-rescue.yml --syntax-check
Ключевые слова block, rescue и always должны иметь одинаковый уровень отступа. Проверка синтаксиса — это быстрый способ обнаружить неправильно расположенную секцию перед запуском контролируемого сбоя.
Запуск пути с контролируемым сбоем
На этом этапе вы запустите плейбук с включенным по умолчанию сбоем. В сводке выполнения (recap) должно быть указано, что задача была восстановлена (rescued), а не то, что плейбук завершился с ошибкой.
Перед выполнением команд на этом этапе вернитесь в каталог проекта Ansible.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/block-rescue.yml | tee reports/failure-path.txt
Ожидается, что в сводке выполнения будет показано rescued=1 и failed=0. Это означает, что Ansible зафиксировал сбой задачи внутри блока, выполнил задачи восстановления и не посчитал весь плейбук завершившимся с ошибкой.
cat reports/rescued.txt reports/always.txt
Два файла маркеров должны содержать текст rescued controlled failure и always ran. Вы не должны увидеть block-success.txt на этом пути, так как блок не дошел до задачи установки маркера успеха.
Запуск пути успеха с дополнительной переменной
На этом этапе вы переопределите simulate_failure через командную строку. Блок должен выполниться нормально, секция rescue не должна запускаться, а секция always должна выполниться в любом случае.
Перед выполнением команд на этом этапе вернитесь в каталог проекта Ansible.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/block-rescue.yml -e simulate_failure=false | tee reports/success-path.txt
Опция -e simulate_failure=false переопределяет переменную плейбука только для этого запуска. Теперь команда false пропускается, обычный блок доходит до block-success.txt, а секция rescue не выполняется.
cat reports/block-success.txt reports/always.txt
На пути успеха должны отобразиться сообщения block completed и always ran. Плейбук удаляет старые маркеры в начале, поэтому rescued.txt после этого запуска существовать не должен.
Сравнение результатов сбоя и успеха
На этом этапе вы сравните два сохраненных запуска плейбука. Хранение небольших доказательств помогает устранять неполадки и определять, какой путь был выполнен, не читая весь вывод целиком. Перед выполнением команд на этом этапе вернитесь в каталог проекта Ansible.
cd /home/labex/project/rhce-ansible
grep -E 'rescued=|failed=' reports/failure-path.txt reports/success-path.txt
Отчет о пути сбоя должен содержать rescued=1, в то время как отчет о пути успеха должен содержать rescued=0. В обоих случаях должно быть failed=0, но по разным причинам.
ls -1 reports
Список отчетов должен включать оба сохраненных вывода плейбука плюс маркеры из последнего пути. Хранение обоих выводов облегчает сравнение того, как rescue меняет сводку выполнения.
Резюме
Вы использовали секции block, rescue и always для обработки контролируемого сбоя, затем запустили тот же плейбук по пути успешного выполнения и сравнили сохраненные результаты.
