今天需要把zabbix服务端转移到另外一个机房,伴随的问题是需要批量修改客户端的配置,刚好可以把昨天练习的salt功能实践一下


整个目录结构为:

saltstack学习三:批量修改zabbix配置文件_salt

首先还是从top.sls文件入手/srv/salt/top.sls:

saltstack学习三:批量修改zabbix配置文件_salt_02

匹配所有机器,按zabbix目录下zabbixAgentConfig.sls文件操作

然后zabbixAgentConfig.sls就是同步zabbix的配置文件了:

saltstack学习三:批量修改zabbix配置文件_zabbix_03

然后将修改好的zabbix_agentd.conf 上传到zabbix目录,并重命名为zabbix_agentd.conf.jinja


好了,一切准备就绪,下面开始推送文件:

salt '*' state.highstate

然后重启zabbix_agentd:

salt '*' cmd.run 'killall  zabbix_agentd'
salt '*' cmd.run '/usr/local/zabbix/sbin/zabbix_agentd -c /usr/local/zabbix/etc/zabbix_agentd.conf'


做完之后又想了一下,好像做得有点二,zabbix_agentd.conf都没有用到任务的变量,搞个毛jinja模板,好吧有点多余了,好像人家都可以做到监控到配置文件有变动自动重启服务,好吧我不会怎么写这个功能,再研究一下salt怎么重启zabbix先~~~


好吧,刚试了一下怎么样在sls模板中重启zabbix,这是我调整后的zabbixAgentConfig.sls

saltstack学习三:批量修改zabbix配置文件_salt_04

这样可以一步到位推送文件再加重启了

到这里,我又遇到一个问题,salt好像没有对比配置文件差异就重启了服务,我执行一次zabbix就重启一次,好像有点不科学,再研究一下怎么搞。。


刚刚去群上请教了一下大神,绿肥大神告诉我用cmd.wait,到官网查了一下,cmd.wait会考虑watch的条件才去执行命令

saltstack学习三:批量修改zabbix配置文件_zabbix_05

所以又将zabbixAgentConfig.sls做修改:

saltstack学习三:批量修改zabbix配置文件_salt_06

这个是最终版本了,终于完美了,哈哈,,不容易啊。。。