События и Reactor

Событийная подсистема — то, что отличает Salt от чисто «прогонных» инструментов конфигурации: помимо команд «сверху вниз», в нём есть постоянный поток событий «снизу вверх» и механизм автоматической реакции на них. Всё, что происходит в системе, порождает события на шине поверх ZeroMQ: запуск и возврат job, аутентификация миньонов, старт миньона. Beacons расширяют этот поток наблюдениями за самой ОС: упал сервис, изменился файл, кончается диск. Reactor на мастере замыкает контур: сопоставляет теги событий с SLS-файлами реакций и запускает их. Вместе это даёт event-driven инфраструктуру — систему, которая не только выполняет команды, но и сама реагирует на происходящее.

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

Полный контур выглядит так. Beacon на миньоне — фоновая проверка с интервалом (например, beacon service следит за процессом nginx). Заметив изменение, он публикует событие: сообщение с тегом вида salt/beacon/web-01/service/ и словарём данных, которое по ZeroMQ уходит на мастер. Мастер выкладывает событие на свою шину; посмотреть поток вживую можно командой salt-run state.event pretty=True — это первый инструмент отладки всей связки. Reactor в конфиге мастера хранит карту «шаблон тега → список SLS»; при совпадении он рендерит reactor-SLS (внутри доступны tag и data события) и асинхронно выполняет описанные там вызовы — execution-модули на миньонах, runner'ы на мастере. События можно порождать и вручную: salt-call event.send 'myapp/deploy/done' '{"version": "1.2"}' с миньона — так во всю эту механику встраиваются собственные скрипты и CI.

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

Классика — self-healing: beacon видит, что сервис умер, reactor запускает состояние, возвращающее его к жизни; человек узнаёт из уведомления, а не из инцидента. Второй сценарий — автоматизация жизненного цикла машин: миньон при старте шлёт событие salt/minion/<id>/start, reactor применяет к новой машине highstate — удобно при автоскейлинге. Третий — аудит и интеграции: события о смене конфигов (beacon inotify) уходят во внешние системы, а внешние webhooks через salt-api превращаются в события и запускают оркестрацию. Общий критерий: реакция должна быть простой и детерминированной. Сложные многошаговые сценарии из reactor лучше делегировать runner'у state.orchestrate, оставив реактору роль тонкого диспетчера.

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

Главный антипаттерн — «толстый» reactor: длинная логика с условиями прямо в reactor-SLS; выполняется он асинхронно, ошибки видны только в логе мастера, и отлаживать это мучительно — держите реакции тонкими. Вторая ошибка — событийные штормы: слишком частые beacons плюс реакция, которая сама порождает события, дают лавину и загруженный мастер; ставьте разумные интервалы и проверяйте контур на цикличность. Третья — неидемпотентные реакции: если событие придёт дважды (а рассчитывать нужно именно на это), реакция не должна ломать систему повторным выполнением. И не доверяйте слепо данным события при принятии решений с правами — содержимое формирует отправитель.

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

• Шина событий
• Beacons
• Reactor
• Событийная модель
• Оркестрация