使用 Spinnaker 自动化部署代码到 Kubernetes 示例

目录

1、示例说明

通过 初试 Netflix 开源持续云交付平台 Spinnaker 和 初试 Kubernetes 集群中 Spinnaker 平台之集群管理 两篇文章的介绍，我们初步了解 Spinnaker 的集群管理和部署功能两大核心功能，但是都是单独演示，没有将两者有机结合起来，今天，我们来通过一个示例来演示如何通过 Spinnaker 结合外部平台完成整个流程的自动化构建以及自动化部署到 Kubernetes 集群中。下边，我针对该示例做一些必要的说明。

该示例是参照 Spinnaker 官网示例 Kubernetes Source To Prod，其流程主要包括以下几个步骤：

1. 开发人员推送新的 branch | tag 到 GitHub 代码仓库中，触发 GitHub Webhooks 对应配置的 DockerHub 自动构建一个针对该 branch | tag 的镜像。
2. Spinnaker 监听到 DockerHub 新的镜像生成，自动执行部署该镜像到一个新的 Dev 环境的Kubernetes 集群中，并且销毁该 Dev 环境中老版本的复制集。
3. 外部验证 Dev 环境该实例部署是否正常，并在 Spinnaker 流程中确认结果。
4. 如果验证通过，则 Spinnaker 重新部署该镜像到新的 Prod 环境中，并且使 Prod 环境中老版本实例失效。

示例整体流程如下图所示：

2、环境、软件准备

本次演示环境，我是在本机 MAC OS 上操作，Kubernetes 集群使用 Minikube 安装到 VirtualBox 虚拟机上，以下是安装的软件及版本：

• Git: version 2.10.1
• Docker: version 17.09.0-ce
• Oracle VirtualBox: version 5.1.20 r114628 (Qt5.6.2)
• Minikube: version v0.22.2
• Helm: version v2.8.0
• Kuberctl:
  
  • Client Version: v1.8.1
  • Server Version: v1.7.5

注意：这里 Spinnaker 安装过程，我就不在详细描述了，具体步骤参考 初试 Kubernetes 集群中使用 Helm 搭建 Spinnaker 平台 即可，写的很详细，本次主要通过一个 Demo 示例介绍如何通过 Spinnaker 结合外部平台完成整个流程的自动化构建以及自动化部署到 Kubernetes 集群的操作过程。

3、相关配置

要完成本次示例，我们需要完成以下几个配置：

• GitHub 代码仓库，包含我们要部署的代码。
• DockerHub 镜像仓库，需要配置与 GitHub 仓库 Webhook 关联，并自动触发 Build 操作。
• 运行中的 Kubernetes 集群，这里我使用 Minikube 安装到本地虚拟机上。
• 运行中的 Spinnaker 平台，这里我已经使用 Helm 安装到本机中。

3.1、GitHub 配置

首先我们需要有一个 GitHub 代码仓库，如果没有的话，可以去 GitHub 官网 注册一个账号，示例 Demo 代码可以 Fork 这里。Fork 完成之后，需要配置该仓库的 Webhook 来自动触发 DockerHub Automated Build 功能配置，当有 Push 操作时，自动监听触发构建镜像。

点击 spin-kub-demo 项目 “Settings” —> “Integrations & services” —> “Services” 栏右侧 —> “Add Service” —> 下拉框 “Available Services” 中选择 “Docker” 项，显示页面中点击 “Add Service” 即可完成配置，配置完成后如下图所示。

3.2、DockerHub 配置

其次我们需要一个 DockerHub 镜像仓库，如果没有的话，可以去 DockerHub 官网 注册一个账号，然后配置 “Create Automated Build”，使其能够自动关联 GitHub 获取代码变更并且自动创建 Docker Image，配置完毕后，类似我的 DockerHub spin-kub-demo 项目一样，具体如何配置可参考 DockerHub Build 官网文档。

上图，我这里配置了 Type 为 Branch，Name 为 /.*/，Docker Tag Name 为空 (跟 Branch 一样)，意味着，当我们在 GitHub 上针对某个分支进行 push 操作时，会自动触发 DockerHub Build，构建出版本为 Branch Name 一致版本号的镜像，例如针对分支 v.0.0.6 自动构建完成后的镜像名称为 huwanyang168/spin-kub-demo:v.0.0.6。注意：这里一定要配置正确，可先行实验一下，否则无法继续后续 Spinnaker 操作。

3.3、Kubernetes & Spinnaker 配置

这里参照 初试 Kubernetes 集群中使用 Helm 搭建 Spinnaker 平台 文章，本地搭建一下 Spinnaker 平台，要确保 Kubernetes 集群和 Spinnaker 平台各个服务可以正常运行。

