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 %}

company: Foo Industries

Warning: https://docs.saltstack.com/en/latest/faq.html#faq-grain-security

See Is Targeting using Grain Data Secure? for important security information.

The above pillar sets two key/value pairs. If a minion is running RedHat, then the apache key is set to httpd and the git key is set to the value of git. If the minion is running Debian, those values are changed to apache2 and git-core respectively. All minions that have this pillar targeting to them via a top file will have the key of company with a value of Foo Industries.

Consequently this data can be used from within modules, renderers, State SLS files, and more via the shared pillar dictionary:

apache:
  pkg.installed:
    - name: {{ pillar[‘apache‘] }}

git:
  pkg.installed:
    - name: {{ pillar[‘git‘] }}

Finally, the above states can utilize the values provided to them via Pillar. All pillar values targeted to a minion are available via the ‘pillar‘ dictionary. As seen in the above example, Jinja substitution can then be utilized to access the keys and values in the Pillar dictionary.

Note that you cannot just list key/value-information in top.sls. Instead, target a minion to a pillar file and then list the keys and values in the pillar. Here is an example top file that illustrates this point:

base:
  ‘*‘:
     - common_pillar

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

foo: bar
boo: baz

When working with multiple pillar environments, assuming that each pillar environment has its own top file, the jinja placeholder {{ saltenv }} can be used in place of the environment name:

{{ saltenv }}:
  ‘*‘:
     - common_pillar

Yes, this is {{ saltenv }}, and not {{ pillarenv }}. The reason for this is because the Pillar top files are parsed using some of the same code which parses top files when running states, so the pillar environment takes the place of {{ saltenv }} in the jinja context.

dynamic pillar environments New in version 2017.7.5,2018.3.1

If environment __env__ is specified in pillar_roots, all environments that are not explicitly specified in pillar_roots will map to the directories from __env__. This allows one to use dynamic git branch based environments for state/pillar files with the same file-based pillar applying to all environments. For example:

这个功能只能在‘New in version 2017.7.5,2018.3.1‘之后才能使用，我个人觉得很好。

pillar_roots:
  __env__:
    - /srv/pillar

ext_pillar:
  - git:
    - __env__ https://example.com/git-pillar.git

The separate pillar SLS files all merge down into a single dictionary of key-value pairs. When the same key is defined in multiple SLS files, this can result in unexpected behavior if care is not taken to how the pillar SLS files are laid out.

单独的pillar sls文件合并成一个single dictionary of key-value pairs时候，key要保持唯一性，不然会意外情况发生。

比如：Then a request for the bind pillar key will only return named. The bind9 value will be lost, because services.sls was evaluated later.

For example, given a top.sls containing the following:

base:
  ‘*‘:
    - packages
    - services

with packages.sls containing:

bind: bind9

and services.sls containing:

bind: named

 PILLAR DICTIONARY MERGING

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.

如果多个pillar sls文件里有同样的key，并且在这些文件中的key有字典嵌套，那么这些字典文本将会被递归合并。

For example, keeping the top.sls the same, assume the following modifications to the pillar SLS files:

packages.sls:

bind:
  package-name: bind9
  version: 9.9.5

services.sls:

bind:
  port: 53
  listen-on: any

结果会变成:

$ salt-call pillar.get bind
local:
    ----------
    listen-on:
        any
    package-name:
        bind9
    port:
        53
    version:
        9.9.5

INCLUDING OTHER PILLARS New in version 0.16.0

Pillar SLS files may include other pillar files, similar to State files. Two syntaxes are available for this purpose. The simple form simply includes the additional pillar as if it were part of the same file:

include:
  - users

The full include form allows two additional options -- passing default values to the templating engine for the included pillar file as well as an optional key under which to nest the results of the included pillar:

include:
  - users:
      defaults:
          sudo: [‘bob‘, ‘paul‘]
      key: users

salt ‘*‘ saltutil.refresh_pillar