实战篇——用Pipeline完成持续交付实践

导语

前边几章主要介绍了Spinnaker的安装、安全、和常用构建的集成，本章就通过一个实例来完成一个完整的持续交付功能。
我们将涉及一个pipline流程，整个流程大概是：

1. 开发人员提交代码到gitlab后，自动触发pipeline执行
2. pipeline调用jenkins构建完成docker image的构建，并将构建后的镜像上传到阿里云镜像仓库
3. 镜像构建完成后，自动发布到测试环境
4. 测试人员测试完毕后，根据测试结果选择回滚到上一个版本还是发布到线上

Stage-Configure部分

在configure部分，主要配置Pipeline自动触发方式、定义全局环境变量、执行结果通知

Automated Triggers

支持多种触发方式，包括Cron、Git、Jenkins、Docker Registry、Webhook等方式。
这里，我们采用git的方式（用户提交代码）实现自动触发功能。
首先，配置gitlab,点击项目左侧Settings——>Integrations，在URL中填写spinnaker网关gate的访问地址，如http://spin-gate.test.com/webhooks/git/gitlab

其次，在Spinnaker中配置
因为我们为项目配置了应用权限，为了保证pipeline可以被自动触发，需指定一个角色，具体请参考安全篇
Type选择Git
Repo Type选择gitlab
Organization or User填写仓库所在Group的名称
Project填写项目名称
Branch填写要监听的制定分支

Parameters

在该部分，可以定义一些要在整个Pipeline中会用到的全局变量，在后边的Stage中可以采用${parameters.变量名}的方式直接调用
我们定义一个镜像标签变量image_tag，取系统当前时间值

利用Jenkins构建镜像

添加一个Stage,类型选择Jenkins

Jenkins Configuration

在Controller下拉列表中选择前边配置的jenkins（在前边文章中有集成Jenkins的教程）
在Job下拉列表中会列出jenkins中所有的Job，选择对应的job
在jenkins job中如果勾选了参数化构建的话，需要设置相应的参数值传给jenkins

添加Bake Stage

构建镜像完成后，面临一个选择，就是采用何种方式将镜像部署到k8s中去，Spinnaker提供了两种选择，在Deploy Stage部分大家会看到，一种是文本的形式，即直接在部署部分书写yaml文件；另一种是利用Artifact的方式，该方式需要我们提前定义要使用的Artifact。
这里我们添加两个Bake类型的Stage,分别用来配置测试环境和生产环境要用到的helm模板和对应的values.yaml文件获取来源以及要替换的配置项。

测试环境bake(dev)

如上图
Template Renderer（模板渲染）我们采用HELM2的方式

Helm Options：
Name：添加helm部署名称
Namespace: helm要部署到的命名空间

Template Artifact
Expected Artifact下拉点击Define a new Artifact
Account：选择我们前边文章定义的helm仓库
Name下拉列表中选择对应的helm chart
Version下拉列表选择版本

Overrides部分主要定义Helm chart发布的时候的values.yaml文件的获取来源以及需要替换的key。
这里我把values.yaml文件放到了gitlab中，所以配置从gitlab中去拉取
Expected Artifact:因为我们前边文章已经配置了gitlab的集成，所以直接在下拉列表中选择
Content URL：添加values.yaml文件的路径。（大家注意，这里是通过直接调用gitlab的api的方式去拉取的文件，格式为：http://gitlab.test.com/api/v4/projects/项目ID/repository/files/niu-cloud%2Focean-grouper%2Fdev-values%2Eyaml/raw）

在Overrides Key Value部分填写上边拉取的values.yaml中需要替换的内容，比如说不通环境的镜像标签等

再往下拉有一个Produces Artifacts页签，该Artifacts是系统自动配置的，相当于把Bake部分整体做了打包，在Deploy Stage中使用该Artifacts去部署

生产环境Bake(prod)

生产环境的bake配置其实和测试环境的差不多，需要修改的地方就是对应环境的values.yaml以及部署的时候该文件需要条换的内容

添加Deploy(dev) Stage

在bake stage配置完成后，流程应该进入到部署测试环境环节，新增一个Stage,类型选择Deploy

Basic Settings部分

Account选择要将前边定义的helm chart部署到哪个k8s中

Manifest Configuration

Manifest Source选择部署方式，上边提到过有两种形式，这里我们选择Artifact的方式
Manifest Artifact：选择Bake(dev)中系统自动生成的Artifact（我改了名字，默认是一个随机生成的名字）

添加后续执行逻辑判断

在项目发布到测试环境后，应该等待测试人员进行测试，测试完毕后根据结果来决定是发布到线上环境还是回滚到上一个版本。
Manual Judgment：该类型的Stage用于人工的逻辑判断，增加Pipeline的可控性，内容支持多种语法表达的方式。

如上图，创建一个Manual Judgment类型的Stage，取名为“Next Action”
Instructions：填写操作说明
Judgment Inputs：添加两个选项，表示线上回家和回滚

Check Preconditions

在上边Manual Judgment中，我们定义了两个Judgment Inputs判断项，接下来创建两个Check Preconditions类型的Stage来分别对这两个判断项进行判断，如果条件为真，则执行对应的后续Stage流程。如上图，若我们选择prod，则发布到线上环境；若是选择rollback，则开发环境回滚到上一个版本。

以判断回滚到上一个版本为例说明配置
点击“Add Precondition”

Check:选择Expression方式
Expression: ${#judgment(‘Next Action’)==‘rollback’} //判断Manual Judgment选择结果是否为rollback
Fail Pipeline:取消勾选，表示即使结果不成立也不影响其他判断分支的执行

另一个分支判断是否发布到线上配置和判断是否回滚配置大致相同，只是修改判断表达式为${#judgment(‘Next Action’)==‘prod’}即可

Undo Rollout to latest version

如果测试人员测试发现该版本有问题，需要进行回滚，则在Manual Judgment一步选择rollback选项，经过Check for rollback判断结果为真，执行后续回滚Stage
新增一个 Undo Rollout (Manifest)类型的Stage,命名为Undo Rollout to latest version

在Undo Rollout (Manifest) Configuration标签下选择要回滚的k8s、命名空间、回滚类型、项目名称、回滚版本即可。

结语

经过以上配置后，一个完成的从自动触发构建镜像，发布到测试环境，进行人工判断及后续流程的完成Pipeline就配置完成了。