4、Spinnaker 集群管理（Cluster）

4.1、创建应用（Application）

浏览器访问 http://127.0.0.1:9000 进入 Spinnaker UI 页面，点击导航栏 “Applications” 进入应用列表页面，点击页面右上角 “Actions” —> “Create Application” 创建一个应用。

在创建应用弹框页面，填写 Name、Owner Email 等信息，这里我填写 demo 作为应用名称，点击 “Create” 按钮完成应用的创建。

4.2、创建负载均衡策略（Load Balancer）

demo 应用创建完毕，接下来我们先创建一个 Dev Load Balancer 负载均衡策略，先进行 Dev 环境的部署。进入该应用详情页面，点击顶部导航栏 “LOAD BALANCERS”，进入负载均衡列表页面，默认是没有任何记录的。

点击页面 “Create Load Balancer” 按钮，在创建负载均衡弹框页面填写信息，点击 “Create” 完成负载均衡策略的创建。这里 “Stack” 处填 dev，可以理解为作为测试环境使用标示，在 “Ports” 栏下边 “Target Port” 处填 8000，作为对外转发目标端口。“Advanced Settings” 栏下边 “Type” 处选择 ClusterIP，这里可选项有 ClusterIP、LoadBalancer、NodeType，针对不同的应用类型和平台，选择所支持的类型，这里我选择默认值 ClusterIP。

Dev Load Balancer 创建完毕后，接下来我们创建一下 Prod Load Balancer 用来进行 Prod 环境的部署。创建过程同上操作，主要修改 “Stack” 为 prod，并且在 “Advanced Settings” 栏下边 “Type” 处选择 NodeType，其他保持一致。

创建完毕后 Load Balancers 页面如下所示：

4.3、创建服务组（Server Group）

demo 应用的 Load Balancers 创建完毕，接下来我们创建一个 Dev Service Group 服务组，点击导航栏 “CLUSTERS”，进入集群列表页面，默认也是没有任何记录的。点击 “Create Service Group” 按钮，在创建服务组弹框页面填写信息，点击 “Create” 完成服务组的创建。这里 “Stack” 处依填 dev，“Containers” 处填写容器 Docker 镜像地址，这里我们直接使用上边配置的个人 DockerHub 仓库镜像，Spinnaker 会自动拉取所有版本镜像列表供选择，这里我选择 index.docker.io/huwanyang168/spin-kub-demo:v.0.0.6 作为测试镜像。“Load Balancers” 处选择上边创建的 demo-dev 负载均衡策略。“Replicas” 栏下方 “Capacity” 处填 1，意味着该服务组将启动 1 个由该容器镜像启动的 Pod 实例。“Port” 栏 “Container Port” 处填写为 8000，保持跟 Load Balancers Target 端口一致，“Container” 栏下方 “name” 修改为 demo。点击 “Probes” 栏，点击 “Enable Readiness Probe” 按钮来添加探测，修改 “Port” 为 8000，这里 “Readiness Probe” 为服务是否准备就绪的探测。

注意：这里如果在 Containers 栏下拉选择 image 时没有自己项目的镜像列表，只有 library 的话，需要修改 values.yaml 配置自己的 DockerHub 仓库，当然也可以使用其他私有仓库配置。

$ vim values.yaml
...
# Configure your Docker registries here
accounts:
- name: dockerhub
  address: https://index.docker.io
  repositories:
#    - library/alpine
#    - library/ubuntu
#    - library/centos
#    - library/nginx
    - huwanyang168/spin-kub-demo
    - huwanyang168/tiller
# - name: gcr
#   address: https://gcr.io
#   username: _json_key
#   password: ''
#   email: [email protected]

demo-dev 服务组创建完毕，会自动拉取镜像并启动服务，成功后页面如下图所示。

现在测试环境已经成功启动了 demo-dev 服务了，接下来我们来测试一下该服务是否能够正常访问吧！在终端使用命令 $ kubectl proxy 启动一个代理，通过该代理转发，可以将 Kubernetes API 认证使用本地 ~./kube/config 认证证书，然后通过浏览器访问 http://127.0.0.1:8001/api/v1/proxy/namespaces/default/services/demo-dev:80/ 即可。

5、Spinnaker 部署管理（Pipeline）

上边我们已经创建了关联 dev Loadbalancer 的 demo-dev Server Group，而且能够正常运行，接下来，就要创建流程 Pipeline，来完成整个自动化构建和部署流程。

5.1、创建自动部署 Dev 流程

点击 Demo 应用页的导航栏 “PIPELINES”，点击页面右上角 “Create” 按钮，弹框中 “Type” 选择 Pipeline，“Pipeline Name” 处填写 Deploy to Dev，点击 “Create” 按钮完成创建。

