salt-call и masterless-режим

salt-call — это CLI, запускаемый на самом миньоне, а не на мастере. Та же библиотека execution-модулей, тот же движок states — но выполнение и вывод происходят локально, на машине, где вы стоите. Два главных применения: отладка (видно полный лог выполнения именно этого миньона) и masterless-режим с флагом --local, когда Salt работает вообще без мастера — конфигурация, states и pillar читаются с локального диска. Masterless превращает Salt в инструмент класса «настрой одну машину», пригодный для сборки образов, CI и локальной разработки формул без всякой инфраструктуры.

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

Обычный salt-call test.ping выполняет функцию локально, но за данными (файлы по salt://, pillar) обращается к мастеру. С флагом --local обращения к мастеру нет вовсе: salt-call --local state.apply возьмёт SLS-файлы из file_roots, указанных в конфиге миньона (по умолчанию /srv/salt), pillar — из локальных pillar_roots, и применит состояния к самой машине. Для мастерless-работы на постоянной основе в конфиге миньона выставляют file_client: local — тогда флаг можно не указывать. Главный отладочный приём: salt-call state.apply -l debug показывает полный процесс — рендеринг Jinja, загрузку grains, порядок выполнения states и точную причину падения, тогда как на мастере вы видите только итоговый результат. Посмотреть grains локально — salt-call --local grains.items.

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

Первый сценарий — отладка: state падает на одном миньоне из сотни, вы заходите на него и запускаете salt-call state.apply mystate -l debug, получая трассировку, недоступную с мастера. Второй — сборка образов: в Dockerfile или Packer-шаблоне достаточно поставить пакет миньона, положить states и выполнить salt-call --local state.apply — мастер, ключи и порты не нужны. Третий — CI-проверка формул: прогон states в чистом контейнере на каждый merge request. Четвёртый — единичные машины (edge-узлы, рабочие станции, домашний сервер), где мастер избыточен: states хранятся в git, машина периодически делает git pull и salt-call --local state.apply. Если машин становится много и нужна центральная точка управления и сбора результатов — это сигнал переходить на полноценную схему с мастером.

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

Частая ошибка — забыть --local на машине без мастера: salt-call будет долго пытаться достучаться до мастера и упадёт по таймауту, хотя states лежат рядом на диске. Обратная ситуация: --local на машине, подключённой к мастеру, — и вы удивляетесь, почему не подтянулся pillar с мастера — в masterless-режиме доступны только локальные данные. Третья ошибка — считать вывод salt-call и вывод мастера эквивалентными по правам: salt-call требует root (или sudo) на самой машине. Четвёртая — разложить states не туда: в masterless-режиме пути берутся из file_roots конфига миньона, а не из привычного серверного /srv/salt на мастере — проверьте /etc/salt/minion прежде чем винить Salt.

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

• Конфигурация minion
• state.apply и state.sls
• file_roots и salt://
• Salt в CI/CD
• salt-ssh (agentless)