A SaltStack tutorial to start mastering data center minions

Set up a test environment

To follow along with this SaltStack tutorial, use any Linux distribution as the master OS for a test environment. Most common Linux distributions include the SaltStack binaries in their repositories. However, to configure Red Hat Enterprise Linux or CentOS 7.x as a Salt Master, add the EPEL repository that contains unsupported packages that will run on RHEL and CentOS. After enabling this repository, run yum install salt-master to install the SaltStack master and yum install salt-minion to set up a Red Hat-based system as a minion.

The minion automatically tries to find its master during install, based on a domain name system record that resolves to "salt." As an alternative, set up the /etc/salt/minion file by including a line that reads master: 192.168.0.10 -- assuming that is the IP address of the master. On both systems, TCP ports 4505 and 4506 must be open in the firewall.

The Salt Master and the minions use keys to communicate. When a minion connects to a master for the first time, it automatically stores keys on the master. Use the salt-key -L command on the master system to obtain a list of the keys of all registered minions. The fact that a key is listed does not mean it is accepted. To accept all minion keys from the Salt Master, use the salt-key -A command. To verify the availability of all currently registered minions, run the salt-run manage.status command.

Run commands on minions

To run a command on a minion, structure the command starting with the salt command, followed by the targets on which to run the command, and the module name, which is followed by the function. The administrator can use an asterisk to refer to all minions, or use the minion name to affect that particular minion. An example of this structure is salt "*" test.ping, which will issue the ping command against all minions.

Salt is flexible in addressing minions, and regular expressions can refer to a minion name. Once comfortable with the basics in this SaltStack tutorial, try addressing minions based on attributes, which run commands against minions that meet specific criteria.

SaltStack uses grains to store specific minion attributes -- for example, information about the operating system, the hardware or BIOS. Use the grain module and refer to a specific function to request information about a minion. For example, the command salt "*" grains.item os queries all minions to discover what operating system they currently run. Run grain-specific commands to target minions with specific properties as well. For example, salt -G "cpuarch:x86_64" test.ping pings all minions running a 64-bit operating system. SaltStack includes a set of default, predefined grains, and it is relatively easy for an administrator to add grains.

Module command options

Administrators have multiple options to run commands on a minion. The easiest method is to use the salt-run command, followed by the minion specification and the specific command for a given task. Salt modules, however, offer the administrator more flexibility, as they are independent of the operating system. For example, the file.append module allows the administrator to append a line to a file:

salt "*" file.append /etc/hosts

10.0.0.10         salt.example.com

While modules should be OS-agnostic, exercise caution when using them. The module example given in this SaltStack tutorial, for example, only works on Linux- and Unix-based minions that have a file with the name /etc/hosts available.

There is limited standardization in package managers on Linux. Consider using the pkg.install module to install or reinstall a software package flexibly. For example, salt "*" pkg.install ldap-client installs the Lightweight Directory Access Protocol client package on all SaltStack minions.