Reactor

Reactor — компонент мастера, который слушает шину событий и на совпадение тега запускает заданные SLS-файлы реакций. Это исполнительная половина событийной модели: beacons и job'ы поставляют события, reactor превращает их в действия — перезапустить сервис, применить highstate к новой машине, дёрнуть runner. Карта реакций описывается в конфиге мастера: шаблону тега (с glob-подстановками) сопоставляется список reactor-SLS. Ключевой момент, о который спотыкаются почти все: reactor-SLS — это не обычный state-файл. Он не описывает желаемое состояние системы — он описывает, какие вызовы Salt сделать в ответ на событие, и рендерится в момент прихода события с доступом к его содержимому.

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

Реакции объявляются в /etc/salt/master:

reactor:
  - 'salt/minion/*/start':
    - /srv/reactor/highstate.sls
  - 'salt/beacon/*/service/':
    - /srv/reactor/restart.sls

Reactor-SLS — Jinja-шаблон, которому доступны переменные tag и data (полезная нагрузка события). Результат описывает вызовы четырёх видов: local.<функция> — execution-модуль на миньонах (имя local — потому что используется LocalClient), runner.<функция> — runner на мастере, wheel.<функция> — управление ключами и конфигурацией, caller.<функция> — вызов на миньоне-отправителе (для salt-call окружений):

{% if data['id'].startswith('web-') %}
highstate_new_minion:
  local.state.apply:
    - tgt: {{ data['id'] }}
{% endif %}

Выполнение асинхронное: reactor ставит вызовы в очередь и не ждёт результатов. Посмотреть активную карту реакций можно командой salt-run reactor.list, а отлаживать связку — держа открытым salt-run state.event pretty=True и глядя в лог мастера.

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

Reactor уместен там, где реакция проста и однозначна: перезапуск упавшего сервиса по beacon-событию, применение highstate к миньону по salt/minion/<id>/start (типовая связка для автоскейлинга), отправка уведомления, запись факта во внешнюю систему. Рабочее правило — «thin reactor»: сам reactor-SLS должен быть минимальным диспетчером, а всё многошаговое (проверить, дождаться, сделать, откатить) выносится в оркестрацию — reactor вызывает runner.state.orchestrate, и логика живёт в обычном, тестируемом orchestrate-SLS. Это же правило спасает отладку: оркестрацию можно запустить руками и увидеть вывод, реакцию — нельзя.

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

Первая — сложная логика прямо в reactor-SLS: выполняется асинхронно, вывода нет, ошибки — только в логе мастера; отладка превращается в археологию. Вторая — слепое доверие данным события: содержимое data формирует отправитель, поэтому реакции с высокими правами на его основе опасны; хрестоматийный пример — автопринятие ключей реакцией на salt/auth через wheel.key.accept: без дополнительной проверки это дыра, позволяющая любому желающему зарегистрировать миньона. Третья — циклы: реакция запускает job, job порождает события, события снова матчатся реакцией — мастер начинает молотить сам себя; проверяйте, что теги реакций не пересекаются с тегами порождаемых ими событий. И помните: изменения секции reactor в конфиге требуют перезапуска мастера.

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

• Шина событий
• Beacons
• События и Reactor
• Runner state.orchestrate
• Ключи и salt-key