蓝绿色部署是一种对生产堆栈进行增量更新的方式,而无需停机,也不会为正确处理滚动更新(包括回滚功能)提供任何复杂性
我不需要重复这个奇妙的解释或马丁·福勒的原始著作 。 但是我会继续介绍它们。
蓝绿色部署是其中有一组“活动”和“备用”服务器的服务器。 主服务器正在运行当前版本,备用服务器可以运行任何新部署的版本。 “活动”和“备用”与“蓝色”和“绿色”略有不同,因为一组始终是“蓝色”,而一组始终是“绿色”,而“活动”和“备用”标签会更改。
例如,在AWS上,您可以通过在主堆栈中有两个子堆栈(活动堆栈和备用堆栈(由堆栈标签指示))来编写部署脚本,每个子堆栈都有一个(或多个)应用程序层自动伸缩组,以及一个执行以下操作的脚本(也适用于非AWS):
- 将构建推送到可访问的位置(例如s3)
- 将备用自动缩放组大小设置为所需的值(不使用时备用保持为0)
- 使它在启动时获取推送的构建
- 等待它开始
- 运行健全性测试
- 切换DNS指向备用ASG前面的ELB
- 切换标签以激活备用标签,反之亦然
- 将先前活动的ASG大小设置为0
应用程序层是无状态的 ,因此很容易进行此类热替换。
但是(如Fowler所指出的)数据库是最棘手的组件。 如果您有2个数据库,其中备用数据库是活动数据库的从属副本(并且每次切换时都会更改),则设置会变得更加复杂。 而且您仍然必须进行架构更改。 因此,如果可能的话,使用单个数据库是更简单的方法,而不管您是拥有“常规”数据库还是无模式数据库。
实际上,归结为让您的应用程序在启动时以两种版本都可以使用的方式修改数据库。 这包括架构更改–创建表(或无架构db中的相关术语),创建字段,添加/删除字段以及插入新数据(例如枚举)。 根据数据和数据类型的不同,它可能会以多种方式出错。 一些空值,一些数据类型更改,使一些值不可解析,等等。
当然,使用常规的SQL数据库很难做到这一点。 正如我之前链接的文章中所建议的那样,您可以使用存储过程(我不喜欢),也可以使用数据库迁移工具 。 对于无模式数据库,您必须手动执行操作,但是通常只需要较少的操作–您无需更改表或显式创建新表,因为所有内容都是自动处理的。 最重要的是不要破坏正在运行的版本。
但是,如何确保一切正常?
- 测试阶段-最好使用生产数据库的副本
- (自动)针对尚未生效的新部署运行行为/接受/健全性测试套件,然后再将DNS切换为指向它。 如果失败,请停止该过程。
仅在这些检查通过之后,才切换DNS并将您的域指向先前的备用组,从而将其升级为“活动”。 切换可以手动完成,也可以使用部署脚本自动完成。 “交换机”可以不是DNS交换机(因为您需要较低的TTL)。 例如,它可以是负载均衡器或子网配置–最佳选择取决于您的设置。 虽然使所有内容都自动化是好的,但执行一些手动步骤并不一定是一件坏事。
总体而言,我建议采用蓝绿色部署方法,以实现零停机时间升级。 但是,请始终确保已正确升级数据库,以便它可以同时使用旧版本和新版本。
翻译自: https://www.javacodegeeks.com/2015/06/blue-green-deployment-with-a-single-database.html