It may be hard to imagine on the development side, but there are instances where a deployed host is not accessible from the Salt Master in a production environment. This forces a bit of creativity if you have a set of standard formulas you need to apply to the host.
For instance, imagine a host sitting in a highly restricted DMZ network. Even with the advent of Salt SSH for minionless administration, SSH access may only be opened from a jumpbox and not the Salt Master itself. In cases like this, a Masterless Minion is a viable alternative.
A Masterless Minion is simply a deployment model where the minion’s ‘salt-call’ command is used to apply the state directly, and instead of contacting the Master to get state and pillar data, it is pulled from the local minion itself.
You typically setup the file structure of a masterless minion in the same way that the master is setup. State files are copied into ‘/srv/salt’, pillar data into ‘/srv/pillars’, but now the salt-call is driven by the config file ‘/etc/salt/minion’ instead of ‘/etc/salt/master’.
There is nothing forcing you into these standard directory structures, it can be changed, but I’m just pointing out that the same defaults apply.
The first step is to configure the Minion. Edit the default ‘/etc/salt/minion’ file and set:
Now, in this same ‘/etc/salt/minion’ file, define your file root (states), and pillar root locations. This has the same format as what you are used to seeing in the Salt Master’s ‘/etc/salt/master’ file. Change these values to reflect what you use on your Master.
file_roots: base: - /srv/salt pillar_roots: base: - /srv/pillar
At this point, you should copy the state and pillar directories from your Master over to your Masterless Minion. This can be done via SSH/SCP or any other mechanism you have in place.
As a last step, stop the Minion service. It is unnecessary for executing these states locally.
> sudo service salt-minion stop
Execute State Locally
Now you are ready to execute your states locally. Using the salt-call method, you can apply state, show pillar data, and execute anything else you usually do from the remote Salt Master. For example, to check pillar data:
> salt-call pillar.items
To apply highstate:
> salt-call state.apply