SaltStack is built around an event infrastructure that can be leveraged and extended to drive reactive provisioning, configuration, and management across all devices in your infrastructure.

1. Event–Driven Self–Healing Infrastructure
with​ SALTSTACK
SaltStack is a complete systems management software platform for scalable
orchestration and automation of any infrastructure or application stack. Salt is built
around an event infrastructure that can be leveraged and extended to drive reactive
provisioning, configuration, and management across all devices in your infrastructure.
Salt’s internal components communicate with each other by sending and listening to
events. In Salt, events are sent for about everything you could imagine.
Benefits of event-driven architecture:
An event-driven architecture can help to achieve a flexible system that can adapt to
changes and make decisions in real time. Real-time situational awareness means that
business decisions, whether manual or automated, can be made using all of the
available data that reflects the current state of your systems.
SALTSTACK Components:
Salt Master:​ ​Central management system. This system is used to send commands and
configurations to the Salt minion that is running on managed systems.
Salt Minions:​Managed system. This system runs the Salt minion which receives commands
and configuration from the Salt master.
Formulas (States):​A declarative or imperative representation of a system configuration.
Grains:​System variables. Grains are static information about the underlying managed system
and include operating system, memory, and many other system properties. You can also define
custom grains for any system.

2. Pillar:​User-defined variables. These secure variables are defined and stored on the Salt
Master and then ‘assigned’ to one or more minions using targets. Salt pillar data stores values
such as ports, file paths, configuration parameters, and passwords.
Beacons:​Beacons let you use the Salt event system to monitor non-Salt processes.When
monitored activity occurs in a system process, an event is sent on the Salt event bus that can
be used to trigger a reactor.
1> Beacons are deployed on Salt Minions.
2> It uses modules to monitor systems.
3> publish messages to Salt event bus
Salt beacons can currently monitor and send Salt events for many system activities, including:
● file system changes - ​INOTIFY
● system load - ​MEMUSAGE
● service status - ​SERVICE
● disk usage - ​DISKUSAGE
Reactor:​Salt's Reactor system gives Salt the ability to trigger actions in response to an event.
It is a simple interface to watching Salt's event bus for event tags that match a given pattern and
then running one or more commands in response.
1> Reactors are defined on Salt Master
2> Reads messages from Salt event bis
3> Maps events to reactor SLS file based on configuration file

3. Lets configure with existing Salt setup, In this practical
will demonstrate beacons SERVICE module.
Master node ip​ - 192.168.0.10 ​- hostname - ​master-node-0-10
Minion node ip ​- 192.168.0.20 ​- hostname - ​minion-node-0-20
Minion configurations:
Install prerequisites:
yum install -y python2-psutil python-inotify python-pip
create config file for beacons:
vim /etc/salt/minion.d/beacons.conf
beacons:
service:
- services:
nginx:
onchangeonly: True
restart Salt minion service to reload the configuration
systemctl restart salt-minion
Master configurations:
install prerequisites:
yum install -y python2-psutil python-inotify python-pip
verify the beacons config on minions from Master:
CMD -- salt * beacons.list
output:
minion-node-0-20:
beacons:
service:

4. - services:
nginx:
onchangeonly: true
create reactor.conf file
vim /etc/salt/master.d/reactor.conf
reactor:
- 'salt/beacon/*/service/*':
- /home/salt/automation/salt/reactor/service.sls
create service.sls file
vim /home/salt/automation/salt/reactor/service.sls
{%- if data[data['service_name']]['running'] == False %}
start {{data['service_name']}}:
local.service.start:
- tgt: {{data['id']}}
- args:
- name: {{data['service_name']}}
{%- endif %}
restart Salt master service to reload the configuration
systemctl restart salt-master
NOW let's stop the Nginx service on minion and see the logs in
Master with below command. Here will break the log in 4 stages and
explain each of them.
run on master node - salt-run state.event pretty=true
STAGE 1-​ ​Beacons sends event to salt master event bus for Nginx service not
running
salt/beacon/​minion-node-0-20​/service/nginx {
"_stamp": "2020-05-25T18:50:32.654503",
"id": "​minion-node-0-20​",
"nginx": {
"running": false
},

5. "service_name": "nginx"
}
20200525185032777481 {
"_stamp": "2020-05-25T18:50:32.777877",
"minions": [
"​minion-node-0-20​"
]
}
STAGE 2 -​ ​Now runner will check the condition when Nginx service status is
down on minion
salt/job/20200525185032777481/new {
"_stamp": "2020-05-25T18:50:32.778353",
"arg": [
{
"__kwarg__": true,
"name": "nginx"
}
],
"fun": "service.start",
"jid": "20200525185032777481",
"minions": [
"​minion-node-0-20​"
],
"missing": [],
"tgt": "​minion-node-0-20​",
"tgt_type": "glob",
"user": "root"
}
STAGE 3 -​ ​Runner with trigger the command and start the Nginx service on
minion
salt/job/20200525185032777481/ret/​minion-node-0-20 {
"_stamp": "2020-05-25T18:50:32.972192",
"cmd": "_return",
"fun": "service.start",
"fun_args": [

6. {
"name": "nginx"
}
],
"id": "​minion-node-0-20​",
"jid": "20200525185032777481",
"retcode": 0,
"return": true,
"success": true
}
STAGE 4 -​ ​Once the service is started again beacons will push the event in
master event bus with Nginx status running
salt/beacon/​minion-node-0-20​/service/nginx {
"_stamp": "2020-05-25T18:50:33.658475",
"id": "​minion-node-0-20​",
"nginx": {
"running": true
},
"service_name": "nginx"
}