基于容器服务的持续集成与云端交付(四)- 多种发布方式

前言

哲学有各种各样的流派,百家争鸣,但是只有一个哲学问题是严肃的,那就是生与死。而云端交付过程中也只有三个问题是严肃的。

  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

部署后会有“Welcome to nginx”的成功页面提示。如果用户想变更配置, 可以在操作面板上选择“变更配置”,进入信息修改阶段,选择变更的发布策略与新版本服务的配置。

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。

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

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

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

复杂拓扑下的蓝绿发布

场景分析

大于大多数场景而言,对客户提供服务的软件的形态有三种。一种是前端类服务,用户可以直接或者间接通过网页、接口调用使用该服务提供的能力;一种是后端类服务,用户无法直接使用该服务提供的功能,该服务主要的使用者是其他服务,并通过其他服务最终将处理后的结果反馈给用户;第三种是调度任务类服务,即不被用户使用也不被其他服务调用,它的生命周期只存在在一个任务的执行生命周期中,通常任务的执行周期完毕,服务的生命周期就停止,通常为无状态资源密集性服务。

对于上述三种场景,以路由权重切换为主要实现方式的发布策略例如蓝绿发布、A/BTest等通常情况下比较适用于前端类服务与后端类服务。下面我们用一个简单的例子来拆解下如何使用阿里云容器服务来实现这两类服务的蓝绿发布。

在上一篇发布策略的文章中,有的开发者会问我的应用的拓扑关系不是单体的,不能通过单一容器级别的路由权重切换解决。在此要明确的一件事情,蓝绿发布是一种发布策略,部署的最小维度是容器,而发布的最小维度是应用。蓝绿发布的原理是老的应用的版本不变,新的应用版本进行部署,如果新版本与老版本之间应用的名字以及相关的配置没有改变,那么会认为这个应用是新老版本中共用的,无需变更;需要进行变更的应用通过名字的不同进行区分。简单的来讲,蓝绿发布是一个应用级别的更新操作,你可以对一个服务进行两个版本之间的切换,服务是一个逻辑的概念,而不是容器这样一个实体的概念,蓝绿发布可以做复杂拓扑的应用更新操作。

DEMO

下面我们通过一个拓扑结构复杂一点的例子来讲述蓝绿发布。应用的拓扑结构如下:

serviceB会调用serviceA,这两个都是python构建的,代码如下:

serviceA通过接口返回数据“world!”

from flask import Flask
app = Flask(__name__)

@app.route('/')
def world():
  return 'world!'

if name == '__main__':
  app.run(port=5000,debug=True,host='0.0.0.0')

serviceB调用serviceA的接口,并将返回的数据字段前面添加“Hello ”

from flask import Flask
import requests
import os

dep_endpoint = os.getenv('dep_endpoint');

app = Flask(__name__)

@app.route('/')
def hello():
  msg = requests.get(dep_endpoint);
  return 'Hello ' + msg.text;

if name == '__main__':
  app.run(port=5001,debug=True,host='0.0.0.0')

传统应用之间的调用方式可以是通过配置IP地址或者域名来调用,也可以通过服务注册中心中的地址的方式调用,但是对于一个无状态的多实例的服务,常见的做法是使用客户端的负载均衡器或者服务器的服务均衡器端点来实现。在容器服务中使用的方式是使用服务器端的负载均衡端点的方式,提供内部调用的路由端点,来实现后端服务的负载均衡。大致的调用方式如下。

serviceA-v1:
  image: 'registry-internal.cn-hangzhou.aliyuncs.com/ringtail/demo-service-a:1.0'
  labels:
    aliyun.scale: 3
    aliyun.routing.port_5000: servicea.local
serviceB-v1:
  image: 'registry-internal.cn-hangzhou.aliyuncs.com/ringtail/demo-service-b:1.0'
  environment:
    - 'dep_endpoint=http://servicea.local'
  labels:
    aliyun.scale: 2
    aliyun.routing.port_5001: serviceb
  external_links:
    - "servicea.local"

serviceB通过external_links的方式将serviceA的内部路由端点引入,在环境变量中将

dep_endpoint=http://servicea.local,使用servicea.local作为调用的地址。

访问serviceB的对外访问地址,可以得到:

我们最开始基本结构的应用就已经部署完毕了,下面开始进行不同服务的蓝绿发布。

前端服务的蓝绿发布

首先我们先看如果做前端服务的蓝绿发布,也就是说要对serviceB进行蓝绿发布的流程。大致的结构图如下。

