Introduction
This post is all about targeting minions and configuration management. Up to now every time we have invoked a command on a minion we have used the syntax salt "*" module.command. The "*" glob is the global target. It targets every minion who’s private key is currently accepted by the master. While this is useful for a few things we are going to need a way target systems on a more ganular basis. For this we havegrains.
Selective Targeting of Minions
The grains program runs on each minion node collecting system data and storing it in memory for fast retrieval. To list all available grain items and their current settings running the following command:
salt "*" grains.items
Example Output:
Salt has been nice enough to color code the output to make it easy to understand. Everything in blue is the key and everything in green is the value, of the key:value pair.
Let’s begin selectively targeting minions on the command line by matching a certain value of a named key. Matching can be done verbatim or with a glob.
To invoke filtering by grain match while using an Execution Module with the salt CLI command the -Gswitch is used. For example, to select all minions running the Ubuntu OS we could run the following command:
salt -G 'os:Ubunt*' test.ping
In the second command above we see that we can return one “grain” with the argument grains.itemitem.
Now we can target minions and return system data. Let’s expand on that knowledge with the State System.
The State of Configuration Management
The State System is how Salt executes configuration management. The State System is built on two things, SLS Formula files written in YAML and the state.sls Execution Module.
SLS formulas are like Puppet manifests or Chef recipes. They contain structured data that instruct the minion to “be” a certain way. Here are a few examples of that can be contained in a formula:
- pkg: installs a package
- service: starts a service
- user.present: create a user
- file.managed: copy a file and maintain metadata.
Formulas are stored under the /srv/salt directory. A complex directory structure is supported with multiple target minions through the use of the top.sls file. It is detailed and requires explanation. Read the doc here.
Let’s step though an example apache.sls formula:
The first line names the formula.
apache:
Next the apache httpd package is confirmed to be installed, if it is not then the package manager installs it.
pkg:
- installed
The service key makes sure that the httpd service is running. Also there is the watch key word. Used in this context, it will monitor for changes to the package, config file, or the apache user. If found it will resart thehttps service.
service:
- running
- watch:
- pkg: apache
- file: /etc/httpd/conf/httpd.conf
- user: apache
The user.present and group.present key words setup the apache user and group. if these already exist, this will confirm the settings and change them if needed to conform. Also, notice the require key word. Require is a way to enforce order. By group requiring pkg it will be executed after. The same understanding applies to user and group. This is also transitive so user will execute after pkg
Also notice the form user.present. There is also an inverse user.absent that removes a user. Group has a similar construct.
user.present:
- uid: 87
- gid: 87
- home: /var/www/html
- shell: /bin/nologin
- require:
- group: apache
group.present:
- gid: 87
- require:
- pkg: apache
The next section is a managed file. The first line is the path to the file on the minion node. The source key word specifies the file on the salt-master that will be copied. The default root of salt:// is /srv/salt
/etc/httpd/conf/httpd.conf: file.managed: - source: salt://apache/httpd.conf - user: root - group: root - mode: 644
Read more about the State System here.
It is important to note that the values we have set so far in the formula are all literals. To set variables we need to invoke the pillar system.
A Pillar of Salt
Pillars can be best explained as the reverse of grains. Grains contains information about minions generated by the minion. Pillars contain information about minions defined on the master.
These can be several things. Variables for states or static init data for multiple minions can both be stored in pillars. Pillars can also exist in a tree configuration almost identical to how the state tree. The is also a topfile for Pillar. The root of the Pillar system is /srv/pillar.
The Pillar system, like most of Salt, starts simple and can get very complex. If you need this system I suggest you know what you a getting into. Read the SaltStack docs here.
You should now have a better understanding of Salt. Stay tuned until next time where we go further down the Salt mine with Events and the Reactor System.
Pandiyan M 