Understanding and configuring Salt pillars

In this recipe, we will learn about pillars, how they fit into the Salt architecture, and how to configure them. We will create pillar data for a user state, which we will configure later using this pillar data.

How to do it...

We will create pillar data for the development environment.

1. First, we will create a directory for the name of the pillar data (usually it is named the same as the state we are configuring this pillar for, that is, if we are configuring this pillar for the user state, we will name this pillar directory user:

   [root@salt-master ~]# mkdir \
   /opt/salt-cookbook/pillar/development/user
   
   [root@salt-master ~]# touch \
   /opt/salt-cookbook/pillar/development/user/init.sls
   

2. Edit /opt/salt-cookbook/salt/pillar/development/user/init.sls and add the following content:

   dev_user:
     name: thomas
     password: "$1$PG1inys0$kB2I83KzEVzVs9G7xLHjA1"
     uid: 1001
     comment: "Thomas"

   And run the following command:

   [root@salt-master ~]# touch \
   /opt/salt-cookbook/pillar/development/top.sls
   

3. Edit /opt/salt-cookbook/pillar/development/top.sls and add the following content:

   development:
     '*':
       - user

How it works...

In Salt, a pillar is a feature used to store data such as keys and passwords or any other type of data such as repetitive directory paths or usernames that are then accessed from states. All minion-specific data to be seen only by the minion is stored in pillars and is visible to the minion for which the data is meant and configured. In this recipe, we created pillar data in the development environment for a user state, which we will configure in the next recipe.

First, we created a directory similar to the name of the state that we will configure in the pillar directory path of the development environment:

[root@salt-master ~]# mkdir \
/opt/salt-cookbook/pillar/development/user

Next, we created a file called init.sls in the directory created earlier, where we will create the pillar data. The default file in a pillar directory is named init.sls, where .sls is the file extension for all Salt state, pillar, and top files. Salt manages the SLS files internally. If the user pillar is referenced, we must understand that it's the content of the init.sls file in the user directory that is being referred to. The contents of all SLS files in Salt are in the YAML format, and indentations are very important both for parsing by Salt and to keep the configurations organized.

In the init.sls file, we populated the pillar data that we need. Basically, we configured the first user of a user list of developers mentioning various parameters for the user, such as their username, user ID, password in hash format (note that it is enclosed in quotes to avoid problems with special characters), and the comment:

dev_user:
  name: thomas
  password: "$1$PG1inys0$kB2I83KzEVzVs9G7xLHjA1"
  uid: 1001
  comment: "Thomas"

If we are planning to add multiple users, the format can be as shown here:

dev_user:
  thomas:
    password: "$1$PG1inys0$kB2I83KzEVzVs9G7xLHjA1"
    uid: 1001
    comment: "Thomas"

The methods to parse this kind of YAML definition will be discussed later in the book.

Next, we created a file called top.sls in the base pillar directory of the development environment. The contents of the top.sls file determine which nodes or minions will have access to which pillar data. We created the following contents in the file:

development:
  '*':
    - user

The first line mentions the environment. Without this line, the base environment will be used as the default. The * operator in the second line is a wildcard, which means that all minions will have access to the user pillar data. This line can be manipulated to add various types of matchers to target minions that will be discussed later in the book. The third line mentions the name of the pillar directory that we created. If only the name of the directory is mentioned, we have to understand that the contents of the init.sls files are being referred to. If we create a file called devs.sls in the user directory, then the contents of that file can be mentioned in the top.sls file as user.devs, shown as follows:

development:
  '*':
    - user.devs

When the states are run on the minions, this file is checked and these definitions determine if that particular minion is allowed to access the contents of this pillar.

See also

• The Writing and retrieving pillar data and Using pillar data in states recipes in Chapter 2, Writing Advanced Salt Configurations, to learn more about using pillars
• The Understanding and writing Salt states recipe, to learn how to use this pillar data in states