GitFS

GitFS — бэкенд файлового сервера, который отдаёт миньонам файлы напрямую из git-репозиториев, минуя каталоги на диске мастера. Ключевая особенность: ветки и теги репозитория автоматически становятся окружениями (saltenv) — ветка dev даёт окружение dev, тег v1.2 — окружение v1.2, а ветка master по умолчанию отображается в base. Это превращает работу с конфигурацией в обычный git-flow: изменение состояния — это коммит, продвижение между окружениями — merge, ревью — merge request. Мастер сам клонирует репозитории, кэширует их локально и периодически подтягивает обновления; руками на мастер ничего выкладывать не нужно.

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

В конфиге мастера включается бэкенд и перечисляются репозитории:

fileserver_backend:
  - gitfs
gitfs_remotes:
  - ssh://git@git.example.com/salt/states.git

Работу с git выполняет провайдер — pygit2 (рекомендуемый, на базе libgit2) или GitPython; выбирается опцией gitfs_provider. Для ssh-доступа у pygit2 задаются gitfs_pubkey и gitfs_privkey. Мастер хранит кэш репозиториев в /var/cache/salt/master/gitfs и обновляет его фоновым процессом обслуживания файлового сервера; принудительно — salt-run fileserver.update. Каждая ветка и каждый тег видны как отдельный saltenv; какая ветка считается base, задаёт gitfs_base, а лишние окружения отсекаются через gitfs_saltenv_whitelist / gitfs_saltenv_blacklist. Несколько remote'ов накладываются друг на друга по порядку списка — первый выигрывает при совпадении путей; per-remote параметры root и mountpoint позволяют отдать подкаталог репозитория или смонтировать его в подпуть salt://.

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

GitFS — стандарт для команд, где инфраструктурный код проходит ревью: вся история изменений в git, выкатка в окружение — это merge в соответствующую ветку, откат — revert. Особенно удобно с формулами: каждую формулу подключают отдельным remote'ом в gitfs_remotes, пиня нужную версию, вместо копирования кода в своё дерево. Хорошо работает и гибрид: fileserver_backend: [roots, gitfs] — основная база из git, а локальный /srv/salt для экстренных патчей (помня, что roots первым в списке перекрывает git). Для одиночного мастера с парой десятков миньонов GitFS может быть избыточен — связка «roots + CI, выкладывающий репозиторий на мастер» даёт тот же git-flow без зависимостей от pygit2.

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

Самая частая проблема — окружение зависимостей: pygit2 и libgit2 должны быть согласованных версий и установлены в то же окружение Python, где работает мастер (в onedir-пакетах — через salt-pip); иначе GitFS молча не стартует, и диагноз виден только в логе мастера. Вторая — забыть про задержку кэша: свежий push становится виден миньонам не мгновенно, а после очередного обновления файлового сервера, поэтому «закоммитил, применил, изменений нет» — это обычно не баг, а кэш; выручает salt-run fileserver.update. Третья — путать GitFS с git-pillar: pillar из git настраивается отдельно через ext_pillar, gitfs_remotes на pillar не влияет. Наконец, ssh-доступ без корректных ключей и известных хостов даёт невнятные ошибки аутентификации — проверяйте клонирование тем же ключом вручную.

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

• Файловый сервер
• file_roots и salt://
• Окружения и ветки
• Формулы
• Внешние pillar