In this recipe, we will learn about some advanced minion configurations, such as environments and grains. We will understand how they work and how to configure them on the minion.
Uncomment and edit the /etc/salt/minion file to set the environment parameter:
environment: development
The environment parameter in a Salt minion determines which environment the minion belongs to. This parameter helps Salt to determine which directory path it should look for on the master to fetch the correct configuration for the minion as per the environment specified.
As we specified in this recipe:
environment: development
When the minion calls and requests the master for its configuration, it looks for the development environment configured on the master and, if it finds one, it then looks for its base path, which in our case is /opt/salt-cookbook/development. It then looks for the relevant files in this directory.
However, do note that this environment parameter is useful when the minion calls the master, that is, the pull mechanism takes place. When the master pushes the configurations to minions, we can specify the environment while doing so but it only tells the master which directory path it should serve the files from. However, it does not tell the master which minions to target. To target minions from the development environment when pushing configurations from the master, we have to use grains, which we will discuss next.
In Salt, grains are information about system properties that helps Salt to target minions and configure pillars and states based on these properties. Salt makes a lot of grains available to us by default, a few being os, cpu, memory, hostname, domain name, IP addresses, MAC addresses, and so on. However, this feature becomes more useful when we are able to configure custom grains to suit our needs such as location, server type, application name, database name, and so on.
Grains can be configured in a couple of ways. The first option is to configure grains in the minion configuration file, that is, /etc/salt/minion, and the second option is to do this in a different file called /etc/salt/grains. In both cases, grains are configured as YAML key-value pairs.
For the first option, that is, in the /etc/salt/minion file, we have to configure the grains as we have done in this recipe:
grains: environment: development location: datacenter1 server_type: webserver
Note the grains key in the first line. This is because the file /etc/salt/minion has a number of other parameters, and we have to explicitly specify that this section is for grains followed by the actual key-value pairs that determine our custom configured data.
For the second option, that is, the file /etc/salt/grains, we populated it as follows:
environment: development location: datacenter1 server_type: webserver
Note the absence of the grains key here. The grains key is not needed in this case as this file is only for grain data. Next, we added the key-value pairs determining our custom data.
However, we have to keep in mind that grain data is static. If the grain data is modified or new grains are added, the minion has to be refreshed for the master to see the new data. This can be done with the help of execution modules, which we will learn later in the book. As of now, a restart of the salt-minion daemon should make the new data available.
The Installing and configuring the Salt minion recipe, to learn how to configure minions
The Targeting minions recipe, in Chapter 2, Writing Advanced Salt Configurations, to learn about how to target minions
The Applying Salt states to minions recipe, to learn how to synchronize minions with masters