Режим test=True

state.apply test=True — это dry-run системы состояний: Salt проходит весь цикл (рендеринг Jinja, парсинг YAML, компиляция, проверка текущего состояния каждым модулем), но не вносит изменений в систему. Вместо этого каждое состояние сообщает, что оно собиралось бы сделать. Для эксплуатации это главный предохранитель: перед любым применением состояний на прод вы сначала видите план — как terraform plan перед apply или --check в Ansible. Привычка «сначала test, потом apply» дешёвая в исполнении и регулярно спасает от сюрпризов вида «конфиг перезапишется целиком, потому что кто-то правил его руками на сервере».

Как это работает

Аргумент test=True принимает любой вариант применения состояний:

salt 'web*' state.apply test=True            # план всего highstate
salt 'web*' state.apply nginx test=True      # план одного SLS
salt-call state.apply nginx test=True        # локально на миньоне

Флаг прокидывается в каждую функцию state-модуля через __opts__['test']. Модуль выполняет только фазу проверки: сравнивает факт с декларацией и возвращает result: None с комментарием о планируемом изменении (в терминале такие состояния подсвечиваются жёлтым). Уже соответствующие состояния возвращают зелёный True, реальные ошибки (например, не отрендерился Jinja) — красный False. file.managed в test-режиме показывает и diff содержимого файла — это самая информативная часть вывода. Работает и обратная сторона: если в конфиге миньона задано test: True (постоянный dry-run), разово применить изменения можно через state.apply test=False. Итоговая сводка Succeeded: X (unchanged=Y, changed=Z) даёт быстрый ответ, сколько состояний реально «хотят» измениться.

Когда применять

Практический минимум: любой прогон состояний на проде начинается с test=True; в идеале это закреплено в CI-пайплайне — тестовый прогон, просмотр плана, затем реальное применение. Особенно ценен режим при первом наведении Salt на давно живущий «рукопашный» сервер: план покажет масштаб расхождений до того, как вы их затрёте. Регулярный test=True по расписанию — дешёвый детектор дрейфа: непустой план на «сойдённой» системе означает, что кто-то менял её в обход Salt (или ваши состояния неидемпотентны — тоже полезное знание). Ограничение: test-режим не песочница. Он не покажет каскадные эффекты реального исполнения: cmd.run не выполнится, поэтому его настоящий результат неизвестен, а состояние, зависящее от результатов предыдущего (ещё не применённого), в плане может выглядеть иначе, чем поведёт себя в реальном прогоне.

Типичные ошибки

Главная ошибка — считать план точным пророчеством: test-режим оценивает каждое состояние против текущей системы, без учёта изменений, которые внесли бы предыдущие состояния, поэтому реальный прогон может отличаться. Вторая — неверно читать цвета: жёлтый (None) — «будут изменения», это нормально; тревожиться нужно из-за красного False — это ошибка уже на этапе проверки. Третья — забывать, что Jinja рендерится по-настоящему: если в шаблоне есть вызовы с побочными эффектами, они выполнятся и в test-режиме. Наконец, test=True не заменяет тестирование: линтер и прогон состояний в CI на одноразовой виртуалке или контейнере ловят то, чего в плане не видно.

Связанные понятия

• state.apply и state.sls
• Состояния (states)
• Requisites: require и watch
• Тестирование состояний
• Линтинг SLS