fightclub

saltstack中的设计模式(五)

发表于 | 分类于

上一篇文章中，我们介绍了通过import jinja的方式进行代码的复用，这个场景并不是很常见。更为常见的场景是使用include来进行引用

接下来是今天的案例

为每个通过salt部署的服务提供定制化的监控

我们通过salt部署了很多的服务，这些服务除了本身的配置以外，我们也希望为服务定制一些自定义zabbix监控脚本。
我们通过services.zabbix进行zabbix的部署。每当我们部署新的服务，对应的客户端脚本以及配置也会更新，更新好以后重启zabbix

假设我们需要部署的服务为mariadb，sls的入口在/srv/salt/services/mariadb/init.sls,
我们可以将监控部分独立成一个配置文件，放在/srv/salt/services/mariadb/zabbix.sls中

实现

/srv/salt/services/mariadb/init.sls

1
2
3
4
5
include:
  .zabbix
otherid:
  some.somefunc: []

/srv/salt/services/mariadb/zabbix.sls

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
include:
  - services.zabbix
/opt/scripts/mariadb_status.sh:
  file.managed:
    - source: salt://{{ slspath }}/scripts/mariadb_status.sh
    - mode: 755
mariadb_zabbix_conf:
  file.managed:
    - name: /etc/zabbix/zabbix_agentd.d/userparameter_mariadb.conf
    - source: salt://{{ slspath }}/templates/userparameter_mariadb.conf
    - mode: 600
    - user: zabbix
    - group: zabbix
    - require:
      - file: /opt/scripts/mariadb_status.sh
    - listen_in:
      - service: zabbix_agentd

我们在mariadb的任务中，引用了一个zabbix子任务来实现zabbix的扩展, 在子扩展中，引用了zabbix的原始任务。
通过include引入的任务，会在编译的时候重新排序，可以避免因为ID重复导致的错误。

总结

这个案例内，主要运用到以下几个技巧：

  • 在使用include的时候，可以使用一个.带指当前目录
  • 如果换成salt://协议，可以使用带指当前目录
  • state的执行顺序可以通过REQUISITE参数进行重新编排。在配置文件切分很多份的时候，可以使用反向REQUISITE，也就是带后缀_in的参数实现解耦。

state的用法可以参考saltstack官方文档