云原生环境下交付工具的选择
持续交付作为运维工作里极其重要的一个环节,本身就存在一些历史悠久的工具,拿 Jenkins 来说,可以通过插件实现各种各样复杂的功能;随着云原生、devops、gitops 等理念的不断普及,也涌现出不少新生力量,比如说 Gitlab CI、KubeVela、ArgoCD、云效等,在 CI 或者 CD 环节中大展身手,合理使用的情况下都能显著的提升效率;但是今天我们的主角不是上面的这些选手,而是另一个极具潜力的黑马:Zadig。
一、简介
Zadig 是一款分布式持续交付产品,由 KodeRover 公司基于 Kubernetes 自主设计研发,具有产品持续交付、持续测试、持续追踪的全流程能力,业务架构图: 更详细的信息可以去官方文档查看,传送门
二、为什么选择 Zadig?
原来是使用 Jenkins 做的交付,结合 kustomize 也能实现基于 k8s 编排应用的丝滑交付。我们考虑其他工具的出发点一方面是:新增一个环境的话配置对应的交付任务也比较复杂;另一方面是:为了方便测试和开发同学,作为一个交付系统来说,Jenkins 是足够胜任的,但是并不能很好的展示被交付应用的运行状态、日志等,还需要其他工具或者系统去看应用运行是不是正常、查看日志等,所以考虑是否有开源的产品可以满足需求,经过一顿找找找,Zadig 凭借着出色的能力,在一众选手中杀出重围,另一个有力的竞争者是云效,云效是阿里云的 PaaS 应用,基于阿里云能力栈可完整覆盖整个应用的生命周期,简单说明一下:
-
zadig 核心优势:并发工作流(云效并发任务大于 6 的话需额外购买)、更灵活&维护成本更低(构建与部署过程可高度个性化定制,公共配置可复用)、100%开源(私有化部署,不强耦合指定云厂商);
-
云效核心优势:产品线更全(覆盖应用全生命周期)、功能开箱即用、更完善的发布策略(分批发布、灰度发布、蓝绿发布,且发布过程可控);
结合需求和当前运维现状,权衡后选择了 Zadig。
三、落地过程
3.1 安装:
- Zadig 提供云上测试环境(非常 Nice):https://os.koderover.com/
- 官方提供完善的安装文档,并且有微信群进行全方位技术支持 👍👍👍,这里只提一下推荐使用外部高可用的数据库、存储来提高部署安全性。
3.2 使用:
官方提供了很多案例帮助用户熟悉 Zadig 能力栈和具体配置,这里就不展开细说了,只说明一下我们在落地过程中做了哪些关键的事情
- 外部系统集成:ldap(用户管理)、gitlab(代码管理)、oss(保存缓存文件)、镜像仓库(保存镜像制品);
- 项目初始化流程:项目 —> 服务—> 环境 —> 构建—> 工作流交付。
3.3 一些经验
Zadig 目前还处于快速迭代的阶段,难免存在一些功能和易用性问题,但每次更新都能显著看到改善,以下是我们遇到的一些问题,做一个分享。
- 在 v1.10.0 版本中,可能存在以下问题:
- 本身不支持管理全局 configmap、docker-registry 等(v1.11.0 版本已经部分支持),可以将环境初始化的内容存放在一个 git 仓库里作为一个微服务用于新环境创建前的初始化;可以将其作为项目的第一个服务进行创建,供后续的其他服务使用。
- zadig 暂不兼容 kustomize,提供了模板库功能实现公共配置抽离和复用,缺点是只适合服务初始化使用,更新模板后需要逐个手动应用到服务(批量更新功能预计 v1.12.0 上线);
- K8S 项目集成 Jenkins CI 时需要 Jenkins 任务添加名为 IMAGE 的构建参数;
- 主机支持通过标签进行分组,但是不支持多标签;
- 构建配置目前不支持复用(服务和代码仓库强关联),每个服务就需要单独创建一个构建,同类服务的构建过程其实就一个代码仓库不同其他完全一致,也就是说 90%的配置工作都是多余的;相关优化功能 zadig 开发团队已经在计划中,后续版本会解决这个问题;
- 构建环节中仓库名中有中划线会导致<REPO>变量获取失败;
- gilab 集成只能使用管理员用户;
- 服务编排里无论什么改动都会重建 deployment 的 rs、重建 pod,一些资源对象比如 pdb、hpa 这种仍倾向于手动维护;
四、价值与展望
我们目前已经接入了多个环境的数百个前后端微服务的交付,顺利进行了数千次部署交付,Zadig 漂亮的界面(可强 Jenkins 太多了~)和易用性也得到了测试和研发同学的肯定。作为一个懒人,希望 Zadig 在配置复用上再改善一些,虽然可以自己开发脚本通过 API 实现很多重复配置的自动化,我们落地过程中就开发了脚本实现:服务、构建、用户权限分配等功能的批量管理,极大降低了配置成本;但还是希望 Zadig 能提供原生功能实现,降低大家的使用成本。