Runners и salt-run

Runners — это модули, которые выполняются на самом мастере, а не на миньонах. Это принципиальное отличие от execution-модулей: команда salt '*' pkg.upgrade публикует задание миньонам и те выполняют его у себя, а salt-run manage.status запускает Python-код прямо в процессе мастера. Runners нужны для задач, у которых нет «своего» миньона: посмотреть состояние парка, поднять данные о заданиях, запустить оркестрацию, поработать с шиной событий. CLI-инструмент для их вызова — salt-run, и правила таргетинга к нему неприменимы: таргета нет, есть только имя runner-функции и её аргументы.

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

Runner — это Python-модуль из подсистемы мастера; встроенные лежат в составе Salt, свои можно класть в каталог, указанный в опции runner_dirs конфигурации мастера. Вызов выглядит как salt-run <модуль>.<функция> [аргументы]. Самые ходовые встроенные runners: manage — обзор парка (salt-run manage.status покажет живых и упавших миньонов, manage.down — только недоступных); jobs — работа с историей заданий (salt-run jobs.active, salt-run jobs.lookup_jid <jid> — забрать результаты по идентификатору задания); state — оркестрация через salt-run state.orchestrate; salt-run state.event pretty=True — смотреть шину событий в реальном времени. Поскольку код исполняется на мастере, у runner'а есть доступ к ключам, кэшу возвратов миньонов, файловому серверу и конфигурации — тому, чего у миньонов нет. Результат печатается локально, без стадии сбора возвратов по сети.

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

Runners — ваш инструмент, когда вопрос звучит «что происходит с инфраструктурой в целом», а не «сделай на этих машинах». Диагностика: manage.status перед раскаткой, чтобы не считать упавшие миньоны «проваленными». Разбор инцидентов: jobs.lookup_jid, когда команда ушла по таймауту, а знать результат всё-таки нужно. Отладка событийной модели: state.event — первое, что открывают при настройке beacons и Reactor. Оркестрация: state.orchestrate — это тоже runner, и это не случайно: координировать порядок между машинами может только тот, кто видит их все, то есть мастер. Наконец, кастомный runner — правильное место для админской логики, которой нужен доступ к данным мастера: свои отчёты, интеграции, проверки.

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

Главная путаница у новичков — не различать salt и salt-run: пытаются написать salt '*' manage.status (миньоны про такой модуль не знают) или наоборот salt-run pkg.upgrade (runner не таргетирует миньоны). Запомните: salt — про миньонов, salt-run — про мастера. Вторая ошибка — забывать, что runner работает с кэшем: manage.status опирается на данные о последних ответах, и только что умерший миньон может ещё числиться живым. Третья — давать доступ к salt-run слишком широко: runners исполняются с правами процесса мастера, и через внешнюю аутентификацию (eauth) их стоит открывать точечно, по конкретным функциям.

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

• Оркестрация
• Runner state.orchestrate
• Удалённое выполнение
• Шина событий
• Внешняя аутентификация (eauth)