在这个应用中前端服务的蓝绿发布,也就是对serviceB进行蓝绿发布,下面我们修改serviceB的代码

from flask import Flask
import requests
import os

dep_endpoint = os.getenv('dep_endpoint');

app = Flask(__name__)

@app.route('/')
def hello():
  msg = requests.get(dep_endpoint);
  return 'Welcome to the ' + msg.text; //ץද"Hello " => "Welcome to the "

if name == '__main__':
      app.run(port=5001,debug=True,host='0.0.0.0')

修改编排模板,进行蓝绿发布

serviceA-v1:
  image: 'registry-internal.cn-hangzhou.aliyuncs.com/ringtail/demo-service-a:1.0'
  labels:
    aliyun.scale: 3
    aliyun.routing.port_5000: servicea.local
serviceB-v2:
  image: 'registry-internal.cn-hangzhou.aliyuncs.com/ringtail/demo-service-b:2.0'
  environment:
    - 'dep_endpoint=http://servicea.local'
  labels:
    aliyun.scale: 2
    aliyun.routing.port_5001: serviceb
  external_links:
    - "servicea.local"

进行蓝绿发布更新后,可以看到更新后的服务列表,其中黄色的serviceA-v1表示当前的应用在蓝绿发布的过程中不会产生变化,serviceB-v1为老版本,serviceB-v2为新版本

通过路由列表选择相应的权重管理,进行权重的调整,将serviceA-v1的权重调整为0,将serviceA-v2的权重调整为100,此时访问serviceB的网址可以发现。

验证完毕,点击确认发布完成,完成蓝绿发布。

后端服务的蓝绿发布

我们再看下如何做后端服务的蓝绿发布,也就是说对serviceA进行蓝绿发布。大致的结构图如下。

修改编排模板

serviceA-v2:
  image: 'registry-internal.cn-hangzhou.aliyuncs.com/ringtail/demo-service-a:2.0'
  labels:
    aliyun.scale: 3
    aliyun.routing.coexist: true
    aliyun.routing.port_5000: servicea.local
serviceB-v2:
  image: 'registry-internal.cn-hangzhou.aliyuncs.com/ringtail/demo-service-b:2.0'
  environment:
    - 'dep_endpoint=http://servicea.local'
  labels:
    aliyun.scale: 2
    aliyun.routing.coexist: true
    aliyun.routing.port_5001: serviceb
  external_links:
    - "servicea.local"

部署后的服务列表:

此时可以发现serviceB-v2在本次发布中不会进行变更,调整服务的权重

此时再访问serviceB的地址,可以得到如下的结果

总结

蓝绿发布是一种用于升级与更新的发布策略,对于增量升级有比较好的支持,但是对于涉及数据表结构变更等等不可逆转的升级,并不完全合适用蓝绿发布来实现,需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求,希望给位开发者可以在自己的业务场景中,更灵活的使用和实现蓝绿发布。

附录

代码仓库地址:https://github.com/ringtail/BlueGreenDevelopment

个人简介

莫源,阿里云高级研发工程师。在加入阿里巴巴之前,先后在北京天方地圆科技有限公司、微软亚洲研究院任职。现主要负责阿里云容器服务产品的底层服务发现系统、集群管理系统的研发,从事容器的持续交付、持续集成的方案的设计与实现。在云计算、分布式系统、图像识别与虚拟现实方向有多年的开发经验。

时间: 2024-09-18 03:12:37

基于容器服务的持续集成与云端交付(四)- 多种发布方式的相关文章

基于容器服务的持续集成与云端交付(五)- 探究持续交付系统的本质

换个角度看持续交付 在<基于容器服务的持续集成与云端交付>系列中,我们已经讨论了持续集成与持续交付给软件开发带来的变革,介绍了如何从零搭建一个持续交付系统以及在阿里云上面如何实现持续交付. 不过,在这篇文章中,我们会用一个不一样的角度来思考持续交付,到底持续交付给我们带来了什么,在容器的持续交付的场景中还缺少什么.回到本系列第一篇文章中的容器持续交付的流程图: 这张图中描述了一个基于容器的持续交付的流程,它定义了几个阶段,本地开发阶段.持续集成阶段.持续交付阶段等等,规定了在每个阶段中该做什么

基于容器服务的持续集成与云端交付(二)- 多维度打磨交付能力

