Ответ
Идемпотентность — ключевое свойство Ansible, означающее, что многократный запуск плейбука приводит к одинаковому конечному состоянию системы. Проверяю это на практике и через анализ кода.
Практическая проверка:
-
Запуск с флагом
--check(Dry Run):ansible-playbook site.yml --check --diff--check: не вносит изменений, только симулирует запуск.--diff: показывает, какие файлы были бы изменены (для модулейtemplate,copy).- Ожидаемый результат для идемпотентной роли: В выводе не должно быть задач в статусе
changed. Допустимы толькоokиskipped.
-
Двойной реальный запуск:
# Первый запуск — могут быть изменения (changed) ansible-playbook site.yml # Немедленный повторный запуск — изменений быть не должно ansible-playbook site.ymlВо втором выводе ищу строку
changed=0. Это прямой индикатор идемпотентности.
Анализ кода роли (на что смотрю):
- Использование идемпотентных модулей:
yum,apt,file,service,template. Они сами проверяют текущее состояние.- name: Ensure package is installed ansible.builtin.apt: name: nginx state: present # Модуль проверит, установлен ли пакет - Опасные места — модули
command/shell: Они не идемпотентны по умолчанию. Всегда проверяю, используются ли с ними параметрыcreatesилиremoves, которые добавляют проверку состояния.- name: Run script only if lock file does not exist ansible.builtin.command: /opt/scripts/setup.sh args: creates: /var/lock/setup.lock # Задача выполнится только один раз - Регистрация результатов и условные выполнения (
when): Частая причина неидемпотентности — неправильные условия. Проверяю, чтоwhenопирается на факты (ansible_facts) или зарегистрированные выходные данные (register) задач, которые сами являются идемпотентными.
В своей работе я всегда пишу роли с расчетом на идемпотентность, так как это основа надежной автоматизации и безопасного повторного запуска.