Running a masterless salt-minion lets you use Salt's configuration management for a single machine without calling out to a Salt master on another machine.
Since the Salt minion contains such extensive functionality it can be useful to run it standalone. A standalone minion can be used to do a number of things:
It is also useful for testing out state trees before deploying to a production setup.
The salt-bootstrap script makes bootstrapping a server with Salt simple for any OS with a Bourne shell:
wget -O - https://bootstrap.saltstack.com | sudo sh
See the salt-bootstrap documentation for other one liners. When using Vagrant to test out salt, the Vagrant salt provisioner will provision the VM for you.
To instruct the minion to not look for a master, the file_client
configuration option needs to be set in the minion configuration file.
By default the file_client
is set to remote
so that the
minion gathers file server and pillar data from the salt master.
When setting the file_client
option to local
the
minion is configured to not gather this data from the master.
file_client: local
Now the salt minion will not look for a master and will assume that the local system has all of the file and pillar resources.
Note
When running Salt in masterless mode, do not run the salt-minion daemon. Otherwise, it will attempt to connect to a master and fail. The salt-call command stands on its own and does not need the salt-minion daemon.
Following the successful installation of a salt-minion, the next step is to create a state tree, which is where the SLS files that comprise the possible states of the minion are stored.
The following example walks through the steps necessary to create a state tree that ensures that the server has the Apache webserver installed.
Note
For a complete explanation on Salt States, see the tutorial.
top.sls
file:/srv/salt/top.sls:
base:
'*':
- webserver
/srv/salt/webserver.sls:
apache: # ID declaration
pkg: # state declaration
- installed # function declaration
Note
The apache package has different names on different platforms, for instance on Debian/Ubuntu it is apache2, on Fedora/RHEL it is httpd and on Arch it is apache
The only thing left is to provision our minion using salt-call
.
The salt-call command is used to run remote execution functions locally on a minion instead of executing them from the master. Normally the salt-call command checks into the master to retrieve file server and pillar data, but when running standalone salt-call needs to be instructed to not check the master for this data:
salt-call --local state.apply
The --local
flag tells the salt-minion to look for the state tree in the
local file system and not to contact a Salt Master for instructions.
To provide verbose output, use -l debug
:
salt-call --local state.apply -l debug
The minion first examines the top.sls
file and determines that it is a part
of the group matched by *
glob and that the webserver
SLS should be applied.
It then examines the webserver.sls
file and finds the apache
state, which
installs the Apache package.
The minion should now have Apache installed, and the next step is to begin learning how to write more complex states.