当前位置：网站首页>00 后云原生工程师：用 Zadig 为思创科技（广州公交）研发开源节流

00 后云原生工程师：用 Zadig 为思创科技（广州公交）研发开源节流

2022-06-28 22:01:00 【InfoQ】

这是我和 Zadig 的故事！

在互联网大肆发展，数字化转型的背景下，互联网出行大肆盛行的当下，传统的客运站已经逐渐站在了城市的边缘。越来越多的人出行选择了高铁、飞机。客运站更多时候都起着一个追溯曾经的青春的作用，是老一辈的人的出行首选，因为他们不太懂这些“新潮玩意”（互联网出行），但随着出行方式的多变，客运站售票方式多样化和个人用户出行目标的不变，我们需要拓展多样化的售票方式对用户去做支撑，大量的用户涌入和需求迭代就对 IT 基础设施带来了新的挑战。

本文作者：思创 运维工程师唐启涛

企业研发瓶颈

企业研发效率慢，开发人员不能全身心投入到需求开发当中

思创科技作为一家公交行业的互联网转型企业，在规模较小的时候开发人员能够担任“全栈工程师”。所有的研发步骤节点都可以由开发人员参与完成项目迭代上线。但是随着公司的发展，项目的增长和需求的繁多。研发人员在进行代码验证的时候，花费了太多的时间。无法全身心投入到研发过程当中。

同时针对于研发人员天马行空的想法验证也有着局限性。一个行业的创新，必定是需要验证众多天马行空的想法，才能最终实现突破性的创造。但如果依旧按照之前传统的研发体系，那么软件研发创新的可能性就会随着时间的发展，研发人员的精神疲惫，无法获取灵感创新。

IT 技术发展自身技术的跟进和变革（虚拟化无法满足现有状态）

传统的虚拟化在项目中已经逐步的感到“疲惫”。在项目申报中，服务器一般都会有着部分的冗余空间，但是恰恰就是这部分的冗余空间，在某些时刻就是浪费。我们需要做到一个变革，一场能够在将 IT 利用率达到最好的变革。

DevOps 和容器化就随着研发瓶颈逐渐出现在我们后续的工作中。

DevOps 的探索

为什么选择 Zadig？

起初我们选择的是 Jenkins ，因为 Jenkins 在业内太有名。随意在马路边上拉上一个 IT 从业者，你问他 Jenkins 是什么，他肯定知道。哈哈。随后的落地中，我们也确实是使用着 Jenkins 去做一个探索。起初想做到如下，但是效果不太理想。

Jenkins 首先创立的初衷是针对于主机服务，在创立的时候并没有为 Kubernetes 留下一道方便之门

Jenkins 做持续集成部署有着繁多的 Pipeline 和 Jenkinsfile，Dockerfile 以及各类 K8s 服务 Yaml 文件。在文件管理上略显杂乱。这些东西都是比较有规律的文件，缺乏统一管理。且如果 Jenkins 是包括了以往传统的主机部署项目的话是可以说是继续探索下去的，但是在大规模实现容器化编排的现在 Jenkins 在我们这就有点乏力。

但是 Jenkins 有着灵活的插件和 Pipeline ，可以实现人工介入发布，这是我们比较喜欢的一点。但随着项目的上线和使用，发现他的并发构建在现有环境下较慢故暂时搁置。

Jenkins Pipeline 在微服务发布项目中，需要修改 Pipeline ，造成不必要的麻烦

Jenkins 无法对服务的发布顺序做改变，只能通过脚本的形式手动选择顺序发布

在后续的工作中，发现了 Zadig ，他成为了我们

高效研发的“尚方宝剑”

。

初识 Zadig

Zadig 其实我觉得接触起来非常容易，前提是你要了解基本的 K8s 概念和你需要构建服务的语言基本情况，这样你使用起来就是

直接起飞

。

Zadig 在我们这有着高效的研发流程，具体体现在：

高效管理 K8s 服务 Yaml，Helm，微服务的 Dockerfile 的模版
，完美解决了 Jenkins 中繁多的文件问题

Zadig
完美支持云原生项目和主机项目
，可以实现鱼和熊掌，我都要！

在我们扁平化的环境下， Zadig 的效能能够
完美覆盖我们的所有场景
。

Zadig
环境管理能力很强大
，能够提供其他工具无法提供的
环境复
制功能，在不同环境下支持不同的 Configmap，环境变量等

Zadig 进行
CI 提速较为明显

具有强大的
统计数据
模块

我们从 1.6 版本就开始使用 Zadig ，那个时候 Zadig 还是一个比较稚嫩的 CI/CD 工具，但是现在都已经发版到 1.12 了，具有太多有用的功能了。

