Runners и salt-run

Runners — это модули, которые выполняются непосредственно на мастере, а не на миньонах. Это отличает их от execution-модулей: команда salt '*' pkg.upgrade отправляет задание миньонам, которые выполняют его у себя, тогда как salt-run manage.status запускает Python-код прямо в процессе мастера. Runners нужны для задач, которые не могут быть выполнены на миньонах: например, для просмотра состояния парка, сбора данных о заданиях, запуска оркестрации или работы с шиной событий. Для вызова 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 — правильное место для админской логики, которой нужен доступ к данным мастера: свои отчёты, интеграции, проверки.

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

Основная путаница у новичков — не различать 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)