maxkabakov - Fotolia
Assess Salt configuration management's capabilities and limitations
Salt's benefits for IT operations include fast configuration and flexible, responsive functioning. Get a handle on the basics of Salt, then install it to explore the tool's capabilities.
The Salt configuration management and orchestration tool, often called SaltStack, is event-driven and enables fast operations -- when the admin is familiar with how to use it.
Salt is written in Python. It has two simple processes: The salt-master runs on the master server, and the salt-minions each run on the machines under control.
Salt configuration management works by executing remote shell operations in parallel rather than synchronously, enabling multiple commands, which can be thought of as shell commands, to target multiple machines simultaneously. Because the tool is event-driven, it responds to events as they occur, even when a command is actively running outbound on that machine. This two-way communication is facilitated through persistent connections on ports 4505 and 4506 by default.
This persistent connection gives Salt a concurrent push model in addition to the event response capability. Minions issue events to let the master know of changes in their state, rather than run on a preset schedule.
There are also limitations with the tool, explained later in this article. The best way to explore Salt configuration management is to get a basic understanding of how it works and install it for a trial run.
Install Salt
Enter the IP address for the master salt onto each minion and the master. Although the host name is customizable, the master should resolve to salt. Then, run the below command on both master and minions -- do not include -P on the master:
curl -L https://bootstrap.saltstack.com -o install_salt.sh
sudo sh install_salt.sh -P -M
Salt uses keys for authentication. The minion requests connection to the master upon startup. On the master, run the following command to show minion keys that are pending acceptance:
salt-key -L
The following command will accept them:
salt-key -A
On Ubuntu, run this command to stop or start Salt:
service salt-minion stop (or start)
service salt-master stop (or start)
Set up a Salt configuration file
Salt configuration files are sometimes called state files. These files contain individual commands for minions, such as to retrieve specific information from a MySQL database, append to files or query Redis. State is, simply, instructions to install the targeted software on managed systems and keep it in a specified condition through event responses.
By default, Salt stores configuration files in the /srv/salt folder, created during the initial installation. The main file state is /srv/salt/top.sls. Salt creates different environments, such as production, as subdirectories within this folder.
Salt is free, but the company SaltStack offers a paid enterprise version. SaltStack Enterprise adds commercial features to the open source Salt tool, including a GUI and the ability to extend Salt to Windows, Mac and Solaris.
Salt configuration files are written in YAML or Jinja, which is Python's template language. Jinja enables admins to add control logic to commands, such as if-then statements. For example, this command verifies that the OS on a managed system is not FreeBSD:
{% if grains['os'] != 'FreeBSD' %}
YAML files are simpler text files than Jinja uses, without much logic. For Salt, they work by matching text; blocks of code are indicated through exactly two spaces between each indented command.
In the example shown below, base indicates the root environment. Consider using base, dev, prod and others for various environments. Also, in the example, euro* indicates all servers with hostnames that begin with euro. And redis directs Salt to the file /srv/salt/redis.sls for further instructions:
base:
'euro*':
- redis
In /srv/salt/redis.sls, redis is a Python module. Modules are SaltStack-written Python code packages that install and manage specific software. Execution modules offer commands to execute specific functions in different environments -- to copy files, for example.
A Salt user can write his own modules using instructions provided on SaltStack's website. At time of publication, the only public repository of community-created modules is on GitHub.
State is declared with pkg and the installed function runs the script. Through pkg, Salt knows to use yum for Red Hat versions of Linux and apt-get for Ubuntu.
redis:
pkg:
- installed
Run the following command to install redis on the target machine. This particular command targets the hostname eurovps:
salt 'eurovps' state.apply
Targets can include:
- Globbing, which enables wildcards, such as *;
- grains;
- regular expressions;
- pillars, which are environments defined by a file hierarchy; and
- hostnames.
Salt installs redis and responds like so:
A state file operates differently for Salt users than running specific functions in specific modules. For example, the command below checks that only the root user can read the sudoers file:
Salt grains
Grains in the Salt configuration management parlance are system properties: kernel version, properties of the CPU and so on. List them as so:
Grains enable Salt to target configurations to machines based on their properties. This command executes on all machines that have an x86-64-type CPU:
salt -G 'cpuarch:x86_64' test.ping
The Salt module test.ping shows that a minion is online.
Monitoring beacons
A beacon monitors metrics and events, such as disk space, file modification or custom events that are set up in your own software to send a message to Salt.
The beacon below watches for changes to the file /tmp/readme.txt:
beacons:
inotify:
/tmp/readme.txt:
mask:
- modify
Salt limitations
Salt configuration management technology and use are complicated. For help from the community, go to Stack Overflow with questions about specific problems. To report bugs, turn to Salt's GitHub page and documentation.
Salt does not provide much error information, but you can run a minion with a debug option:
salt-minion -l debug
An additional option is to use the following:
tail -f /var/log/salt/minion
There are some areas where Salt users might struggle.
Jenkins is among the most popular build-and-release systems for CI/CD and Agile and offers a Salt plug-in, but there's not much of a feedback loop. Jenkins informs the Salt admin that a command has run or has not, without many details. The experience is akin to attempting to open a webpage to see status 200 and nothing more.
The inotify function on Salt does not work on CentOS versions older than 7 or on Windows OSes. Beacons will run on CentOS version 6.9, but as with Windows, they cannot monitor certain kernel events without the user installing additional software.
