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

本文主要是介绍运维人少，如何批量管理上百个微服务、上千条流水线？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

随着微服务和云原生技术的发展，一个业务系统往往由多个微服务应用组成，多个业务方向涉及几十上百应用。每个应用研发过程又划分为测试、预发、生产多条流水线，也即成百上千条流水线。而一个企业下通常只有 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$:latestimagePullPolicy: Alwaysenv:- name: DOWNSTREAM_ADDRvalue: "b"- name: HEADERSvalue: "x-request-id"{{- if .skywalking}}- name: ENHANCEvalue: "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: TCPcontainer_port: 20221
- protocol: UDPcontainer_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 -excd $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)，插件安装成功后效果图示如下：

工作流触发器配置