进入到 Deploy to Dev 流程设置页面，在 “Automated Triggers” 栏下点击 “Add Trigger”，“Type” 栏选择 Docker Registry，“Registry Name” 栏会加载 values.yaml 文件中仓库配置的账户名称，这里我选择 dockerhub，“Organization” 栏会加载选择的 Registry 下配置的所属组织列表，这里我选择自己的账户 huwanyang168，“Image” 栏选择要触发的镜像，这里我选择 huwanyang168/spin-kube-demo 镜像，“Tag” 栏这里不填，意思就是匹配任何新的 Tag。以上配置的作用就是，当我们的 DockerHub 仓库中 huwanyang168/spin-kube-demo 有新的镜像生成时，会自动触发该流程启动。

接下来点击 “Add Stage” 按钮，增加一个节点，该节点执行部署镜像到 Dev 环境。“Type” 栏选择 Deploy，“Stage Name” 栏填写 Deploy to Dev，如下图所示。

“Deploy Configuration” 栏下点击 “Add Server Group” 在弹框中 “Copy configuration from” 可以选择之前我们创建的服务组 demo-dev，点击 “Use This Template” 按钮，进入到配置部署集群弹框页面。

配置部署集群弹框页面跟之前创建的服务组 demo-dev 一样，不过有一个地方需要修改一下，在 “Container” 栏下边 “Image” 选择 Image from Trigger(s) 这一项，意思是跟 “Automated Triggers” 那里镜像保持一致，页面其他配置保持不变。

最后，添加一个节点，目的是为了销毁之前的 demo-dev 服务组（还记得上边已经启动的 demo-dev 服务组了吧）。点击 “Add Stage” 按钮，“Type” 栏选择 Destory Server Group，“Destroy Server Group Configuration” 栏下 “Namespaces” 选择 default，“Cluster” 选择 demo-dev，“Target” 选择 Previous Server Group。解释一下，我们要选择 default Namespaces，因为之前的 demo-dev 服务组就是使用的 default 命名空间，如果我们不太清楚选择哪个，可以点击下方 “Toggle for list of existing clusters” 链接，就会过滤掉其他 Namespaces。Target 处一定要选择 Previous Server Group，意思是销毁掉之前的服务组，这里别选错了。

5.2、创建验证流程

接下来，我们创建一个新的流程，为了验证 Deploy to Dev 流程是否部署成功。点击 “Create” 按钮，弹框中 “Pipeline Name” 栏填 Verity Deploy-Dev，进入到 Verity Deploy-Dev 流程设置页面，在 “Automated Triggers” 栏下点击 “Add Trigger”，“Type” 栏选择 Pipeline，“Pipeline” 栏选择 Deploy to Dev 流程，“Pipeline Status” 栏勾选 successful，意思是当 Deploy to Dev 流程成功执行后，将自动触发该流程。

然后添加一个节点，目的是让流程暂停，等待人工验证本次部署实例是否成功。点击 “Add Stage” 按钮，“Type” 栏选择 Manual Judgment，“Instructions” 栏输入 Manual Judgment Verity if “demo-dev” server run ok 对该流程做一下简要的说明信息（支持 Html 的哈）。

当然，这里只是简单的做一下人工验证，服务是否正常运行，也可以更复杂一些，配置 Kubernetes job 或者测试平台来验证服务是否正常，方式有很多种，根据实际需求来合理配置即可。

5.3、创建自动部署 Prod 流程

接下来，我们继续创建一个新的流程，目的是当 Verity Deploy-Dev 流程人工验证通过后，执行自动化部署到 Prod 环境中去。点击 “Create” 按钮，弹框中 “Pipeline Name” 栏填 Deploy to Prod，进入到 Deploy to Prod 流程设置页面，在 “Automated Triggers” 栏下点击 “Add Trigger”，“Type” 栏选择 Pipeline，“Pipeline” 栏选择 Verity Deploy-Dev 流程，“Pipeline Status” 栏勾选 successful，意思是当 Verity Deploy-Dev 流程成功执行后，将自动触发该流程。

然后添加一个新节点，目的是从集群中找到最新的镜像，为什么要加这个节点呢？ 因为既然是自动化部署，dev 环境 Image 已经测试完毕，那么就不需要再指定部署哪一个镜像了，直接从集群中查找最新的哪个镜像就是本次要部署的镜像了。点击 “Add Stage” 按钮，“Type” 栏选择 Find Image from Cluster，“Find Image from Cluster Configuration” 栏下 “Namespace” 选择 default，“Cluster” 栏选择镜像所在集群 demo-dev，“Server Group Selection” 栏选择 Newest，表示最新的服务组。“Image Name Pattern” 栏填 .*，这里说明一下，此处用来过滤镜像名称匹配，当单个 Pod 中部署多个不同镜像时使用，这里我们只有一个镜像，所以可以使用 .* 匹配所有。

