行业内各巨头的自动化运维架构都各种功能各种酷炫,让人可望而不可即。最终的目标大家都知道了,但问题是如何根据自己团队的当前情况一步步向那个目标演进。
笔者曾经所在的一个团队有三个半开发人员,要维护几十台云主机,部署了十多个应用,这些应用90%都是遗留系统。应用系统的编译打包基本在程序员自己的电脑上完成。分支管理就是dev分支开发,测试通过后,再合并到master分支中。生产环境的应用配置要登录具体的机器看才知道,更不用说配置中心及配置版本化了。在监控方面,甚至连基本的机器级别的基础监控都没有。
笔者平时的工作是50%的时间做业务开发,50%的时间做运维。而且,只有笔者一个人做运维。面对这么多问题,笔者考虑如何在低成本情况下实现自动化运维。本节就是总结笔者在这方面的一些经验和实践,希望对读者有所帮助。
事情有轻重缓急,监控和告警是一开始就要做的,即使业务开发被拖慢也要先做。只有知道了当前情况,才能做好下一步计划。
现在市面上有很多监控系统,如Zabbix、Open-Falcon、Prometheus 等。最终笔者选择了Prometheus。有以下几个理由。
之前我们介绍过,人少机器多,所以安装Prometheus的过程也必须要自动化,同时版本化。笔者先是以自己的工作电脑为控制机器,使用Ansible部署整个监控系统
使用Ansible作为部署工具的一个好处是有很多现成的role。在安装Prometheus时,使用现成的Prometheus-ansible。
有了监控数据后,我们就可以对数据进行可视化了。Grafana和Prometheus集成得非常好,所以我们又部署了Grafana,示意图如图所示。
Prometheus默认集成了多种告警渠道,钉丁除外。钉钉集成Prometheus告警组件:prometheus-webhook-dingtalk。
完成以上工作后,基础监控架构就大号了,为后期Redis监控,JVM监控做准备
很多运维人员或者开发人员一开始为了节约时间,采用手动方式搭建监控基础设施。事实上,这只是将“填坑”的时间拖后,或者留给后面的人罢了。
笔者推崇一开始就做配置版本化。在搭建监控系统的过程中,已经将配置抽离出来,放到一个单独的代码仓库进行管理。以后所有部署,我们都会将配置和部署逻辑分离。这样,只需要复制一份配置,改一改,就可以在新的环境中快速搭建一套新的监控系统。
关于如何管理Ansible部署脚本的配置,我们使用如下目录结构。
都是文本存储,后面切换使用Consul做配置中心,只需要将本身部署到Consul中就行。而且ansible2.0以上已经原生支持Consul操作
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。