作者:唐启涛,运维开发工程师
摘要:听听来自广州的 00 后工程师,讲述为什么 Zadig 用的爽?以及作为「过来人」的他,又是如何落地 Zadig,帮助提升工程师幸福度、帮助公司实现研发降本增效。
Who?
大家好,我叫唐启涛。目前就职于广州某公司,哈哈,刚刚入职没有多久,然后岗位应该算是运维还是运维开发,我也不知道。因为我工牌是运维开发,但是我企业微信又是运维,不过这个不重要,以下是我作为一个“Zadig 过来人”带来的一些使用分享、以及方案选型对比,希望对后续大家公司的 CI/CD 优化有所帮助。
传统 CI/CD 处理的问题
说到 CI/CD 的工具,IT 圈内名声最响亮的可能就会是传统的老牌 CI/CD 的王者之一:Jenkins。说到它基本上 IT 人都知道。在曾经云计算时代,乃至更久远的时代,因为那个时候软件架构还没有拆分成微服务,很多都是主机部署。所以 Jenkins 靠着一套 Pipeline 和*风格流水线,打遍天下无敌手。
Jenkins 之所以能够这么纵横宇内有很大的一部分原因就是:开放,CI/CD,使用简单,能够走完一整套交付流程。
- 开放:意味着有着开放包容的api和插件,能够面临各种场合。
- CI/CD:意味着能够完整的走完一整套交付,包含代码的拉取,制品的生成存储以及服务的部署。
但是随着技术的不断迭代,Jenkins 终将有一天不再适合新的环境。各位请继续往下看嘞。
云原生时代 CI/CD 面临的挑战
在云原生时代,万物皆可云原生。随着微服务的盛行,业务逻辑的服务拆分,容器化的兴起,编排容器逐步成为了业务主流规范。进入到这一阶段,新的挑战也就随之而来。例如:
- 以前服务少,Jenkins 能够一把梭哈,现在服务多起来了,每个服务都要一个Jenkins Job,尽管都是一样的逻辑,复制粘贴,但是数量多了也终将是一个麻烦事。如果十个,百个呢?
- 现在每个服务都要用 Jenkins 去做 CI/CD,那么我要封装很多的 pipeline,还有 Dockerfile,这种有规律的文件为什么不能抽象化,每次都要自己写。
- 每次使用都是通过 kubelet 加 shell 命令去做的构建部署,这样合理吗?
- 环境众多,开发、测试、预发、压测、生产,每个项目总有那么最少两三个环境吧,这个时候环境多了如何管理呢?
- 通过 K8s 的标准编排,很多服务配置文件都会以 ConfigMap,Secret 的形式存在,不同环境的配置都会不一致,那么如何去做统一管理呢?
- 研发人员的感知态如何做到?研发人员需要知道这个服务上了 K8s 是否启动成功,包含日志,事件信息,部署 Job 是否成功。这些能提供吗?
- 发版服务的时候,如何才能合理管理版本呢?
- 开发测试找你要环境,你该如何快速部署相应呢?
以上种种就是服务迁移 K8s 后所要面临的部分问题。Jenkins 很好,但是在新趋势的到来后,个人还是感觉心有力而力不足。
或许你会说可以使用 Jenkins+ArgoCD 来弥补相互之间的差距啊。但是我始终还是觉得,Jenkins+ArgoCD 并非是最理想的状态。
Jenkins+ArgoCD
Jenkins 可以做 CI,ArgoCD 可以做 CD,两者相辅相成,可以实现基本的 K8s 环境的 CI/CD。类似示例图如下:
两者结合固然是可以做到持续集成和持续发布的,但是我们还是要结合实际出发。我没有说不好,只是具体还要看使用场景和能够解决 哪 些问题。
现有很多 IT 公司都会有云资产,很多的正式环境都会放置在云端。这个时候就会有分歧——环境问题。
或许我开发测试使用本地机房,但是我云端因为是生产环境,会单独独立区分环境。那么按照环境区分原则,我会有 2 套环境,开发测试一套 Jenkins+ ArgoCD ,正式环境一套 Jenkins+ ArgoCD 。那么这个时候如果说公司对环境更为重视还会有预发, 压测 环境,那么又是一套 Jenkins+ ArgoCD 。好家伙,几套环境,上线一个服务都会在以上环境中乘以 3 的操作,直接带来的感觉就是:
- 效能降低
- 环境治理困难
- 服务配置文件难以管理
以上就是后续会面临的问题,还有一些问题就是,通过 Jenkins+ ArgoCD 仅仅只能做到 C I /CD ,更多的呢,能够做到吗?这里好像还要打一个问号 。
为什么 Zadig 用的爽?
Zadig 就是专门用来做效能的一款开源 CI/CD 平台。我十分认可 Zadig 的使命:工程师是数字经济最重要的资产,Zadig 让工程师专注企业创新。他可以完美的解决我们迁移 K8s 后的 一系列 问题。如果加以规划和使用,可以用如下流程图来概括:
详细部署图如下:
通过一定的规划后可以实现 CI/CD 环境,一套 主导所有。
这个时候可以算下成本,假设你环境之间是这样区分的:
- 其中正式环境 Jenkins 存在 slave 1 台,4核16G 云主机,包月:412元 /月
- 其中压测 ,预发环境 Jenkins 存在 slave 1 台,4核16G 云主机,包月:412元 /月
- 开发测试环境,4 个 slave , 4 核 16G,本地机房虚拟机 ,共计消耗资源:16核,64G
如果统一了,那么 降本增效 不就出来了吗?
这个时候可能有人会说,小伙子是 托儿 ,哈哈别急,让我慢慢道来。
Zadig 能解决企业数字化转型的什么难题
现有主机环境问题?
很多企业在转型刚刚开始期间,或者说业务场景需要,会有部分业务存在 容器 部署。如果这个时候让你迁移,肯定不会一股脑的往 K8s 上塞,会慢慢的进行优化,这个时候 Zadig 支持主机环境的CI / CD,并且依靠 K8s 的弹性资源,能够根据需求创建 Job 执行构建部署任务,但是天下没有什么最好,只有更好,如果你微服务是多实例可能还真有点问题。那就是需要创建 2 个 Job。
弥补 Jenkins Job 单服务 2 任务的情况(一个构建打包,一个部署,通过 Git 修改协调(ArgoCD))
如果客官您使用的是 ArgoCD 那么我相信你肯定是基于 GitLab 去做的,Jenkins 肯定是在正式环境有 2 个 Job,一个负责构建上传镜像,另一个就是拉取 Git 仓库进行服务的更改。这个时候会显得很冗余,那么 Zadig 提供良好的构建部署的划分,只需要你运行工作流的时候 轻轻 点击是否构建即可。
提供完善的分支,PR 构建
好的 CI/CD 产品肯定是会对 Git PR 去做相关的适配的, Zadig 同样如此,能够在没有合并之前提前进行测试,无需完成合并。
环境复制,开发测试,提升效能
在微服务横行的今天,很多时候指不定那天就同时接了好几个需求去做,那么这个时候开发需要环境,测试需要环境 , 怎么保证环境不冲突呢?那就是给他们一个新环境,但是提供新环境需要投入人力成本进去,有没有什么办法快速构建一套环境出来开发测试,后续不使用的时候销毁?
以前可能有点麻烦,但是随着业务容器化加上 K8s 的弹性扩缩容,这个就很好实现了,只需要找到相应的镜像, YAML 更新到新的 Namespace 就可以了,但是这还是不够优雅。
Zadig 提供环境的全量复制操作,一键就是一个基准环境,配合 Istio 进行子环境测试,直接解放双手,原地起飞。
Istio 子环境参考: 自测联调环境 | Zadig 文档
环境托管功能,一个工作流,一个构建发布所有托管环境
同项目,一直迭代,每个环节的服务都是一样的,为什么一定要区分开呢,通过相应的权限控制,一套构建,部署所有的服务不香吗?
环境配置(Ingress,ConfigMap,Secret)
项目中的 配置 等也有着较好的管理空间,可以直接抽象成为一个变量,每个环节的配置不同,但是引用的配置名相同,就可以实现环境之间的平滑迁移,比如:
-
上线中间件等连接依赖问题(ConfigMap + Service + Endpoint + CoreDNS )
-
S ervice ExternalName
-
S ervice None + E ndpoints
-
-
项目外部访问接口问题(Ingress)
-
**中间件连接账号密码问题(**Secret + env)
YAML,Dockerfile,Helm,服务构建模板管理
Zadig 有着良好的抽象能力,能够直接优化比较重复的动作,就比如 CI/CD 经常遇到的镜像 Dockerfile, YAML 等,通过抽象成为模板实现配置的统一和规范化管理。
YAML 模板化
Helm 模板化
这里偷懒没搞,其实我不太熟 H elm
Dockerfile 模板化
构建配置模板化
我个人提供两种思路:
-
服务模板化 : 所有的服务配置一次构建,后续上线新的服务,构建 镜像 的时候直接引用模板
-
语言模板化 : 按照语言区分进行构建模板 的抽象, 构建模板主要信息 如下:
-
构建产物所需要的应用,比如: G o,Java, NodeJS
-
构建产物所需要配置的命令
-
Harbor 整合,配合正式环境的发布
可以通过对 Harbor 的整合,实现不同环境的发布,就比如:正式环境只需要托管,无需配置其他的构建信息,工作流执行构建上传到指定的 Harbor,正式环境不需要打包更新,直接更换 镜像 制品 。
版本管理(发版的 tag 交付物追踪)
每个服务的 tag 制品发版管理,出现问题可快速回退相应的版本 。
研发人员感知态
开发人员启动发版工作流后,执行成功会有相关的 IM 推送,例如常见的 :
- 企业微信
- 钉钉
- 飞书
部署逻辑这里,需要等待相关的探针就绪之后才会让工作流进入下一步 。
拓展功能点:
测试功能的原生接入
代码扫描的支持
自定义工作流,连接万物
如果前面还有没能够解决老板您的问题,可以尝试用自定义工作流,自己编码业务实现逻辑,然后通过自定义工作流实现。以下我就举一个 RDS 慢日志查询的 例子。
如果说,正式环境使用了云上的数据库,以阿里云为例,查询慢日志。规范起见,开发人员是没有阿里云账号的,运维人员有,但是运维人员一般都会基于 RDS 做相关的慢 SQL 监控,如果有那么就需要去检索慢 SQL 条目。
一般这个时候会不断找运维同学提供,但是如果说可以通过一条工作流实现,那么运维同学的负担就会降低,可以去做更多的事情。
以 上 是我提供的一个思路,当然自定义工作流可以使用的场景可不仅仅是这样,还有更多的场景需要大家一起发掘,也希望大家能够不断的输入场景给 Zadig。
CI/CD 可观测性:
CI/CD 可观测性也是很核心的一点, 它 可以让研发大佬清晰的知晓公司的研发效能如何,构建规律如何,测试情况如何。很多时候都能够从这里读出一些后续工作方向出来,Zadig 的这个概览也是我十分喜爱的一个点,毕竟是自己打下的*不是吗?
总结
IT 领域的演变,就是运维人员通过不断向上接手开发人员眼中“跟开发无关的杂活”,来不断为开发人员减负。开发人员在得到了解放后,可以将视角更多的聚焦在自己开发的业务系统上,释放出自己的创造力。但是运维人员也要不断的优化现有的基础设施架构 ,以及 构建简单易用的平台化工程 来给 开发人员使用。平台化工程或许是未来 CI/CD 的一个趋势和演进方向吧。