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 с тестовым 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-системе полный доступ к мастеру: токен с правом «выполнить что угодно на всех миньонах» — самый лакомый секрет в вашей инфраструктуре.

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

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

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

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

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

🔤 Английские термины в этой теме