部署策略对比:蓝绿部署、金丝雀发布及其他

部署策略对比:蓝绿部署、金丝雀发布及其他

閱讀本文約花費: 13 (分鐘)

目前,软件开发最大的变化是部署频率。产品团队更早(更频繁)的将产品发布到生产环境。数月或者数年的发布周期变得越来越短 – 对那些构建纯软件产品的人来说更是如此。

现在,使用面向服务的架构和微服务方式,开发者可以设计模块化的代码库。这允许他们同时在代码库中不同的地方编写和部署代变更。

缩短部署周期的业务优势狠明显:

  • 缩短上市时间
  • 客户可以在更短的时间内获得产品价值
  • 客户的反馈也会更快的到达产品团队,这意味着团队可以更快的迭代特性和修复问题
  • 开发人员的整体士气会上升

但是,这种转变也给运维或者 DevOps 团队带来了新挑战。更频繁的部署,意味着已经部署的代码会对站点可用性和客户体验带来负面影响。这就是制定代码部署策略如此重要的原因,因为它可以最大限度的降低产品和客户的风险。

在本文中,我们将讨论不同的部署策略、最佳实践和工具,让你的团队可以更快更可靠的工作。

现代应用的挑战

现代应用通常是分布式的,基于云的。它们可以弹性扩展来满足需求,基于高可用架构更好地容错。这些应用可以使用全托管服务,例如 AWS Lambda  Elastic Container Service(ECS) 等平台处理一些运维责任。

这些应用经常频繁部署。例如,移动 app 和 web 应用可能一个月内经历多次更改。有些甚至一天多次部署到生产环境。

它们通常采用微服务架构,多个组件一起工作来提供完整的功能。不同的组件可以有不同的发布周期,但它们全部无缝衔接在一起工作。

活动部分数量的增加,意味着出错的几率增大。随着多个开发团队对代码库的修改,当问题发生时,很难定位到问题的根因是什么。

另一个挑战是基础设施层的抽象,它们现在已经被当作代码了。在部署新应用的时候,可能还需要部署新的基础设施代码。

常见部署策略

为了应对这些挑战,应用和基础设施团队应该设计和采用适合他们用例的部署策略。

这里我们将回顾和讨论不同部署策略的优缺点,以便你可以选择合适的。

“大爆炸“部署

顾名思义,“大爆炸”部署一次性更新整个应用或者其中的大部分。这个策略可以回溯到软件在物理介质上发布并由客户安装的时代。

大爆炸部署要求企业在发布之前进行广泛的开发和测试,通常和大型有序发布的“瀑布模型”有关。

现代应用不管是在客户端还是服务端,都有定期自动更新的优势。大爆炸的方式对于现代团队来说,太慢,而且不敏捷。

大爆炸部署的特点包括:

  • 所有的主要部件都打包在一个部署中;
  • 用新的软件版本整个替换现有的版本,或者替换大部分;
  • 部署通常会导致长时间的开发和测试周期;
  • 假定失败的可能性很小,因为回滚是不可能和不现实的;
  • 完成时间通常需要很久,需要多个团队的共同努力;
  • 需要客户采取措施来更新客户端安装。

大爆炸部署不适用于现代应用,因为面向公众的或者是关键业务应用无法接受这种风险,一旦中断就意味着巨大的经济损失。回滚通常耗时且代价巨大,甚至是不可能的。

大爆炸的方式适合非生产环境系统(例如,重新创建开发环境),或者是类似桌面应用这种供应商打包的解决方案。

滚动部署

滚动、阶段性,或者是分步部署比大爆炸部署更好一些,因为它们可以最大限度的降低相关风险,包括面向用户的停机时间。

在滚动部署中,应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间,新旧版本会共存,而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。

下图显示了该部署模式:旧版本显示为蓝色,新版本显示为绿色,它们部署在集群中的每一台服务器上。

部署策略对比:蓝绿部署、金丝雀发布及其他

应用程序套件升级是一个滚动部署的典型例子。如果原始应用部署在容器中,升级可以一次处理一个容器。修改每个容器从应用供应商的站点上下载最新的镜像。如果其中的一个应用存在兼容性问题,旧的镜像可以重新创建这个容器。在这种情况下,套件的新旧版本应用可以共存,直到每个应用都更新完毕。

蓝绿、红黑、A/B 部署

这是另一个能自动防御故障的流程。在这个方法中,两个相同的生产环境并行工作。

一个是当前运行的生产环境,接收所有的用户流量(称之为蓝)。另一个是它的副本,但是闲置(称之为绿)。两者使用相同的数据库后端和应用配置:

部署策略对比:蓝绿部署、金丝雀发布及其他
应用的新版本部署在绿色版本环境中,进行功能和性能测试。一旦测试通过,应用的流量从蓝色版本路由到绿色版本。然后绿色版本变成新的生产环境。

