SaltStack reactors and orchestration
This is where Salt differs most from Ansible and Puppet. Both of those converge hosts toward a declared state — on a schedule, or when someone runs them. Salt has an event bus, so infrastructure can respond to things happening rather than only to being asked.
That changes what is expressible. Auto-remediation, scaling triggers, and reacting to a minion coming online are natural here and awkward in a convergence-only model. The cost is that event-driven systems are harder to reason about: the trigger is somewhere other than the action, and debugging means reconstructing what fired.
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
Fleet coordination, not host configuration
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.