Организация репозиториев

Как разложить Salt-код по репозиториям — архитектурное решение, которое определяет, насколько легко команде ревьюить изменения, разграничивать доступ и переиспользовать код. Устоявшийся отраслевой паттерн — разделение на два типа репозиториев: формулы (переиспользуемый код, репозиторий на сервис: nginx-formula, ssh-formula) и окружение (env-репозиторий с top.sls и pillar-данными, который «сшивает» формулы с конкретными хостами). Формула отвечает на вопрос «как настраивать сервис», окружение — «на каких машинах и с какими данными». Это же разделение проводит границу ответственности: формулы может ревьюить вся команда, env-репозиторий описывает реальную инфраструктуру и требует более внимательного контроля.

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

Типичный env-репозиторий содержит два дерева: base/top.sls (назначение state-формул на таргеты) и pillar/ (top file + данные по ролям). Формулы подключаются к мастеру одним из двух способов. Первый — GitFS: каждый репозиторий формулы прописывается в gitfs_remotes конфига мастера, и его состояния становятся доступны в file_roots без копирования. Второй — CI-доставка: пайплайн собирает нужные версии формул и выкладывает их на мастер в отдельный каталог (например, /srv/salt-formulas), указанный в file_roots после /srv/salt. В обоих случаях правило одно: потребитель фиксирует версию формулы — тег или коммит, а не движущуюся ветку. Формула, которую «просто тянут по master», превращает каждый merge в мгновенный деплой на весь парк.

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

Разделение «формулы + env» окупается уже с 3–5 сервисов: без него top file, данные и код срастаются в монолит, который нельзя ни переиспользовать, ни аккуратно ревьюить. Pillar стоит выносить в отдельный репозиторий с более узким кругом доступа, как только в нём появляются чувствительные данные: даже зашифрованные секреты и сетевые политики доступа не должны быть видны всем, кто правит формулы. Обратная крайность — репозиторий на каждый чих: если формулу использует одна команда в одном окружении, десяток микрорепозиториев только умножает накладные расходы на PR, версии и синхронизацию; здоровый ориентир — отдельный репозиторий для того, что реально переиспользуется или имеет отдельный цикл изменений.

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

Первая — pillar с секретами в общем репозитории со state-кодом: круг доступа к коду всегда шире круга доступа к данным, и «приватности репозитория» как защиты недостаточно. Вторая — формулы без релизов: версия в метаданных годами остаётся 0.0.1, тегов нет, потребители тянут ветку — и однажды чужой merge раскатывается на прод в момент state.apply. Третья — дрейф между способами доставки: часть формул приезжает через GitFS, часть лежит копией в env-репозитории, и через полгода никто не знает, какая версия реально применяется. Четвёртая — отсутствие pillar.example в формулах: интерфейс формулы становится недокументированным, и его восстанавливают чтением Jinja.

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

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

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

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

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