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

Окружение (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.

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

• top.sls и highstate
• GitFS
• file_roots и salt://
• Pillar top file
• Секреты в pillar