Zadig on Github / Zadig on Gitee

阅读原文 / 加入 Zadig 技术交流群

大家对 CI/CD 的概念并不陌生，但真实世界的 CI/CD 绝不是一段代码做「构建->部署->发布」那么简单，大部分情况下一个产品是由若干个微服务组成的，而微服务之间互相有依赖，不同角色基于不同测试环境进行协作。这里给大家介绍一个典型的微服务架构项目，如何用 Zadig  实现全流程自动化、持续交付。该项目包含 Python, Redis, Postgres, Node.js, and .Net 等前后端、数据库、中间件、相对典型的微服务应用程序组合。

大家对 CI/CD 的概念并不陌生，但真实世界的 CI/CD 绝不是一段代码做「构建->部署->发布」那么简单，大部分情况下一个产品是由若干个微服务组成的，而微服务之间互相有依赖，不

 

   准备工作

本案例所用代码及配置 fork 自 GitHub Zadig 仓库，主要包括：

• 案例中 5 个服务的 Kubernetes YAML 配置：YAML

• 案例中 3 个业务服务的 Dockerfile 文件：result、vote、worker

接入 GitHub 代码源

第一步：新建 GitHub OAuth 应用程序

• 个人账号下的代码库接入：可以通过点击用户名 -> Settings -> Developer settings -> OAuth Apps 来新建应用程序。

• GitHub Organization 下的代码仓库接入：可以通过点击 Organization Settings -> Developer settings -> OAuth Apps 来新建应用程序。

 下面以 GitHub Organization 为例，如下所示。

• 打开 Organization Settings。

• 选择 Developer settings -> OAuth Apps，点击 New OAuth App 新建应用程序。

 

第二步：配置 GitHub OAuth 应用程序

在

新建应用程序页面，你需要进行如下步骤：

• Application name：zadig，也可以填写可识别的任一名称

• Homepage URL：http://[koderover.yours.com]

• Authorization callback URL：http://[koderover.yours.com]/api/directory/codehosts/callback

• 点击注册

 

第三步：获取 Client ID、Client Secret 信息

应用创建成功后，GitHub 会返回应用的基本信息，点击 Generate a new client secret 生成 Client Secret。

• 此时页面包括完整的 Client ID 、Client Secret。

 

第四步：将 Client ID、Client Secret 集成到系统

切换到 Zadig 系统，管理员依次点击系统设置 -> 集成管理 -> 代码源集成 -> 点击添加按钮。

依次填入如下已知信息：

• 代码源：此处选择 GitHub

• Client ID：应用的 Client ID

• Client Secret：应用生成的 Client Secret

• Organization：GitHub 要授权的 Organization 名称或者个人 GitHub Username

信息确认无误后点击、前往授权，耐心等待，此时系统会跳转到 GitHub 进行授权。

点击授权按钮，同意授权后，GitHub 会跳转到 Zadig 系统，至此 GitHub 集成完毕。

 

产品交付

第一步：项目配置

进入 Zadig 系统，新建项目 voting。

进

 

第二步：创建服务与服务构建

这里我们需要为以下 5 个服务添加服务配置：

• vote

• worker

• result

• redis

• db

并为以下三个业务服务添加构建以支持持续交付：

• vote

• worker

• result

注：服务配置指的是 YAML 对这个服务的定义。Kubernetes 可以根据这个定义产生出服务实例。可以理解为 Service as Code 。

 

Zadig 提供两种方式管理这些模板：

• 系统平台管理：在 Zadig 中直接输入 YAML 。

• 代码仓导入与同步：从某个代码仓库中导入，之后提交到代码仓的 YAML 变更会被自动同步到 Zadig 系统上。

这里，我们使用代码仓导入的方式。案例所需 YAML 配置位于  koderover/zadig 仓库 freestyle-k8s-specifications 文件目录中，现在要做的就是把它们导入。

• 加载服务配置：点击仓库托管 按钮 -> 选择仓库信息 -> 选择文件目录。Zadig 支持一次性导入多个服务，同步 examples -> voting-app -> freestyle-k8s-specifications 文件目录可导入此次案例中所需的 5 个服务。

• 配置服务构建：选择服务 -> 点击添加构建 -> 填写构建脚本。

以 result 服务为例，在构建脚本中填写以下代码：

cd $WORKSPACE/voting-app/<service-directory>docker build -t $IMAGE -f Dockerfile .docker push $IMAGE

重复以上配置服务构建过程，完成 vote 、 result  和  worker 的构建配置，注意根据不同的服务修改脚本中的 <service-directory> 参数。

第三步：加入运行环境

• 点击向导的“下一步”。这时，Zadig 会根据你的配置，创建两套环境（dev，qa），以及相关工作流。

• 点击下一步完成向导。至此，onboarding 完成。一个有 5 个微服务的系统，2 套环境、3 条工作流已经产生。

 

第四步：工作流交付

• 点击运行触发工作流启动。

• 选择需要更新的服务，比如 vote 和 result，点击「启动任务」运行工作流。

 

• 查看工作流运行状况：

• 下面是项目的总体状态：

 

• 进入集成环境，查看服务列表并点击 result 和 vote暴露出来的 URL 可以查看网站。

 

vote 页面：

 

result 页面：

 

第五步：配置自动触发工作流

添加触发器，使得代码 Push 或者 Pull Request 都触发 result，vote，worker 三个服务的重新构建和部署：

• 进入工作流配置页面

• 添加 Webhook 触发器

 

• 配置 Webhook 触发器

 

• 保存工作流

 

第六步：代码改动持续交付

• 提交 GitHub PR 修改源代码，交换 vote 服务中 CATS 和 DOGS 的背景颜色。

• 进入 项目->voting->工作流->voting-workflow-dev 查看工作流，可以看到 PR 变更已自动触发工作流执行：

• 待 voting-workflow-dev 工作流执行完毕，进入 项目->voting->集成环境，点击 dev 环境中 vote 服务的服务入口，查看网站结果，可以看见 CATS 和 DOGS 背景栏颜色已被更改。

                      

关于 Zadig

Zadig 是基于 Kubernetes 设计、研发的开源分布式持续交付 (Continuous Delivery) 产品，为开发者提供云原生运行环境，支持开发者本地联调、微服务并行构建和部署、集成测试等。Zadig 内置了面向 Kubernetes、Helm、云主机、大体量微服务等复杂业务场景的最佳实践，为工程师一键生成自动化工作流 。

欢迎大家 Star、Fork、 Watch！和众多开发者一起探讨、交流，共建开源社区！

 

Zadig on Github / Zadig on Gitee

阅读原文 / 加入 Zadig 技术交流群