接着我们添加一个节点，目的是将查找到的镜像部署到 Prod 环境中去。点击 “Add Stage” 按钮，“Type” 栏选择 Deploy，“Stage Name” 栏输入 Deploy to Prod，“Deploy Configuration” 栏下点击 “Add Server Group” 按钮，弹出选择服务组对话框。

在选择服务组模板对话框页面，“Copy configuration from” 可以选择之前我们创建的服务组 demo-dev-v000，点击 “Use This Template” 按钮，进入到配置部署集群弹框页面。注意：这里先拿 demo-dev 作为模板，进入配置详情页面后，我们会修改其中某些配置，这样方便一些，当然也可以提前建好 demo-prod 服务组。

配置部署集群弹框页面跟之前创建的服务组 demo-dev 一样，不过这次要修改三个地方，第一个地方 “Stack” 栏修改为 prod；第二个地方 “Load Balancers” 栏删除原 demo-dev 并选择 demo-prod；第三个地方 “Container” 栏下边 “Image” 选择 Find Image Result(s) demo-dev.* 这一项，意思是跟上一节点中查找 Image 结果保持一致，页面其他配置保持不变。

最后我们添加一个节点，目的是当新的部署完成后，Prod 环境中老版本的该实例将废弃掉不再接入流量。点击 “Add Stage” 按钮，“Type” 栏选择 Disable Cluster，“Disable Cluster Configuration” 栏下 “Namespaces” 处继续选择 default，“Cluster” 处填写 demo-prod，注意：这里没法使用点击 “Toggle for list of existing clusters” 链接方式过滤 namespace，因为暂时只有 demo-dev 集群运行中，demo-prod 服务组还未创建，没法选择，这里只能手动填写。

5.4、运行并验证流程

上边在 Spinnaker 依次创建了 Deploy to Dev、Verity Deploy-Dev、Deploy to Prod 三个流程，创建完毕后如下图所示。

接下来，要开始运行并验证该流程是否正常运行了。那么如何开始自动化运行该流程呢？其实很简单，就是往我们的 Github 代码仓库中 spin-kub-demo 项目提交一个新的分支即可自动触发 DockerHub 构建 Image，然后自动触发 Spinnaker 流程的运行，这里我以分支名 v0.0.9 为例。

$ cd ~/git/my_github
$ git clone https://github.com/huwanyang/spin-kub-demo.git
$ cd spin-kub-demo
$ git checkout -b v0.0.9
$ git push origin v0.0.9

Push 该分支到 GitHub 仓库后，会自动触发 DockerHub 执行构建 Image，本次构建镜像为 huwanyang168/spin-kub-demo:v0.0.9，构建完成后如下图所示。说明一下：DockerHub 触发镜像构建有时候会比较慢，需要队列等待一段时间，本次构建差不多等待了半个小时。

构建完毕后，我们会发现 Spinnaker demo 应用中 Deploy to Dev Pipeline 就自动启动了，并将最新的镜像部署到 demo-dev 之后，流程会自动进入到 Verity Deploy-Dev 等待人工判断服务是否正常。

此时去 Clusters 页面查看 demo-dev 服务组，对比下之前的 demo-dev 服务组，会发现原 demo-dev-v000 服务已经被销毁，新的 demo-dev-v001 已经运行起来了，这也是符合我们预期 Deploy to Dev 流程中各个节点的设置。

接下来，我们去验证一下 demo-dev 实例是否运行正常，继续通过浏览器访问 http://127.0.0.1:8001/api/v1/proxy/namespaces/default/services/demo-dev:80/ 地址，发现页面背景色变为绿色，这也说明本次部署是成功的，因为在 v0.0.9 分支中，我将背景色修改成了绿色，以示区别。

既然验证通过，那么我们就去运行中的 Verity Deploy-Dev 流程中，点击 “Continue” 使流程继续下去。此时流程会自动进入到 Deploy to Prod，在第一个节点上，显示的详情信息中，会发现它匹配到的 Image 就是本次要上线的版本 huwanyang168/spin-kub-demo:v0.0.9，符合我们的预期，稍等一会，流程就成功执行完后续各节点。

现在，我们通过浏览器访问 http://127.0.0.1:8001/api/v1/proxy/namespaces/default/services/demo-prod:80/ 地址，发现跟 demo-dev 实例一致，验证通过，本次部署成功。

此时，我们去 Clusters 页面查看所有的服务组列表，就能看到 demo-dev 和 demo-prod 两个服务均正常运行中。

参考资料

• Spinnaker kubernetes-source-to-prod
• DockerHub Build 官网文档