pillar是Saltstack最重要的组件之一，其作用是在Master本地定义与被控主机相关的任何数据，定义好的数据可以用于在其他组件中使用，如模板、state、API等。
pillar安全性很高，适用于一些比较敏感的数据，这也是区别于grains最关键的一点，如定义不同业务组主机的用户id、组id、读写权限、程序包等信息，定义的规范是采用Python字典形式，即键/值，最上层的键一般为主机的id或组的名称。
以下为在Master配置文件中，与pillar相关的配置选项的使用说明。相同内容也可以选择参考官网英文原文，或者github翻译类项目中的中文译文。
PILLAR CONFIGURATION
PILLAR_ROOTS
Default:
base:
- /srv/pillar
设置用于保存pillar sls数据的环境和目录。 此配置与file_roots使用方法相同：
pillar_roots:
base:
- /srv/pillar
dev:
- /srv/pillar/dev
prod:
- /srv/pillar/prod
ON_DEMAND_EXT_PILLAR
New in version 2016.3.6,2016.11.3,2017.7.0.
Default: [‘libvirt’, ‘virtkey’]
允许使用pillar.ext获取外部pillar数据。
on_demand_ext_pillar:
- libvirt
- virtkey
- git
Warning:
这将允许minions通过pillar.ext请求特定的pillar数据，这可能被视为一种安全风险。 但是，以这种方式生成的pillar数据不会影响内存中的pillar数据，因此这种风险仅限于states/modules等的情况。
DECRYPT_PILLAR
New in version 2017.7.0.
Default: []
在pillar数据编译期间需要进行递归解密的路径列表。
decrypt_pillar:
- 'foo:bar': gpg
- 'lorem:ipsum:dolor'
此列表中的条目可以格式化为简单字符串，也可以格式化为键/值对，其中键是pillar位置，值是用于pillar解密的渲染器。 如果使用前者，则将使用decrypt_pillar_default选项所指定的渲染器。
DECRYPT_PILLAR_DELIMITER
New in version 2017.7.0.
Default: :
分隔符,用于区分decrypt_pillar选项中的嵌套数据结构。
decrypt_pillar_delimiter: '|'
decrypt_pillar:
- 'foo|bar': gpg
- 'lorem|ipsum|dolor'
DECRYPT_PILLAR_DEFAULT
New in version 2017.7.0.
Default: gpg
如果没有为decrypt_pillar中的给定pillar key指定一个，则使用默认渲染器用于解密。
decrypt_pillar_default: my_custom_renderer
DECRYPT_PILLAR_RENDERERS
New in version 2017.7.0.
Default: [‘gpg’]
允许用于支柱解密的渲染器列表。
decrypt_pillar_renderers:
- gpg
- my_custom_renderer
PILLAR_OPTS
Default: False
pillar_opts选项会将master的配置文件数据添加到名为master的pillar dict中。 这可以用于在master配置文件中设置简单配置，然后可以在所有minions上使用。
请注意，将此选项设置为True后意味着master配置文件将会被包含在所有minion的pillar中。 虽然这使得服务和系统的全局配置变得容易，但是如果敏感数据存储在master配置中，则可能不希望这样。
pillar_opts: False
PILLAR_SAFE_RENDER_ERROR
Default: True
pillar_safe_render_error选项可防止master将pillar渲染过程中的错误传递给minion。 这是默认设置为True的，因为错误k中可能包含模板数据，这将会给minion提供它不应该具有的信息，如密码！ 设置为True时，错误消息仅显示：
`Rendering SLS ‘my.sls’ failed. Please see master log for details.``
pillar_safe_render_error: True
EXT_PILLAR
ext_pillar选项允许在填充pillar数据时调用任意数量的外部pillar接口。 该配置是基于ext_pillar函数工作的。 可以在此处找到有哪些可用的ext_pillar函数：
https://github.com/saltstack/salt/blob/develop/salt/pillar
默认地, ext_pillar interface is not configured to run.
Default: []
ext_pillar:
- hiera: /etc/hiera.yaml
- cmd_yaml: cat /etc/salt/yaml
- reclass:
inventory_base_uri: /etc/reclass
EXT_PILLAR_FIRST
New in version 2015.5.0.
Default: False
此选项允许在pillar_roots之前先评估外部pillar源。 外部pillar数据与pillar_roots下的数据分开评估，然后两组pillar数据合并为一个pillar字典，因此该配置选项的值将影响哪个关键字会“获胜”，当在外部pillar数据和pillar_roots下数据中都存在相同的名称。 通过将此选项设置为True，ext_pillar键将覆盖pillar_roots，而将其保留为False则效果相反。
ext_pillar_first: False
PILLARENV_FROM_SALTENV
Default: False
设置为True时，pillarenv值将在运行状态时继承自saltenv的值。 这基本上使salt-run pillar.show_pillar saltenv=dev相当于salt-run pillar.show_pillar saltenv=dev pillarenv=dev。 不过如果在CLI上设置了pillarenv，它将覆盖此选项。
pillarenv_from_saltenv: True
注意 对于使用salt远程执行命令时，则应该在Minion配置中设置此选项。
PILLAR_RAISE_ON_MISSING
New in version 2015.5.0.
Default: False
将此选项设置为True可以在尝试从pillar中检索一个指定名称的值失败时强制引发KeyError。 如果将此选项设置为False，则失败的尝试将返回空字符串。
GIT EXTERNAL PILLAR (GIT_PILLAR) CONFIGURATION OPTIONS
GIT_PILLAR_PROVIDER
New in version 2015.8.0.
Default: master
指定要用于git_pillar的提供程序。 必须是pygit2或gitpython。 如果未设置，则将以相同的顺序尝试两者，并且安装了兼容版本的第一个将是使用的提供程序。
git_pillar_provider: gitpython
GIT_PILLAR_BASE
New in version 2015.8.0.
Default: master
如果所需的分支与此值匹配，并且git_pillar配置中省略了环境，则该git_pillar远程的环境将是base。 例如，在下面的配置中，foo分支/标记将分配给base环境，而bar将映射到bar环境。
git_pillar_base: foo
ext_pillar:
- git:
- foo https://mygitserver/git-pillar.git
- bar https://mygitserver/git-pillar.git
GIT_PILLAR_BRANCH
New in version 2015.8.0.
Default: master
如果从git_pillar remote中省略了分支，则将使用这里指定的分支。 例如，在下面的配置中，前两个remotes将使用pillardata分支/标签，而第三个将使用foo分支/标签。
git_pillar_branch: pillardata
ext_pillar:
- git:
- https://mygitserver/pillar1.git
- https://mygitserver/pillar2.git:
- root: pillar
- foo https://mygitserver/pillar3.git
GIT_PILLAR_ENV
New in version 2015.8.0.
Default: ‘’ (unset)
用于git_pillar remote的环境。 这通常来自分支/标记（或来自每个remote的env参数），但如果设置了该选项，这将覆盖从分支/标记名称派生env的过程。 例如，在下面的配置中，foo分支将被分配给base环境，而bar分支需要明确地将bar配置为其环境，以防止它也被映射到base环境。
git_pillar_env: base
ext_pillar:
- git:
- foo https://mygitserver/git-pillar.git
- bar https://mygitserver/git-pillar.git:
- env: bar
出于这个原因，建议不要设置此选项，除非用例要求所有（或几乎所有）git_pillar remotes控制器使用相同的环境，而不管使用的分支/标记。
GIT_PILLAR_ROOT
New in version 2015.8.0.
Default: ‘’
相对于git_pillar top文件和SLS文件所在的存储库根目录的路径。 在下面的配置中，将在名为pillar的子目录中查找pillar top文件和SLS文件。
git_pillar_root: pillar
ext_pillar:
- git:
- master https://mygitserver/pillar1.git
- master https://mygitserver/pillar2.git
这是一个全局选项。 如果只有一个或两个repos需要从子目录中获取文件，那么可以省略git_pillar_root，并且可以在每个remote的基础上指定root，如下所示：
ext_pillar:
- git:
- master https://mygitserver/pillar1.git
- master https://mygitserver/pillar2.git:
- root: pillar
在此示例中，对于第一个remote文件，将在存储库的根目录中查找top文件和SLS文件，而在第二个remote文件中，将从pillar子目录中检索pillar数据。
GIT_PILLAR_SSL_VERIFY
New in version 2015.8.0.
Changed in version 2016.11.0.
Default: False
指定在联系远程存储库时是否忽略SSL证书错误。 如果您使用的是使用自签名证书的git仓库，则False设置非常有用。 但是，请记住，将此设置为True以外的其他任何值是一种被认为不安全的操作，与之相比使用基于SSH的传输（如果可用）可能是更好的选择。
在2016.11.0版本中，默认配置值从False更改为True。
pygit2仅支持在版本0.23.2及更高版本中禁用SSL验证。
GIT_PILLAR_GLOBAL_LOCK
New in version 2015.8.9.
Default: True
设置为False时，如果git_pillar远程数据库存在update/checkout锁定且写入的pid未在master服务器上运行，则锁定文件将自动清除并获取新锁定。 设置为True时，Salt会在存在锁定时记录警告。
在单master部署中，禁用此选项可以帮助自动处理在git_pillarupdate/checkout期间关闭/重新启动master服务器的实例，并保留锁定。
但是，在通过GlusterFS，nfs或其他网络文件系统共享git_pillar cachedir的多master部署中，强烈建议不要禁用此选项，因为这样做会导致锁定文件是由其他master创建时被删除。
# Disable global lock
git_pillar_global_lock: False
GIT_PILLAR_INCLUDES
New in version 2017.7.0.
Default: True
通常，在处理git_pillar remotes数据库时，如果ext_pillar配置中同一git部分下的多个repo引用相同的pillar环境，则给定环境中的每个repo都可以访问其top file引用的其他repos文件。文件。 但是可能需要禁用此行为。 如果是这样，请将此值设置为False。
有关如何包含工作的更详细的检查，请参阅git_pillar文档中的此解释。
git_pillar_includes: False
GIT EXTERNAL PILLAR AUTHENTICATION OPTIONS
这些参数目前仅适用于pygit2 git_pillar_provider。 如GitFS Walkthrough中所述，身份验证与gitfs中的身份验证相同，但全局配置选项的命名方式不同，以反映它们用于git_pillar而不是gitfs。
GIT_PILLAR_USER
New in version 2015.8.0.
Default: ‘’
与git_pillar_password一起，用于对HTTPS remotes进行身份验证。
git_pillar_user: git
GIT_PILLAR_PASSWORD
New in version 2015.8.0.
Default: ‘’
与git_pillar_user一起，用于对HTTPS remotes进行身份验证。 如果存储库不使用身份验证，则不需要此参数。
git_pillar_password: mypassword
GIT_PILLAR_INSECURE_AUTH
New in version 2015.8.0.
Default: False
默认情况下，Salt不会对HTTP（非HTTPS）远程进行身份验证。 此参数启用HTTP身份验证的支持。 启用此功能需要你自担风险。
git_pillar_insecure_auth: True
GIT_PILLAR_PUBKEY
New in version 2015.8.0.
Default: ‘’
与git_pillar_privkey（以及可选的git_pillar_passphrase）一起，用于对SSH remotes进行身份验证。
git_pillar_pubkey: /path/to/key.pub
GIT_PILLAR_PRIVKEY
New in version 2015.8.0.
Default: ‘’
与git_pillar_pubkey（以及可选的git_pillar_passphrase）一起，用于对SSH remotes进行身份验证。
git_pillar_privkey: /path/to/key
GIT_PILLAR_PASSPHRASE
New in version 2015.8.0.
Default: ‘’
此参数是可选的，仅在用于身份验证的SSH密钥受密码保护时才需要。
git_pillar_passphrase: mypassphrase
GIT_PILLAR_REFSPECS
New in version 2017.7.0.
Default: [’+refs/heads/:refs/remotes/origin/’, ‘+refs/tags/:refs/tags/’]
从远程存储库获取时，默认情况下Salt将获取分支和标记。 此参数可用于覆盖默认值并指定要提取的替代refspec。 此参数与其GitFS对应项的工作方式类似，既可以全局配置，也可以为单个remote进行配置。
git_pillar_refspecs:
- '+refs/heads/*:refs/remotes/origin/*'
- '+refs/tags/*:refs/tags/*'
- '+refs/pull/*/head:refs/remotes/origin/pr/*'
- '+refs/pull/*/merge:refs/remotes/origin/merge/*'
GIT_PILLAR_VERIFY_CONFIG
New in version 2017.7.0.
Default: True
默认情况下，当master服务器启动时，它会对配置的git_pillar存储库执行一些健康性检查。 如果任何这些健康性检查失败（例如使用无效配置时），则master守护程序也将中止。
要跳过这些健康性检查，请将此选项设置为False。
git_pillar_verify_config: False
PILLAR MERGING OPTIONS
PILLAR_SOURCE_MERGING_STRATEGY
New in version 2014.7.0.
Default: smart
pillar_source_merging_strategy选项允许您配置不同源之间的合并策略。 它接受5个值：
- none: 它根本不会执行任何合并，只解析传递环境中的pillar数据，如果没有指定环境，则解析“base”环境。New in version 2016.3.4.
- recurse: 它将以递归方式合并数据。 例如，下面两个来源：
foo: 42
bar:
element1: True
bar:
element2: True
baz: quux
将会被合并为:
foo: 42
bar:
element1: True
element2: True
baz: quux
- aggregate:
指示使用＃!yamlex渲染器的源之间进行元素的聚合。
例如，下面两个配置：
#!yamlex
foo: 42
bar: !aggregate {
element1: True
}
baz: !aggregate quux
#!yamlex
bar: !aggregate {
element2: True
}
baz: !aggregate quux2
将会被聚合为:
foo: 42
bar:
element1: True
element2: True
baz:
- quux
- quux2
- overwrite:将使用2014.1分支及更早版本的行为。根据元素的处理顺序覆盖元素。
例如，第一个处理的pillar数据：
A:
first_key: blah
second_key: blah
第二个处理的pillar数据：
A:
third_key: blah
fourth_key: blah
将会被合并为：
A:
third_key: blah
fourth_key: blah
- smart (default):根据“渲染器”的设置猜测最佳策略。
为了使基于yamlex的功能（如！aggregate）在使用默认智能合并策略的文档中按预期工作，必须将渲染器配置选项设置为jinja | yamlex或类似。
PILLAR_MERGE_LISTS
New in version 2015.8.0.
Default: False
递归合并列表,通过聚合方式而不是替换它们。
pillar_merge_lists: False
PILLAR_INCLUDES_OVERRIDE_SLS
New in version 2017.7.6,2018.3.1.
Default: False
在2017.7.3版之前，来自pillar includes的键将合并在顶部的pillar SLS。 自2017.7.3起，includes的先被合并在一起，然后pillar SLS合并在其上。
将此选项设置为True可返回旧版本时的行为。
pillar_includes_override_sls: True
PILLAR CACHE OPTIONS
PILLAR_CACHE
New in version 2015.8.8.
Default: False
Master服务器可以在本地缓存pillars，以避免在每个请求上为每个minion呈现它们时花费渲染处理成本。 只有在已知pillar渲染时间不令人满意的情况下才能启用此功能，并且已解决了有关在master缓存中存储pillars的任何附带安全问题。
启用此功能时，请务必通读其他pillar_cache_*配置选项，以完全了解可调参数及其含义。
pillar_cache: False
设置为pillar_cache: True时并不会对使用targeting minions with pillar有影响。
PILLAR_CACHE_TTL
New in version 2015.8.8.
Default: 3600
当且仅当master服务器设置了pillar_cache：True时，缓存TTL选项会控制master服务器将缓存视为无效（时间量，以秒为单位），并重新编译和存储新的pillars。
PILLAR_CACHE_BACKEND
New in version 2015.8.8.
Default: disk
当且仅当master设备设置了pillar_cache：True选项时，可以选用以下几种存储选项之一：
- disk (default):
默认存储后端。 这会将渲染的pillars数据缓存到master缓存。 渲染的pillars被序列化并反序列化为msgpack结构以提高处理速度。 请注意，pillar存储为UNENCRYPTED方式。 请确保master缓存具有适当的权限设置（提供了合理的默认值）。 - memory [EXPERIMENTAL]:
pillar缓存的一个可选后端，它使用纯Python内存数据结构以获得最佳性能。 然而，有几点需要注意。 首先，因为每个master工作进程都包含自己的内存缓存，所以不保证minion请求之间的缓存一致性。 这种情况在pillar很少发生变化的情况下效果最好。 其次，也许更重要的是，这意味着任何可以检查sat-master的进程都可以访问未加密的pillars！ 这可能代表存在潜在的安全风险。
pillar_cache_backend: disk