处理传统CI/CD问题说到CI/CD工具，IT圈最著名的可能是传统老牌CI/CD王者之一：詹金斯。说起来，基本上做IT的人都知道。在云计算时代，甚至更久，因为那个时候软件架构还没有拆分成微服务，很多都是部署在主机上。所以Jenkins靠着一套Pipeline和free-stylepipeline天下无敌。Jenkins之所以能纵横宇宙，很大一部分原因在于：开放性、CI/CD、易用性、能够走完整套交付流程。开放性：就是拥有开放包容的api和插件，可以在各种场景下使用。CI/CD：表示可以完成一套完整的交付，包括代码拉取、产品生成和存储、服务部署。但是随着技术的不断迭代，Jenkins总有一天会不再适应新的环境。大家请继续往下看。云原生时代CI/CD面临的挑战云原生时代，万物皆可云原生。随着微服务的盛行、业务逻辑服务的拆分、容器化的兴起，容器编排逐渐成为业务的主流标准。进入这个阶段，新的挑战也随之而来。比如：以前服务很少，Jenkins可以stud。现在服务多了，每个服务都需要一个JenkinsJob。虽然道理是一样的，复制粘贴，但是编号终究是一件麻烦的事情。十个或一百个呢？现在每个服务都需要用Jenkins做CI/CD，所以我要打包很多pipeline和Dockerfile。为什么这个正则文件不能抽象出来，每次都要自己写。每次都用kubelet和shell命令来构建部署合理吗？有很多环境，比如开发、测试、预发布、压测、生产。每个项目必须至少有两个或三个环境。此时如何管理众多环境？通过K8s的标准安排，很多服务的配置文件会以ConfigMap和Secret的形式存在，不同环境下的配置会不一致，那么如何统一管理呢？如何达到研发人员的感知状态？研发人员需要了解服务是否在K8s上启动成功，包括日志、事件信息、部署作业是否成功。可以提供这些吗？发布版本服务时如何合理管理版本？您需要一个开发测试环境，如何快速部署？以上就是服务迁移到K8s后会面临的一些问题。Jenkins很好，但是新趋势到来后，还是觉得自己内心强大但不够强大。也许你会说，你可以使用Jenkins+ArgoCD来弥合它们之间的鸿沟。但是我还是觉得Jenkins+ArgoCD并不是最理想的状态。Jenkins+ArgoCDJenkins可以做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有1台slave，4核16G云主机，包月：412元/月，还有压测及预发布环境Jenkins1台slave，4核16G云主机，包月：412元/月开发测试环境，4台slave，4核16G，本地机房虚拟机，资源总量消耗：16核，64G如果统一，那么降本增效就出来了吗？这时候可能会有人说小伙子是个保姆，哈哈，别着急，我慢慢来。Zadig能为企业数字化转型解决哪些问题？现有主机环境问题？在转型初期，或者业务场景需要很多企业的时候，会有部分业务进行容器部署。如果这时候让你迁移，你肯定不会把所有的脑筋都放在K8s上，会慢慢优化。此时Zadig在宿主机环境中支持CI/CD，依托K8s的弹性资源，你可以根据需要创建作业来执行构建和部署。任务，但世界上没有最好，只有更好。如果你的微服务有多个实例，可能会出现一些问题。即需要创建2个Job。弥补JenkinsJob单服务2任务的情况（一个构建包，一个部署，通过Git修改协调（ArgoCD））如果你用的是ArgoCD，那么我相信你一定是基于GitLab来做的，Jenkins肯定是官方有的环境中有2个工作，一个负责构建和上传镜像，一个负责服务变更拉取Git仓库。这时候会很冗余，所以Zadig提供了一个很好的构建和部署的划分，你只需要在运行工作流的时候点击是否构建即可。提供一个完整的分支，用PR构建的CI/CD产品肯定会适配GitPR。Zadig也是如此，可以在合并前提前测试，无需完成合并。环境复制、开发测试和性能改进在当今的微服务中非常普遍。很多时候，并不确定几个需求是否会同时得到满足。这个时候开发需要环境，测试需要环境。如何保证环境不冲突？那就是给他们一个新的环境，但是提供一个新的环境需要投入人力成本。有什么办法可以快速搭建开发测试环境，不用的时候再销毁？以前可能有点麻烦，但是随着业务容器化和K8s的弹性伸缩，这很容易实现。只需要找到对应的镜像，更新YAML到新的Namespace即可，但还是不够优雅。Zadig提供了完整的复制操作环境。一键式是一个基准环境。配合Istio进行分环境测试，直接解放双手，原地起飞。Istio子环境参考：自测联调环境|Zadig文档[1]环境托管功能，一个工作流，一次构建和发布所有托管环境与项目相同，并一直迭代。每个环节的服务都是一样的，为什么一定要区分呢？开放，通过相应的权限控制，一套构建，部署所有服务不好吗？环境配置（Ingress、ConfigMap、Secret）项目中的配置也有很好的管理空间，可以直接抽象成一个变量。每个链接的配置不同，但是引用的配置名称相同，所以环境可以实现。平滑迁移，如：线上中间件等连接依赖（ConfigMap+Service+Endpoint+CoreDNS）a.服务ExternalNameb。ServiceNone+Endpoints项目外部访问接口问题（Ingress）中间件连接账号密码问题（Secret+env）YAML、Dockerfile、Helm、服务构建模板管理Zadig有很好的抽象能力，可以直接优化重复动作，比如图片CI/CD经常遇到的Dockerfile、YAML等，通过抽象成模板实现配置的统一规范化管理。YAMLtemplatingHelmtemplating这里偷懒了，其实我对HelmDockerfiletemplatingbuildconfigurationtemplating不是很熟悉我个人提供两种思路：servicetemplating：所有服务配置一次构建，新服务稍后上线，镜像直接参考模板化时的模板语言：根据语言区分抽象出构造模板。施工模板的主要信息如下：a．构建产品所需的应用程序，例如：Go、Java、NodeJSb。构建产品Harbor集成需要配置的命令，配合官方环境的发布，通过Harbor集成可以实现不同环境的发布。比如官方环境只需要托管，不需要配置其他构建信息，工作流执行构建并上传到指定的Harbor，官方环境不需要打包更新，直接更换镜面产品。版本管理(releasedtagdeliverytracking)对每个服务进行tag产品发布管理，如果出现问题，可以快速回滚对应的版本。研发人员感知状态开发人员启动发布流程后，执行成功会有相关的IM推送。比如常见的：企业微信钉钉飞书部署逻辑这里需要等待相关的探针准备好后，才能让工作流进入下一步。原生接入扫码扩展功能点测试功能，支持自定义工作流，连接一切。如果你和老板还是解决不了你的问题，你可以尝试使用自定义工作流，编写自己的业务实现逻辑，然后通过自定义工作流实现。下面我举一个RDS慢日志查询的例子。如果官方环境使用的是云端数据库，以阿里云为例查询慢日志。为了规范起见，开发者没有阿里云账号，运维人员有。但是运维人员一般都是基于RDS做相关的慢SQL监控。如果有，他们需要检索慢速SQL条目。通常这个时候我会继续找运维同学提供，但是如果能够通过一个工作流来实现，那么运维同学的负担就会减轻，可以做更多的事情。以上是我提供的一个思路。当然，自定义工作流中可以使用的场景不仅限于此，还有更多的场景需要大家一起去发现。也希望大家能继续给Zadig输入场景。CI/CDObservabilityCI/CD可观察性也是一个很核心的点。让研发领导清楚了解公司的研发效率、施工规则、测试情况等。很多时候，我可以从这里阅读一些后续的工作指导。Zadig的这个概述也是我非常喜欢的一点。毕竟是自己打下的江山吧？总结IT领域的演进，就是运维人员通过不断接手开发人员眼中的“与开发无关的杂务”，不断减轻开发人员的负担。开发人员解放后，可以更专注于自己开发的业务系统，释放自己的创造力。但运维人员也必须不断优化现有的基础设施，搭建好用的平台项目供开发者使用。平台工程化可能是未来CI/CD的一个趋势和演进方向。参考链接[1]https://docs.koderover.com/zadig/v1.15.0/env/self-test-env/作者介绍我叫唐启涛。目前在广州的一家公司工作，哈哈，刚入职没多久，然后就不知道这个职位应该算是运维还是运维开发。因为我的工卡是运维开发，但是我的企业微信也是运维，不过这个不重要。以下是我作为“Zadig人”带来的一些使用分享和方案选择对比。的CI/CD优化。
