运维人少，如何批量管理上百个微服务、上千条流水线？

管哥-运维

已于 2024-04-17 11:19:21 修改

阅读量684

点赞数 25

文章标签：运维微服务 kubernetes zadig CICD 自动化

于 2024-04-16 11:12:23 首次发布

本文链接：https://blog.csdn.net/yaodunlin/article/details/137816916

版权

随着微服务和云原生技术的发展，一个业务系统往往由多个微服务应用组成，多个业务方向涉及几十上百应用。每个应用研发过程又划分为测试、预发、生产多条流水线，也即成百上千条流水线。而一个企业下通常只有 1～2 个运维或架构师负责这些应用的配置管理工作。该场景下你是否会遇到以下苦恼：

业务应用太多啦，一个应用配置的修改就得修改几十上百遍，还有可能错改、漏改？
流水线太多啦，怎么分组管理，快速找到目标流水线？流水线怎么批量授权给一线开发测试同学？

我们来看下Zadig 以应用为中心聚合管理资源环境、CI/CD 流程、人员权限等；提供应用模板，支持使用模板一键创建应用，快速初始化应用配置；支持应用模板修改批量升级应用，帮助你高效管理上百应用、上千条流水线，帮助企业研发流程和规范有效落地。

Zadig 是由 KodeRover 公司基于 Kubernetes 研发的自助式云原生 DevOps 平台，源码 100% 开放。Zadig 提供灵活可扩展的工作流支持、多种发布策略编排以及一键安全审核等特性。该平台还支持定制的企业级 XOps 敏捷效能看板，深度集成多种企业级平台，并通过项目模板化批量快速接入，实现数千个服务的一键纳管治理。其主要目标是帮助企业实现产研的数字化转型，使工程师成为创新引擎，并为数字经济的无限价值链接提供支持

使用模版一键创建应用

通常企业一类应用研发会采用相同的技术栈，如 Web 类后端服务通常会采用 Java 开发语言、Spring boot 框架、K8s 部署形态，前端服务通常会采用 Node.js 开发语言、K8s 部署形态等。一类应用的研发流程、部署架构、环境划分、角色权限划分基本类似，可将一类应用定义为应用模板，同类应用使用模板即可快速初始化配置。

我们提供以下 2 种方式，帮助企业使用模板快速完成初始化。

【需要部署的同学请私信我价格面议】

K8s YAML 模板

背景

K8s YAML 模板适用于使用 K8s YAML 部署的项目。支持用户在通用的模板上创建服务，提供更大的可扩展性。

#新建模板

可将 K8s 资源的 YAML 配置文件抽象，在项目中创建服务时基于 K8s YAML 模板对服务进行定义。

依次访问项目-模板库-K8s YAML 进入到 K8s YAML 模板库的管理页面。

创建 K8s YAML 模板

点击+按钮 -> 输入模板名字 -> 填写模板内容 -> 保存模板。

如果模板中有使用自定义变量，需在右侧自定义变量区域将变量显示声明出来并按需配置默认值，详细信息请阅读变量列表。

创建 K8s YAML 模板

#变量列表

包括系统内置变量和自定义变量。

系统内置变量：包括 $T-Project$ 和 $T-Service$ ，可直接在 K8s YAML 模板中使用。在项目中基于模板创建服务后，二者会自动被替换为对应的项目名称和服务名称。
自定义变量：以 YAML 代码段的形式来声明，通过形如 {{.key}} 或者 Go template 的方式在模板中使用。

提示

在项目中基于模板创建服务时可修改自定义变量的默认值。
自定义变量的 key 中不支持中划线。
Go template 的使用请参考官方文档 (opens new window)。

除了支持使用常量值，还支持使用服务配置中的内置变量来为模板中的自定义变量赋值，比如下图示例中，使用 $Service$ 给 cmd 赋值。

K8s YAML 模板变量的高阶用法

切换列表视图可定义模板变量的可见性。

不可见的变量：仅可在环境中的全局变量中使用
可见的变量：可在环境中的服务变量和全局变量中使用

注意

使用模板新建的服务且开启自动同步的情况下：

服务变量可见性不可修改
服务变量可见性继承模板中变量可见性配置

#使用模板

在 K8s YAML 项目中创建服务时可选择从模板导入服务，参考使用模板新建服务。

#查看引用列表

点击 K8s YAML 模板右侧的引用列表，即可查看引用该模板的项目和服务列表。

查看 K8s YAML 模板引用列表

#应用到服务

点击应用到服务，即可使用最新的模板内容以及自定义变量更新所有开启了自动同步的服务配置。

提示

对服务开启自动同步操作参考使用模板新建服务。
当自定义变量有改动时，对服务配置的更新逻辑参考更新服务配置。

应用到服务

#示例

#K8s YAML 模板

