DevOps与阿里云容器服务（三）

前言

你若问十个哲学家什么是『哲学』通常你会得到十一种答案（有一种是你自己的）。

你若问十个持续交付布道师什么是『DevOps』，你恐怕得到的是上百种答案（因为你自己也有好几种）。

只有一个哲学问题是严肃的，那就是生与死。

而对于DevOps只有三个问题是严肃的

1.如何重建你的系统      （How to recreate your system？）
2.如何安全地部署你的系统 （How to safely change your system）
3.部署后的问题监控与解决 （When something has gone wrong)

而今天我们要谈的是如何安全的部署你的系统，部署这个名词包含了很多的含义，最简单的解释就是如何让你的程序运行在最终的环境上。但是部署的方式上面有非常多的最佳实践。接下来我们来讨论下常见的几种发布方式，以及这些发布方式和容器结合的使用。

发布策略

常见的发布策略有蓝绿发布、金丝雀发布（灰度发布）、ABTest，在国内的开发者中，对这几个概念有独立的理解。蓝绿发布通常被大家成为热部署；金丝雀发布在国内的名头完全被他的变种发布方式盖过了，主要是灰度发布与ABTtest，下面我们来详细的为大家解释一下他们之间的异同。

蓝绿发布

在发布的过程中用户无感知服务的重启，通常情况下是通过新旧版本并存的方式实现，也就是说在发布的流程中，新的版本和旧的版本是相互热备的，通过切换路由权重的方式（非0即100）实现不同的应用的上线或者下线。

金丝雀发布

通过在线上运行的服务中，新加入少量的新版本的服务，然后从这少量的新版本中快速获得反馈，根据反馈决定最后的交付形态。

灰度发布

灰度发布是通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本的过程。虽然马丁·扶老耳朵大人认为灰度发布与金丝雀发布是等同的，但是在具体的操作和目的上面个还是有些许差别的。金丝雀发布更倾向于获取快速的反馈，而灰度发布更倾向于从一个版本到另一个版本平稳的切换。

ABTest

ABTest和灰度发布非常像，但是从发布的目的上，可以简单的区分灰度发布与ABTest，ABTest侧重的是从A版本或者B版本之间的差异，并根据这个结果进行决策。最终选择一个版本进行部署。因此和灰度发布相比，ABTest更倾向于去决策，和金丝雀发布相比，ABTest在权重和流量的切换上更灵活。

阿里云容器服务实现蓝绿发布

下面我们通过一个简单的例子来演示蓝绿发布的流程。假设我们要进行蓝绿发布的应用是一个nginx的静态页面,初始的应用模板如下

nginx-v1:
  image: 'registry.aliyuncs.com/ringtail/nginx:1.0'
  labels:
    aliyun.routing.port_80: nginx
  restart: always

部署后页面的效果如下

点击变更配置

选择变更的发布策略与新版本服务的配置

nginx-v2:
  image: 'registry.aliyuncs.com/ringtail/nginx:2.0'
  labels:
    aliyun.routing.coexist: true
    aliyun.routing.port_80: nginx
  restart: always

在蓝绿发布中，新版本与旧版本不能共用同一个名字；如果共享同一个路由地址，那么需要添加aliyun.routing.coexist的label，这个label的含义是，当前的服务与其他服务共享路由地址，在蓝绿发布的场景中，为了保证应用的零宕机切换，新版本的服务的路由权重默认为0，需要通过路由管理页面进行调整，方可进行流量切换。在进行发布的过程中，会经历两个状态，一个是蓝绿发布中，一个是蓝绿发布待确认。

蓝绿发布中表示，新版本的服务尚未启动完成，而蓝绿发布待确认表示新版本的服务已经启动完成，此时需要进行发布确认或者发布回滚方可进行下一次发布。进入应用的详情页面，可以看到新版本的应用和旧版本的应用并存。其中蓝色的表示旧版本的服务，绿色表示新版本的服务。如果一个服务在前后两个版本中都存在且没有变化，那么会出现黄色的标签，表示这个应用在蓝绿发布中不会出现任何变化。

点击路由列表，调整与之对应的路由权重。

如图所示，旧版本服务的权重为100，新版本服务的权重为0，下面我们将旧版本服务的权重调整为0，新版本服务的权重调整为100

由于默认路由服务是进行会话保持的，您可以打开一个新的浏览器窗口，访问新的版本，结果如下。

当整个发布流程验证完毕后，需要进行发布确认，方可进行下一次发布。

点击发布确认后，查看应用的详情，可以看到应用的服务列表已经更新了，旧的服务已经完全下线删除了