Тестирование и CI

Состояния Salt — это код, который управляет продакшеном, и относиться к нему нужно как к коду: хранить в Git, прогонять через ревью, статический анализ и автоматические тесты. Цена ошибки здесь выше, чем в обычном приложении: опечатка в SLS-файле, попавшая в top.sls, раскатится через highstate на сотни миньонов за секунды. При этом инфраструктурный код тестировать сложнее прикладного — результат зависит от ОС, установленных пакетов и текущего состояния машины, поэтому один уровень проверок не даёт достаточных гарантий. На практике вокруг Salt-репозитория выстраивают пирамиду: быстрый статический анализ на каждый коммит, dry-run на целевых системах и интеграционные тесты в одноразовых окружениях.

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

Нижний уровень — статический анализ. salt-lint проверяет SLS-файлы на типовые проблемы: отступы, устаревший синтаксис, подозрительные конструкции. Рендер-проверка через salt-call --local state.show_sls <имя> ловит ошибки Jinja и YAML до того, как файл попадёт на мастер. Средний уровень — dry-run: salt '*' state.apply test=True показывает, что именно изменится на реальных миньонах, ничего не трогая. Верхний уровень — интеграционные тесты: kitchen-salt поднимает одноразовый контейнер или виртуальную машину, применяет к ней состояния, а testinfra проверяет результат — установлен ли пакет, запущен ли сервис, слушается ли порт. Все три уровня собираются в CI-пайплайн: линтер и рендер-проверка на каждый коммит, kitchen-прогон на merge request, dry-run — обязательный шаг перед выкаткой на прод.

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

Глубину тестирования выбирают по цене ошибки. Минимум для любого репозитория состояний — salt-lint в pre-commit-хуке и в CI: это дёшево и отсекает целый класс проблем ещё до ревью. Как только состояниями пользуется больше одного человека или парк переваливает за десяток миньонов, добавляйте обязательный прогон test=True в процесс выкатки. Интеграционные тесты с kitchen-salt оправданы для переиспользуемых формул и критичных ролей — базовые образы, балансировщики, базы данных, — где регрессия задевает всё сразу. Отдельный случай — обновление самого Salt: прогон тестовой матрицы против новой версии до апгрейда мастера экономит часы разбирательств после.

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

Самая частая — считать test=True полноценным тестом: dry-run не выполняет команды и не видит изменений, которые зависят от результатов предыдущих состояний, поэтому «чистый» прогон ещё не гарантирует успешного применения. Вторая — тестировать только в Docker-контейнерах без systemd, где service.running ведёт себя не так, как на боевой машине. Третья — расхождение версий: тесты гоняются на свежем Salt из pip, а в проде стоит прошлый LTS; пиньте версию тестового окружения под прод. Наконец, тесты без pillar-данных проверяют не тот код, который реально выполняется, — подкладывайте в тестовое окружение реалистичный pillar.

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

• Линтинг SLS
• Тестирование состояний
• Salt в CI/CD
• Режим test=True
• Состояния (states)