使用 Zadig 持续交付 Spring Boot 项目到 Kubernetes
Zadig on Github / Zadig on Gitee
Spring Boot 是构建 Java 后端应用程序的一种非常流行的框架，被企业和开发者广泛采用。本文介绍如何使用 Zadig 持续交付 Spring Boot 项目到 Kubernetes 上，该项目主要包含 Maven 构建的 Worker 、DB(Postgres) 以及 Redis 这三个服务，以下步骤包含从 Code 到 Ship 的整个过程的演示。
准备工作
-
项目案例中用到的 worker 服务源代码、YAML 文件、Dockerfile 文件，可以在 GitHub Zadig 仓库 examples/voting-app 项目中找到
-
建议把源码放到自己的 GitHub 代码仓库后再进行下面的操作
项目配置
-
创建项目，具体内容如下图所示：
-
接下来会看到创建成功的提示：
创建服务
-
创建服务
创建服务有两种方式，第一种是选择平台编辑直接把 YAML 内容粘到系统中。第二种是选择从仓库导入 YAML 文件，示例中采用第二种。
-
-
点击仓库托管，在弹出的窗口中选择代码仓库，同步 examples->voting-app->freestyle-k8s-specifications->worker 文件目录，加载 worker 服务 YAML 配置文件。
-
系统会自动检测 YAML 格式是否合法，右侧会自动解析出来系统变量、自定义变量和服务组件，这里也可以继续添加自定义变量。具体过程如下图所示：
![]()
-
-
创建构建
-
这里可以选择 worker-e2e 这个服务组件添加构建，然后选择代码库和添加构建脚本，具体如下图所示：
![]()
-
构建脚本如下
-
cd $WORKSPACE/zadig/examples/voting-app/workerdocker build -t $IMAGE -f Dockerfile.j .docker push $IMAGE
添加完成后，点击保存构建。然后点击仓库托管，继续添加 DB(Postgres) 和 Redis 服务，如下图所示：
实际场景中已存在现有可用的中间件服务，在网络联通情况下可以直接使用；若同一中间件服务针对不同环境需要使用不同的服务地址，可以通过设置环境变量的方式配置
- 添加成功后，点击下一步，完成服务配置。
加入运行环境
-
进入「加入运行环境」，系统会自动创建两套集成环境和三条工作流，两套集成环境可分别给开发和测试使用，三条工作流也会自动绑定对应的集成环境以达到持续交付的目的。具体如下图所示：
工作流交付
-
点击运行工作流 voting-app-workflow-dev 对 worker 服务进行更新，来实现 dev 环境的持续交付
-
qa 环境的持续交付类似的操作，不赘述。
到此，您已熟悉 Zadig 的基本功能了，下面将展示如何配置自动触发工作流。
配置自动触发工作流
-
创建基于 GitHub 事件的触发器，修改 voting-app-workflow-dev 工作流，为 dev 环境设置 GitHub 事件触发器，系统目前支持 push 和 pull_request 两种事件，具体如下图所示：
前提条件：需要配置 GitHub Webhook，全局 Webhook 请参考 GitHub Webhook
-
提交 代码库 PR，在 Check runs 中会展示具体的系统工作流的状态，具体如下图所示：
-
点击任务链接可以跳转到 Zadig 系统里查看工作流具体执行信息，如下图所示：
-
待工作流执行完毕，可看到 dev 环境 worker 服务的镜像已经被更新了，具体如下图所示：
通过以上步骤，我们已经完成了部署在 Kubernetes 上的 Spring Boot 项目持续交付配置，通过接入 Zadig 开发者可以方便的对服务进行查看、管理和更新，比如服务查看、Pod Debug、实时日志等。
