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

Конфигурация миньона живёт в YAML-файле /etc/salt/minion и drop-in-файлах в каталоге /etc/salt/minion.d/ (файлы *.conf). В минимальном виде миньону нужна ровно одна опция — master: с адресом мастера, всё остальное имеет разумные значения по умолчанию. Но именно на уровне конфигурации миньона решаются практически важные вещи: под каким идентификатором машина известна мастеру, что она делает при старте, какие статические grains ей приписаны и как она себя ведёт при недоступности мастера. Как и у мастера, изменения применяются только после перезапуска сервиса: systemctl restart salt-minion.

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

Ключевые опции. master — адрес мастера (имя или IP); значением может быть и список адресов — так включается multi-master-схема. id — идентификатор миньона, под которым его видит мастер и по которому таргетируются команды; если опция не задана, миньон берёт FQDN хоста и кэширует результат в файле /etc/salt/minion_id — при следующих стартах используется именно кэш, а не свежий hostname. startup_states: highstate заставляет миньон применить highstate сразу после запуска сервиса — удобно для самонастройки машин после разворачивания. Блок grains: в конфигурации задаёт статические grains (роль, датацентр, окружение), которые дальше используются в таргетинге и top file. log_level управляет подробностью лога /var/log/salt/minion. Автоматизации кладут свои настройки отдельными файлами в minion.d/ — например, cloud-init записывает туда master и id, не трогая основной файл.

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

Явно задавать id стоит всегда, когда hostname машин нестабилен или неинформативен: осмысленные идентификаторы вида web-01.prod делают таргетинг и top file читаемыми. Статические grains в конфигурации — правильное место для «паспортных» атрибутов машины: роль, команда-владелец, окружение; в отличие от pillar, эти данные объявляет сам миньон. startup_states включают там, где машины создаются автоматически и должны доводить себя до нужного состояния без ручного вмешательства. Список в master: применяют для отказоустойчивости, когда мастеров больше одного. А minion.d/ — стандартный способ раскатывать фрагменты конфигурации самим же Salt: состояние управляет drop-in-файлом и перезапускает сервис по watch.

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

Главная ловушка — кэш minion_id в золотых образах: если образ снят с машины, где миньон уже стартовал, все клоны поднимутся с одинаковым идентификатором и будут конфликтовать за один ключ на мастере. Перед снятием образа удаляйте /etc/salt/minion_id и каталог ключей миньона. Вторая ошибка — смена id на живой машине без понимания последствий: мастер видит «нового» миньона, и его ключ нужно принять заново, а старый — удалить через salt-key -d. Третья — правка конфигурации без перезапуска сервиса. Четвёртая — дублирование одной опции в основном файле и в minion.d/: значение возьмётся только из одного места, и поведение выглядит «мистическим», пока не сведёшь опцию в единственный файл.

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

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

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

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

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