前言 在上一篇中,和大家一起讨论了传统软件交付的问题.持续交付的难点.以及为什么云端的容器交付可以协助大家快速的持续交付. 但是当真正的将一个系统通过云端容器交付的时候会发现不能单纯的将Docker作为一种交付工具来对待,更多的时候是作为一个交付平台的基础设施来看待,还需要关心的是使用Docker后网络.存储.安全.性能.监控等等不同方面带来的变革. 因为交付的本质是将一套复杂的软件系统从零到一完成开发.测试.部署.上线的过程,软件的复杂度直接关系到了交付的难度,特别是现在微服务的架构方式越来越

基于容器服务的持续集成与云端交付(一)- 交付之禅

前言 随着微服务架构与容器虚拟化技术的发展,持续集成与持续交付的概念又重新回到了大家的视野,越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题:使用持续交付的工具来实现代码在不同环境上的自动部署.原本有些学院派乌托邦式的思想正被千千万万次的集成与部署证明着它应有的价值.那么究竟是因为什么让持续集成与持续交付这个已经不再年轻的软件开发与交付的思想重新焕发绽放迷人的光彩呢? 传统软件交付之殇 传统软件的开发与交付的周期都很漫长,一款普通的企业软件通常需要十几个开发人员,几个月的时间来完

基于容器服务的持续集成与云端交付(三)- 从零搭建持续交付系统

前言 在上一篇文章中讨论了容器服务提供的交付能力,在本文中我们将讨论如何从零搭建一个持续交付系统. 对于大多数公司而言,选择一个合适自己的持续交付系统是尤为重要的一件事情,不同的公司.不同的业务使用的场景也各不相同,因此要根据自己的业务场景与发展方向来选择合适的方案.根据不同的业务场景与交付方式,阿里云容器服务提供了三种不同的持续交付方案. 基于Jenkins的持续交付方案 基于Jenkins的持续集成和持续交付方案是所有方案中最灵活.能力最强的方式,但也是需要客户自主运维的方案.对于现有提供持

云效(原RDC)+ 容器服务完成持续集成

最近在将公司的持续集成架构做一个系统的调整,调整过程中受到了RDC团队大量的帮助,所以利用国庆时间写了几篇RDC的分享,希望能让更多的人了解和用好RDC这个产品. 我会把我最近3个月的使用体会分成5个部分:使用RDC的动机.PHP项目集成.JS项目集成.JAVA项目集成.Docker类项目集成这5个分支来写 因为近期RDC的迭代比较频繁,所以我的分享会比较的浅,点到为止,仅供参考,目录: 1.RDC如何耦合进我们的业务 2.如何构建一个基于Composer的PHP项目 3.如何构建一个基于Nod

微服务的持续集成,四步“构建”一个代码世界

本文讲的是微服务的持续集成,四步"构建"一个代码世界,大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误. 今天我们就来聊一聊微服务的持续集成. 目录 一.持续集成之构建 二.持续集成之部署 三.持续集成之测试 四.持续集成之发布 五.总结 一.持续集成之构建 当微服务产生

基于 Jenkins 快速搭建持续集成环境

持续集成是一种软件开发实践,对于提高软件开发效率并保障软件开发质量提供了理论基础.Jenkins 是一个开源软件项目,旨在提供一个开放易用的软件平台,使持续集成变成可能.本文正是从持续集成的基本概念入手,通过具体实例,介绍了如何基于 Jenkins 快速搭建持续集成环境. 持续集成概述 什么是持续集成 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题.尤其是近些年来,敏捷(Agile) 在软件工程领域越来越红火,如何能再不断变

大叔公开课~微服务与持续集成

闲话多说 免费报名:http://www.genshuixue.com/teacher/classCourseDetail/171117794648 .Net Core来了,带给我们的是什么?跨平台,无疑是最大的亮点! Docker横空出世,让开发者和运维者都尝到了甜头! Jenkins持续集成,功能包括了持续的软件版本发布与测试,让开发人员专心关注自己的代码开发,让运维人员专心写部署代码,一次性工作,从来不要反复的做一件事! 云时代来了,容器时代了,面向应用的微服务也来了,麻烦也就跟着来了,我

阿里云容器服务 - 提速云端应用部署与运维

阿里云容器服务 - 提速云端应用部署与运维 阿里云容器服务简介 什么是容器服务 什么是容器 容器服务解决了什么问题 容器服务架构 容器服务使用流程及场景 容器服务 阿里云容器服务(Container Service)是一种高性能可伸缩的容器管理服务.支持一键部署Docker集群,提供便利的基于容器的服务与应用的编排.部署及完整的生命周期管理.提供阿里云Docker镜像加速管理服务,支持基于Git等代码仓库集成.http://www.aliyun.com/product/containerserv