STORING STATIC DATA IN THE PILLAR
在pillar中存储静态变量
介绍：
pillar作为一个提供全局变量的接口，可以分发给minion，使用类似salt 状态树的方式管理，一般放在master上，可以将敏感数据的使用具体到某些minion上。
在master端声明pillar变量
参照file_roots环境配置，为每一个环境提供一个pillar环境，不可放在state状态树的子目录下，示例：
1 pillar_roots: 2 base: 3 - /srv/pillar 4 5 在pillar中使用top.sls文件 6 base: 7 '*': 8 - packages
base：表示应用于pillar定义的base环境，每一个file_roots对应一个pillar_roots环境。
*：表示匹配minion，可以有多种匹配方式，可以使用grains变量
- packages：表示一个packages的sls文件被调用，以/srv/pillar/packages.sls或/srv/pillar/packages/init.sls的方式存在
对于pilar中top.sls文件的一点理解：
相当于一个必要的pillar变量使用环境的控制信息，可以与saltenv环境相关联，是必要存在的，每一个在file_roots引用了的pillar变量，都必须在对应的pillar_roots环境下的top.sls被完整定义。
一个在top文件中使用grains配置的示例：
1 dev: 2 'os:Debian': 3 - match: grain 4 - packages
#在sls文件中使用模板
1 /srv/pillar/packages.sls 2 {% if grains['os'] == 'RedHat' %} 3 apache: httpd 4 git: git 5 {% elif grains['os'] == 'Debian' %} 6 apache: apache2 7 git: git-core 8 {% endif %}
注意：pillar数据可以在within modules, renderers, State SLS files被使用。
一个在sls中使用pillar变量的示例：
1 git: 2 pkg.installed: 3 - name: {{ pillar['git'] }}
pillar变量定义的两种方式：
（1）直接在sls文件中定义键值对
1 base: 2 '*': 3 - common_pillar 4 5 common_pillar.sls 6 foo: bar 7 boo: baz
（2）使用init.sls的方式
1 common_pillar/init.sls 2 foo: bar 3 boo: baz
在多pillar环境下如果灵活的使用top文件：
1 {{ saltenv }}: 2 '*': 3 - common_pillar
saltenv变量由执行state.sls模块时的saltenv='XX'参数决定。
PILLAR NAMESPACE FLATTENING
示例：
1 base: 2 '*': 3 - packages 4 - services 5 6 packages.sls 7 bind: bind9 8 9 services.sls 10 bind: named
在这种情况下bind的值会取第二个，第一个会被覆盖，所以要避免这种问题，可以使用嵌套字典的形式。
PILLAR DICTIONARY MERGING
pillar字典合并，当多个sls文件定义了相同的键，且定义的键都是一个嵌套字典，pillar将递归的进行合并键里面的内容示例：
1 packages.sls: 2 bind: 3 package-name: bind9 4 version: 9.9.5 5 6 services.sls: 7 bind: 8 port: 53 9 listen-on: any
结果是:
$ salt-call pillar.get bind
1 local: 2 ---------- 3 listen-on: 4 any 5 package-name: 6 bind9 7 port: 8 53 9 version: 10 9.9.5
INCLUDING OTHER PILLARS
pillar中的sls文件可以包含其他pillar sls文件，这个功能可以用于将一些公共的pillar变量抽象出来存放在一个基础的sls文件中，被其他sls文件引用。
示例：
1 include: 2 - users 3 4 include: 5 - users: 6 defaults: 7 sudo: ['bob', 'paul'] 8 key: users
可以提供两个附加的选项，定义用于设置默认值的键值对
IN-MEMORY PILLAR DATA VS. ON-DEMAND PILLAR DATA
由于pillar数据不会总是在master端实时进行编译，所以minion会存一份pillar数据
查看minion端的pillar数据的几种方式
pillar.item
pillar.get
pillar.raw
由于minion中的pillar数据并不是实时更新的，所以有时候需要进行手动刷新，以上的3个命令不会触发数据刷新，手动刷新命令如下：
salt '*' saltutil.refresh_pillar
但是在执行某些命令的时候会触发pillar数据刷新，如下：
Running states #运行state文件
Running pillar.items 执行items命令时
HOW PILLAR ENVIRONMENTS ARE HANDLED
在使用多个pillar环境的时候，默认pillar是将所有环境的数据集合到一起的。
如何限制minion端接受pillar变量的环境，minion端配置：
pillarenv: base
#该选项会忽略除base以外的pillar变量
还有一种方式在执行state模块执行的时候指定pillar环境：
salt '*' state.apply mystates pillarenv=testing
VIEWING PILLAR DATA
有以下几个函数展示pillar数据：
pillar.item
从in-memory中检索一个或多个键值对
pillar.items
会先刷新一遍master端的pillar数据，再同步过来
pillar.raw
类似于上一个，但是不会获取最新的数据
pillar.get
该方法的使用如下示例：
1 foo: 2 bar: 3 baz: qux 4 #一个嵌套的字典结构
模板中是这样引用的：
{{ pillar['foo']['bar']['baz'] }}
pillar.get函数能够更加安全的引用这个pillar变量，且当变量不存在的时候可设置默认值
{{ salt['pillar.get']('foo:bar:baz', 'qux') }}
SETTING PILLAR DATA AT THE COMMAND LINE
在命令行配置pillar变量，意味着pillar不止是可以从pillar环境中取得，示例如下：
salt 'xxx' state.sls XXconfig saltenv='XXX' pillar='{"ip": "spam"}'
释义：手动设置的pillar数据将覆盖从file_roots环境取得的IP变量数据
MASTER CONFIG IN PILLAR
pillar数据一般存储在master端，也可以将这些数据推送到所有minion端，但是这是非常危险的，因为这样几乎把master上的所有配置的数据全部暴露出去了，包含master端的配置文件信息，node分组信息等，默认是禁止的。
pillar_opts: True
MINION CONFIG IN PILLAR
在minion端配置pillar
参考master的pillar配置，譬如配置一个mysq密码
mysql.pass: hardtoguesspassword
MASTER PROVIDED PILLAR ERROR
master端提供pillar数据错误报警，可以设置为关掉
pillar_safe_render_error: False