云原生环境下交付工具的选择

公众号:yunops


持续交付作为运维工作里极其重要的一个环节,本身就存在一些历史悠久的工具,拿 Jenkins 来说,可以通过插件实现各种各样复杂的功能;随着云原生、devops、gitops 等理念的不断普及,也涌现出不少新生力量,比如说 Gitlab CI、KubeVela、ArgoCD、云效等,在 CI 或者 CD 环节中大展身手,合理使用的情况下都能显著的提升效率;但是今天我们的主角不是上面的这些选手,而是另一个极具潜力的黑马:Zadig。


一、简介

Zadig 是一款分布式持续交付产品,由 KodeRover 公司基于 Kubernetes 自主设计研发,具有产品持续交付、持续测试、持续追踪的全流程能力,业务架构图: Zadig-Architecture 更详细的信息可以去官方文档查看,传送门

二、为什么选择 Zadig?

原来是使用 Jenkins 做的交付,结合 kustomize 也能实现基于 k8s 编排应用的丝滑交付。我们考虑其他工具的出发点一方面是:新增一个环境的话配置对应的交付任务也比较复杂;另一方面是:为了方便测试和开发同学,作为一个交付系统来说,Jenkins 是足够胜任的,但是并不能很好的展示被交付应用的运行状态、日志等,还需要其他工具或者系统去看应用运行是不是正常、查看日志等,所以考虑是否有开源的产品可以满足需求,经过一顿找找找,Zadig 凭借着出色的能力,在一众选手中杀出重围,另一个有力的竞争者是云效,云效是阿里云的 PaaS 应用,基于阿里云能力栈可完整覆盖整个应用的生命周期,简单说明一下:

结合需求和当前运维现状,权衡后选择了 Zadig。

三、落地过程

3.1 安装:

3.2 使用:

官方提供了很多案例帮助用户熟悉 Zadig 能力栈和具体配置,这里就不展开细说了,只说明一下我们在落地过程中做了哪些关键的事情

3.3 一些经验

Zadig 目前还处于快速迭代的阶段,难免存在一些功能和易用性问题,但每次更新都能显著看到改善,以下是我们遇到的一些问题,做一个分享。

  1. 本身不支持管理全局 configmap、docker-registry 等(v1.11.0 版本已经部分支持),可以将环境初始化的内容存放在一个 git 仓库里作为一个微服务用于新环境创建前的初始化;可以将其作为项目的第一个服务进行创建,供后续的其他服务使用。
  2. zadig 暂不兼容 kustomize,提供了模板库功能实现公共配置抽离和复用,缺点是只适合服务初始化使用,更新模板后需要逐个手动应用到服务(批量更新功能预计 v1.12.0 上线);
  3. K8S 项目集成 Jenkins CI 时需要 Jenkins 任务添加名为 IMAGE 的构建参数;
  4. 主机支持通过标签进行分组,但是不支持多标签;
  5. 构建配置目前不支持复用(服务和代码仓库强关联),每个服务就需要单独创建一个构建,同类服务的构建过程其实就一个代码仓库不同其他完全一致,也就是说 90%的配置工作都是多余的;相关优化功能 zadig 开发团队已经在计划中,后续版本会解决这个问题;
  6. 构建环节中仓库名中有中划线会导致<REPO>变量获取失败;
  7. gilab 集成只能使用管理员用户;
  8. 服务编排里无论什么改动都会重建 deployment 的 rs、重建 pod,一些资源对象比如 pdb、hpa 这种仍倾向于手动维护;

四、价值与展望

我们目前已经接入了多个环境的数百个前后端微服务的交付,顺利进行了数千次部署交付,Zadig 漂亮的界面(可强 Jenkins 太多了~)和易用性也得到了测试和研发同学的肯定。作为一个懒人,希望 Zadig 在配置复用上再改善一些,虽然可以自己开发脚本通过 API 实现很多重复配置的自动化,我们落地过程中就开发了脚本实现:服务、构建、用户权限分配等功能的批量管理,极大降低了配置成本;但还是希望 Zadig 能提供原生功能实现,降低大家的使用成本。