前面四篇文章讲的更多是说这套监控平台是如何一步搭建起来的,但在实际生产中,我们要给客户搭建很多套私有云环境,不可能每个环境手动去装一边,因为zabbix的监控项和grafana的dashboard都可以做成模板导入。剩下就是一些软件安装和zabbix-agent的配置问题了,目前我采用的做法是将monitor-server封装成一个镜像,镜像里面将软件都安装好了monitor-server上有写好的ansible的playbook,agent端通,过monitor-server上的ansible的playbook去推送安装。
ansible是一个python写的基于ssh的轻量级的自动化运维工具,它有以下优点
优点:
(1)、轻量级,无需在客户端安装agent,更新时,只需在操作机上进行一次更新即可;
(2)、批量任务执行可以写成脚本,而且不用分发到远程就可以执行;
(3)、使用python编写,维护更简单,ruby语法过于复杂;
(4)、支持sudo;
(5)、基于ssh无需agent端就可以实现自动化配置。
缺点:
(1)、ansible默认才用轮询的方式,如果节点数量一多,撑不住,相比较基于c/s架构的saltstack 中间还有消息队列辅助在大规模集群中性能确实弱。
下面主要介绍自己写的playbook,目录结构如下
1 | /etc/ansible/ |
我这里分为3个roles ,ceph、common、telegraf
ceph主要做的操作有
1、拷贝配置文件
common 主要做的操作有
1、环境初始化
2、拷贝软件包到对应节点
3、解压tar包
4、安装软件
5、修改对应的配置文件
6、修改执行权限
7、修改防火墙开放端口
8、启动服务、设置开机自启
telegraf主要做的操作有
1、安装telegraf
2、修改telegraf systemd的启动用户
3、拷贝telegraf配置文件
4、重启telegraf并设置开机启动
因为每个节点所对应的角色不一样,ansible所跑的脚本也是不一样的,所以定义这3个roles,服务器的角色通过hosts文件控制
定义了三组角色,控制节点、计算节点、存储节点、融合节点、每组角色设置了不同的metadata,这个metadata是通过templates/zabbix_agentd.conf.j2传给对应节点zabbix-agent里面的HostMetadata参数,然后zabbix-server根据不同的metadata去调用不同的模板。定义group是为了在task里面调用不同的命令。
通过site.yml来控制不同的host调用不同的role
可以看见common的hosts是all表示在hosts定义的所有组都会调用common, telegraf roles是只有control的host会去调用 ceph roles是storage的 hosts去调用
每个roles下面分handlers、tasks、templates、vars 其中,
handlers:也是task,但只有其关注的条件满足时,才会被触发执行 ,
templates:定义的是配置文件模板,比如我们这里定义好了zabbix_agent、和telegraf的配置文件模板
vars:定义变量,我在templates里面定义了zabbix_agent变量,里面的server 和server_active我都是以变量方式存储的,然后在执行ansible前先把变量改好,这样在不同的环境配置文件里的ip也会根着变。