资讯专栏INFORMATION COLUMN

一些小团队的自动化运维实践经验

princekin / 2540人阅读

摘要:行业内各巨头的自动化运维架构都各种功能各种酷炫,如下图,让人可望不可及。面对这么多问题,我就想啊,如何在低成本情况下实现自动化运维。自动扩缩容通过配置告警规则,调用相应就可以实现实战以上就是笔者关于自动化运维的一些实践。

行业内各巨头的自动化运维架构都各种功能各种酷炫,如下图,让人可望不可及。现在最终的样子大家都知道了,但问题是如何根据自己团队当前的情况一步步向那个目标演进?

笔者所在团队,三个半开发,要维护几十台云机器,部署了十来个应用,这些应用 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 以上的版本已经原生集成了Consule: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 的连接方式,由于网络环境各不相同,网上也有很多种方式,大家自行选择适合的方式。

好,现在我们需要告诉 Jenkins 如何对我们的业务代码进行编译打包。有两种方法:

界面上设置

使用 Jenkinsfile:类似于 Dockerfile 的一种文本文件,具体介绍:Using a Jenkinsfile[7]

作者毫不犹豫地选择了第2种,因为一是利于版本化;二是灵活。

Jenkinsfile 类似这样:

pipeline {

    agent any

    stages {

        stage("Build") {

            steps {

                sh "./gradlew clean build"

                archiveArtifacts artifacts: "**/target/*.jar", fingerprint: true

            }

        }

    }

}

那么 Jenkinsfile 放哪里呢?和业务代码放在一起,类似这样每个工程各自管理自己的 Jenkinsfile:

这时,我们就可以在 Jenkins 上创建一个 pipleline Job了:

关于分支管理,我们人少,所以,建议所有项目统一在 master 分支进行开发并发布。

让 Jenkins 帮助我们执行 Ansible

之前我们都是在程序员的电脑执行 Ansible 的,现在我们要把这项工作交给 Jenkins。具体操作:

在 Jenkins 安装 Ansible 插件[8]

在 Jenkinsfile 中执行

withCredentials([sshUserPrivateKey(keyFileVariable:"deploy_private",credentialsId:"deploy"),file(credentialsId: "vault_password", variable: "vault_password")]) {

             ansiblePlaybook vaultCredentialsId: "vault_password", inventory: "environments/prod", playbook: "playbook.yaml",

             extraVars:[

               ansible_ssh_private_key_file: [value: "${deploy_private}", hidden: true],

               build_number: [value: "${params.build_number}", hidden: false]

             ]

}

这里需要解释下:

ansiblePlaybook 是 Jenkins ansible 插件提供的 pipeline 语法,类似手工执行:ansible-playbook 。

withCredentials 是 Credentials Binding[9] 插件的语法,用于引用一些敏感信息,比如执行 Ansible 时需要的 ssh key 及 Ansible Vault 密码。

一些敏感配置变量,我们使用 Ansible Vault[10] 技术加密。

Ansible 脚本应该放哪?

我们已经知道各个项目各自负责自己的自动化构建,所以,Jenkinfile 就放到各自项目中。那项目的部署呢?同样的道理,我们觉得也应该由各个项目自行负责,所以,我们的每个要进行部署的项目下都会有一个 ansible 目录,用于存放 Ansible 脚本。类似这样:

但是,怎么用呢?我们会在打包阶段将 Ansible 目录进行 zip 打包。真正部署时,再解压执行里面的 playbook。

快速为所有的项目生成 Ansible 脚本及Jenkinsfile

上面,我们将一个项目进行 Jenkins 化和 Ansible 化,但是我们还有很多项目需要进行同样的动作。考虑到这是体力活,而且以后我们还会经常做这样事,所以笔者决定使用 cookiecutter[11] 技术自动生成 Jenkinsfile 及 Ansible 脚本,创建一个项目,像这样:

小结

