REQUISITES AND OTHER GLOBAL STATE ARGUMENTS(state文件require及其他全局变量)

require用于建立states之间的关系，这种依赖关系以<state name> : <ID or name>的形式来定义
Requisites有两种形式，require和require_in，分别表示依赖和被依赖的关系
示例：

1 vim:
2   pkg.installed: []
3 
4 /etc/vimrc:
5   file.managed:
6     - source: salt://edit/vimrc
7     - require:
8       - pkg: vim

View Code

示例2：

1 vim:
2   pkg.installed:
3     - require_in:
4       - file: /etc/vimrc
5 
6 /etc/vimrc:
7   file.managed:
8     - source: salt://edit/vimrc

View Code

REQUISITE MATCHING

require需要两条信息进行匹配，一个是state模块名，一个是name或ID参数

OMITTING STATE MODULE IN REQUISITES

在2016.3.0的版本中，salt模块名是可选的，如果省略掉模块名的话，所有匹配到的id都会被依赖，而不管是哪一个state模块

1 - require:
2   - vim

View Code

STATE TARGET MATCHING

state标记匹配
示例：

 1 Deploy server package:
 2   file.managed:
 3     - name: /usr/local/share/myapp.tar.xz
 4     - source: salt://myapp.tar.xz
 5 
 6 Extract server package:
 7   archive.extracted:
 8     - name: /usr/local/share/myapp
 9     - source: /usr/local/share/myapp.tar.xz
10     - archive_format: tar
11     - onchanges:
12       - file: Deploy server package

View Code

Deploy server package拷贝tar包文件，Extract server package解压文件，二者通过onchanges状态声明建立依赖关系

IDENTIFIER MATCHING

识别匹配，上面的例子定义的依赖可以适用Deploy server package(ID)，也可以使用/usr/local/share/myapp.tar.xz(name)
示例：

 1 # (Archive arguments omitted for simplicity)
 2 
 3 # Match by ID declaration
 4 Extract server package:
 5   archive.extracted:
 6     - onchanges:
 7       - file: Deploy server package
 8 
 9 # Match by name parameter
10 Extract server package:
11   archive.extracted:
12     - onchanges:
13       - file: /usr/local/share/myapp.tar.xz

View Code

DIRECT REQUISITE AND REQUISITE_IN TYPES

在salt中使用的requisite建立依赖的变量由如下几种：

require
watch
prereq
use
onchanges
onfail

同时也存在相应的requisite_in

require_in
watch_in
prereq_in
use_in
onchanges_in
onfail_in

REQUIRE

指定的依赖state执行成功之后，包含该require的state将执行下去，如果require指定的依赖state执行失败则不予执行

REQUIRE AN ENTIRE SLS FILE

在require中定义sls文件，这是构建复杂大型的sls组的好帮手

1 include:
2   - foo
3 
4 bar:
5   pkg.installed:
6     - require:
7       - sls: foo

View Code

当指定一个sls文件依赖的之后，这个sls文件都被定义为require的依赖项

WATCH

用于当其他state发生变化的时候添加附加行为，新的onchanges应该替代watch，当在在state里面包含watch指令的时候，当被watch的state执行的时候会返回一个字典，包含一个changes的键名，如下所示：

 1 {
 2     "local": {
 3         "file_|-/tmp/foo_|-/tmp/foo_|-directory": {
 4             "comment": "Directory /tmp/foo updated",
 5             "__run_num__": 0,
 6             "changes": {
 7                 "user": "bar"
 8             },
 9             "name": "/tmp/foo",
10             "result": true
11         }
12     }
13 }
14 
15 {
16     "local": {
17         "pkgrepo_|-salt-minion_|-salt-minion_|-managed": {
18             "comment": "Package repo 'salt-minion' already configured",
19             "__run_num__": 0,
20             "changes": {},
21             "name": "salt-minion",
22             "result": true
23         }
24     }
25 }

View Code

上例中包含两个要点内容result和changes，如果result为True，那么包含该watch的state的模块将被正常执行，这部分的功能是镜像require的功能。

如果result值为True，且changes键的内容非空，那么watch将为state带来额外的动作，这个额外的动作是由mod_watch函数返回的，前提是这个salt模块必须包含有这个mod_watch函数.
如果changes的值为空的话，watch将和require的功能逻辑差不多。
示例：

1 ntpd:
2   service.running:
3     - watch:
4       - file: /etc/ntp.conf
5   file.managed:
6     - name: /etc/ntp.conf
7     - source: salt://ntp/files/ntp.conf

View Code

PREREQ

prereq可以为state模块设置一个预动作，利用test=True先测试运行一下state的结果状态，如果changes非空，则在在state状态执行之前先执行包含prereq的state模块
示例：

 1 graceful-down:
 2   cmd.run:
 3     - name: service apache graceful
 4     - prereq:
 5       - file: site-code
 6 
 7 site-code:
 8   file.recurse:
 9     - name: /opt/site_code
10     - source: salt://site/code

View Code

示例定义了在配置文件发生变动之前，先将服务下线或检测配置文件或代码的状态。

ONFAIL

onfail应用于当某个state执行失败了就执行这个state，类似于取反的意思，其使用方式和require或watch一样

示例：

 1 primary_mount:
 2   mount.mounted:
 3     - name: /mnt/share
 4     - device: 10.0.0.45:/share
 5     - fstype: nfs
 6 
 7 backup_mount:
 8   mount.mounted:
 9     - name: /mnt/share
10     - device: 192.168.40.34:/share
11     - fstype: nfs
12     - onfail:
13       - mount: primary_mount

