Fotolia
Set Salt configuration management free without a master
Salt configurations usually involve at least one minion controlled by a master, but that's not always necessary. See how to use Salt to run a single machine in masterless mode.
In some scenarios, the Salt configuration management tool is best run without a master.
Salt configuration management setups typically include a Salt master with Salt minions on various machines to receive and communicate configuration settings. The minion is the agent that runs on the managed computer, and the Salt master coordinates it all. Most deployments for the Python-based configuration management tool follow this design -- but not all do.
To run a single machine, Salt offers masterless mode. There are some good uses for a masterless Salt configuration. For example, a server may not be able to contact the master, but the administrator still wants to automate that server's configuration.
The essence of Salt configuration management is the state file, in which the configuration of a machine is declared. In masterless mode that has the state file available, the Salt minion can run without contacting the master to apply the state.
IT administrators can apply this scenario to configure any state, including a state that will set up a new master. If no state files are available, the salt-call command can be used to run Salt commands without a master.
Bootstrapping the minion server
To run Salt configuration management in masterless mode, set up Salt components on the server it will manage. The SaltStack website provides a bootstrap script:
curl -L https://bootstrap.saltstack.com -o bootstrap_salt.sh sudo sh bootstrap_salt.sh
After bootstrapping a node, tell the node not to look for a Salt master. Set the file_client parameter in the minion.conf configuration file to local: file_client: local. Next, use a state tree to begin the actual Salt configuration process; a state tree defines the work that will occur. State files can be used to perform any task, including package installation, file modification and user creation. This example defines a state tree that installs a web server.
A valid state tree has a minimum of two state files (sls files). We'll use the files /srv/salt/top.sls and /srv/salt/webserver.sls. There's always the top.sls, which is the starting point and contains generic instructions, used to define all work to be done on a Salt minion. At least one state file always provides detailed information about the rest of the states. The webserver.sls file in this example defines what exactly will occur, and is referred to from the top.sls file.
The /srv/salt/top.sls file is a YAML file that can have the following content:
base:
'*':
- webserver
And the /srv/salt/webserver.sls YAML file can take the following contents:
httpd:
pkg:
- installed
The first line in the webserver.sls file refers to the actual name of the package you will install; this package name works on CentOS, but may be different on another platform. This example uses a pkg statement to install a software package. Alternatively, administrators can use state files to deploy any type of configuration to the Salt managed node.
After defining state file contents, apply them using the salt-call command. Use salt-call --local state.apply to tell salt-call to apply the state, where the option --local tells the command that it doesn't have to contact a Salt master to complete the action.
These steps enable an administrator to apply a state on a masterless Salt client. The essential component in this Salt configuration is the state tree file. While masterless Salt configuration management is less popular than the configuration of a master and minions, it is useful for administrators who will automate as much of their infrastructure provisioning as possible.
