Pillars of Salt system

Pillars are tree-like structures of data defined on the Salt Master and passed through to minions. They allow confidential, targeted data to be securely sent only to the relevant minion. Pillar data is useful for:

Highly Sensitive Data

Information transferred via pillar is guaranteed to only be presented to the minions that are targeted, making Pillar suitable for managing security information, such as cryptographic keys and passwords.

Minion Configuration

Minion modules such as the execution modules, states, and returners can often be configured via data stored in pillar.

Variables

Variables which need to be assigned to specific minions or groups of minions can be defined in pillar and then accessed inside sls formulas and template files.

Arbitrary Data

Pillar can contain any basic data structure in dictionary format, so a key/value store can be defined making it easy to iterate over a group of values in sls formulas.

Pillar is therefore one of the most important systems when using Salt.

Salt Pillar system

Default Pillar tree

Pillar data is managed in a similar way as the Salt State Tree. The Salt master maintains a pillar_roots setup that matches the structure of the file_roots used in the Salt file server. Like the Salt file server the pillar_roots option in the master config is based on environments mapping to directories. The pillar data is then mapped to minions based on matchers in a top file which is laid out in the same way as the state top file. Salt pillars can use the same matcher types as the standard top file.

pillar_roots:
  base:
    - /srv/salt/pillar

This example configuration declares that the base environment will be located in the /srv/salt/pillar directory. It must not be in a subdirectory of the state tree.

The top file /srv/salt/pillar/top.sls used matches the name of the top file used for States, and has the same structure:

base:
  '*':
    - common_pillar

And the actual pillar file at /srv/salt/pillar/common_pillar.sls:

foo: bar
boo: baz

If the same pillar key is defined in multiple pillar SLS files, and the keys in both files refer to nested dictionaries, then the content from these dictionaries will be recursively merged.

External Pillar backends

Salt provides a mechanism for generating pillar data by calling external pillar interfaces. The external pillars that are called when a minion refreshes its pillars is controlled by the ext_pillar option in the Salt master configuration:

ext_pillar:
  - example_a: some argument
  - example_b:
    - argumentA

etcd pillar backend

In order to use an etcd server, a profile must be created in the master configuration file:

my_etcd_config:
    etcd.host: 127.0.0.1
    etcd.port: 4001

After the profile is created, configure the external pillar system to use it. Optionally.

ext_pillar:
  - etcd: my_etcd_config

reclass pillar backend

This ext_pillar plugin provides access to the reclass database, such that Pillar data for a specific minion are fetched using reclass.

ext_pillar:
  - reclass:
        storage_type: yaml_fs
        inventory_base_uri: /srv/salt

reclass assumes a node-centric perspective into your inventory. This is obvious when you query reclass for node-specific information, but it might not be clear when you ask reclass to provide you with a list of groups. In that case, reclass loops over all nodes it can find in its database, reads all information it can find about the nodes, and finally reorders the result to provide a list of groups with the nodes they contain.

Since the term “groups” is somewhat ambiguous, it helps to start off with a short glossary of reclass-specific terminology:

reclass concepts

Concept	Description
Node	A node, usually a computer in your infrastructure
Class	A category, tag, feature, or role that applies to a node Classes may be nested, i.e. there can be a class hierarchy
Application	A specific set of behaviour to apply
Parameter	Node-specific variables, with inheritance throughout the class hierarchy.

A class consists of zero or more parent classes, zero or more applications, and any number of parameters. A class name must not contain spaces. A node is almost equivalent to a class, except that it usually does not (but can) specify applications.

When reclass parses a node (or class) definition and encounters a parent class, it recurses to this parent class first before reading any data of the node (or class). When reclass returns from the recursive, depth first walk, it then merges all information of the current node (or class) into the information it obtained during the recursion.

Furthermore, a node (or class) may define a list of classes it derives from, in which case classes defined further down the list will be able to override classes further up the list.

Lab: Create simple Salt pillar

Pillar data is managed in a similar way as the Salt State tree. The Salt master maintains a pillar_roots setup that matches the structure of the file_roots used in the Salt file server.

Create Salt master configuration file /etc/salt/master.d/pillar.conf with following content to enable basic pillar engine:

pillar_roots:
  base:
    - /srv/salt/pillar

This configuration declares that the base environment will be located in the /srv/salt/pillar directory.

Now create pillar top file /srv/salt/pillar/top.sls on cfg01 node:

base:
  '*':
    - common
  'svc0[1-2]*':
    - apache

And the create pillar file at /srv/salt/pillar/common.sls on cfg01 node containing common server parameters:

linux:
  time_zone: Europe/Prague
  data_center: prg01
  environment: stg
  package:
    byobu:
      version: latest
    htop:
      version: latest

And then create apache pillar file at /srv/salt/pillar/apache.sls on cfg01 node containg apache2 specific configuration parameters:

apache:
  server:
    modules:
      - wsgi_module
    host:
      name.com:
        type: redirect

Now you can test the content of your pillar data for all nodes in your infrastructure:

cfg01# salt '*' pillar.items