OpenShift 4 Hands-on Lab (2) - 应用部署和切换策略（蓝绿、金丝雀和A/B、部署回滚）
文章目录
- 应用上线部署策略
- 蓝绿部署
- 金丝雀发布和A/B测试
- 通过调整Route权重实现
- 通过调整Pod数量实现
- 部署回滚
应用上线部署策略
本节介绍应用部署上线和切换应用访问的常用策略。虽然可以根据需要灵活使用以下策略，但由于本节使用了同一组验证的应用，因此请按顺序进行下面3个Lab操作。
在部署应用前，需要将https://github.com/liuxiaoyu-git/bluegreen.git的代码fork到自己的GitHub账户下，下文将用“MY_GITHUB”代表用户各自的GitHub账户名。
蓝绿部署
蓝绿部署是最常见的一种不间断的应用升级部署的方式，蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚。蓝绿部署的特点是在一个时间点请求会100%地发给蓝绿部署中的一个目标。
蓝绿部署通常生产环境需要两组配置，一组是active的生产环境的配置，一组是inactive的配置。用户访问的时候，只让用户访问active的服务器集群。蓝色环境（active）运行旧版本应用version1。当要升级到version2，先在绿色环境中部署新版本应用，并进行测试。如果测试没问题，就可以把路由指向绿色环境。
- 依次执行以下命令，首先创建项目，然后部署blue版的应用，在根据Service生成Route。
$ oc new-project USER-ID-bluegreen
$ oc new-app https://github.com/MY_GITHUB/bluegreen.git#master --name=blue
$ oc expose service blue --name=bluegreen
$ oc get route bluegreen
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
bluegreen bluegreen-mywar.apps.cluster-beijing-c70a.beijing-c70a.example.opentlc.com blue 8080-tcp None
- 用浏览器访问http://bluegreen-mywar.apps.cluster-beijing-c70a.beijing-c70a.example.opentlc.com可以看到以下显示‘Blue的页面。
- 部署Green版的应用。
$ oc new-app https://github.com/MY_GITHUB/bluegreen.git#green --name=green
- 将Route访问的后台服务切换到Green应用上。
$ oc patch route/bluegreen -p '{"spec":{"to":{"name":"green"}}}'
- 再次用浏览器访问应用的Route对应的http://bluegreen-mywar.apps.cluster-beijing-c70a.beijing-c70a.example.opentlc.com地址，可以看到此时显示的已经是Green版的应用页面了。
金丝雀发布和A/B测试
我把金丝雀发布和A/B测试放在一起，因为它们的特点都是在一个时间点允许将请求根据需要流向不同的目标，不过金丝雀发布和A/B测试有不同的目的。金丝雀发布又名灰度发布，是用逐步过渡的方法实现新版本应用上线的一种发布策略；而A/B测试主要是用来测试一个应用的不同实现版本的差异化表现的方法，例如评估两个不同界面风格的应用哪个更受用户的欢迎、其性能差异等。
通过调整Route权重实现
- 执行命令，编辑名为bluegreen的Route。
$ oc project USER-ID-bluegreen
$ oc edit route bluegreen
- 在“spec”区域的“to”后增加“alternateBackends”一段内容，修改完“spec”区域的内容应该如下：
。。。
spec:
host: bluegreen-mywar.apps.cluster-beijing-c70a.beijing-c70a.example.opentlc.com
port:
targetPort: 8080-tcp
subdomain: ""
to:
kind: Service
name: green
weight: 50
alternateBackends:
- kind: Service
name: blue
weight: 50
wildcardPolicy: None
。。。
- 保存bluegreen的Route配置后执行命令查看bluegreen的Route的blue和green各有50%的机会接收请求。
$ oc get route bluegreen
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
bluegreen bluegreen-mywar.apps.cluster-beijing-c70a.beijing-c70a.example.opentlc.com green(50%),blue(50%) 8080-tcp None
- 执行以下命令，查看红色加亮的字体，确认数量基本是一样的。
$ while true;do curl $(oc get route bluegreen -o template --template '{{.spec.host}}') | grep -e green -e blue;done
- 分别执行以下命令，分别将blue和green接收请求的比例设为30%-70%以及50%-50%，然后用（4）脚本确认。
$ oc set route-backends bluegreen --adjust blue=30%
$ oc set route-backends bluegreen --adjust blue=+10%
$ oc set route-backends bluegreen --equal
通过调整Pod数量实现
还可用一个Service对应多个DeploymentConfig，然后通过调整DeploymentConfig中运行的Pod实例数实现在不同版本的应用分配流量。
- 执行以下命令，先根据App Image创建ab-example应用和对应的Route资源，然后只保留应用的Service和Route配置（删除DeploymentConfig配置）。再根据App Image创建ab-example-a和ab-example-b应用，然后只保留它们的DeploymentConfig（删除Service配置）。这样就有了1个Service和2个DeploymentConfig。
$ oc new-project USER-ID-ab
$ oc new-app openshift/deployment-example:v1 --name=ab-example --labels=ab-example=true
$ oc expose svc/ab-example --name=ab-example
$ oc delete dc/ab-example
$ oc new-app openshift/deployment-example:v1 --name=ab-example-a --labels=ab-example=true
$ oc new-app openshift/deployment-example:v2 --name=ab-example-b --labels=ab-example=true SUBTITLE=Shard-B COLOR=red
$ oc delete svc/ab-example-a
$ oc delete svc/ab-example-b
- 此时名为ab-example的Service是通过Pod Selector选择有哪些Pod处理请求。在OpenShift控制台的Administrator视图中进入Networking的Services。在列表中可以都看到Pod Selector（见下图），然后点击Pod Selector下面的链接。
- 可以看到根据当前的条件（ab-example=true和deploymentconfig=ab-example），是没有对应的Pod。
- 如果删除“deploymentconfig=ab-example”条件，就可以选出2个DeploymentConfig定义的Pod。
- 再次通过Networking的Services进入ab-example，然后点击Action中的Edit Pod Selector。
- 在Edit Pod Selector对话框中点击“deploymentconfig=ab-example”右侧删掉图标，然后点击Save关闭窗口。
- 此时在ab-example的Service界面中进入Pods标签，可以看到该Service已经对应上2个Pod了，它们分别由ab-example-a和ab-example-b部署的。
- 此时回到这个项目的Developer视图的Topology，可以看到下图。可以看到2个DeploymentConfig都对应相同的Service名称和Route地址。
- 多次执行以下命令，确认可以轮流看到v1和v2版本应用。
$ curl $(oc get route ab-example -o template --template '{{.spec.host}}') | grep h2
- 执行命令，将名为ab-example-a的DeploymentConfig运行的Pod数设为0。然后在多次执行（9）命令，确认只能看到v2版本应用。
$ oc scale dc/ab-example-a --replicas=0
- 执行以下命令，将名为ab-example-b的DeploymentConfig运行的Pod数设为0，将名为ab-example-a的DeploymentConfig运行的Pod数设为1。然后在多次执行（9）命令，确认只能看到v1版本应用。
$ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0
部署回滚
下面首先部署version 1版的blue应用，再更改应用到新版本version 2后再次部署blue，当发现部署后的新版本应用出现问题，可以通过部署回滚快速切换到以前运行正常的version 1版本应用。
- 首先将请求全部发到blue的应用上。
$ oc project USER-ID-bluegreen
$ oc set route-backends bluegreen --adjust blue=100%
- 进入https://github.com/MY_GITHUB/bluegreen.git，选择requestHandlers.js文件，然后点击History右侧的编辑图标。
- 找到“”，在后面增加“version 1”用来做版本跟踪，然后点击页面最下方的Commit changes图标
' version 1'+
- 在OpenShift控制台通过点击Builds->blue->Builds查看当前build列表，然后点击右上方的Actions->Start Build的下拉菜单触发一次新的build。
- 此时页面会转blue-2的界面，进入Logs可以看到Build的进度。
- 进入OpenShift控制台的Topology，可以看到DC blue图标的变化过程，这说明当Build完后OpenShift会自动触发一次Deployment，部署新Build的App Image。
- 选中DC blue的图标，然后在右侧滑出部分进入Overview。当Deployment过程完成后，DC blue的Last Version会变为2（每成功Deployment一次，Last Version会增加1）。
用命令查看blue的Deployment Config，也可得到 REVISION（即Last Version）为2。
$ oc get dc blue
NAME REVISION DESIRED CURRENT TRIGGERED BY
blue 2 1 1 config
- 访问bluegreen的Route，会发现页面会显示“version 1”
$ curl $(oc get route bluegreen -o template --template '{{.spec.host}}') | grep version
- 重复以上2-8操作，将页面从“version 1”改为“version 2”，然后再手动触发一次Build。在Build完后，OpenShift会自动将Build的最新App Image部署起来，此时页面就会显示“version 2”。
- 执行以下命令，将显示version 2的blue应用退回到上一个显示version 1的版本。在回退完后，用（8）步的命令验证。
$ oc rollout undo dc/blue
deploymentconfig.apps.openshift.io/blue rolled back
- 执行命令查看当前有多少和blue相关的Build，可以看有以下3个。
$ oc get build
NAME TYPE FROM STATUS STARTED DURATION
blue-1 Source Git@31c4e83 Complete About an hour ago 1m14s
blue-2 Source Git@e7df24a Complete About an hour ago 1m29s
blue-3 Source Git@69b099b Complete About an hour ago 1m26s
- 查看名为blue-2的Build生成的App Image。
$ oc describe build blue-2 | grep 'Image Digest'
Image Digest: sha256:5fae117dd73f9dc28cb3228a8efc2a53cf15289bfd8224ef2163de59f4930c05
- 查看名为blue的ImageStream信息，它用来跟踪blue的App Image。通过镜像签名可确认有对应build-2生成的App Image（以下结果从下向上第2行）。
$ oc describe is blue | grep blue
Name: blue
Labels: app=blue
Image Repository: default-route-openshift-image-registry.apps.cluster-beijing-c70a.beijing-c70a.example.opentlc.com/mywar/blue
* image-registry.openshift-image-registry.svc:5000/mywar/blue@sha256:e7dac0f2191e385b25c39ec5bf2108c75a7d6770417551b03e5f79b1f8e989d7
image-registry.openshift-image-registry.svc:5000/mywar/blue@sha256:5fae117dd73f9dc28cb3228a8efc2a53cf15289bfd8224ef2163de59f4930c05
image-registry.openshift-image-registry.svc:5000/mywar/blue@sha256:085591991c22f4f76ab9ffa0f4247eb6047710b99547c7514f38168f6e25d5cd
- 我们刚刚已经将blue的deployment使用的App Image版本回退到了显示version 1的版本。执行下面命令可再次将deployment回退到最后一个版本（即显示version 2）。
$ oc rollback blue
deploymentconfig.apps.openshift.io/blue deployment #6 rolled back to blue-3
Warning: the following images triggers were disabled: blue:latest
You can re-enable them with: oc set triggers dc/blue --auto
- 执行以下命令可将应用回退到初始版本（即不显示version 1或version 2）
$ oc rollback blue --to-version=1