云器科技为何选择 Zadig 应对多云发布难题

企业如何轻松驾驭多云发布挑战？Zadig 给你答案㊙️

杭州云之重器科技有限公司，业界简称「云器科技」，自 2021 年成立以来，以其创新的"Single-Engine"湖仓平台引领数据架构革新，统一了数据处理流程，成为多云数据管理的先锋。

云器科技汇聚了阿里云、字节跳动、微软、Oracle 等顶尖企业的资深专家，携手推动数据使用的转型。其旗舰产品 Lakehouse，提供企业级全托管数据平台，用户注册账户即可轻松进行数据管理和分析，无需涉足复杂的后台维护。

云器 Lakehouse 搭载的先进增量计算引擎，整合了批处理、流计算与交互式分析，适配多云环境，助力企业优化数据架构，减少冗余。云器科技以此确立了其在自动化和智能化数据平台领域的领先地位。

其背后的工程效率和技术运维团队，在云原生 DevOps 实践中扮演了关键角色。本文我们采访了云器工程效率团队——郑伟，给大家分享如何通过 Zadig 平台，应对多云环境挑战，实现高效安全发布，保障业务连续性。

# 场景痛点

在我们的微服务的构建部署工程化实施过程中，原先采用的 Jenkins 逐渐显露出一些局限性，主要表现在以下几个方面：

1. 配置复杂性高

在使用 Jenkins 进行新环境的 Pipeline 配置时，我们遇到了相当复杂的设置流程。每当涉及到编译代码或构建镜像等环节的变更时，都需要对每一个 Job 进行单独的修改，这不仅增加了工作量，也增加了出错的风险。

2. 微服务项目的配置挑战

在微服务架构中，由于每个服务都需独立配置 Pipeline，这导致管理工作变得繁琐。而且，每当需要增加新的环境时，我们不得不重复复制和调整相关 Jobs，这一过程既耗时又容易出错。

随着公司业务发展，新开云厂商和 region 的增加，加剧了管理和使用的复杂性。

3. Jenkins Job 界面灵活但极易出错

Jenkins 的用户界面在处理复杂的构建流程配置时，不够直观和简洁。在执行发布操作或查看环境内服务状态、镜像 tag 时，界面操作显得不够直接，影响了工作效率。

# 选择 Zadig 的原因

当时评估选型 DevOps 平台的过程中，我们不仅考虑了 Zadig，还评估了其他备选方案。然而，Zadig 最终以其独特的优势胜出，以下是我们选择 Zadig 的主要原因：

1. 集成 Gerrit 的需求

我们代码库使用的是 Gerrit。在评估过程中，发现 ArgoCD、KubeSphere 等不支持与 Gerrit 集成，而 Zadig 已支持集成 Gerrit 的需求。

2. 云原生和国内研发优势

Zadig 是国内公司研发的云原生 DevOps 平台，提供一站式 CI/CD 解决方案。它的模板和工作流功能比 Jenkins 更加强大，且集成了飞书审批功能，支持多云环境，确保了稳定高效的交付。

3. 产品与技术团队的支持

Zadig 的产品和技术团队给予了大力的支持，我们反馈的问题都能得到及时的响应和解决。

# Zadig 解决方案

1. 强大的模板库

Zadig 提供了包括 K8S YAML、Dockerfile、构建和工作流等在内的模板库，极大提升了工程化效率。

模板的目的是为了能复用，比如前端有通用的 Dockerfile 模板，后端有通用的 Dockerfile 模板；构建模板也是相同的道理，多个不同的后端 Maven 项目，可以使用相同的构建模板（相同的编译命令 mvn clean package 和 Dockerfile），同样如果多个前端项目都是相同的编译命令和 Dockerfile，也可设计构建模板来提高工程化效率。

无论是新增服务，还是构建、Dockerfile、YAML 更新，只要修改模板就可以自动同步（对模板库操作应用到服务时，该服务配置将自动基于模板内容同步）。通过使用模板，更加方便地编排构建部署工作流，极大提升工程化效率。

2. 使用变量的灵活性

模板中的变量使得不同服务的配置差异化变得简单，全局变量的运用进一步提高了配置的复用性。

一般大多数服务都用到的变量，在同一个环境下变量值相同的使用全局变量。全局变量值，一般会跟随环境变化，只要改一次，即可应用到所有服务。

3. Go 模板语法的高效性

Go 模板语法允许根据不同的条件渲染模板，简化了 Kubernetes 配置文件的生成。

我们用到 Go 模板的几个场景：

pod 的 hostNetwork，配置 Pod 是否使用宿主机的网络和相应的 DNS 策略

spec:
  template:
    spec:
      hostAliases:
      {{- range .ip_hostnames}}
        - ip: {{ .ip }}
          hostnames: 
          {{- range .hostnames}}
            - {{ . }}
          {{- end}}
      {{- end}}

如果 .hostNetwork 被设置为真，则 Pod 使用宿主机的网络和 DNS 设置；否则，Pod 使用 Kubernetes Pod 网络和集群内的 DNS 解析。

Pod 的 hostAliases，HostAliases 定义 Pod 的 hosts 文件（/etc/hosts）里的内容。

spec:
  template:
    spec:
      hostAliases:
      {{- range .ip_hostnames}}
        - ip: {{ .ip }}
          hostnames: 
          {{- range .hostnames}}
            - {{ . }}
          {{- end}}
      {{- end}}

Go 模板语法来条件性地包含注释（annotations），用于支持个别的 CloudProvider 需要特殊的配置。

kind: Service
apiVersion: v1
metadata:
  annotations:
    {{- if .CloudProviderGCP }}
    cloud.google.com/neg: '{"ingress": true}'
    cloud.google.com/backend-config: '{"default": "{{.backend_config}}"}'
    {{- end }}

4. 工作流的高效编排

Zadig 的工作流支持多服务并行构建和部署，在一个工作流即可实现多个服务的构建、部署、测试等，提高了工作流程的管理和执行效率。

5. 发布集成飞书审批

Zadig 支持集成飞书审批流程，一定程度上增强了环境发布管控的便捷性和安全性。

# 实践成果

多云高效发布

目前我们在阿里云、腾讯云、AWS、GCP 的 10 个 region 开服，近期华为云等也即将开服。Zadig 使我们在多云环境下的发布工作变得简单高效，已成功应用于阿里云、腾讯云、AWS、GCP 等多个云服务区域。

万级构建部署

使用 Zadig 不到一年时间，执行的自动化构建和部署次数已达到 2 万次以上，显著提升了研发和部署的效率。

总之，通过引入 Zadig，我们解决了之前使用 Jenkins 时面临的配置复杂性问题，简化了用户界面操作，并通过强大的模板库和工作流功能，实现了工程化效率的显著提升。同时，Zadig 的多云支持和飞书审批集成，进一步加强了我们在多云环境下的发布管控能力。