Saltstack自动化 sls文件使用

sunkezai

一、sls文件及环境配置
　　SLS（代表SaLt State文件）是Salt State系统的核心。SLS描述了系统的目标状态，由格式简单的数据构成。这经常被称作配置管理。在使用sls之前，需要先指定环境配置的根目录，不然后面执行的时候会出现找不到文件的提示。环境配置文件为master节点的/etc/salt/master：

• 　　# file_roots:
  
• 　　#   base:
  
• 　　#     - /srv/salt/
  
• 　　#   dev:
  
• 　　#     - /srv/salt/dev/services
  
• 　　#     - /srv/salt/dev/states
  
• 　　#   prod:
  
• 　　#     - /srv/salt/prod/services
  
• 　　#     - /srv/salt/prod/states
  

　　file_roots 配置salt配置的存放目录, 其中base环境是必要的, 指定top.sls存放的位置。默认没指定环境时则从base目录获取文件，其它则是一些自定义的, 可以通过环境变量指定.这样可以逻辑上隔离一些环境配置.每一个环境都可以定义多个目录, 优先级关系由定义目录的顺序决定.如：

• 　　file_roots:
  
• 　　base:
  
• 　　- /srv/salt/foo
  
• 　　- /srv/salt/bar
  

　　如果寻找 salt://file.sls, 如果都存在/srv/salt/foo/file.sls和/srv/salt/bar/file.sls, 则使用第一个找到的.
　　具体也可以参考 States tutorial, part 4 (官方文档)。
　　对于不同的环境，可以通过如下命令进行调用：

• 　　salt "*" state.sls  saltenv='prod' nginx.stock  // 执行prod环境下nginx目录下的stock.sls文件。以可以使用下面的方法调用：
  
• 　　salt-call  state.sls webserver saltenv=dev test=True
  

　　一个简单的sls示例

• 　　# cat /srv/salt/iftop.sls
  
• 　　iotop:
  
• 　　pkg.installed
  

　　这里使用YAML格式进行缩进。可以使用如下命令执行：

• 　　# salt '*' state.sls  iftop  或
  
• 　　# salt '*' state.apply iftop
  

　　两者的执行是相同的：

二、top.sls 文件及sls结构
　　top.sls 是配置管理的入口文件，一切都是从这里开始，在master 主机上，默认存放在/srv/salt/目录. top.sls 默认从 base 标签开始解析执行,下一级是操作的目标，可以通过正则，grain模块,或分组名,来进行匹配,再下一级是要执行的state文件，不包换扩展名。
1、主机匹配
　　创建 /srv/salt/top.sls 文件，可以通过正则、分组名、grain模块几种方式进行主机匹配：

• 　　#通过正则进行匹配
  
• 　　base:
  
• 　　'*':
  
• 　　- webserver
  
• 　　# 通过分组名进行匹配，必须要有 - match: nodegroup
  
• 　　base:
  
• 　　group1:
  
• 　　- match: nodegroup
  
• 　　- webserver
  
• 　　# 通过grain模块匹配，必须要有- match: grain
  
• 　　base:
  
• 　　'os:Fedora':
  
• 　　- match: grain
  
• 　　- webserver
  

、子state文件
　　创建/srv/salt/webserver.sls 文件，上面top中匹配到webserver主机，都将执行webserver.sls 里面的内容，对webserver.sls 中写入如下内容：

• 　　httpd:                 # 标签定义
  
• 　　pkg:                  # state declaration
  
• 　　- installed         # function declaration
  

　　第一行被称为（ID declaration） 标签定义，在这里被定义为安装包的名。注意：在不同发行版软件包命名不同,比如 redhat/centos 中叫httpd的包 Debian/Ubuntu中叫apache2；
　　第二行被称为（state declaration）状态定义， 在这里定义使用（pkg state module）；
　　第三行被称为（function declaration）函数定义， 在这里定义使用（pkg state module）调用 installed 函数。
　　这里使用命令调用top.sls 文件即可，如下：

• 　　salt '*' state.highstate
  
• 　　salt '*' state.highstate top
  
• 　　salt '*' state.highstate -v test=True  //测试执行
  

　　注：这里绝对不能像使用单个sls文件那样，使用state.apply或state.sls加被被执行的top.sls文件名，这里必须使用highstate（高水平的state），不然还像之前一样用，会报错如下：

• 　　Comment: State '*.webserver' was not found in SLS 'top'
  
• 　　Reason: '*.webserver' is not available.
  

三、SLS文件命名空间
　　上例子中,SLS文件 webserver.sls 被简称为webserver. SLS文件命名空间有如下几条基本的规则

• 　　SLS文件的扩展名 .sls 被省略。 (例如. webserver.sls 变成 webserver)；
  
