In Infrastructure Management with SaltStack: Part 1 I introduced Salt and covered installing and basic use. In this post I’ll be going a bit deeper and discuss
grains, The State system, and
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 have
Selective Targeting of Minions
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
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
-G switch 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
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
The first line names the formula.
Next the apache
httpd package is confirmed to be installed, if it is not then the package manager installs it.
pkg: - installed
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 the
service: - running - watch: - pkg: apache - file: /etc/httpd/conf/httpd.conf - user: apache
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
pkg it will be executed after. The same understanding applies to
group. This is also transitive so
user will execute after
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
/etc/httpd/conf/httpd.conf: file.managed: - source: salt://apache/httpd.conf - user: root - group: root - mode: 644
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
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
top file for Pillar. The root of the Pillar system is
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.