Mixed Environments¶
When running in a mixed environment (you already have (Proxy) Minions running, and you would also like to use the salt-sproxy), it is highly recommended to ensure that salt-sproxy is using the same configuration file as your Master, and the Master is up and running.
Using the --use-existing-proxy
option on the CLI, or configuring
use_existing_proxy: true
in the Master configuration file, salt-sproxy
is going to execute the command on the Minions that are connected to this
Master (and matching your target), otherwise the command is going to be
executed locally.
For example, suppose we have two devices, identified as minion1
and
minion2
, extending the example salt-sproxy 101:
/srv/salt/pillar/top.sls
:
base:
'minion*':
- dummy
/srv/salt/pillar/dummy.sls
:
proxy:
proxytype: dummy
The Master configuration remains the same:
/etc/salt/master
:
pillar_roots:
base:
- /srv/salt/pillar
Starting up the Master, and the minion1
Proxy:
# start the Salt Master
$ salt-master -d
# start the Proxy Minion for ``minion1``
$ salt-proxy --proxyid minion1 -d
# accept the key of minion1
$ salt-key -y -a minion1
# check that minion1 is now up and running
$ salt minion1 test.ping
minion1:
Test
In a different terminal window, you can start watching the Salt event bus (and leave it open, as I’m going to reference the events below):
$ salt-run state.event pretty=True
# here you will see the events flowing
Executing the following command, notice that the execution takes place locally
(you can identify using the proxy/runner
event tag):
$ salt-sproxy -L minion1,minion2 test.ping --events
minion1:
True
minion2:
True
The event bus:
20190603145654312094 {
"_stamp": "2019-06-03T13:56:54.312664",
"minions": [
"minion1",
"minion2"
]
}
proxy/runner/20190603145654313680/new {
"_stamp": "2019-06-03T13:56:54.314249",
"arg": [],
"fun": "test.ping",
"jid": "20190603145654313680",
"minions": [
"minion1",
"minion2"
],
"tgt": [
"minion1",
"minion2"
],
"tgt_type": "list",
"user": "sudo_mircea"
}
proxy/runner/20190603145654313680/ret/minion1 {
"_stamp": "2019-06-03T13:56:54.406816",
"fun": "test.ping",
"fun_args": [],
"id": "minion1",
"jid": "20190603145654313680",
"return": true,
"success": true
}
proxy/runner/20190603145654313680/ret/minion2 {
"_stamp": "2019-06-03T13:56:54.538850",
"fun": "test.ping",
"fun_args": [],
"id": "minion2",
"jid": "20190603145654313680",
"return": true,
"success": true
}
As presented in Event-Driven Automation and Orchestration, there is one event for the job creating, then
one for job start, and one event for each device separately (i.e.,
proxy/runner/20190603145654313680/ret/minion1
and
proxy/runner/20190603145654313680/ret/minion2
, respectively).
Now, if we want to execute the same, but use the already running Proxy Minion
for minion1
(started previously), simply pass the --use-existing-proxy
option:
$ salt-sproxy -L minion1,minion2 test.ping --events --use-existing-proxy
minion2:
True
minion1:
True
In this case, the event bus would look like below:
proxy/runner/20190603150335939481/new {
"_stamp": "2019-06-03T14:03:35.940128",
"arg": [],
"fun": "test.ping",
"jid": "20190603150335939481",
"minions": [
"minion1",
"minion2"
],
"tgt": [
"minion1",
"minion2"
],
"tgt_type": "list",
"user": "sudo_mircea"
}
salt/job/20190603150335939481/new {
"_stamp": "2019-06-03T14:03:36.047971",
"arg": [],
"fun": "test.ping",
"jid": "20190603150335939481",
"minions": [
"minion1"
],
"missing": [],
"tgt": "minion1",
"tgt_type": "glob",
"user": "sudo_mircea"
}
salt/job/20190603150335939481/ret/minion1 {
"_stamp": "2019-06-03T14:03:36.147398",
"cmd": "_return",
"fun": "test.ping",
"fun_args": [],
"id": "minion1",
"jid": "20190603150335939481",
"retcode": 0,
"return": true,
"success": true
}
proxy/runner/20190603150335939481/ret/minion2 {
"_stamp": "2019-06-03T14:03:36.245592",
"fun": "test.ping",
"fun_args": [],
"id": "minion2",
"jid": "20190603150335939481",
"return": true,
"success": true
}
proxy/runner/20190603150335939481/ret/minion1 {
"_stamp": "2019-06-03T14:03:36.247206",
"fun": "test.ping",
"fun_args": [],
"id": "minion1",
"jid": "20190603150335939481",
"return": true,
"success": true
}
In this sequence of events, you can notice that, in addition to the events from
the previous example, there are two additional events:
salt/job/20190603150335939481/new
- which is for the job start against the
minion1
Proxy Minion, and salt/job/20190603150335939481/ret/minion1
-
which is the return from the minion1
Proxy Minion. The presence of the
salt/job
event tags proves that the execution goes through the already
existing Proxy Minion.
If you would like to always execute through the available Minions, whenever possible, you can add the following option to the Master configuration file:
use_existing_proxy: true