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:
Stand up a master server via States (Salting a Salt Master)
Use salt-call commands on a system without connectivity to a master
Masterless States, run states entirely from files local to the minion
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:
curl -L https://bootstrap.saltstack.com -o bootstrap_salt.sh sudo sh bootstrap_salt.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
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
minion is configured to not gather this data from the master.
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.
Configuration which resided in the
master configuration (e.g.
should be moved to the minion configuration
since the minion does not read the master configuration.
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.
For a complete explanation on Salt States, see the tutorial.
base: '*': - webserver
Create the webserver state tree:
apache: # ID declaration pkg: # state declaration - installed # function declaration
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
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
--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
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.