那个时候我们就是

十分看重 Zadig 对 Kubernetes CI/CD 的管控力

。只需要定义好相关服务的 Yaml ，这个 Yaml 可以从模板库中提取，就十分的 Nice。填写相关的服务参数，就可以实现运行了。并且他可以自定义运行顺序，可以说非常棒。

在后续对 Zadig 的关注中，我们发现他逐步的推出了新的产品。我们对 Zadig 也十分充满信心。在后续我们也尝试过升级，但是那个时候自己电脑上 VMware 做虚拟化升级测试是可以，信心满满的去生产做升级。好家伙，什么服务都起来了，但就是无法访问 UI 界面。只能回退，后续我们在和官方接触后才发现是 Istio 和 Zadig 的网关冲突，在升级的时候关闭了相关的参数后才正常升级，体验到了更好的产品。通过这个事件我也体会到了

开源产品社区和用户之间的联系更紧

，那么问题定位也能更方便，不断的使用产品，不断的反馈，社区不断的打磨，铸就一个更为强大的产品诞生，未尝不是一件美事。

落地和反馈

在 Zadig 落地后，项目的开发验证得到了

跨越式的发展

，以往的验证都是自己本地 IDE 启动，然后本地测试，测试人员无法进行测试。但是随着 Zadig 的流水线作业。服务的迭代速度也是越来越快。并且在扁平化的项目中， Zadig 可以

对项目环境进行快速复制验证

，保障在环境下的隔离。

在之前我们可能还考虑说是大家对这个有所抵触，但是随着第一个项目的成功上线，后续大家对于这些东西都不再有着排斥。反而是主动说着上线。毕竟谁不想做一个 “专一” 的人呢？

同时

大大提升了每日开发想法的验证个数

。极大的提升了研发效能。同时随着项目容器化，越来越多的虚拟机被释放出来，实现了 IT 资源的进一步高利用率。

怎么判断 Zadig 是否适合你

如果你们公司的是和我们一样在推动数字化转型，容器化编排。那么 Zadig 十分适合你。

如果你们公司用着 Jenkins 做传统的主机发布管理，这个时候要上 Kubernetes 实现容器化，那么 Zadig 同样适合你们，可以做到 Jenkins 和 Zadig 的集成发布

如果你们公司的项目较为扁平化，那么 Zadig 可以基本覆盖 95% 的场景，加上 Zadig 众多的优势，何乐不为呢？

如果你们公司刚刚开始进行

云原生探索

，那么 Zadig 是你们的不二之选，上手快，社区活跃度高。问题响应之快，绝对可以为贵公司 DevOps 理念的落地提供技术支撑。

Zadig 实现的价值

Zadig 不仅仅是一个优秀的 CI/CD 工具，他更是 DevOps 文化的践行者。通过 Zadig 我们实现了高效研发，在研发人员的每日研发利用率上对比以往做到了更大的提升，省出宝贵时间去创造更多产品价值。

针对需求迭代，做到了每日服务需求有更新

针对开发验证，可以做到集成环境资源的收缩自如

Zadig 不仅实现了自身的企业价值，还帮助解决了我们这些软件企业发展中的许多瓶颈问题。

使用情况总结

当前思创科技产品业务线 5 条，其中 3 条业务线都已完全接入 Zadig，其余 2 条业务线属于传统业务，更新频率较低。

通过 Zadig 管理了3个集群，其中 2 套集群为远端业务集群。部分环境无法通过 Kubernetes 去编排容器实现远程发布，通过zadig的主机项目，实现远程容器发布，方便后续的业务迁移。

运行环境 17 个其中 12 个测试、5 个生产，共计 200+ 个应用程序，实现了 4000+ 次自动化构建和部署，部署成功率 99% 以上

从发布频率上看，以往都是有开发人员主动介入发布，在本地通过打包的形式部署在服务器上，发布。一天发布的频率大约在 10 次上下。在接入 Zadig 之后代码更新迭代的频率得以飞速提升，慢的一天也是30 左右，快的一天 70 余次

对 Zadig 和开源社区的期待

在发展上希望未来 Zadig 能够在开源领域多多提升自身活跃度，多参加开源社区的活动和开源峰会布道推广，例如： KubeCon，CloudNativeCon，Open Source Summit 等。希望让更多的企业，研发负责人，一线员工能够看到 Zadig 在云原生时代对 DevOps 的强有力的改变。也希望 Zadig 社区能够越做越好。

至于什么其他 Zadig 功能性的建议，我也不再献丑了。