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

作者&＃xff1a;翟志军

来源&＃xff1a;http://showme.codes/2018-06-07/devops-in-action/

注&＃xff1a;本文要求读者对Ansible和 Jenkins有一定的认识。

题记: 幸福的家庭都是相似的 不幸的家庭各有各的不幸

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

笔者所在团队&＃xff0c;三个半开发&＃xff0c;要维护几十台云机器&＃xff0c;部署了十来个应用&＃xff0c;这些应用90%都是遗留系统。应用系统的编译打包基本在程序员自己的电脑上。分支管理也清一色的 dev 分支开发&＃xff0c;测试通过后&＃xff0c;再合并到 master 分支。生产环境的应用配置要登录上具体的机器看才知道&＃xff0c;更不用说配置中心及配置版本化了。

对了&＃xff0c;连基本的机器级别的基础监控都没有。

我平时的工作是 50% 业务开发&＃xff0c;50% 运维。面对这么多问题&＃xff0c;我就想啊&＃xff0c;如何在低成本情况下实现自动化运维。本文就是总结我在这方面一些经验和实践。希望对读者有帮助。

1、别说话&＃xff0c;先上监控和告警

事情有轻重缓急&＃xff0c;监控和告警是我觉得一开始就要做的&＃xff0c;即使业务开发被拖慢。只有知道了当前的情况&＃xff0c;你才好做下一步计划。

现在市面上监控系统很多&＃xff1a;Zabbix、Open-Falcon、Prometheus。最终作者选择了 Prometheus。因为&＃xff1a;

1. 它是拉模式的

2. 它方便使用文本方式来配置&＃xff0c;有利于配置版本化

3. 插件太多了&＃xff0c;想要监控什么&＃xff0c;基本都会有现成的

4. 以上三者&＃xff0c;我基本都要重新学&＃xff0c;我为什么不学一个 Google SRE 书上推荐的呢&＃xff1f;

之前我们已经介绍过&＃xff0c;人少机器多&＃xff0c;所以&＃xff0c;安装 Prometheus 的过程也必须要自动化&＃xff0c;同时版本化。笔者使用的是 Ansible &＃43; Git 实现。最终样子如下&＃xff1a;

这里需要简单介绍一下&＃xff1a;

1. Prometheus Server 负责监控数据收集和存储

2. Prometheus Alert manager 负责根据告警规则进行告警&＃xff0c;可集成很多告警通道

3. node-exporter 的作用就是从机器读取指标&＃xff0c;然后暴露一个 http 服务&＃xff0c;Prometheus 就是从这个服务中收集监控指标。当然 Prometheus 官方还有各种各样的 exporter。

使用 Ansible 作为部署工具的一个好处是太多现成的 role 了&＃xff0c;安装Prometheus 时&＃xff0c;我使用的是现成的&＃xff1a;prometheus-ansble

有了监控数据后&＃xff0c;我们就可以对数据进行可视化&＃xff0c;Grafana 和 Prometheus 集成得非常好&＃xff0c;所以&＃xff0c;我们又部署了 Grafana:

在 Grafana 上查看 nodex-exporter 收集的数据的效果图大概如下&＃xff1a;

可是&＃xff0c;我们不可能24小时盯着屏幕看CPU负载有没有超吧&＃xff1f;这时候就要上告警了&＃xff0c;Promehtues 默认集成了 N 多告警渠道。可惜没有集成钉钉。但也没有关系&＃xff0c;有好心的同学开源了钉钉集成 Prometheus 告警的组件&＃xff1a;

prometheus-webhook-dingtalk。

接着&＃xff0c;我们告警也上了&＃xff1a;

完成以上工作后&＃xff0c;我们的基础监控的架子就完成了。为我们后期上 Redis 监控、JVM 监控等更上层的监控做好了准备。

2、配置版本化要从娃娃抓起

在搭建监控系统的过程中&＃xff0c;我们已经将配置抽离出来&＃xff0c;放到一个单独的代码仓库进行管理。以后所有部署&＃xff0c;我们都会将配置和部署逻辑分离。

关于如何使用 Ansible 进行配置管理&＃xff0c;可以参考这篇文章&＃xff1a;How to Manage Multistage Environments with Ansible 。我们就是使用这种方式来组织环境变量的。

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

现阶段&＃xff0c;我们所有的配置都以文本的方式存储&＃xff0c;将来要切换成使用Consul做配置中心&＃xff0c;也非常的方便&＃xff0c;因为 Ansible2.0以上的版本已经原生集成了consule: consul_module

Tips: Ansible 的配置变量是有层次的&＃xff0c;这为我们的配置管理提供了非常大的灵活性。

3、Jenkins 化&＃xff1a;将打包交给 Jenkins

我们要将所有的项目的打包工作交给 Jenkins。当然&＃xff0c;现实中我们是先将一些项目放到 Jenkins 上打包&＃xff0c;逐步将项目放上 Jenkins。

