Pillar is an interface for Salt designed to offer global values that can be distributed to all minions. Pillar data is managed in a similar way as the Salt State Tree.
Pillar was added to Salt in version 0.9.8
Note
Storing sensitive data
Unlike state tree, pillar data is only available for the targeted minion specified by the matcher type. This makes it useful for storing sensitive data specific to a particular minion.
The Salt Master server 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.
The configuration for the pillar_roots in the master config is identical in behavior and function as the file_roots configuration:
pillar_roots:
base:
- /srv/pillar
This example configuration declares that the base environment will be located in the /srv/pillar directory. The top file used matches the name of the top file used for States, and has the same structure:
/srv/pillar/top.sls
base:
'*':
- packages
This further example shows how to use other standard top matching types (grain matching is used in this example) to deliver specific salt pillar data to minions with different 'os' grains:
dev:
'os:Debian':
- match: grain
- servers
/srv/pillar/packages.sls
{% if grains['os'] == 'RedHat' %}
apache: httpd
git: git
{% elif grains['os'] == 'Debian' %}
apache: apache2
git: git-core
{% endif %}
Now this data can be used from within modules, renderers, State SLS files, and more via the shared pillar dict:
apache:
pkg:
- installed
- name: {{ pillar['apache'] }}
git:
pkg:
- installed
- name: {{ pillar['git'] }}
Once the pillar is set up the data can be viewed on the minion via the pillar module, the pillar module comes with two functions, pillar.data and pillar.raw. pillar.data will return a freshly reloaded pillar and pillar.raw wil return the current pillar without a refresh:
# salt '*' pillar.data
[1] | Note that you cannot just list key/value-information in top.sls. |
When pillar data is changed on the master the minions need to refresh the data locally. This is done with the saltutil.refresh_pillar function.
salt '*' saltutil.refresh_pillar
This function triggers the minion to refresh the pillar and will always return True
Pillar data can be used when targeting minions. This allows for ultimate control and flexibility when targeting minions.
salt -I 'somekey:specialvalue' test.ping
For convenience the data stored in the master configuration file is made available in all minion's pillars. This makes global configuration of services and systems very easy but may not be desired if sensitive data is stored in the master configuration.
To disable the master config from being added to the pillar set pillar_opts to False:
pillar_opts: False