View Code

ONCHANGES

onchanges应用于依赖的state运行后出现变更的，且result需要为True
以下配置是错误的示例：

 1 myservice:
 2   pkg.installed:
 3     - name: myservice
 4   file.managed:
 5     - name: /etc/myservice/myservice.conf
 6     - source: salt://myservice/files/myservice.conf
 7     - mode: 600
 8   cmd.run:
 9     - name: /usr/libexec/myservice/post-changes-hook.sh
10     - onchanges_in:
11       - file: /etc/myservice/myservice.conf

View Code

注意onchange和onchange_in的使用区别，onchangs用于检测指定的state执行是否出现变化，而onchange_in则用于检测自身是否执行产生变化，二者定义的依赖执行关系顺序是相反的
正确的实例：

 1 myservice:
 2   pkg.installed:
 3     - name: myservice
 4   file.managed:
 5     - name: /etc/myservice/myservice.conf
 6     - source: salt://myservice/files/myservice.conf
 7     - mode: 600
 8   cmd.run:
 9     - name: /usr/libexec/myservice/post-changes-hook.sh
10     - onchanges:
11       - file: /etc/myservice/myservice.conf

View Code

USE

在state中继承其他state中定义的参数，就像继承模板一样那么方便和简洁，避免冗余的state声明内容

 1 /etc/foo.conf:
 2   file.managed:
 3     - source: salt://foo.conf
 4     - template: jinja
 5     - mkdirs: True
 6     - user: apache
 7     - group: apache
 8     - mode: 755
 9 
10 /etc/bar.conf
11   file.managed:
12     - source: salt://bar.conf
13     - use:
14       - file: /etc/foo.conf

View Code

use本是用于网络开发方面的states编写，但是目前在salt里面其他地方也是可以正常使用。
注意：use不会继承其他state中的必备参数，譬如source参数。

THE _IN VERSIONS OF REQUISITES

每个requisites都会有相应的_in版本，其使用方式恰好相反
示例：

Using require

 1 httpd:
 2   pkg.installed: []
 3   service.running:
 4     - require:
 5       - pkg: httpd
 6       
 7 Using require_in
 8 
 9 httpd:
10   pkg.installed:
11     - require_in:
12       - service: httpd
13   service.running: []

View Code

require被用于执行之前进行state评估是否有附件条件需要先执行，require_in被用于执行的时候评估是否在在本次执行中后紧接着执行的state条件，require_in被用于在一个单独的sls中指定其中一个states时很有用处
示例：

 1 http.sls
 2 
 3 httpd:
 4   pkg.installed: []
 5   service.running:
 6     - require:
 7       - pkg: httpd
 8 
 9 php.sls
10 
11 include:
12   - http
13 
14 php:
15   pkg.installed:
16     - require_in:
17       - service: httpd
18 
19 mod_python.sls
20 
21 include:
22   - http
23 
24 mod_python:
25   pkg.installed:
26     - require_in:
27       - service: httpd

View Code

以上示例存在3个独立的sls文件，mod_python和php要求在httpd服务启动之前成功执行，

FIRE EVENT NOTIFICATIONS

使用fire_event选项可以进minion端的执行状态发送给master端一个事件信息
参考链接：https://github.com/saltstack/salt/issues/34255

1 nano_stuff:
2   pkg.installed:
3     - name: nano
4     - fire_event: custom/tag/nano/finished

View Code

ALTERING STATES

state变化系统用于确保state按照用户期望的方式进行

RELOAD

是一个布尔选项，强迫在一个state状态执行完成之后去重载某个模块，可以设置reload_pillar和reload_grains

UNLESS

如果设置的条件返回False则继续执行state，如果设置多个条件则任意一个返回False即可
示例：

1 deploy_app:
2   cmd.run:
3     - names:
4       - first_deploy_cmd
5       - second_deploy_cmd
6     - unless: ls /usr/bin/vim

View Code

ONLYIF

指定条件中每一个命令都必须返回True，否则不执行state,这里的True和False是shell中的概念。
示例：

 1 stop-volume:
 2   module.run:
 3     - name: glusterfs.stop_volume
 4     - m_name: work
 5     - onlyif:
 6       - gluster volume status work
 7     - order: 1
 8 
 9 remove-volume:
10   module.run:
11     - name: glusterfs.delete
12     - m_name: work
13     - onlyif:
14       - gluster volume info work
15     - watch:
16       - cmd: stop-volume

View Code

LISTEN/LISTEN_IN

类似于watch_in,但是listen不会修改state的执行顺序，只是在所有state执行完成之后，再评估执行的状态并确认是否执行
示例：

 1 restart-apache2:
 2   service.running:
 3     - name: apache2
 4     - listen:
 5       - file: /etc/apache2/apache2.conf
 6 
 7 configure-apache2:
 8   file.managed:
 9     - name: /etc/apache2/apache2.conf
10     - source: salt://apache2/apache2.conf

View Code

CHECK_CMD

可以设置检查state执行的结果是否成功
示例：

1 comment-repo:
2   file.replace:
3     - name: /etc/yum.repos.d/fedora.repo
4     - pattern: ^enabled=0
5     - repl: enabled=1
6     - check_cmd:
7       - ! grep 'enabled=0' /etc/yum.repos.d/fedora.repo

View Code

当运行了comment-repo之后，利用check_cmd检查是否还有没替换掉的enabled=0内容，如果有就返回false

OVERRIDING CHECKS

mod_run_check被用于onlyif和unless的检查
mod_run_check_cmd被用于check_cmd的检查