Azure Spring Apps 中的蓝绿部署策略

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

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

交替部署

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

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

假设应用程序有两个部署：deployment1 和 deployment2。 当前，将 deployment1 设置为生产部署，并运行应用程序的版本 v3。

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

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

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

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

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

最后，在 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 设置为生产部署。

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

命名部署方法的权衡

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

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

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

部署管道失败

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

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

后续步骤

• 自动将应用程序部署到 Azure Spring Apps