总结下来,我们小团队的自动化运维实施的顺序大概为:

上基础监控

上 Gitlab

上 Jenkins,并集成 Gitlab

使用 Jenkins 实现自动编译打包

使用 Jenkins 执行 Ansible

以上只是一个架子,基于这个“架子”,就可以向那些大厂的高大上的架构进行演进了。比如:

CMDB的建设:我们使用 ansible-cmdb[12] 根据 inventory 自动生成当前所有机器的情况

发布管理:Jenkins 上可以对发布的每个阶段进行定制。蓝绿发布等发布方式可以使用通过修改 Ansible 脚本和 Inventory 实现。

自动扩缩容:通过配置 Prometheus 告警规则,调用相应 webhook 就可以实现

ChatOps:ChatOps实战[13]

以上就是笔者关于自动化运维的一些实践。还在演进路上。希望能与大家交流。

相关链接:

https://github.com/prometheus/node_exporter

https://github.com/ernestas-poskus/ansible-prometheus

https://github.com/timonwong/prometheus-webhook-dingtalk

https://www.digitalocean.com/community/tutorials/how-to-manage-multistage-environments-with-ansible

http://docs.ansible.com/ansible/latest/modules/consul_module.html

https://github.com/geerlingguy/ansible-role-jenkins

https://jenkins.io/doc/book/pipeline/jenkinsfile/

https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

https://jenkins.io/doc/pipeline/steps/credentials-binding/

http://docs.ansible.com/ansible/2.5/user_guide/vault.html

https://github.com/audreyr/cookiecutter

https://github.com/fboender/ansible-cmdb

https://showme.codes/2017-10-08/chatops-in-action/

原文链接:http://showme.codes/2018-06-07/devops-in-action/

欢迎加入本站公开兴趣群

软件开发技术群

兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流

QQ群:26931708

Hadoop源代码研究群

兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop

QQ群:288410967 

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/3951.html

相关文章

  • 直击六大会场 | 洞察100+创新实践,2018TOP100summit圆满落幕!

    摘要:北京时间月日月日,由和中国国际人才交流基金会联合主办的第七届全球软件案例研究峰会简称在北京国家会议中心圆满落幕。本届峰会,来自阿里美团百度平安银行等企业的讲师分别从企业转型及研发效能方面分享敏捷和的实践细节和操作经验。 北京时间11月30日-12月3日,由msup和中国国际人才交流基金会联合主办的第七届全球软件案例研究峰会(简称:TOP100summit)在北京国家会议中心圆满落幕。T...

    YacaToy 评论0 收藏0
  • 崔立强:Dev无感Ops,如何做到高效软件交付

    摘要:用云效首先可以获得研发模式的标准化,我们将其命名为,这是目前应用最广最适合阿里巴巴的分支管理模式,不但具有高度自由,快速迭代的特性,还可以与流水线结合,让整个公司具有统一的软件交付规范。最终避免了的发布故障。 在2018第二届研发效能嘉年华上,阿里巴巴云效技术专家崔力强带来了如何做到高效软件交付的精彩演讲,首先介绍了阿里巴巴在近几年在交付平台上的技术经验,以及目前云上工具平台交易的趋势...

    wawor4827 评论0 收藏0
  • 从DevOps到Cloud Native,应用上云姿势全解锁

    摘要:此文已由作者林帆授权网易云社区发布。好在问题发生在工作时间,被及时发现,没有导致什么损失。此外,服务的安全性也逐渐需要提上日程。这种应用与云高度融合的实践算得上是的一种终极形态。 此文已由作者林帆授权网易云社区发布。 欢迎访问网易云社区,了解更多网易技术产品运营经验。 序文伴随着IaaS、PaaS等云端基础设施技术的成熟,应用上云成为许多企业软件部门的心头大事。通过把传统软件系统搬到云...

    GT 评论0 收藏0

发表评论

0条评论

princekin

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<