首先我们要有 Jenkins。

搭建 Jenkins 同样有现成的 Ansible 脚本&＃xff1a;ansible-role-jenkins。注意了&＃xff0c;在网上看到的大多文章告诉你 Jenkins 都是需要手工安装插件的&＃xff0c;而我们使用的这个 ansible-role-jenkins 实现了自动安装插件&＃xff0c;你只需要加一个配置变量 jenkins_plugins 就可以了&＃xff0c;官方例子如下&＃xff1a;

---- hosts: allvars:jenkins_plugins:- blueocean- ghprb- greenballs- workflow-aggregatorjenkins_plugin_timeout: 120pre_tasks:- include_tasks: java-8.ymlroles:- geerlingguy.java- ansible-role-jenkins

搭建好 Jenkins 后&＃xff0c;就要集成 Gitlab 了。我们原来就有Gitlab了&＃xff0c;所以&＃xff0c;不需要重新搭建。如何集成就不细表了&＃xff0c;网络上已经很多文章。

最终 Jenkins 搭建成以下这个样子&＃xff1a;

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

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

1. 界面上设置

2. 使用 Jenkinsfile&＃xff1a;类似于 Dockerfile 的一种文本文件&＃xff0c;具体介绍&＃xff1a;Using a Jenkinsfile

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

Jenkinsfile 类似这样&＃xff1a;

pipeline {agent anystages {stage(&＃39;Build&＃39;) {steps {sh &＃39;./gradlew clean build&＃39;archiveArtifacts artifacts: &＃39;**/target/*.jar&＃39;, fingerprint: true}}}}

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

这时&＃xff0c;我们就可以在 Jenkins 上创建一个 pipleline Job了&＃xff1a;

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

4、让 Jenkins 帮助我们执行 Ansible

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

1. 在 Jenkins 安装 Ansible 插件

2. 在 Jenkinsfile 中执行

withCredentials([sshUserPrivateKey(keyFileVariable:"deploy_private",credentialsId:"deploy"),file(credentialsId: &＃39;vault_password&＃39;, variable: &＃39;vault_password&＃39;)]) {ansiblePlaybook vaultCredentialsId: &＃39;vault_password&＃39;, 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]]
}

1. ansiblePlaybook 是 Jenkins ansible 插件提供的 pipeline 语法&＃xff0c;类似手工执行&＃xff1a;ansible-playbook 。

2. withCredentials 是 Credentials Binding 插件的语法&＃xff0c;用于引用一些敏感信息&＃xff0c;比如执行 Ansible 时需要的 ssh key 及 Ansible Vault 密码。

3. 一些敏感配置变量&＃xff0c;我们使用 Ansible Vault 技术加密。

5、Ansible 脚本应该放哪&＃xff1f;

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

类似这样&＃xff1a;

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

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

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

7、小结

总结下来&＃xff0c;我们小团队的自动化运维实施的顺序大概为&＃xff1a;

1. 上基础监控

2. 上 Gitlab

3. 上 Jenkins&＃xff0c;并集成 Gitlab

4. 使用 Jenkins 实现自动编译打包

5. 使用 Jenkins 执行 Ansible

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

• CMDB的建设&＃xff1a;我们使用 ansible-cmdb 根据 inventory 自动生成当前所有机器的情况

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

• 自动扩缩容&＃xff1a;通过配置 Prometheus 告警规则&＃xff0c;调用相应 webhook 就可以实现

• ChatOps: ChatOps实战

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

- END -

热文&＃xff1a;

1. Intellij IDEA神器那些让人爱不释手的14种小技巧&＃xff0c;统统告诉你&＃xff01;

2. 一文告诉你&＃xff0c;Intellij IDEA神器隐藏的11种实用小技巧&＃xff01;

 往期推荐&＃xff1a;

• 死磕Java系列&＃xff1a;

1. 深入分析ThreadLocal

2. 深入分析synchronized的实现原理
   

3. 深入分析volatile的实现原理
   

4. Java内存模型之happens-before

5. Java内存模型之重排序

6. Java内存模型之分析volatile

7. Java内存模型之总结

8. J.U.C之AQS简介

9. J.U.C之AQS&＃xff1a;CLH同步队列

……

• Spring系列&＃xff1a;

1. Spring Cloud Zuul中使用Swagger汇总API接口文档
   

2. Spring Cloud Config Server迁移节点或容器化带来的问题

3. Spring Cloud Config对特殊字符加密的处理

4. Spring Boot使用&＃64;Async实现异步调用&＃xff1a;使用Future以及定义超时

5. Spring Cloud构建微服务架构&＃xff1a;分布式配置中心&＃xff08;加密解密&＃xff09;

6. Spring Boot快速开发利器&＃xff1a;Spring Boot CLI

……

可关注我的公众号

深入交流、更多福利

扫码加入我的知识星球

点击“阅读原文”&＃xff0c;看本号其他精彩内容