SaltStack - Configuration Management

Configuration management is one of the most significant concept in SaltStack. It is used to create a reusable configuration template, called a state. The state describes everything required to put a system component or an apppcation into a known configuration.

Salt State

Salt state is a reusable configuration for a specific part of a system. States are easier to understand and described using a simple YAML.

Create a Salt State

Salt states are easy to create. Let us create a simple state in this chapter. Move to the directory “salt-vagrant-demo/saltstack/salt/” and create a file named samples.sls and add the following pnes in it.

samples.sls

install_network_packages:
   pkg.installed:
      - pkgs:
         - rsync
         - lftp
         - curl

Now, save the file and run the following command in the Salt master.

root@saltmaster:/home/vagrant# salt  minion1’ state.apply samples

Here, we installed rsync, lftp and curl through the pkg.installed module using the Salt state in a salt minion, minion1. If it works properly, you could see the response as shown below.

It will produce the following output −

minion1:
----------
   ID: install_network_packages
   Function: pkg.installed
   Result: True
   Comment: All specified packages are already installed
   Started: 08:08:48.612336
   Duration: 545.385 ms
   Changes:

Summary for minion1
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time: 545.385 ms

Apply Salt State

Now that we have created a state using the ‘.sls’ file and appped it by specifically calpng it. Salt has a default state file called as the top.sls file. The top file is used to apply multiple state files to Salt minions. The top file describes where states should be appped. Well, States and the Top file work together to create the core of SaltStack’s configuration management capabipty.

Let us now create a simple top.sls file in the directory saltstack/salt and add the following.

top.sls

base:
   * :
      - common
    minion1 :
      - samples

Here, the state, commonly apppes to all system state, samples apppes to minion1.

Next, run the Salt master and apply the state as shown below.

root@saltmaster:/home/vagrant# salt  *  state.apply

It will produce the following output −

minion1:
----------
   ID: common_packages
   Function: pkg.installed
   Result: True
   Comment: All specified packages are already installed
   Started: 09:33:35.642355
   Duration: 588.21 ms
   Changes:

Summary for minion1
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time: 588.210 ms
minion2:
----------
   ID: common_packages
   Function: pkg.installed
   Result: True
   Comment: All specified packages are already installed
   Started: 09:33:35.890331
   Duration: 602.79 ms
   Changes:

Summary for minion2
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time: 602.790 ms

Apply Batch Size

If you have a large number of connected minions, then you can pmit how many systems are updated at once. It is performed by using the –batch-size option, which is defined below.

root@saltmaster:/home/vagrant# salt --batch-size 5  *  state.apply

It will produce the following output −

Executing run on [ minion2 ,  minion1 ]
jid:
   20170314094638482664
minion1:
----------
   ID: common_packages
   Function: pkg.installed
   Result: True
   Comment: All specified packages are already installed
   Started: 09:46:41.228519
   Duration: 582.24 ms
   Changes:

Summary for minion1
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time: 582.240 ms
retcode:
   0
jid:
   20170314094638482664
minion2:
----------
   ID: common_packages
   Function: pkg.installed
   Result: True
   Comment: All specified packages are already installed
   Started: 09:46:41.153609
   Duration: 605.235 ms
   Changes:

Summary for minion2
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time: 605.235 ms
retcode:
   0

Salt State Functions

Salt state functions are used to install and configure apppcations on your remote system. Let us install a “Vim” package using the Salt state function.

Create and Apply State Function

Create a file named “sample.sls” under the directory “salt-vagrant-demo/saltstack/salt/sample.sls” and add the following −

sample.sls

install vim:
   pkg.installed:
      - name: vim

Once, Vagrant environment is up, run the salt master and apply the sample.sls by running the following command.

root@saltmaster:/home/vagrant# sudo salt  minion2’ state.apply sample

It will produce the following output −

minion2:
----------
   ID: install vim
   Function: pkg.installed
   Name: vim
   Result: True
   Comment: Package vim is installed
   Started: 15:07:45.752764
   Duration: 553.506 ms
   Changes:

Summary for minion2
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time: 553.506 ms

Now, we have added a package “Vim”. Let us now test the package using the Salt testing method.

Salt State Testing

The test run is mandated by adding the “test = True” option to the states. The return information will show states that will be appped in yellow and the result is reported as ‘None’.

The following command is used to test the state −

root@saltmaster:/home/vagrant# sudo salt  minion2’ state.apply sample test = True

It will produce the following output −

minion2:
----------
   ID: install vim
   Function: pkg.installed
   Name: vim
   Result: True
   Comment: Package vim is already installed
   Started: 15:07:45.752764
   Duration: 553.506 ms
   Changes:

Summary for minion2
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time: 553.506 ms

SaltStack ─ Pillar Component

Pillar is an essential component to make Salt states reusable. It is used to define secure data for minions assigned using targets. Salt pillar data stores values such as ports, file paths, configuration parameters and passwords.

Pillar config File

The configuration for the pillar_roots in the master config file is shown below −

pillar_roots:
   base:
      - /srv/pillar

Here, the file is in the “/srv/pillar” directory.

Consider, the top file located in /srv/pillar/top.sls has the following structure −

base:
    * :
      - default

Now, move to the default.sls file located in /srv/pillar/default.sls and add the following code.

# Default pillar values
apache
git

After saving the file, refresh the pillar to update all the changes.

Refreshing the Pillar

You can refresh the pillar using the following command.

root@saltmaster:/home/vagrant# salt  *  saltutil.refresh_pillar

The above command is used to refresh the Salt pillar data on all the minions.

List Pillar Data

To pst out the pillar data, you can use the command given below.

root@saltmaster:/home/vagrant# salt  *  pillar.ls

It will produce the following output −

minion2:
   - apache
   - git
minion1:
   - apache
   - git

Pillar Items

Once the pillar is setup, the data can be viewed on the minion via the pillar module. It can be accessed through the function pillar.items, which is defined below.

root@saltmaster:/home/vagrant# salt  *  pillar.items

It will produce the following output −

minion2:
   ----------
   apache:
      httpd
   git:
      git
minion1:
   ----------
   apache:
      httpd
   git:
      git

SaltStack – Include Component

The ‘Include’ component is used to define the same configuration task in multiple places. It is easy to perform. At the top of your state file, add an include using the following format −

include:
   - state file 1 
   - state file 2

Here, state file 1 and state file 2 are the names of the SLS files that you want to include. No need to include the .sls extension. The Included Salt states are inserted at the top of the current file.

State File in the Subdirectory

You can include subdirectory state file using a dot (.). It acts as a directory separator.

include:
   - dir.sls1 

Grains Interface

Grains is an interface used to derive the information about the underlying system. Grains are collected for the operating system, domain name, IP address, kernel, OS type, memory and many other system properties.

Grains Targeting

Grain data can be used when targeting minions, which is defined in the following code block.

root@saltmaster:/home/vagrant# salt -G  os:Ubuntu  test.ping

It will produce the following output −

minion1:
   True
minion2:
   True

Listing Grains

Grains can be psted by using the ‘grains.ls’ module, which is defined below.

root@saltmaster:/home/vagrant# salt  *  grains.ls

List Items

Like Pillar, Grains data can also be psted by using the grains.items’.

root@saltmaster:/home/vagrant# salt  *  grains.items