利用 Zadig 多云环境周部署千次,跨云跨地域持续交付全球业务

Zadig 解决了跨云、跨地域场景的联调交付痛点,极大的减轻了脚本的维护、环境治理,节约了大量的时间成本,充分串联起研发、测试和运维团队,提升研发效能和应用交付体验

iMile 是一家跨境电商物流初创公司,提供中东和拉美等新兴市场的物流服务,通过自建快递团队、精细化运营和互联网技术手段,致力于完善跨境物流的末端一公里。iMile 已成长为中东 Top 3 的跨境电商物流服务公司,同时也是当地行业内发展速度 Top 2 的技术效益丰硕的物流公司。

# 痛点分析

在以往的业务研发过程,我们遇到如下的痛点:

  1. 环境治理复杂:dev、fat、lpt、uat、prod 等多套环境分布在不同地区的数据中心,使用 Jenkins 流水线部署交付需要大量人工干预。
  2. 研发效率低:研发团队程序调试、联调测试环境不够友好,经常需要在多个环境的不同版本里来回切换协助测试、前后端排查问题,研发时间被占用。
  3. 测试资源不足:排期项目与日常迭代经常混合在同一套测试环境里测试,大量代码变动时部署并行效率不高,影响测试进度。
  4. 维护成本高:服务部署使用 Jenkinsfile + YAML 的方式,每个工程需要维护一套配置和脚本,当工程越来越多时,维护成本会越来越重。

# Zadig 之旅

在选型 Zadig 之前,我们有多套 K8s 集群,分别部署在了多个不同的数据中心,使用 Kubeboard 进行多集群统一管控,对集群统管暂无其他特殊需求。

# 偶遇 Zadig

无意中在 B 站看到了 KodeRover Workathon 的线上分享(如下图),就开始同团队成员一起研究KodeRover(Zadig)这个产品。发现它与云原生能够非常完美的结合,多集群服务可统一纳管,多流水线并发构建,容器服务可视化交付,面向研发交互友好。

恰巧当时我们研发团队立项一个重构的项目,需要一套独立的测试环境来满足联调测试任务。我们抱着新鲜的态度就部署了一套 Zadig 集群,计划通过它来解决这个项目重构的测试环境需求。通过 3 天时间的摸索沟通交流,我们很快在 Zadig 上部署了前后端工程服务到 K8s 集群。

# 网络改造

我们当时网络状况是这样的:办公内网与云端的开发、测试环境内网是连通的,但到 K8s 的 Service 和容器网络层并未打通。

重构项目小组开始使用 Zadig 进行项目测试了,但后端研发同学找到我们提了一个需求“我想 debug 这个服务打断点”。若要实现,则必须将 K8s 内网与办公网全面打通,我们着手对网络进行改造,这样很快研发即可在自己的 IDEA IDE 随时调用、debug 自己的某一个服务。

# 全面拥抱 Zadig

全面拥抱云原生属于运维体系的进化,那么全面拥抱 Zadig 则是研发体系的进化

一个月后重构项目顺利上线,整个项目测试未与原有测试环境使用 NS 隔离,未对日常迭代和其他需求的测试环境造成任何干扰,项目部署变得非常容易,可以边调试边查看某个容器日志,对研发同学的操作体验有了质的提升,已经完全抛弃了原先使用 Kubelet 进入容器的种种麻烦。

有了这个正向的反馈,我们随即做了一个决定,将开发环境、测试环境等全面接入 Zadig。

经过 4 个月的磨合,我们将所有开发和测试环境的 K8s 集群接入了 Zadig。代码工程通过 YAML 标准模板导入即可创建部署自己需要的服务。

经过近半年的努力,我们的研发、测试、运维团队已经将所有服务全面接入 Zadig。接入 Zadig 的服务近 400个,一周部署平均近千次,较大的提升了研发效率,让研发专注代码业务实现,测试团队专注质量提升。测试或者验证过程可以在几分钟内随时拉起一套环境,供研发和测试使用,减轻了运维工作量和成本。

简单回顾了一下几个非常重要的需求细节,我们在这几个功能完善之后,将所有集群全部接入了 Zadig。

  1. 因我们属于多地域跨云部署,Zadig 默认只有一个镜像仓库,我们如果使用同一个仓库的话,不同集群的镜像拉取和推送都是通过公网进行,拉取速度受到带宽制约,且消耗流量非常多。
  2. IM 工具消息提示推送文案优化。
  3. 项目权限管理的颗粒化控制。

# 整体收益

Zadig 通过“工作流”整体串联了 K8s 的各个组件,也串联起了我们整个研发团队,极大的减轻了脚本的维护、环境治理,同时上手也非常简单高效。在项目迭代和交付中起到了极大的帮助,节约了大量的时间成本,让专业的人做“专业”的事儿,让项目研发高效并行,减少团队间的沟通 Gap,给我们的研发交付帮助极大。

总结就是简单,高效

# 期待和建议

  1. 服务镜像版本回滚,目前只有本地集群(Zadig 部署的集群)可以使用镜像版本回滚,通过 Agent 连接的集群无法做到镜像回滚。
  2. 细化权限控制的颗粒化程度,可以做到权限分组自定义或者服务自定义到用户或者用户组。
  3. 支持多种部署方式,例如 Android 原生 APP 工程的构建,我们尝试通过自定义镜像来构建,但是安卓原生依赖资源很大,镜像也很大,拉取镜像启动镜像的速度比在云主机直接构建耗时更久。
  4. 期待测试功能和 API 功能集合更加丰富,可以考虑插件方式完善 Zadig 的生态。

感谢 Zadig 团队的一直以来的帮助,在此期间我们一起探讨了很多需求,都得到了快速的响应和解决。同样期待 Zadig 可以走出国门,向海外市场进发!

© 2024 筑栈(上海)信息技术有限公司 沪 ICP 备 19000177 号 - 1