大规模微服务想上 K8s？用 Zadig 实在香！
编者按：本文来自微信公众号“KodeRover”（ID:KodeRover），作者：Zadig，36氪经授权发布。
大家对 CI/CD 的概念并不陌生，但真实世界的 CI/CD 绝不是一段代码做「构建->部署->发布」那么简单，大部分情况下一个产品是由若干个微服务组成的，而微服务之间互相有依赖，不同角色基于不同测试环境进行协作。这里给大家介绍一个典型的微服务架构项目，如何用 Zadig实现全流程自动化、持续交付。该项目包含 Python, Redis, Postgres, Node.js, and .Net 等前后端、数据库、中间件、相对典型的微服务应用程序组合。
准备工作
本案例所用代码及配置 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！和众多开发者一起探讨、交流，共建开源社区！
