Salt в CI/CD

Отдельные проверки — линтер, dry-run, kitchen — приносят максимум пользы, когда собраны в единый пайплайн: каждый merge request проходит одни и те же ворота, а доставка изменений на мастер и раскатка на миньоны перестают быть ручными операциями. Идея та же, что и в CI для приложений: Git — единственный источник истины, изменение состояния — это pull request, а путь от коммита до продакшена формализован и воспроизводим. У Salt для такой схемы есть удобная особенность — GitFS: файловый сервер мастера умеет читать состояния прямо из Git-репозитория, превращая «деплой конфигурации» в обычный merge в нужную ветку.

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

Типовой пайплайн в GitLab CI или GitHub Actions состоит из четырёх этапов. Первый — статика: salt-lint по всем SLS-файлам плюс проверка форматирования. Второй — рендер: salt-call --local state.show_sls c тестовым pillar ловит ошибки Jinja и YAML. Третий — интеграция: kitchen-salt применяет изменённые роли к одноразовым окружениям и гоняет testinfra-проверки. Четвёртый — доставка. Здесь два распространённых варианта: либо мастер настроен на GitFS (fileserver_backend: gitfs) и сам подтягивает ветку — тогда merge в ветку окружения и есть деплой; либо CI-джоба выкладывает проверенный срез репозитория в file_roots мастера. Раскатку на миньоны оформляют отдельным, часто ручным шагом: сначала state.apply test=True по целевой группе с публикацией плана в merge request, после одобрения — реальный прогон, на больших парках — батчами через --batch-size, чтобы не перезапустить все сервисы одновременно.

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

Полный пайплайн окупается, когда Salt-репозиторий — командный: несколько авторов, регулярные изменения, продакшен, где цена ошибки измеряется простоем. Если вы единственный администратор пяти машин, достаточно pre-commit-хуков и привычки к test=True. Схема с GitFS особенно удобна при нескольких окружениях: ветки репозитория отображаются в saltenv, и изменение сначала живёт в ветке staging-окружения, а в прод попадает тем же merge'ем, который уже прошёл проверку. Автоматическую раскатку highstate по всем миньонам без ручного шага стоит включать только там, где тесты действительно покрывают состояния, — иначе пайплайн лишь ускоряет доставку ошибок.

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

Держать «серую зону» между CI и мастером: пайплайн зелёный, но на мастер изменения попадают вручную по SSH — рано или поздно там окажется незакоммиченная правка, которую затрёт следующий деплой. Пропускать этап рендера: линтер не знает pillar, и битый Jinja доедет до мастера. Публиковать план test=True некому: шаг есть, но вывод никто не читает — встройте план в интерфейс merge request. Раскатывать highstate на весь парк одним прогоном без батчей — одновременный рестарт сервиса на всех узлах превращает мелкую правку в инцидент. И не давайте CI-системе полный доступ к мастеру: токен с правом «выполнить что угодно на всех миньонах» — самый лакомый секрет в вашей инфраструктуре.

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

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

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

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

Полезные ресурсы