Тестирование состояний

Линтер отвечает за аккуратность кода, но важно также убедиться, что состояния приводят систему в нужный вид. У Salt для этого есть два инструмента: режим test=True и интеграционное тестирование в одноразовых окружениях. Режим test=True позволяет запустить состояния «вхолостую» и показать план изменений на реальной машине. Интеграционное тестирование осуществляется с помощью kitchen-salt и testinfra. kitchen-salt создаёт чистый контейнер или виртуальную машину, применяет к ней состояния, а testinfra проверяет, что результат совпадает с ожиданиями. Вместе эти инструменты обеспечивают проверку изменений на проде и работоспособность состояний на чистой системе.

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

Dry-run запускается командой salt '*' state.apply test=True или локально через salt-call. Salt рендерит SLS, строит список состояний и для каждого сообщает, какие изменения будут внесены. Состояния с ожидающими изменениями помечаются как None, что означает, что они изменятся при реальном прогоне. Система при этом не трогается. Интеграционный цикл описывается в файле .kitchen.yml, где задаются платформы, применяемые состояния и pillar-данные для теста. Команда kitchen converge создаёт окружение и применяет состояния, kitchen verify запускает проверки, а kitchen test выполняет полный цикл с удалением окружения в конце. Проверки пишутся на Python с фикстурами testinfra, например, host.package("nginx").is_installed, host.service("nginx").is_running, host.socket("tcp://443").is_listening.

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

test=True — повседневный инструмент: перед выкаткой на прод, при отладке нового состояния и при проверке дрейфа парка с описанным состоянием. Запуск по расписанию с алертом на непустой план помогает обнаруживать дрейф. Kitchen-цикл дороже в поддержке, поэтому его используют там, где отдача максимальна: переиспользуемые формулы, которые должны работать на нескольких дистрибутивах, и критичные роли, регрессия в которых бьёт по всему парку. Для маленького репозитория из пары состояний достаточно линтера и дисциплины test=True. Полноценные тесты добавляйте, когда состояния начинают переиспользоваться или меняться чаще раза в неделю.

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

Переоценивать test=True: dry-run не исполняет cmd.run, поэтому цепочка, где второе состояние зависит от результата первого, в тестовом режиме выглядит иначе, чем при реальном применении. Гонять kitchen только в Docker: в минимальных образах нет systemd, и service.running там либо падает, либо проверяет не то. Для сервисных состояний нужен образ с init-системой или полноценная ВМ. Забывать pillar в тестовой конфигурации: состояние, отрендеренное с пустым pillar, — это другое состояние. И писать проверки, дублирующие SLS: тест package.is_installed после pkg.installed почти бесполезен — проверяйте поведение системы: сервис отвечает, порт слушается, конфиг валиден.

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

• Режим test=True
• Тестирование и CI
• Salt в CI/CD
• Структура формулы
• salt-call и masterless-режим