• 　　子目录可以更好的组织,每个子目录都由一个点来表示.(例如 webserver/dev.sls 可以简称为 webserver.dev）；
  
• 　　如果子目录创建一个init.sls的文件，引用的时候仅指定该目录即可. (例如 webserver/init.sls 可以简称为 webserver）；
  
• 　　如果一个目录下同时存在webserver.sls 和 webserver/init.sls，那么 webserver/init.sls 将被忽略，SLS文件引用的webserver将只引用webserver.sls 。
  

四、state多文件及层级关系
1、state多文件示例
　　如下是一个state多文件示例：

• 　　apache/init.sls
  
• 　　apache/httpd.conf
  
• 　　ssh/init.sls
  
• 　　ssh/server.sls
  
• 　　ssh/banner
  
• 　　ssh/ssh_config
  
• 　　ssh/sshd_config
  

　　创建一个引用这些目录的SLS文件：web.sls

• 　　web:
  
• 　　- apache
  
• 　　- ssh
  

2、state的层级关系
　　state的层级关系一般使用两个关键字include 和 extend 。使用include 包含某个state文件；extend 与include配合使用，作用是修改或扩展引用的state文件的某个字段。
　　include示例如下：
　　/srv/salt/apache.sls文件：

• 　　httpd:
  
• 　　pkg:
  
• 　　- installed
  
• 　　service:
  
• 　　- running
  
• 　　- require:
  
• 　　- pkg: httpd
  

　　使用 include 可以包含现有state文件而不必重新写，这个再创建一个/srv/salt/httpd-custom.sls文件：

• 　　include:
  
• 　　- apache
  

　　extend示例如下：
　　创建/srv/salt/apache-change.sls文件：

• 　　include:
  
• 　　- apache
  
• 　　extend：
  
• 　　apache
  
• 　　pkg:
  
• 　　- name: vim
  
• 　　- installed
  

　　当extend与watch，或require结合使用的时候，则是扩展某个字段的属性，比如在ssh/server.sls中定义了一个apache通用的服务器，现在要增加一个带mod_python模块的apache，不需要重头写新的SLS，直接include原来的server.sls，然后增加安装mode_python的state，再在apache service的watch列表中增加mod_python即可。如下python/mod_python.sls ：

• 　　include:
  
• 　　- apache
  
• 　　extend:
  
• 　　apache:
  
• 　　service:
  
• 　　- watch:
  
• 　　- pkg: mod_python
  
• 　　mod_python:
  
• 　　pkg.installed
  

　　也可以在Extending中修改文件的下载位置。ssh/custom-server.sls:

• 　　include:
  
• 　　- ssh.server
  
• 　　extend:
  
• 　　/etc/ssh/banner:
  
• 　　file:
  
• 　　- source: salt://ssh/custom-banner
  

五、state的逻辑关系
1、state的逻辑关系列表

• 　　match: 配模某个模块，比如 match: grain match: nodegroup
  
• 　　require： 依赖某个state，在运行此state前，先运行依赖的state，依赖可以有多个
  
• 　　watch： 在某个state变化时运行此模块
  
• 　　order： 优先级比require和watch低，有order指定的state比没有order指定的优先级高
  

2、state的逻辑关系实例
　　以下require实例中，在进行文件复制之前，需要确认已经执行httpd安装的动作：

• 　　httpd:                                  # maps to "name"
  
• 　　pkg:
  
• 　　- installed
  
• 　　file：                                # maps to State module filename
  
• 　　- managed:                          # maps to the managed function in the file State module
  
• 　　- name: /etc/httpd/conf/httpd.conf  # one of many options passed to the manage function
  
• 　　- source: salt://httpd/httpd.conf
  
• 　　- require:
  
• 　　- pkg: httpd
  

　　watch语句和require很相似，都能保证被监视或需要的state在自己之前执行，但是watch还有其他作用。在被监视的state发生变化时，定义watch语句的state会执行自己的watcher函数。也就是说，更新软件包，修改配置文件，用户的uid发生变化都会触发service state的watcher函数，从而重启服务。示例如下：

• 　　redis:
  
• 　　pkg:
  
• 　　- latest
  
• 　　file.managed:
  
• 　　- source: salt://redis/redis.conf
  
• 　　- name: /etc/redis.conf
  
• 　　- require:
  
• 　　- pkg: redis
  
• 　　service.running:
  
• 　　- enable: True
  
• 　　- watch:
  
• 　　- file: /etc/redis.conf
  
• 　　- pkg: redis
  

　　上面的示例中，一旦配置文件发生变化，或软件包发生变化，都会进行服务重启。
　　order示例如下：

• 　　vim:
  
• 　　pkg.installed:
  
• 　　- order: 1
  

　　想让某个state最后一个运行，可以用last 。
　　本文出自http://www.361way.com/salt-states/5350.html