In this chapter, we'll discuss how to setup SaltStack to manage infrastructure using 'roles', instead of matching solely on the
id of the minion. This is an intermediate topic, so if you are not familiar with the following concepts inside of Salt, we urge you to check them out in this guide:
- Master/Minion setup
To manage our infrastructure using grains, we'll attach a particular
grain as a role inside the architecture. We'll then tell the Master to match defined roles based upon these grains. Finally, we'll separate out these grains such that we can set multiple roles per-host.
Grains in SaltStack are the interface to derive information about the underlying system. Every machine has a set of immutable grains that won't change. These are loaded when the salt minion starts up so these cannot be modified on the fly. Grains include information like the OS model and version, the number of CPUs a particular machine has, how much memory is available to a machine and more.
SaltStack provides a method for modifying these grains and adding additional information to the grains dictionary in several different ways by either setting them in the
/etc/salt/minion config and/or through the
To add grains to the minion config, simply include the
grains key, for example:
id: minion-01 grains: roles: - database region: us-east-1
To set custom grains within the
/etc/salt/grains file, simply set the grains without prefacing them with
grains:, like so:
roles: - database region: us-east-1
This is how we will setup our role-based execution environment. Setting the
roles grain and then matching states and pillar information based off of these.
SaltStack also enables you to set roles at the command-line as well. To set roles on the command-line, use the command-line from the master:
salt 'minionId' grains.setval roles [roleA, roleB]
Note, this can also be run on the salt minion with a slightly modified comamnd:
salt-call grains.setval roles [roleA, roleB]
In order to apply our roles to different states, we'll have to
target the minions based upon the contents of the roles in their
grains. We'll use SaltStack's powerful targeting system to target minions.
Although we'll talk more about the targeting system in-depth in another chapter, we'll run through a basic introduction to the targeting system.
SaltStack provides a mechanism to select minions based upon simple or complex rules. The targeting system gives you the ability to specify which minion or groups of minions should run a command, apply states, have access to certain pillars, etc.
There are multiple ways to target a minion, but the default method is by machine along the
minion_id. This is the
id of the minion that the minion is configured with in the
/etc/salt/minion configuration file.
salt web1 nginx.restart
We can also match minions based on their grains. This is called compound matching. Let's say we want to run a command only on all of our ubuntu instances. We can do this with the following command:
salt -C 'G@os:Ubuntu' test.ping
Or what if we only want to run a command on all of our webservers:
salt -C 'G@roles:web' test.ping
We can use this functionality when we run a highstate across the cluster. We can use the targeting sytnax in the
top.sls file. for instance:
base: 'roles:saltmaster': - match: grain - salt.master 'roles:mysql': - match: grain - database
As you can can see, targeting turns out to be very easy to do from within SaltStack.
This same syntax can be used with the pillar
highstate, it will apply the appropriate sls files to the right nodes simply based upon their roles.
Note, that we are using arrays as our roles list. SaltStack will still match multiple roles using this same syntax, so it's possible to start a machine with multiple roles.