STATES TUTORIAL, PART 4(第三部分)
使用file_roots配置state文件环境
SALT FILESERVER PATH INHERITANCE
salt文件服务器路径解密
示例：
1 # In the master config file (/etc/salt/master) 2 file_roots: 3 base: 4 - /srv/salt 5 - /mnt/salt-nfs/base
注意：
当定义的多路径之中存在相同的文件引用路径，则以先匹配到的为准。
############################################################
这里有一个值得挖掘和探讨的东西，FILESERVER_BACKEND选项，这个选项的具体配置说明在介绍master配置文件选项就有所说明，这里结合当前的教程内容进行一下挖掘。
FILESERVER_BACKEND
用于设置文件服务器后端配置的，支持roots(本地环境)，git(git环境)，以及二者结合的方式，文件的查找使用从上到下进行匹配的方式，先到先得。
示例：
1 fileserver_backend: 2 - roots 3 - git
############################################################
ENVIRONMENT CONFIGURATION
配置一个多环境，下例就是一个类似开发测试线上的例子，利用文件查找机制，将处于开发的环境放置在dev目录。
示例：
1 file_roots: 2 base: 3 - /srv/salt/prod 4 qa: 5 - /srv/salt/qa 6 - /srv/salt/prod 7 dev: 8 - /srv/salt/dev 9 - /srv/salt/qa 10 - /srv/salt/prod
REQUESTING FILES FROM SPECIFIC FILESERVER ENVIRONMENTS
从指定的文件服务器环境获取文件
具体的使用方法参考前面的文件服务器章节的讲解：
https://docs.saltstack.com/en/2016.11/ref/file_server/environments.html#file-server-environments
PRACTICAL EXAMPLE
示例：
/srv/salt/prod/top.sls:
1 base: 2 ‘web*prod*‘: 3 - webserver.foobarcom 4 qa: 5 ‘web*qa*‘: 6 - webserver.foobarcom 7 dev: 8 ‘web*dev*‘: 9 - webserver.foobarcom
/srv/pillar/top.sls:
1 base: 2 ‘web*prod*‘: 3 - webserver.prod 4 ‘web*qa*‘: 5 - webserver.qa 6 ‘web*dev*‘: 7 - webserver.dev
/srv/pillar/webserver/prod.sls:
1 webserver_role: prod
/srv/pillar/webserver/qa.sls:
1 webserver_role: qa
/srv/pillar/webserver/dev.sls:
1 webserver_role: dev
/srv/salt/prod/webserver/foobarcom.sls:
1 {% if pillar.get(‘webserver_role‘, ‘‘) %}
2 /var/www/foobarcom:
3 file.recurse:
4 - source: salt://webserver/src/foobarcom
5 - env: {{ pillar[‘webserver_role‘] }}
6 - user: www
7 - group: www
8 - dir_mode: 755
9 - file_mode: 644
10 {% endif %}
以上示例包含一下几个重要的内容：
（1）sls文件环境的配置问题，将开发，测试，上线三个环境利用file_roots进行配置，不同的环境关联的目录结构不同。
（2）具体环境中对minion角色的匹配问题，这里得结合grains和minion id做适当的匹配。
（3）pillar环境与state环境的关联以及与minion的关联问题，控制pillar变量在环境中的使用范围问题。
（4）sls文件分布问题，当一个sls文件需要经历开发环境，测试环境，线上环境的时候，sls文件最先应放置在相当于示例的/srv/salt/dev/webserver/src/foobarcom位置，
这个位置只有处于dev环境中的minion能被匹配到。
使用指定的pillar变量环境部署一个top环境，相当于执行一个highstate：
salt --pillar ‘webserver_role:dev‘ state.apply
如果只是仅仅的想只部署这一个环境的换，需要指定state.apply的参数sls文件
salt --pillar ‘webserver_role:dev‘ state.apply webserver.foobarcom
当完成开发阶段，需要进入测试环境的时候，需要将sls文件移动到qa目录下，指定以下命令：
salt --pillar ‘webserver_role:qa‘ state.apply webserver.foobarcom
如果已经完成测试需要部署到正式环境中的话，可以使用以下命令：
salt --pillar ‘webserver_role:prod‘ state.apply webserver.foobarcom
注意：
当你把文件移动到base中的prod目录中，属于正式环境的一部分，但是在qa和dev环境中仍然是可用的，这是由于salt使用了继承的功能，在开发环境中，base目录环境也在dev环境的搜索范围里面，这是面向对象的一个特点。
CONTINUE LEARNING
接下来你可以学习关于state的系统性详细介绍
思考：
（1）部署的时候需要指定类似--pillar ‘webserver_role:prod‘这样的变量指定，为什么？
因为在sls文件中有一个pillar[‘webserver_role‘]获取变量的内容，且使用了env参数，譬如你设置为dev环境的时候，pillar需要为sls提供在dev环境中指定的变量内容，这段内容实际上就是将sls文件与pillar变量环境连接起来。
（2）如果不指定上一个问题中pillar的变量环境，我们可以怎么做实现相同的目的呢？
在上面的例子送，执行前指定pillar环境显得不那么友好，所以建议在pillar设置与file_roots类似的配置结构，虽然看起来配置相对冗杂，但是结构关联关系会比较严谨，不易出现误操作的情况。
示例：
1 pillar_roots: 2 base: 3 - /srv/salt/pillar/prod 4 qa: 5 - /srv/salt/pillar/qa 6 - /srv/salt/pillar/prod 7 dev: 8 - /srv/salt/pillar/dev 9 - /srv/salt/pillar/qa 10 - /srv/salt/pillar/prod
可以通过pillarenv=testing的方式指定pillar的变量环境。