SaltStack reactors and orchestration
This is the part of Salt that most clearly shows its event-driven character.
Reactors
Reactors listen to the master’s event bus and map matching event tags to small reactor SLS files. The Salt user guide stresses that these files should stay simple and fast to render, because the real point is to respond to events quickly and hand off heavier work to client interfaces or worker threads.
That model is powerful for:
- auto-remediation
- notification flows
- infrastructure scaling triggers
- controlled reactions to service or minion events
Orchestration
Orchestration uses salt-run state.orch or salt-run state.orchestrate to coordinate multi-machine workflows from the master.
Unlike normal minion states, orchestration states can call several interfaces in one flow:
- remote execution on minions
- state or highstate application
- master-side runners
- wheel actions such as key management
Why it matters
This is where Salt stops looking like a configuration management tool and starts looking like a fleet coordination system. It is especially useful when Linux administration involves dependencies between machines rather than isolated host setup.
Design cautions
- Reactor logic should stay small and predictable.
- Event-driven systems can create loops if beacons and reactors trigger each other carelessly.
- Orchestration deserves the same clarity and review discipline as application code because it can move a lot of infrastructure quickly.