Ansible --check и --diff: как проверить изменения и понять ограничения

Перед применением playbook полезно увидеть предполагаемые изменения. check mode показывает прогноз поддерживающего его модуля, а diff mode — различия там, где модуль умеет их вычислить. Ни один из этих режимов не заменяет проверку на пилотном узле.

Разделить синтаксис, план и выполнение

Особенно важна последняя строка: запуск с одним --diff всё ещё может изменять систему.

Минимальный безопасный стенд

Для отдельной лабораторной Linux-машины создайте inventory.ini:

[lab]
localhost ansible_connection=local

Playbook demo.yml меняет только учебный файл в /tmp:

---
- name: Validate a small file change
  hosts: lab
  gather_facts: false
  tasks:
    - name: Write demonstration file
      ansible.builtin.copy:
        dest: /tmp/sysadm-check-demo.txt
        content: "demo mode\n"
        mode: '0600'

Сначала убедитесь, что этот путь не занят нужным файлом. Выполните:

ansible-playbook -i inventory.ini demo.yml --syntax-check
ansible-playbook -i inventory.ini demo.yml --check --diff --limit lab

Если файл отсутствует, модуль copy должен сообщить планируемое создание, но не записать его в check mode. После просмотра плана запустите playbook обычно и проверьте итоговый файл.

Проверить идемпотентность

ansible-playbook -i inventory.ini demo.yml --limit lab
ansible-playbook -i inventory.ini demo.yml --check --diff --limit lab

При неизменных входных данных повторная проверка не должна прогнозировать новую запись. Если каждый запуск показывает changed, выясните причину: динамический timestamp в шаблоне, случайное значение, права или задача, которая не описывает желаемое состояние.

Где прогноз неполон

Проверьте в документации каждого модуля поддержку check_mode и diff_mode. command и shell не превращают произвольную программу в безопасную симуляцию. Задача, зависящая от результата предыдущей реальной операции, может не получить ожидаемые данные во время проверки.

В playbook может быть check_mode: false. Такая задача разрешает выполнение даже при общем --check; это нужно найти на ревью. Напротив, check_mode: true принудительно моделирует отдельную задачу. Не считайте флаг CLI универсальной гарантией отсутствия побочных эффектов.

Не вывести секрет в diff

Содержимое конфигурации может включать пароль. Для такой задачи отдельно отключают diff и скрывают журналирование:

- name: Render sensitive configuration
  ansible.builtin.template:
    src: app-secret.j2
    dest: /etc/example/app.conf
    mode: '0600'
  diff: false
  no_log: true

Это отдельный фрагмент для согласованного приложения, а не часть учебного playbook. no_log не заменяет проверку того, что вызываемый скрипт сам не пишет секрет в файл или сторонний журнал.

Рабочая последовательность

1. Зафиксировать версии, inventory и входные переменные.
2. Проверить синтаксис и поддержку режимов нужными модулями.
3. Запустить прогноз на явно ограниченной группе.
4. Разобрать diff и задачи с принудительным выполнением.
5. Применить на пилоте и проверить приложение.
6. Повторить проверку, затем расширять группу.

Справка модуля: ansible.builtin.copy.

Источник материала: Ansible --check и --diff: как проверить изменения и понять ограничения (англоязычный материал разработчиков). Русскоязычная инструкция подготовлена самостоятельно; технические сведения проверены 11 октября 2026 года.