События и Reactor

Событийная подсистема отличает Salt от чисто «прогонных» инструментов конфигурации, обеспечивая постоянный поток событий «снизу вверх» и механизм автоматической реакции на них. В системе происходящее порождает события на шине поверх ZeroMQ, такие как запуск и возврат задач, аутентификация миньонов и старт миньона. 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
• Событийная модель
• Оркестрация