Pillars in Salt

At first Pillars were something that I could not wrap my head around due to confusing Salt documentation. Eventually the docs became better and with working in Salt extensively, the pillars finally kicked in. They are something that any experienced Salt user should be using as they open up more doors in your DevOps infrastructure.

Pillars are basically a secure key value store in Salt that can be used by Salt States. You can store confidential information and options in pillars instead of keeping them in configs and the pass this data to specifically assigned minions (which you can do in pillars/top.sls file).

There are two main ways of getting a value from a pillar in your config file:

{{ salt['pillar.get']('elasticsearch:pathdata', 'default value') }}

{{ pillar['elasticsearch']['pathdata'] }}

The default value in first example can be substitute with an actual default value that you want to be filled in case your pillar dict is not found. In the second example, Salt will throw out Pillar SLS errors in case the pillar is not found. Clearly when you can store default values, using the first example is better.

To assign pillars to specific minions, you can do the following:

base:
  '*':
    - grains

  'P@fqdn:(app|web)server(0|1).domain.com:
    - nginx
    - java

{% if grains['specialgrain'] == "specialgrain_match" %}
    - special_state
{% endif %}

In the above example, we are assigning grains pillar to all the hosts (via *). All hosts matching a grains PCRE (P@) compound matcher will get nginx and java pillars. Finally, any hosts that have a grain that matches specialgrain_match will get the special_state pillar.