apiVersion: apps/v1
kind: Deployment
metadata:
  name: $T-Service$
  labels:
    app.kubernetes.io/name: $T-Project$
    app.kubernetes.io/instance: $T-Service$
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: $T-Project$
      app.kubernetes.io/instance: $T-Service$
  replicas: {{.replicas_num}}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: $T-Project$
        app.kubernetes.io/instance: $T-Service$
    spec:
      containers:
        - name: $T-Service$
          image: ccr.ccs.tencentyun.com/koderover-public/$T-Service$:latest
          imagePullPolicy: Always
          env:
            - name: DOWNSTREAM_ADDR
              value: "b"
            - name: HEADERS
              value: "x-request-id"
            {{- if .skywalking}}
            - name: ENHANCE
              value: "true"
            {{- end}}
          command:
            - /workspace/{{.cmd}}
          ports:
          {{- range .ports_config}}
            - protocol: {{ .protocol }}
              containerPort: {{.container_port}}
          {{- end}}
          resources:
            limits:
              memory: {{.memory_limit}}
              cpu: {{.cpu_limit}}

#自定义变量

cmd: $Service$
cpu_limit: 50m
memory_limit: 50Mi
replicas_num: 1
skywalking: true
value: "value"
ports_config:
- protocol: TCP
  container_port: 20221
- protocol: UDP
  container_port: 21221

Dockerfile 模板

背景

Dockerfile 模板能力，支持用户将通用的镜像构建步骤包装成模板，最大程度地减少重复构建配置工作，暂不支持在主机项目中使用。

#新建模板

Dockerfile 模板在整个系统内均有效，可被应用到不同的项目中使用。

依次访问项目-模板库-Dockerfile 进入 Dockerfile 模板管理页面。

添加 Dockerfile 模板

点击+按钮后输入 Dockerfile 模板名字并在右侧填写模板内容。模板内容保存成功后，系统会自动解析出模板中使用 ARG 命令定义的变量以及变量的值。

添加 Dockerfile 模板

#使用模板

配置构建时，在添加步骤中选择镜像构建，Dockerfile 来源选择模板库并按需选择 Dockerfile 模板。

关于添加步骤中的镜像构建，更多说明请阅读镜像构建。

选择 Dockerfile 模板后，系统会自动将模板中的变量信息显示出来，也可点击右侧的预览查看模板的完整内容。
根据构建服务的实际情况，按需填写构建参数，通过 --build-arg 变量1=变量的值 --build-arg 变量2=变量的值 的方式来对模板进行赋值。

使用 Dockerfile 模板

#查看引用列表

点击 Dockerfile 模板右侧的引用列表，即可查看引用该模板用于构建镜像的项目和构建列表。

查看 Dockerfile 模板引用列表

构建模板

背景

将服务的构建配置抽取成模板，为服务创建构建时可选择基于模板创建，适用于大量服务的构建配置同构的场景。

#新建模板

依次访问项目-> 模板库 -> 构建 进入构建模板管理页面。

点击 + 按钮，填写模板名称，参考构建配置完成构建模板的配置。

模板中的代码信息部分无需配置，在使用构建模板为服务创建构建时再配置。

提示

结合使用构建变量 $REPONAME_<index> 可巧妙的完成构建模板的配置，比如服务的源代码及编译配置在 A 仓库，Dockerfile 文件在 B 仓库，构建配置中的脚本可组织如下：

#!/bin/bash
set -ex

cd $WORKSPACE/$REPONAME_0/service/
cp $WORKSPACE/$REPONAME_1/dockerfiles/$SERVICE.Dockerfile .
make build
docker build -t $IMAGE -f $SERVICE.Dockerfile .
docker push $IMAGE

创建工作流

工作流的触发

本文主要介绍 Zadig 工作流的触发，包括：手动触发、代码变更触发、定时器触发和 OpenAPI 调用触发。

#手动触发

手动触发的两个入口：

工作流列表页
工作流详情页入口

#工作流启动入口-列表页

点击列表中工作流右侧对应的执行按钮，启动工作流。

工作流启动入口-工作流详情页

点击工作流操作中的执行按钮，启动工作流。

工作流详情页

#工作流启动参数说明

从以上两个入口点击执行按钮之后，都会弹出启动工作流，如下图所示。

工作流详情页

参数说明：

环境：选择此次任务所要更新的环境。
服务：选择此次任务更新的服务组件名称，支持在一次工作流任务中更新多个服务组件。
代码选择：用户完成选择服务后，可以自由选择代码信息，Zadig 提供四种代码构建方式：
- 选择某个 Branch，系统会拉取该 Branch 的代码进行构建。
- 选择某个 Branch + pull request 构建，系统会在工作目录中将 pull request 自动合并到所选 Branch 后进行构建，支持选择多个 pull request。
- 选择 pull request，系统会拉取该 pull request 的代码进行构建，支持选择多个 pull request。
- 选择 Tag 构建，系统会拉取该 Tag 的代码进行构建。
变量：构建和测试脚本中设置的自定义变量，在启动工作流时候可以传入具体的值。

提示

若指定了多个 pull request 进行构建，请自行确保所选的 pull request 没有冲突，否则可能会因为代码冲突导致编译失败，进而导致构建失败。

