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

Состояния Salt — это код, управляющий инфраструктурой, и его следует хранить в Git, проходить ревью, статический анализ и автоматические тесты. Ошибки в SLS-файлах могут быстро распространиться на сотни миньонов, поэтому важно обеспечить надёжность. Тестирование инфраструктурного кода сложнее из-за зависимости от ОС, установленных пакетов и текущего состояния машины. Поэтому вокруг 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-salt на 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)