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

linux全栈技术 2020-09-10

1681

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

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

作者：翟志军

来源：http://showme.codes/2018-06-07/devops-in-action/

- END -

Python全栈技术培训

往期精彩文章

kubernetes全栈技术+企业案例演示【带你快速掌握和使用k8s】

突破运维和开发瓶颈、Python、k8s、DevOps转型一网打尽！

python运维开发实战-基础篇

python运维和开发实战-高级篇

python运维和开发实战-安装和创建Django项目

使用 Python 创建 Grafana Dashboards

Jenkins上集成JUnit和TestLink进行Java单元测试流程与配置

GitLab 内置了一个强大的 CI/CD 系统
 Docker公司禁止被列入美国"实体名单"的国家、企业使用

Jenkis pipeline构建项目实践-编写podTemplate实现和k8s对接

kubernetes面试题汇总

“12306” 秒杀系统的设计艺术

DevOps视频和资料免费领取

kubernetes技术分享-可用于企业内部培训

谈谈我的IT发展之路

kubernetes系列文章第一篇-k8s基本介绍

kubernetes系列文章第二篇-kubectl

了解pod和pod的生命周期-这一篇文章就够了

Kubernetes中部署MySQL高可用集群

Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档

k8s1.18多master节点高可用集群安装-超详细中文官方文档

k8s中蓝绿部署、金丝雀发布、滚动更新汇总

运维常见问题汇总-tomcat篇

关于linux内核参数的调优，你需要知道

kubernetes持久化存储volume

kubernetes挂载ceph rbd和cephfs

报警神器Alertmanager发送报警到多个渠道

jenkins+kubernetes+harbor+gitlab构建企业级devops平台

kubernetes网络插件-flannel篇

kubernetes网络插件-calico篇

测试通过storageclass动态生成pv

通过编写k8s的资源清单yaml文件部署gitlab服务

helm安装和使用-通过helm部署k8s应用

Prometheus Operator-上篇-安装和使用篇

Prometheus Operator-下篇

通过kubeconfig登陆k8s的dashboard ui界面

通过token令牌登陆k8s dashboard ui界面

kubernetes DNS服务详细介绍

k8s基于Ingress-nginx实现灰度发布

kubernetes原生的CI/CD工具Tekton-一定要看看~

prometheus operator监控k8s集群之外的haproxy组件

kubernetes搭建EFK日志管理系统

Kubernetes 对计算、存储和网络资源进行监控的工具

kubernetes集群的etcd数据库详细介绍

Linux网络流量监控工具

技术交流群

为了大家更快速的学习知识，掌握技术，随时沟通交流问题，特组建了技术交流群，大家在群里可以分享自己的技术栈，抛出日常问题，群里会有很多大佬及时解答的，这样我们就会结识很多志同道合的人，长按下图可加我微信，备注运维或者k8s或者devops即可进群，让我们共同的努力，向着美好的未来出发吧~~~，想要免费获取各个版本的k8s高可用集群的安装视频或者其他的免费视频，也可进群获取哈~~

扫码加群👇

微信：justso656

微信公众号

长按指纹关注公众号👇

数据库

文章转载自linux全栈技术，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

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

技术交流群

微信公众号

评论