#代码变更触发

在工作流中添加触发器配置后，会在对应的代码托管平台创建 Webhook。当出现满足触发条件的代码变更时，会自动触发运行工作流。目前支持以下 3 个代码托管平台：

GitHub：在工作流中配置触发器后，会自动在 GitHub 平台创建 Webhook。
GitLab：在工作流中配置触发器后，会自动在 GitLab 平台创建 Webhook。
Gerrit：需要先在 Gerrit 上安装 Webhook 插件支持，再在工作流中配置触发器。具体安装可参考链接 (opens new window)，插件安装成功后效果图示如下：

工作流触发器配置

为工作流配置触发器包括 GUI 方式和YAML 配置文件方式，下面展开介绍。

#GUI 方式

在工作流界面中实现触发器的配置，配置过程更直观，可指定代码变更分支（一个分支或通过正则表达式匹配多个分支）、触发事件等。具体配置请参考 GUI 方式配置触发器。

工作流触发器配置

#YAML 配置文件方式

将触发器配置组织在代码库的 YAML 文件中，在 YAML 文件中设置相关触发条件和工作流执行策略，在 Zadig 工作流触发器配置中填写 YAML 文件的路径即可。具体配置请参考 YAML 配置文件方式配置触发器。

工作流触发器配置

#触发效果

配置完成后，根据配置提交 pull request、merge request 或者 push 可触发工作流，以 GitLab 为例，在 merge request 中可以查看工作流的反馈信息，如下所示。

代码变更工作流信息反馈

#进阶使用场景：Pull request 独立测试环境

注意

Pull request 独立测试环境验证功能目前仅支持 GitLab 代码仓库触发

通过工作流触发器中配置基准环境和环境销毁策略实现 pull request 独立测试环境的持续交付过程，完成一段代码的全生命周期质量验证。

Pull request 级持续交付分为以下步骤：

提交更新的 pull request 代码
根据选择的基准环境生成一个相同服务版本的临时环境
执行工作流更新该测试环境中的服务版本，以及针对该集成环境进行相关自动化测试验证
根据环境销毁策略对测试环境进行回收操作

具体配置如下图所示：

workflow

提交代码变更，在对应 pull request 下可看到关于独立环境的状态信息：

workflow

创建的独立环境效果如下：

workflow

#定时器触发

可以通过工作流的定时器功能来实现工作流的定时触发。具体配置请参阅定时器。

#OpenAPI 调用触发

通过 OpenAPI 接口调用来触发工作流，具体操作请参阅执行工作流。

环境的负载均衡

本文主要介绍 Zadig 环境的负载均衡能力。在高峰使用时间段，代码变更触发工作流执行服务更新会因为环境资源的限制，导致工作流任务长时间的等待，大大影响交付效率，Zadig 的环境负载均衡能力可以缓解并发工作流任务使用环境资源的压力。

环境负载均衡

经过简单配置，减少代码变更触发的工作流任务排队数量，实现资源的最大化利用。配置步骤如下：

配置多套环境
配置工作流 Webhook 触发器
开启工作流并发

#第 1 步：配置多套环境

Zadig 系统支持使用一套服务配置，创建多套同构的环境，详细配置过程参考配置多套环境

#第 2 步：配置工作流 Webhook 触发器

准备好多套环境后，配置工作流的触发器，如下图所示。

webhook配置

说明：

部署环境：选择多套用于部署的环境
环境更新策略：选择动态选择空闲环境更新
完成其他的 Webhook 基本配置项

至此，我们已经配置完成，下面我们看看最终执行效果。

#第 3 步：开启工作流并发

同一工作流的多个任务，默认是串行执行，为了减少任务排队时间，需开启工作流的并发执行能力。

配置方式：修改工作流 -> 运行策略 -> 选择并发运行。

开启工作流并发运行

#执行效果

同时提交两个 pull request，触发两个工作流任务，这两个任务会将服务部署到相对空闲的环境中，在工作流并发数允许的情况下，这两个任务将被并发执行以提高交付效率。

env_loadbalance_result

详细问题请看官方文档：什么是 Zadig | Zadig 文档

管哥-运维

关注

25
点赞
踩
19

收藏

觉得还不错? 一键收藏
0
评论
运维人少，如何批量管理上百个微服务、上千条流水线？

随着微服务和云原生技术的发展，一个业务系统往往由多个微服务应用组成，多个业务方向涉及几十上百应用。每个应用研发过程又划分为测试、预发、生产多条流水线，也即成百上千条流水线。而一个企业下通常只有 1～2 个运维或架构师负责这些应用的配置管理工作。该场景下你是否会遇到以下苦恼：我们来看下Zadig 以应用为中心聚合管理资源环境、CI/CD 流程、人员权限等；提供应用模板，支持使用模板一键创建应用，快速初始化应用配置；支持应用模板修改批量升级应用，帮助你高效管理上百应用、上千条流水线，帮助企业研发流程和规范有效
复制链接

扫一扫