Файловый сервер

Файловый сервер — встроенный компонент мастера, который раздаёт миньонам файлы: SLS-состояния, Jinja-шаблоны, конфиги, скрипты и небольшие архивы. Отдельный NFS, HTTP-сервер или rsync не нужны, так как файлы передаются по шифрованному ZeroMQ-каналу (порт 4506), через который передаются и результаты команд. Миньон запрашивает файлы по URL вида salt://nginx/files/nginx.conf. Сервер модульный: за физическое хранение файлов отвечают бэкенды — roots (каталоги на диске мастера, настраиваются опцией file_roots), gitfs (git-репозитории), а также s3fs, hgfs, svnfs, minionfs. Бэкенды перечислены в опции fileserver_backend конфига мастера и опрашиваются по порядку: файл отдаёт первый бэкенд, у которого он найден. Всё дерево файлов разбито на окружения (saltenv), такие как base, dev, prod.

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

Когда миньон рендерит состояние с source: salt://nginx/files/nginx.conf, он отправляет мастеру запрос на получение файла по указанному пути и saltenv. Мастер проходит по списку fileserver_backend, находит файл и отдаёт его по частям вместе с хешем. Миньон кэширует полученные файлы в /var/cache/salt/minion/files/<saltenv>/ и при следующем запуске сравнивает хеши — неизменённые файлы не скачиваются повторно. Работать с сервером можно напрямую через execution-модуль cp: salt '*' cp.get_file salt://scripts/check.sh /usr/local/bin/check.sh копирует файл, а salt '*' cp.list_master показывает все доступные файлы. Для удалённых бэкендов (gitfs, s3fs) мастер держит собственный кэш и периодически его обновляет; форсировать обновление можно командой salt-run fileserver.update. Сами SLS-файлы, которые миньон компилирует при state.apply, приходят по этому же механизму — файловый сервер лежит в основе всей системы состояний.

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

Файловый сервер работает всегда, выбор сводится к бэкенду. roots — самый простой вариант: каталог /srv/salt на мастере, прозрачная отладка, подходит для одного мастера и небольшой команды. gitfs — когда конфигурация живёт в git, изменения проходят ревью через merge request, а ветки отображаются в окружения. Комбинация fileserver_backend: [roots, gitfs] позволяет держать основную базу в git, а локальные патчи — на диске мастера, причём roots первым в списке перекроет одноимённые файлы из git. Для раздачи мелких артефактов (скрипты, unit-файлы, конфиги) salt:// — идеальный канал; крупные бинарники (образы, дистрибутивы в сотни мегабайт) лучше класть во внешнее хранилище и качать состоянием file.managed с source: https://… — гонять гигабайты через мастер медленно и накладно для него самого.

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

Частая ошибка — путать salt://-пути с путями файловой системы: salt://nginx/files/nginx.conf отсчитывается от корня окружения (например, /srv/salt/), а не от /. Вторая — настроить gitfs_remotes, но забыть добавить gitfs в fileserver_backend: бэкенд просто не опрашивается, и файлы «не находятся» без внятной ошибки. Третья — дублирование путей: если один и тот же файл лежит в нескольких корнях file_roots или в нескольких бэкендах, молча побеждает первый по порядку, и правки «не того» экземпляра ни на что не влияют. Наконец, файловый сервер — не место для секретов: любой принятый миньон может запросить любой файл любого окружения, разграничения доступа по миньонам здесь нет — чувствительные данные передают через pillar.

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

• file_roots и salt://
• GitFS
• Окружения и ветки
• Состояния (states)
• Что такое pillar