Какой командой проверить, что будет выполнять Ansible Playbook без его запуска?

Проверка Ansible Playbook перед запуском: ansible-playbook --check

Для безопасного и корректного управления инфраструктурой Ansible предоставляет несколько ключевых команд, позволяющих проверить, что будет выполнять Playbook, без фактического изменения целевых систем. Основной и наиболее часто используемый метод — флаг --check (также известный как dry-run или режим проверки).

Основная команда: ansible-playbook --check

ansible-playbook --check playbook.yml

Эта команда запускает Playbook в режиме "только проверка". Ansible выполняет все шаги:

• Парсинг Playbook и сбор фактов (gather_facts)
• Подключение к целевым хостам
• Обработку переменных и шаблонов
• Ключевое отличие: Все модули, которые обычно изменяют состояние системы (например, file, copy, service, package), выполняются в имитационном режиме. Они сообщают, какие изменения были бы произведены, но не применяют их фактически.

Пример вывода для модуля file:

TASK [Ensure directory exists] **********************************************
ok: [host.example.com] => {
    "changed": false,
    "msg": "file /tmp/test would be created"
}

Вы увидите ключевое слово "would" — указывает на потенциальное действие.

Важные дополнительные флаги и комбинации

1. --diff совместно с --check:

ansible-playbook --check --diff playbook.yml

Флаг --diff показывает детальные различия в файлах, которые будут изменены (например, при использовании модулей template, copy, lineinfile). Это чрезвычайно полезно для проверки конфигураций.

1. --list-tasks:

ansible-playbook --list-tasks playbook.yml

Показывает список всех задач, которые будут выполнены в Playbook, в порядке их запуска. Не выполняет сами задачи.

1. --list-hosts:

ansible-playbook --list-hosts playbook.yml

Показывает список всех хостов, на которых будут выполняться задачи из Playbook, согласно указанным шаблонам (hosts:).

Ограничения и важные предостережения режима --check

• Не все модули поддерживают режим check: Многие модули (особенно сторонние или специализированные) могут не иметь корректной реализации проверки. Они либо пропустят действие, либо выдадут предупреждение.
• Проверка соединения и фактов: Операции, которые не изменяют состояние (например, gather_facts, модуль debug), будут выполнены полностью. Это может повлиять на целевые хосты (сетевая нагрузка, потребление ресурсов).
• Зависимости от состояния: Результаты проверки могут быть не точными, если задачи зависят от динамического состояния системы, которое не учитывается в режиме имитации.
• Требования к правам: Для проверки часто требуются те же права на чтение/подключение, что и для реального запуска.

Практический пример и workflow

Безопасный процесс проверки Playbook:

# 1. Проверить список задач и хостов
ansible-playbook --list-tasks --list-hosts deploy_app.yml

# 2. Запустить проверку с выводом различий
ansible-playbook --check --diff deploy_app.yml

# 3. Если есть опасные задачи (например, удаление), можно ограничить проверку для конкретных хостов
ansible-playbook --check --limit "web_servers" deploy_app.yml

# 4. Для модулей команд (shell, command) --check может не работать корректно, используйте флаг 'changed_when: false' в самой задаче или тестируйте на стенде.

Полезные альтернативы для глубокой проверки

• Локальный тест с --connection=local: Запуск Playbook локально для проверки логики.

ansible-playbook --connection=local --check playbook.yml

• Молекулярное тестирование (molecule): Инструмент для разработки и тестирования Ansible ролей в isolated-окружении (Docker, Vagrant). Позволяет полноценно прогонять Playbook на тестовых инстансах.
• Статический анализ ansible-lint:

ansible-lint playbook.yml

Проверяет синтаксис, лучшие практики и потенциальные ошибки в Playbook без его запуска.

Резюме и рекомендации

• Основная команда: ansible-playbook --check — ваш первый инструмент для dry-run.
• Для детальной проверки конфигураций: всегда добавляйте --diff.
• Для понимания объема работ: используйте --list-tasks и --list-hosts.
• Для полной безопасности: тестируйте критичные изменения на полностью изолированном стенде (виртуальные машины, контейнеры) перед запуском в production.

Правильное использование этих команд — основа предотвращения инцидентов и ключевая практика в DevOps культуре "infrastructure as code".