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

Файловый сервер — встроенный в мастер компонент, который раздаёт миньонам файлы: 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.

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

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

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

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

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