Understanding and configuring Salt pillars

We will create pillar data for the development environment.

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.