STATES TUTORIAL, PART 4(第三部分)
Posted 孤独的海浪
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了STATES TUTORIAL, PART 4(第三部分)相关的知识,希望对你有一定的参考价值。
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的变量环境。
以上是关于STATES TUTORIAL, PART 4(第三部分)的主要内容,如果未能解决你的问题,请参考以下文章