使用英语阅读

通过


你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure Spring Apps 中的蓝绿部署策略

备注

基本、标准和企业计划将从 2025 年 3 月中旬开始弃用,停用期为 3 年。 建议转换到 Azure 容器应用。 有关详细信息,请参阅 Azure Spring Apps 停用公告

标准消耗和专用计划将于 2024 年 9 月 30 日开始弃用,并在六个月后完全关闭。 建议转换到 Azure 容器应用。 有关详细信息,请参阅将 Azure Spring Apps 标准消耗和专用计划迁移到 Azure 容器应用

本文适用于:✔️ 基本版/标准版 ✔️ 企业版

本文介绍 Azure Spring Apps 中的蓝绿部署支持。

Azure Spring Apps(标准计划及更高版本)允许对每个应用采用两个部署,其中只有一个部署会接收生产流量。 此模式通常称为蓝绿部署。 将 Azure Spring Apps 的蓝绿部署支持与持续交付 (CD) 管道和严格的自动化测试相结合,可以很有把握地实现灵敏的应用程序部署。

交替部署

通过 Azure Spring Apps 实现蓝绿部署的最简单方法是创建两个固定的部署,并始终部署到不接收生产流量的部署。 使用适用于 Azure Pipelines 的 Azure Spring Apps 任务,只需将 UseStagingDeployment 标志设置为 true,就能以此方式进行部署。

下面介绍了交替部署方法的实践工作原理:

假设应用程序有两个部署:deployment1deployment2。 当前,将 deployment1 设置为生产部署,并运行应用程序的版本 v3

这使 deployment2 成为过渡部署。 因此,当持续交付 (CD) 管道准备运行时,它会将应用的下一个版本(版本 v4)部署到过渡部署 deployment2 上。

示意图显示了 deployment1 使用 v3 接收生产流量,而 deployment2 则用于暂存 v4。

v4deployment2 上启动后,可以通过专用测试终结点对其运行自动测试和手动测试,以确保 v4 满足所有期望。

示意图显示了 V4 部署在 deployment2 上并正在进行测试。

确信 v4 时,可以将 deployment2 设置为生产部署,使其接收所有生产流量。 v3 将继续在 deployment1 上运行,以防发现需要回滚的严重问题。

示意图显示了 deployment2 上的 V4 正在接收生产流量。

现在,deployment1 是过渡部署 因此,部署管道的下一次运行将部署到 deployment1 上。

示意图显示了暂存到 deployment1 的 V5。

现在可以在 deployment1 的专用测试终结点上测试 V5

示意图显示了 deployment1 上测试的 V5。

最后,在 v5 满足所有期望后,再次将 deployment1 设置为生产部署, 以便 v5 接收所有生产流量。

示意图显示了 deployment1 上的 V5 正在接收生产流量。

交替部署方法的权衡

交替部署方法简单快捷,因为它不需要创建新部署。 但是,它确实存在几个缺点,如以下各节中所述。

永久性过渡部署

过渡部署始终保持运行,从而会消耗 Azure Spring Apps 实例的资源。 这实际上将 Azure Spring Apps 上每个应用程序的资源要求增加了一倍。

审批争用条件

假设在以上应用程序中,发布管道需要手动审批,然后应用程序的每个新版本才能接收生产流量。 这造成了以下风险:当一个版本 (v6) 在过渡部署上等待手动审批时,部署管道会再次运行,并用更新的版本 (v7) 覆盖该版本。 然后,当 v6 获得批准时,部署 v6 的管道将过渡部署设置为生产。 但现在,部署在该部署上并接收流量将是未获得批准的 v7,而不是已批准的 v6

示意图显示了这部分中所述的审批争用情况。

您可以通过确保某个版本的部署流在所有以前版本的部署流均已完成或中止之后才能开始,来防止争用条件。 防止审批争用条件的另一种方法是使用下述命名部署方法。

命名部署

在命名部署方法中,将为每个要部署的应用程序的新版本创建一个新的部署。 应用程序在其定制部署上经过测试后,该部署将设置为生产部署。 包含以前版本的部署可以保持足够长的时间,直到确信不需要回滚。

在下图中,版本 v5 正在部署 deployment-v5 上运行。 部署名称现在包含版本,因为部署是为此版本专门创建的。 开始时没有其他部署。 现在,若要部署版本 v6,部署管道会创建一个新部署 deployment-v6,并在其上部署应用版本 v6

示意图显示了新版本在已命名部署上的部署,如本部分所述。

没有并行部署另一版本的风险。 首先,在已存在两个部署的情况下,Azure Spring Apps 不允许创建第三个部署。 其次,即使可以有两个以上的部署,每个部署都由它所包含的应用程序的版本进行标识。 因此,协调 v6 的部署的管道仅尝试将 deployment-v6 设置为生产部署。

示意图显示 v6 已部署到 deployment-v6 并且正在接收生产流量。

为新版本创建的部署收到生产流量后,将需要删除包含以前版本的部署,以便为将来的部署留出空间。 可能希望推迟几分钟或几小时的时间,以便可以在新版本中发现严重问题时回滚到以前的版本。

示意图显示,在回退期过后,将删除上一个部署。

命名部署方法的权衡

命名部署方法具有以下优点:

  • 防止审批争用条件。
  • 它通过删除不使用的过渡部署来减少资源消耗。

但是,也存在一些缺点,如下一节所述。

部署管道失败

从部署开始到过渡部署被删除期间,运行部署管道的其他任何尝试都将失败。 管道将尝试创建新的部署,这将导致错误,因为 Azure Spring Apps 中的每个应用程序只允许两个部署。

因此,部署业务流程必须能够稍后重试失败的部署过程,或能够确保每个版本的部署流会保持排队状态,直到所有以前版本的流全部完成。

后续步骤