部署策略对比:蓝绿部署、金丝雀发布及其他
如果绿色版本激活后发现了问题,则将流量路由回到蓝色版本中。

在蓝绿部署中,两个系统使用相同的持久化层和数据库后端。保持应用的数据同步至关重要,镜像数据库可以帮助实现这一目标。

你可以使用蓝色版本作为主库进行写入操作,使用绿色版本作为备库进行读操作。在从蓝色版本切换到绿色版本时,数据库会从主库故障转移到备库。如果绿色版本在测试过程中需要写数据,数据库可以进行双向复制。

一旦绿色版本被激活,你可以关闭或者是回收旧的蓝色版本实例。你可以在这些实例上部署一个新版本,用作下次发布的新的绿色版本。

蓝绿部署依赖流量路由。这可以通过更新主机的 DNS CNAMES 来完成。但是,TTL 太久会导致这些变更被延迟。或者,你可以改变负载均衡的配置,让变更立即生效。类似 ELB 的连接特性可以用来提供无缝连接。

金丝雀部署

金丝雀部署和蓝绿有点像,但是它更加规避风险。你可以阶段性的进行,而不用一次性从蓝色版本切换到绿色版本。

采用金丝雀部署,你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布,只有少数用户被路由到它。最大限度的降低影响。

如果没有错误发生,新版本可以逐渐推广到整个基础设施。下图示范了金丝雀部署:

部署策略对比:蓝绿部署、金丝雀发布及其他

金丝雀部署的主要挑战是设计一种路由部分用户到新应用的方法。此外,一些应用可能需要同类用户进行测试,另一些应用可能每次都需要不同类型的用户。

探索一些技术,来考虑路由新用户的方法:

  • 在允许外部用户访问之前,将内部用户暴露给金丝雀部署;
  • 基于源 IP 范围的路由;
  • 在特定地理区域发布应用;
  • 使用应用程序逻辑为特定用户和群体解锁新特性。当应用为其他用户上线后,移除此逻辑。

部署最佳实践

现代应用团队可以遵循一些最佳实践,来最大限度的降低部署风险:

  • 使用部署清单。例如,清单上可能有一项是“在确保停止应用服务后,备份所有数据库”,来防止数据损坏。
  • 采用持续集成(CI)。CI 确保从代码仓库检入的特性分支代码,只会在经过一系列的依赖检查,单元和集成测试,并且成功构建后,才会合并到主干分支。如果过程中出现错误,构建就会失败,并通知应用团队。所以使用 CI 意味着应用的每次变更在部署之前都会进行测试。常见的 CI 工具包括:CircleCI,Jenkins。
  • 采用持续交付(CD)。使用 CD 打包 CI 构建的代码产物,并随时准备部署到一个或多个环境中。更多内容可以看看我们的 Low-Risk Continuous Delivery eBook 
  • 使用标准操作环境(SOEs)来确保环境一致性。你可以使用类似 Vagrant 和 Packer 这样的工具来部署工作站和服务器。
  • 使用自动化构建工具来自动化环境构建。使用这些工具,通常都是简单的点击一个按钮,来销毁整个基础设施栈并从头开始构建。CloudFormation 就是这种工具。
  • 在目标服务器中使用类似 Puppet、Chef 和 Ansible 这样的配置管理工具,来自动应用 OS 设置、打补丁和安装软件。
  • 使用 Slack 这样的通信渠道来自动通知不成功的构建和应用故障。
  • 创建一个程序,在部署失败的时候向负责的团队发送警告。理想情况下,你会在 CI 环境中捕获这些内容,但是如果变更已经部署了,你将需要一种方法来通知负责的团队。
  • 无论是因为可用性还是错误率问题,对健康检查失败的部署启用自动回滚。

部署后监控

即使你采用了所有的这些最佳实践,事情仍然可能会失败。因此,对部署后立即发生的问题进行监控,与规划和执行完美的部署同样重要。

应用性能监控(APM)工具可以帮助团队监控关键性能指标,包括部署后的服务器响应时长。应用和系统架构的变更会极大的影响应用性能。

类似 Rollbar 这样的错误监控解决方案同样重要。它会迅速通知团队新部署或重新激活部署中的错误,这些部署可能会引发严重的 bug,需要立即引起关注。

如果没有错误监控工具,这些 bug 可能永远也不会被发现。虽然一些遇到 bug 的用户会花时间反馈,但大多数其他用户不会这样做。随着时间推移,客户的负面体验会降低满意度,甚至更糟糕的是,阻碍正在进行的业务交易。

错误监控工具还可以在运维 /DevOps 团队和开发者之间,共享所有部署后发生的问题。这些共享让团队变得更具有协作性,响应能力更强。

查看英文原文: Win-Wi n Deploym nt Strategi s for Modern pps

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Scroll Up