大家对 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。
大规模微服务想上 K8s？用 Zadig 实在香
- 选择 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、云主机、大体量微服务等复杂业务场景的最佳实践，为工程师一键生成自动化工作流 。
原文链接：https://my.oschina.net/koderover/blog/5275582?utm_source=tuicool&utm_medium=referral
网友评论