Using state modules

In the previous recipe, you learned about how you can use execution modules to perform configuration tasks in Salt. In this recipe, you are going to learn about of what state modules are and how to use them.

How to do it...

We will use the same minion and the same example as the previous recipe, but we will do the same task using state modules.

1. Create a new state in the staging environment called cron by creating a new directory called cron and create a file in it called init.sls.
2. Edit the init.sls file to have the following contents:

   find /var/log/ -mtime +30 -exec rm -rf {] \;:
     cron.present:
       - user: root
       - minute: 00
       - hour: 12
       - daymonth: '*'
       - month: '*'
       - dayweek: '*'

3. Run the following command to apply the state to the minion:

   [root@salt-master ~]# salt 'stgdc1log01' state.sls cron saltenv=staging
   stgdc1log01:
   ----------
    ID: find /var/log/ -mtime +30 -exec rm -rf {] \;
    Function: cron.present
    Result: True
    Comment: Cron find /var/log/ -mtime +30 -exec rm -rf {] \; added to root's crontab
    Started: 05:19:18.830011
    Duration: 75.282 ms
    Changes:
    ----------
    root:
    find /var/log/ -mtime +30 -exec rm -rf {] \;
   
   Summary
   ------------
   Succeeded: 1 (changed=1)
   Failed: 0
   ------------
   Total states run: 1
   

How it works...

In this recipe, you learned how to perform configurations tasks on minions using state modules.

State modules in Salt are configured by creating proper directory structures for the module and populating the necessary files in the directory. The directory of the module is created in the base directory of the environment, in which we are configuring the module and use the name of the directory as the module name to perform configuration tasks. A complete list of the available state modules can be found at http://docs.saltstack.com/en/latest/ref/states/all.

In this recipe, we made the same configuration task as the previous recipe, that is, to configure a cron entry for the root user, which looks for files older than 30 days in the /var/log directory and deletes them. However, we used the state module instead of the execution module to do this.

First, we created the directory called cron in the base directory of the staging environment, and our state will be called cron, based on the name of this directory. Next, we created a file called init.sls in the directory. The contents of this file are referenced when the state is called cron. If there is a second file called app.sls, then it will be called cron.app. All configuration files should have the .sls extension.

We then populated the file with the following entries:

find /var/log/ -mtime +30 -exec rm -rf {] \;:
  cron.present:
    - user: root
    - minute: 00
    - hour: 12
    - daymonth: '*'
    - month: '*'
    - dayweek: '*'

The first line indicates the cron command that will be updated in the crontab file. The second line is the one that indicates the module and the function being used. Here, the state module cron is being used along with the present function. This indicates that the cron entry should be added if absent and should have the correct configuration if already present. We then define the user, day, and time configurations for the cron entry in YAML format. All the available data fields for all the state modules are defined in the preceding link.

Often a generic name for the particular configuration can be defined in the state files. Let's assume that we are configuring a file, for which there are two ways to define it.

• The first method is as follows:

  /etc/hosts:
    file.managed:
      - source: salt://hostconfig/files/hosts

• The second method is as follows:

  host_config_file:
    file.managed:
      - name: /etc/hosts
      - source: salt://hostconfig/files/hosts

In the first method, we defined the name of the file, that is, its path in the first line and then the configurations were done. However, in the second method, we defined a generic name called host_config_file to reference this configuration and then defined the actual name of the file with the - name field. In all subsequent configurations, the name mentioned in the first line is used to reference this configuration, which can be the real name and path of the file or the generic name.

Finally, we applied the state to the minion with the following command:

[root@salt-master ~]# salt 'stgdc1log01' state.sls cron saltenv=staging

In this command, we tell salt that the module that we are going to apply to the minion is a state module by mentioning state.sls. We then mention the name of the state, that is, cron and the environment of the minion. If the configured file was app.sls instead of init.sls, we would mention cron.app in the command. Do note that state.sls is actually an execution module which is used to apply state modules to minions.

There's more…

There is an alternate method of applying state modules to a minion, which is known as highstate. After a state is configured, the top.sls file of the relevant environment is edited to have an entry similar to the following:

staging:
  '*':
    - cron

There can be a list of states similar to cron, which can be entered one after the other. The minions can also be targeted by using the methods demonstrated in Chapter 2, Writing Advanced Salt Configurations.

Next, the state can be applied to the minion using the following command:

[root@salt-master ~]# salt 'stgdc1log01' state.highstate

This command will apply all the matching states from the top.sls file to the minion. This method is usually used when there are multiple states to be applied to a minion, and applying them one by one using the first method can be tedious.

See also

• Chapter 4, General Administration Tasks, to demonstrate the use of state modules
• The Configuring templates recipe, to learn about how to leverage the power of Salt in configuring custom templates for services and system configurations