设为首页 - 加入收藏 ASP站长网(Aspzz.Cn)- 科技、建站、经验、云计算、5G、大数据,站长网!
热搜: 创业者 数据 手机
当前位置: 首页 > 教程 > 正文

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

发布时间:2018-07-04 07:15 所属栏目:61 来源:翟志军
导读:【资讯】行业内各巨头的自动化运维架构都各种功能,各种酷炫,让人可望不可及。 如下图,现在行业内各巨头自动化运维架构的最终样子大家都知道了,但是如何根据自己团队当前的情况一步步向这个目标演进? 笔者所在团队,三个半开发,要维护几十台云机器,部

  【资讯】行业内各巨头的自动化运维架构都各种功能,各种酷炫,让人可望不可及。

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

  如下图,现在行业内各巨头自动化运维架构的最终样子大家都知道了,但是如何根据自己团队当前的情况一步步向这个目标演进?

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

  笔者所在团队,三个半开发,要维护几十台云机器,部署了十来个应用,这些应用 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 就可以了。

  官方例子如下:

  --- - hosts: all vars: jenkins_plugins: - blueocean - ghprb - greenballs - workflow-aggregator jenkins_plugin_timeout: 120 pre_tasks: - include_tasks: java-8.yml roles: - geerlingguy.java - ansible-role-jenkins

  搭建好 Jenkins 后,就要集成 Gitlab 了。我们原来就有 Gitlab ,所以不需要重新搭建。

  最终 Jenkins 搭建成以下这个样子:

  关于 Jenkins master 与 Jenkins agent 的连接方式,由于网络环境各不相同,网上也有很多种方式,大家自行选择适合的方式。

(编辑:ASP站长网)

网友评论
推荐文章
    热点阅读