小团队如何从零搭建一个自动化运维体系？

　　【资讯】行业内各巨头的自动化运维架构都各类成果，各类酷炫，让人可望不行及。

　　如下图，此刻行业内各巨头自动化运维架构的最终样子各人都知道了，可是怎样按照本身团队当前的环境一步步向这个方针演进?

　　笔者地址团队，三个半开拓，要维护几十台云呆板，陈设了十来个应用，这些应用 90% 都是遗留体系。

　　应用体系的编译打包根基在措施员本身的电脑上。分支打点也清一色的 dev 分支开拓，测试通事后，再归并到 master 分支。

　　出产情形的应用设置要登录上详细的呆板看才知道，更不消说设置中心及设置版本化了。对了，连根基的呆板级此外基本监控都没有。

　　我平常的事变是 50% 营业开拓，50% 运维。面临这么多题目，我就想，如安在低本钱环境下实现自动化运维。

　　本文就是总结我在这方面一些履历和实践，但愿对读者有辅佐。

　　别措辞，先上监控和告警

　　工作有轻重缓急，监控和告警是我认为一开始就要做的，纵然营业开拓被拖慢。只有知道了当前的环境，你才好做下一步打算。

　　此刻市面上监控体系许多：Zabbix、Open-Falcon、Prometheus，可是最终我选择了 Prometheus。

　　缘故起因有如下几点：

　　它是拉模式的。

　　它利便行使文本方法来设置，有利于设置版本化。

　　插件多，想要监控什么，根基城市有现成的插件。

　　以上三者，我根基都要从头学，我为什么不学一个 Google SRE 书上保举的呢?

　　之前我们已经先容过，人少呆板多，以是安装 Prometheus 的进程也必必要自动化，同时版本化。我行使的是 Ansible + Git 实现。

　　最终样子如下：

　　这里必要简朴先容一下：

　　Prometheus Server 认真监控数据网络和存储。

　　Prometheus Alert manager 认真按照告警法则举办告警，可集成许多告警通道。

　　node-exporter[1] 的浸染就是从呆板读取指标，然后袒露一个 http 处事，Prometheus 就是从这个处事中网络监控指标。虽然 Prometheus 官方尚有各类百般的 exporter。

　　行使 Ansible 作为陈设器材的一个甜头是太多现成的 role 了，安装 Prometheus 时，我行使的是现成的：prometheus-ansble[2]。

　　有了监控数据后，我们就可以对数据举办可视化，Grafana 和 Prometheus 集成得很是好，以是我们又陈设了 Grafana：

　　在 Grafana 上查察 nodex-exporter 网络的数据的结果图或许如下：

　　然则，我们不行能 24 小时盯着屏幕看 CPU 负载有没有超吧?这时辰就要上告警了，Promehtues 默认集成了 N 多告警渠道，痛惜没有集成钉钉。

　　但也没有相关，有好意的同窗开源了钉钉集成 Prometheus 告警的组件：prometheus-webhook-dingtalk[3]。

　　接着，我们告警也上了：

　　完成以上事变后，我们基本监控的架子就完成了，这为我们后期上 Redis 监控、JVM 监控等更上层的监控做好了筹备。

　　设置版本化要从娃娃抓起

　　在搭建监控体系的进程中，我们已经将设置抽离出来，放到一个单独的代码客栈举办打点。往后全部陈设，我们城市将设置和陈设逻辑疏散。

　　关于怎样行使 Ansible 举办设置打点，可以参考这篇文章：How to Manage Multistage Environments with Ansible[4] 。

　　我们就是行使这种方法来组织情形变量的。

　　├── environments/ # Parent directory for our environment-specific directories │ │ │ ├── dev/ # Contains all files specific to the dev environment │ │ ├── group_vars/ # dev specific group_vars files │ │ │ ├── all │ │ │ ├── db │ │ │ └── web │ │ └── hosts # Contains only the hosts in the dev environment │ │ │ ├── prod/ # Contains all files specific to the prod environment │ │ ├── group_vars/ # prod specific group_vars files │ │ │ ├── all │ │ │ ├── db │ │ │ └── web │ │ └── hosts # Contains only the hosts in the prod environment │ │ │ └── stage/ # Contains all files specific to the stage environment │ ├── group_vars/ # stage specific group_vars files │ │ ├── all │ │ ├── db │ │ └── web │ └── hosts # Contains only the hosts in the stage environment │

　　现阶段，我们全部的设置都以文本的方法存储，未来要切换成行使 Consul 做设置中心，也很是的利便，由于 Ansible 2.0 以上的版本已经原生集成了Consul：consul_module[5]。

　　Tips：Ansible 的设置变量是有条理的，这为我们的设置打点提供了很是大的机动性。

　　Jenkins 化：将打包交给 Jenkins

　　我们要将全部项目标打包事变交给 Jenkins。虽然，实际中我们是先将一些项目放到 Jenkins 上打包，然后慢慢将项目放上 Jenkins。

　　起首我们要有 Jenkins，搭建 Jenkins 同样有现成的 Ansible 剧本：ansible-role-jenkins[6]。

　　留意了，在网上看到的大多文章汇报你 Jenkins 都是必要手工安装插件的，而我们行使的这个 ansible-role-jenkins 实现了自动安装插件，你只必要加一个设置变量 jenkins_plugins 就可以了。

　　官方例子如下：

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!