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/salt5     - /mnt/salt-nfs/base

注意：

　　当定义的多路径之中存在相同的文件引用路径，则以先匹配到的为准。

############################################################

这里有一个值得挖掘和探讨的东西，FILESERVER_BACKEND选项，这个选项的具体配置说明在介绍master配置文件选项就有所说明，这里结合当前的教程内容进行一下挖掘。

FILESERVER_BACKEND

用于设置文件服务器后端配置的，支持roots(本地环境)，git(git环境)，以及二者结合的方式，文件的查找使用从上到下进行匹配的方式，先到先得。

示例：

1 fileserver_backend:2   - roots3   - 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/qa10     - /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.foobarcom4 qa:5   'web*qa*':6     - webserver.foobarcom7 dev:8   'web*dev*':9     - webserver.foobarcom

/srv/pillar/top.sls:

1 base:2   'web*prod*':3     - webserver.prod4   'web*qa*':5     - webserver.qa6   '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: 64410 {% 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/qa10     - /srv/salt/pillar/prod

可以通过pillarenv=testing的方式指定pillar的变量环境。