企业案例：Zadig 为什么能用的爽

说到 CI/CD 的工具，IT 圈内名声最响亮的可能就会是传统的老牌 CI/CD 的王者之一：Jenkins。说到它基本上 IT 人都知道。在曾经云计算时代，乃至更久远的时代，因为那个时候软件架构还没有拆分成微服务，很多都是主机部署。所以 Jenkins 靠着一套 Pipeline 和自由风格流水线，打遍天下无敌手。,Jenkins 之所以能够这么纵横宇内有很大的一部分原因就是：开放，CI/CD，使用简单，能够走完一整套交付流程。,开放：意味着有着开放包容的api和插件，能够面临各种场合。,CI/CD：意味着能够完整的走完一整套交付，包含代码的拉取，制品的生成存储以及服务的部署。,但是随着技术的不断迭代，Jenkins 终将有一天不再适合新的环境。各位请继续往下看嘞。,,在云原生时代，万物皆可云原生。随着微服务的盛行，业务逻辑的服务拆分，容器化的兴起，编排容器逐步成为了业务主流规范。进入到这一阶段，新的挑战也就随之而来。例如：,以上种种就是服务迁移 K8s 后所要面临的部分问题。Jenkins 很好，但是在新趋势的到来后，个人还是感觉心有力而力不足。,或许你会说可以使用 Jenkins+ArgoCD 来弥补相互之间的差距啊。但是我始终还是觉得，Jenkins+ArgoCD 并非是最理想的状态。,Jenkins 可以做 CI，ArgoCD 可以做 CD，两者相辅相成，可以实现基本的 K8s 环境的 CI/CD。类似示例图如下：,,两者结合固然是可以做到持续集成和持续发布的，但是我们还是要结合实际出发。我没有说不好，只是具体还要看使用场景和能够解决哪些问题。,现有很多 IT 公司都会有云资产，很多的正式环境都会放置在云端。这个时候就会有分歧——环境问题。,或许我开发测试使用本地机房，但是我云端因为是生产环境，会单独独立区分环境。那么按照环境区分原则，我会有 2 套环境，开发测试一套 Jenkins+ArgoCD，正式环境一套 Jenkins+ArgoCD。那么这个时候如果说公司对环境更为重视还会有预发，压测环境，那么又是一套 Jenkins+ArgoCD。好家伙，几套环境，上线一个服务都会在以上环境中乘以 3 的操作，直接带来的感觉就是：,以上就是后续会面临的问题，还有一些问题就是，通过 Jenkins+ArgoCD 仅仅只能做到 CI/CD，更多的呢，能够做到吗？这里好像还要打一个问号。,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 文档 [1],,环境托管功能，一个工作流，一个构建发布所有托管环境,同项目，一直迭代，每个环节的服务都是一样的，为什么一定要区分开呢，通过相应的权限控制，一套构建，部署所有的服务不香吗？,,环境配置（Ingress，ConfigMap，Secret）,项目中的配置等也有着较好的管理空间，可以直接抽象成为一个变量，每个环节的配置不同，但是引用的配置名相同，就可以实现环境之间的平滑迁移，比如：,,YAML，Dockerfile，Helm，服务构建模板管理,Zadig 有着良好的抽象能力，能够直接优化比较重复的动作，就比如 CI/CD 经常遇到的镜像 Dockerfile，YAML 等，通过抽象成为模板实现配置的统一和规范化管理。,,YAML 模板化,,Helm 模板化,这里偷懒没搞，其实我不太熟 Helm,Dockerfile 模板化,,构建配置模板化,我个人提供两种思路：,,
,Harbor 整合，配合正式环境的发布,可以通过对 Harbor 的整合，实现不同环境的发布，就比如：正式环境只需要托管，无需配置其他的构建信息，工作流执行构建上传到指定的 Harbor，正式环境不需要打包更新，直接更换镜像制品。,,版本管理（发版的 tag 交付物追踪）,每个服务的 tag 制品发版管理，出现问题可快速回退相应的版本。,,研发人员感知态,开发人员启动发版工作流后，执行成功会有相关的 IM 推送，例如常见的：,部署逻辑这里，需要等待相关的探针就绪之后才会让工作流进入下一步。,测试功能的原生接入,,代码扫描的支持,,自定义工作流，连接万物,如果前面还有没能够解决老板您的问题，可以尝试用自定义工作流，自己编码业务实现逻辑，然后通过自定义工作流实现。以下我就举一个 RDS 慢日志查询的例子。,,如果说，正式环境使用了云上的数据库，以阿里云为例，查询慢日志。规范起见，开发人员是没有阿里云账号的，运维人员有，但是运维人员一般都会基于 RDS 做相关的慢 SQL 监控，如果有那么就需要去检索慢 SQL 条目。,一般这个时候会不断找运维同学提供，但是如果说可以通过一条工作流实现，那么运维同学的负担就会降低，可以去做更多的事情。,,以上是我提供的一个思路，当然自定义工作流可以使用的场景可不仅仅是这样，还有更多的场景需要大家一起发掘，也希望大家能够不断的输入场景给 Zadig。,CI/CD 可观测性,CI/CD 可观测性也是很核心的一点，它可以让研发大佬清晰的知晓公司的研发效能如何，构建规律如何，测试情况如何。很多时候都能够从这里读出一些后续工作方向出来，Zadig 的这个概览也是我十分喜爱的一个点，毕竟是自己打下的江山不是吗？,,IT 领域的演变，就是运维人员通过不断向上接手开发人员眼中“跟开发无关的杂活”，来不断为开发人员减负。开发人员在得到了解放后，可以将视角更多的聚焦在自己开发的业务系统上，释放出自己的创造力。但是运维人员也要不断的优化现有的基础设施架构，以及构建简单易用的平台化工程来给开发人员使用。平台化工程或许是未来 CI/CD 的一个趋势和演进方向吧。,[1] https://docs.koderover.com/zadig/v1.15.0/env/self-test-env/,我叫唐启涛。目前就职于广州某公司，哈哈，刚刚入职没有多久，然后岗位应该算是运维还是运维开发，我也不知道。因为我工牌是运维开发，但是我企业微信又是运维，不过这个不重要，以下是我作为一个“Zadig 过来人”带来的一些使用分享、以及方案选型对比，希望对后续大家公司的 CI/CD 优化有所帮助。