file_roots и salt://

file_roots — это опция конфигурации мастера, которая связывает каждое окружение (saltenv) со списком каталогов на диске. Все salt://-URL отсчитываются от этих каталогов: путь salt://nginx/init.sls при стандартной настройке превращается в /srv/salt/nginx/init.sls. Это самый простой и распространённый бэкенд файлового сервера (roots), который не требует внешних зависимостей и позволяет удобно смотреть, дифференцировать и версионировать каталоги. Понимание пары «file_roots → salt://» — базовый навык, так как любое состояние file.managed, любой top.sls, любая формула в итоге разрешаются через эту схему адресации.

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

В файле /etc/salt/master окружения описываются следующим образом:

file_roots:
  base:
    - /srv/salt
  dev:
    - /srv/salt-dev
    - /srv/salt

Каждому saltenv соответствует список каталогов; при поиске файла они обходятся по порядку, и первое совпадение побеждает. В dev можно переопределить часть файлов, а остальное «провалится» в общий /srv/salt. URL salt:// всегда относительный: миньон подставляет своё текущее окружение (по умолчанию base, либо явно указанное saltenv=dev) и просит файл у мастера. В корне окружения по конвенции лежит top.sls, а состояния группируются в каталоги: nginx/init.sls, nginx/files/nginx.conf. Проверить, как мастер видит дерево, можно с миньона: salt '*' cp.list_master saltenv=dev. В masterless-режиме file_roots задаётся уже в конфиге миньона, и salt-call --local state.apply читает файлы напрямую с локального диска — схема адресации не меняется.

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

roots — выбор по умолчанию для старта и для небольших инсталляций: один мастер, одна команда, дерево /srv/salt под git-репозиторием, который CI выкатывает на мастер (git pull или rsync по тегу). Это даёт версионирование без усложнения самого Salt. Несколько каталогов в одном окружении полезны для наложения: базовая часть — из общего репозитория, поверх — каталог с локальными особенностями площадки. Отдельные окружения в file_roots (dev, prod) имеют смысл, когда нужно обкатывать состояния на тестовых миньонах до продакшена. Когда команда растёт и хочется полноценного flow «ветка = окружение» с ревью, переходят на gitfs — синхронизировать каталоги руками уже не нужно.

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

Главное заблуждение — считать file_roots безопасным хранилищем: любой принятый миньон может запросить любой файл из любого окружения, поэтому приватные ключи и пароли в дереве состояний — прямая утечка; секреты живут в pillar (у которого свой, отдельный pillar_roots — их регулярно путают). Вторая ошибка — перекрытие каталогов: одинаковый путь в двух корнях одного окружения означает, что второй файл молча игнорируется, и правки в нём «не работают». Третья — редактирование /srv/salt руками на боевом мастере в обход git: через месяц никто не помнит, что и зачем поменяли, а откат невозможен. И не забывайте, что salt:// — это не путь ОС: абсолютные пути в source: не работают.

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

• Файловый сервер
• GitFS
• Окружения и ветки
• top.sls и highstate
• Шаблоны file.managed