前言

该文章基于作者的云原生自运维系统-【风火轮平台】展开描述

• github
• 相关视频

自研该系统的目的

市面上有很多 CICD 的工具，几乎调研了个遍，每个服务都有优缺点，遗憾的是没有很好满足企业使用的一款服务。要么功能单一、要么功能强大却不贴切研发，因为我们要的是符合企业需求的 IT 自运维系统，而不是简单的满足 CICD 流水。以下列举几个情况说明：

• 云厂商提供的构建服务（阿里、腾讯、华为云等）

  • 代码放在别人那，不够放心。
  • 企业内网需要让他们能够访问
  • 功能也不够全：没有根据组织机构对接公司团队、人员，没有审批流程，缺乏统计度量等

• 工具类（这些基本上就是你自研的时候用下）

  • jenkins、jenkinsX
  • gitlab-ci
  • drone
  • apollo
  • skaffold
  • spinnaker
  • kubernetes pipeliner
  • draft
  • forge
  • flux
  • gitkube
  • kubeci
  • keel
  • brigade

• 平台服务（这类虽然功能多，但是缺陷跟上面云厂商的基本一样）

  • argoCD
  • kubesphere

而自研我们的系统就可以足够完备

1. 构建

   • 构建模版
   • 研发可以自定义相关配置

2. 部署

   • 部署模版
   • 部署配置
   • 部署资源审批
   • 部署策略

3. sdk 纳管理（自研的依赖包：maven sdk、node 组建）

   • 权限约束，只能通过平台发布，本地不可以随意发

4. 质量管控

   • 构建步骤的单测、静态代码分析约束
   • 服务 sdk 依赖树采集、分析（知道了公司所有服务都依赖了哪些包，可以约束依赖的版本，在安全问题上能发挥不少用途）

5. 工单审批

   • 服务节点审批
   • 部署资源审批
   • 其他运维琐事的审批和自动化处理

6. 问题分析

   • 容器登录
   • 容器内文件上下传
   • 容器内集成了 arthas jvm 调试工具

7. 统计度量

   • 上线部署结果统计
   • 单测统计
   • 静态代码统计
   • 部署资源统计
   • ...可以方便的一览公司的所有服务情况

8. 代码review

   • MR 请求，可以对 commit 代码逐行评论
   • 打分
   • 流转

9. 服务节点管理

   • cmdb（资源管理平台）
   • 对接服务相关团队、人员 等

10. 消息通知

    • 构建前置、后置
    • 部署前置、后置
    • 通知到群还是指定人员

技术选型

既然要自研，最老牌的 CICD 工具就是 jenkins vs gitlab-ci 了，其他如雨后春笋诞生的很多工具，感觉都不近人意。我们需要的是一个稳定可靠、接口丰富、灵活性强的工具来作为我们平台的基石。
虽然很多 CICD 服务选择用 jenkins（如：阿里的云效平台），但是对比后我们觉得 jenkins api 文档对比 gitlab 简直太糟糕了，最后我们用了 gitlab-ci，加上本身我们的代码放在 gitlab 上的，这样一来协作起来就更一体化。
我们的服务有 3 个，一个前端，二个后端：

• hotwheel-front（vue 前端）
• hotwheel-admin (java 后端)
• hotwheel-agent (golang 后端)

java 语言开发业务方面的功能比较适合，如：对接公司的 sso、组织机构、审批流程、动态生成 ci yaml、动态生成 deployment 等部署资源
golang 语言适合对接 k8s api，能够查询服务的状态，k8s 负载列表等。

当然，上面3个服务只是我们自研的服务，整个平台我们还引入了很多其他支撑服务：gitlab、sonar、maven、validator、metabase、kubernetes、pre-commit 脚本 等

最佳实践

我们将日常研发过程的很多最佳实践融入到我们平台的产品中

git-flow

一个好的工作流是我们日常研发都需要遵守的规范，他指导我们如何正确的提交代码、减少代码冲突、给版本打tag、保持一个完全对应线上服务的代码分支（方便有bug 的时候快速修复）
结合 git-flow 我们的产品加了如下约束：

1. 代码分支与环境关系绑定
   如：develop 分支只能部署到开发环境，只有 tag 分支能部署到生产 等
2. 部署一致性约束
   所有代码必须沿着开发、测试、预生产、生产这样的顺序部署，如新提交了一个 commit 到 release 分支(对应预生产)，此时 release 不能直接部署，这个 commit 的代码必须先在开发环境部署后，然后部署到测试环境，之后才可以部署到预生产，必须沿着这个环境顺序。
   这样做的目的就是防止一些遗漏的代码忘记合并到相关分支，产生一些事故。当然这个约束有点强硬，公司服务比较多的情况可以灵活设置，哪些需要应用这个策略，哪些不用。

构建流水

基于 gitlab-ci，我们只需要动态编写对应的 yaml 文件

• gitlab-ci 的不同步骤允许我们指定不同容器镜像，我们可以灵活的封装自己需要的镜像功能

  • 如：封装构建用的 maven 环境、node 环境、golang 等编译环境，封装 docker 环境来制作镜像产物。

部署流水

部署直接调用 k8s api 触发，部署的过程有很多参数需要动态设置，还要执行很多种类的操作（要做到够灵活才能实现真正的自运维）
参数：

• 健康检查
• 挂载文件
• 资源参数
• 更新策略
• ...

操作：

• 部署
• 回滚
• yaml 参看
• 暂停
• 更新
• ...

部署审批：
部署需要用到服务器资源，虽然在 k8s 集群里面这些资源就是数字加减，但是从公司的角度看有审批比较合适。

debug

自运维里面很重要的一部分就是让研发有自己排查问题的能力

• 能够一键登录容器
• 容器页面内置相关工具

质量门禁

在构建、部署流水中加入一些策略，校验不通过自动失败。

• 单元测试：是否成功、覆盖率是否达标
• 静态代码扫描：坏味道、漏洞、bug 数等
• 集成测试：部署完成后自动对接集成测试验证服务主流程是否通过

统计分析

统计的出发点不是简单列举出自己平台有的字段然后封装成图表展示，每个图表都要带着目的出发，要能暴露出问题点。
暴漏问题只是事件的开始，拿着得到的问题制定解决方案，持续跟进，处理的结果依然需要借助图表来反应。如此反复循环（发现问题、分析处理问题、结果跟进），才是我们 devops 统计分析的价值。
好的统计维度我认为应该是灵活的,不要看大部分的 devops 平台都在统计构建次数、构建耗时、构建成功率等的，然后自己也依葫芦画瓢的整到自己平台上。例如，别人的构建次数可能是为了推算需要提供多少构建机器合理；构建的耗时可能是为了看单测的编写质量等，你需要的话就可以加否则没意义。

数仓

• influxdb 时序数据库
• metabase 报表展示工具

代码 review

可以精确对每一行代码进程评价，可以流转给其他人、打分评价、消息自动通知