Targeting minions

One of the biggest advantages of Salt is the ability to target minions based on various parameters. This gives us the flexibility to apply states, run commands, and gather information from any combination of minions that we need. In this recipe, you will learn how to target minions using different methods.

How to do it...

Since there are quite a lot of ways to target minions, we will not run the command and view the output for each of them. We will look at the possible ways of targeting minions and the methods to implement them. Each of the following examples show the procedure to target minions from the Salt command and also in the top.sls file. However, examples for top.sls are provided only for matchers that have this feature.

The procedure to target minions on the salt command line is as follows:

• Name-based matching with shell style globbing:

  [root@salt-master ~]# salt 'devdc1app01' state.sls group
  [root@salt-master ~]# salt '*.salt-cookbook.com' state.sls \ user
  
  '*.salt-cookbook.com':
   - group
   - user
  

• List-based matching:

  [root@salt-master ~]# salt –L 'prddc1mon01,prddc2mon05' \ state.highstate
  
  'prddc1mon01,prddc2mon05':
   - match: list
   - hostconfig
  

• Regular expression-based matching:

  [root@salt-master ~]# salt 'dev-(dc1|dc2|dc3)-db' state.sls \ mysql
  
  'dev-(dc1|dc2|dc3)-db':
   - match: pcre
   - mysql
  

• Grain-based matching:

  [root@salt-master ~]# salt –G 'server_type:app' state.sls \ tomcat
  
  'server_type:app':
   - match: grain
   - tomcat
  

• Subnet/IP-based matching:

  [root@salt-master ~]# salt –S 10.0.0.0/24 state.sls hostconfig
  [root@salt-master ~]# salt –S 192.168.0.1 state.sls dns
  
  '10.0.0.0/24':
   - match: ipcidr
   - dns
  

• Pillar-based matching:

  [root@salt-master ~]# salt –I 'app_user:stg-app' \ state.highstate
  
  'app_user:stg-app':
   - match: pillar
   - postgres
  

• Matching on grain-based regular expressions:

  [root@salt-master ~]# salt –grain-pcre 'os:(RedHat|CentOS)' \ pillar.items
  
  'os:(RedHat|CentOS) ':
   - match: grain_pcre
   - hostconfig
  

• Compound matching:

  [root@salt-master ~]# salt –C 'G@os:Ubuntu and \ S@172.32.0.0/24' pillar.item fqdn
  
  'G@os:Ubuntu and S@172.32.0.0/24':
   - match: compound
   - hostconfig
  

• Nodegroup matching:

  [root@salt-master ~]# salt –N prodmon state.sls monitoring
  
  'prodmon':
   - match: nodegroup
   - monitoring 
  

How it works...

The various methods of targeting minions demonstrated earlier are described here:

1. Name-based matching with shell style globbing: Name-based matching is nothing but the Building Web Applications with Python and Neo4j name of the minion ID, which in most cases is the FQDN of the minion node. We can also apply matches with * to match all hosts of a domain name as shown. This format can be used for numerous other use cases.
2. List-based matching: List-based matching is simply a comma separated list of minion IDs and specified by the –L parameter in the command line and the list matcher in the top file.
3. Regular expression-based matching: Regular expression patterns enable us to match minions based on regular expressions applied on the minion ID such as dev-(dc1|dc2|dc3)-db. It is specified by pcre in the top file and in quotes in the command line.
4. Grain-based matching: Grain-based matches enable us to target minions based on their grains and values of the grains. One or multiple grains can be matched at a time. This is specified with the –G parameter on the command line and grain in the top file.
5. Subnet/IP-based matching: This type of matching allows us to target minions based on their IP addresses. The matcher can be a single IP address or an entire subnet with a CIDR notation such as 10.0.0.0/24. This matcher is specified with –S on the command line and ipcidr in the top file.
6. Pillar-based matching: Pillar-based matching can be used to target minions by specifying the pillar key and value available to the minion. It may seem similar to grains, but the difference between them is that grains data is obtained from the minions and pillar data is obtained from the master. It is specified by –I on the command line and pillar in the top file.
7. Matching on grain-based regular expressions: Similar to regular expressions in minion IDs, grain values can also be matched using regular expressions similar to os:(RedHat|CentOS). This is specified on the command line with –grain-pcre and with grain_pcre in the top file.
8. Compound matching: Compound matchers are probably the most important matchers available in Salt. It helps us combine the power of all other types of matchers and use them in combination to target minions. Each and every matcher in this list can be used in the compound matcher. In this example, we demonstrated a combination of grain-based and CIDR-based matching to target minions.

   It is specified by –C on the command line and compound in the top file.

9. Nodegroup matching: In the previous recipe, you learned how to configure nodegroups. Here, we used the nodegroups to target minions. This is just another way to implement the compound matcher, that is, we define nodegroups in the main configuration file using compound matcher and then use the nodegroup here to target minions.

   This keeps the complex combinations in the master configuration file and gives us a clean way to target minions by just supplying the nodegroup name. It is specified by –N on the command line and nodegroup in the top file.

See also

• The Understanding and configuring Salt pillars recipe, in Chapter 1, Salt Architecture and Components, to learn more about pillars
• The Writing and retrieving pillar data recipe, to learn more about pillars
• The Using grains in states and Configuring nodegroups recipes, to know more about grains and nodegroups
• Chapter 3, Modules, Orchestration, and Scaling Salt, to learn about more advanced configurations in Salt