We have learned that you can run execution modules by defining the minion name or via * when running on all minions. But running Salt states and execution modules on all the minions in the stack, or on individual minions, is less than ideal when you have hundreds or even thousands of minions being managed by your masters.
Here is where Salt introduces the grains interface, which allows us to identify minions by specific characteristics or even set our own type of label or role to a group of minions that share a same purpose or characteristics, so we can perform more targeted configuration management.
We can leverage the grains interface with the same syntax in which we would execute any command in Salt:
dsala@master:~$ salt “minion1” grains.items
With the preceding command, we list all the different hardware and software characteristics of the system that we targeted. In the output, we can see things such as the operating system family, the system architecture, and even the hypervisor that we are using to run the VM.
This will help us to create state definitions targeting specific systems via something called a top file, which we will discuss in the Chapter 14, Getting Your Hands Salty. An example of a Salt state top file definition using grains and targeting all Debian family VMs will look like this:
base:
'os_family:Debian:
- match: grain
- httpd
As mentioned before, we can also create custom grains in our minions to define roles and tag our minions with unique value pairs. This is useful for grouping minions in specific tasks; for example, all the VMs of the QA team can be tagged with a key value pair, departement: qa, for example. Another way of grouping could be by role, such as appfoo: frontend, and so on. There are many ways to use grain targeting, and all will depend on how we want to administer or push and maintain the desired states.