一、sls文件及环境配置

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

1. # file_roots:
2. #   base:
3. #     - /srv/salt/
4. #   dev:
5. #     - /srv/salt/dev/services
6. #     - /srv/salt/dev/states
7. #   prod:
8. #     - /srv/salt/prod/services
9. #     - /srv/salt/prod/states

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

  1. file_roots:
  2.  base:
  3.    - /srv/salt/foo
  4.    - /srv/salt/bar

如果寻找 salt://file.sls, 如果都存在/srv/salt/foo/file.sls和/srv/salt/bar/file.sls, 则使用第一个找到的.

具体也可以参考 States tutorial, part 4 (官方文档)。

对于不同的环境,可以通过如下命令进行调用:

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

一个简单的sls示例

  1. # cat /srv/salt/iftop.sls
  2. iotop:
  3.  pkg.installed

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

  1. # salt '*' state.sls  iftop  或
  2. # salt '*' state.apply iftop

两者的执行是相同的:

二、top.sls 文件及sls结构

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

1、主机匹配

创建 /srv/salt/top.sls 文件,可以通过正则、分组名、grain模块几种方式进行主机匹配:

1. #通过正则进行匹配
2. base:
3.   '*':
4.     - webserver
5. # 通过分组名进行匹配,必须要有 - match: nodegroup
6. base:
7.   group1:
8.     - match: nodegroup
9.     - webserver
10. # 通过grain模块匹配,必须要有- match: grain
11. base:
12.   'os:Fedora':
13.     - match: grain
14.     - webserver
、子state文件

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

  1. httpd:                 # 标签定义
  2.  pkg:                  # state declaration
  3.    - installed         # function declaration

第一行被称为(ID declaration) 标签定义,在这里被定义为安装包的名。注意:在不同发行版软件包命名不同,比如 redhat/centos 中叫httpd的包 Debian/Ubuntu中叫apache2;

第二行被称为(state declaration)状态定义, 在这里定义使用(pkg state module);

第三行被称为(function declaration)函数定义, 在这里定义使用(pkg state module)调用 installed 函数。

这里使用命令调用top.sls 文件即可,如下:

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

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

  1. Comment: State '*.webserver' was not found in SLS 'top'
  2.         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多文件示例:

1. apache/init.sls
2. apache/httpd.conf
3. ssh/init.sls
4. ssh/server.sls
5. ssh/banner
6. ssh/ssh_config
7. ssh/sshd_config

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

  1. web:
  2.  - apache
  3.  - ssh
2、state的层级关系

state的层级关系一般使用两个关键字include 和 extend 。使用include 包含某个state文件;extend 与include配合使用,作用是修改或扩展引用的state文件的某个字段。

include示例如下:

/srv/salt/apache.sls文件:

1. httpd:
2.   pkg:
3.     - installed
4.   service:
5.     - running
6.     - require:
7.       - pkg: httpd

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

  1. include:
  2.  - apache

extend示例如下:

创建/srv/salt/apache-change.sls文件:

1. include:
2.   - apache
3. extend:
4.   apache
5.     pkg:
6.       - name: vim
7.       - 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 :

1. include:
2.    - apache
3.  extend:
4.    apache:
5.      service:
6.        - watch:
7.          - pkg: mod_python
8.  mod_python:
9.    pkg.installed

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

1. include:
2.    - ssh.server
3.  extend:
4.    /etc/ssh/banner:
5.      file:
6.        - source: salt://ssh/custom-banner

五、state的逻辑关系

1、state的逻辑关系列表
  1. match: 配模某个模块,比如 match: grain match: nodegroup
  2. require: 依赖某个state,在运行此state前,先运行依赖的state,依赖可以有多个
  3. watch: 在某个state变化时运行此模块
  4. order: 优先级比require和watch低,有order指定的state比没有order指定的优先级高
2、state的逻辑关系实例

以下require实例中,在进行文件复制之前,需要确认已经执行httpd安装的动作:

1. httpd:                                  # maps to "name"
2.   pkg:
3.     - installed
4.   file:                                # maps to State module filename
5.     - managed:                          # maps to the managed function in the file State module
6.     - name: /etc/httpd/conf/httpd.conf  # one of many options passed to the manage function
7.     - source: salt://httpd/httpd.conf
8.     - require:
9.       - pkg: httpd

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

1. redis:
2.   pkg:
3.     - latest
4.   file.managed:
5.     - source: salt://redis/redis.conf
6.     - name: /etc/redis.conf
7.     - require:
8.       - pkg: redis
9.   service.running:
10.     - enable: True
11.     - watch:
12.       - file: /etc/redis.conf
13.       - pkg: redis

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

order示例如下:

  1. vim:
  2.  pkg.installed:
  3.    - order: 1

想让某个state最后一个运行,可以用last 。