Окружения и ветки

Окружение (saltenv) — изолированное дерево файлов на файловом сервере: свой набор SLS, шаблонов и, как правило, свой top.sls. Окружения позволяют держать несколько версий конфигурации параллельно — классическая схема base/dev/prod — и обкатывать изменения на тестовых машинах, не трогая продакшен. Откуда берутся окружения, зависит от бэкенда: при roots это записи в file_roots (каждому имени — список каталогов), при GitFS окружения появляются автоматически из веток и тегов репозитория — ветка dev становится saltenv dev, а ветка, указанная в gitfs_base, — окружением base. Важно понимать сразу: saltenv — инструмент организации кода, а не граница безопасности.

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

Окружение участвует в двух местах. Во-первых, в top.sls: верхний уровень топ-файла — имя окружения, внутри — таргеты и списки состояний:

base:
  '*':
    - core
prod:
  'web*':
    - nginx

Во-вторых, при выполнении: salt 'web-01' state.apply nginx saltenv=dev берёт файлы из dev, а миньон можно жёстко привязать к окружению опцией saltenv в его конфиге. Для pillar существует параллельная ось pillarenv — она задаётся отдельно и с saltenv автоматически не совпадает. Если топ-файлы есть в нескольких окружениях, поведение при highstate определяет опция мастера top_file_merging_strategy; чтобы не разбираться в правилах слияния, обычно держат один top.sls в base и из него расписывают все окружения. Типовой цикл с GitFS: коммит в ветку dev → проверка на стенде state.apply … saltenv=dev → merge в prod → миньоны продакшена получают то же изменение.

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

Окружения нужны, когда есть отдельные стенды и требование «сначала проверить, потом катить»: dev-миньоны закреплены за dev, боевые — за prod, продвижение изменений — merge между ветками. Вторая типовая задача — заморозка версий: теги в GitFS дают неизменяемые окружения (saltenv=v1.2), удобно для аудита и отката. При этом для небольших инсталляций честный ответ — окружения не обязательны: многие команды осознанно живут с одним base, а изоляцию стендов делают отдельными мастерами или отдельными репозиториями — это проще, чем следить за согласованностью топ-файлов и пар saltenv/pillarenv. Начинайте с одного окружения и вводите новые, только когда появляется реальный процесс продвижения изменений.

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

Самая болезненная ошибка — считать окружения границей безопасности: любой миньон может запросить файлы и применить состояния из любого saltenv, поэтому «prod-секреты в prod-окружении» ничем не защищены — разграничение секретов делается только через pillar, который мастер отдаёт каждому миньону индивидуально. Вторая — несколько топ-файлов в разных окружениях без понимания top_file_merging_strategy: highstate начинает применять состояния не из той ветки, и отладка выглядит мистикой. Третья — рассинхрон saltenv и pillarenv: состояния взяли из dev, pillar — из base, и шаблоны рендерятся со «старыми» значениями. Наконец, длинно живущие ветки окружений расходятся между собой — чем дольше dev не мержится в prod, тем страшнее итоговый merge.

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

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

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

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

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