Конфигурация master

Поведение мастера полностью определяется YAML-файлом /etc/salt/master и drop-in-файлами в каталоге /etc/salt/master.d/ (файлы *.conf). Дефолтная конфигурация закомментирована, и для маленькой инсталляции мастер работает вообще без правок. Однако продакшен-инсталляция почти всегда требует настройки хотя бы file_roots (откуда мастер раздаёт SLS-файлы) и pillar_roots (откуда берётся pillar). Ключевой практический навык — знать, какие опции на что влияют и когда их трогать: сетевые параметры, каталоги файлового сервера, политика приёма ключей и количество воркеров. Любое изменение вступает в силу только после перезапуска: systemctl restart salt-master.

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

Мастер читает основной файл, затем drop-in-файлы из master.d/, и итоговая конфигурация складывается из всех источников. Поэтому автоматизации удобно класть свои настройки отдельными файлами, не трогая основной. Основные группы опций:

• Сеть: interface — адрес, на котором слушать (по умолчанию все интерфейсы), publish_port (4505) и ret_port (4506) — менять их приходится редко, но знать нужно, чтобы правильно открыть файрвол.
• Файловый сервер: file_roots сопоставляет окружения каталогам, классика — окружение base и каталог /srv/salt; именно сюда указывает схема salt:// в состояниях. Аналогично pillar_roots (обычно /srv/pillar).
• Ключи: auto_accept включает автоматический приём ключей миньонов.
• Производительность: worker_threads — число процессов, обрабатывающих запросы миньонов; дефолт рассчитан на небольшие парки.
• Диагностика: log_level и лог в /var/log/salt/master.

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

Правьте конфигурацию по мере роста, а не заранее. Стартовая точка — file_roots и pillar_roots: без них не выстроить структуру состояний. Когда парк вырастает до сотен миньонов и команды начинают отваливаться по таймаутам, наступает время worker_threads — его поднимают в первую очередь. interface ограничивают конкретным адресом на мастерах с несколькими сетями, чтобы порты 4505/4506 не торчали в лишние сегменты. Отдельные drop-in-файлы в master.d/ — правильный способ подключать внешние pillar, настройки GitFS или интеграции: их проще ревьюить, шаблонизировать и накатывать той же системой конфигурации. Саму конфигурацию мастера тоже стоит держать в git — это такой же код, как и SLS-файлы.

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

Первая — забытый перезапуск: опцию поправили, а мастер продолжает работать по-старому, и команда «не работает» уходит в долгий дебаг. Вторая — auto_accept: True в продакшене: любой хост, дотянувшийся до порта 4506, становится доверенным миньоном и получает доступ к файловому серверу — это дыра в безопасности. Третья — синтаксис YAML: табуляция вместо пробелов или сломанный отступ, после чего сервис просто не стартует; проверяйте journalctl -u salt-master при любом подозрении. Четвёртая — конфликтующие значения одной опции в разных drop-in-файлах: побеждает один из них, и итог зависит от порядка чтения, поэтому держите каждую опцию ровно в одном месте.

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

• Конфигурация minion
• Ключи и salt-key
• file_roots и salt://
• Что такое pillar
• Тюнинг производительности