在部署 Azure Web 应用程序时最大限度地减少停机时间的最佳做法

Question

我有一个应用服务计划，在这个计划中，我将我的解决方案的 5 个组件部署为 Web 应用程序。我在 Azure DevOps 中使用“发布管理”将代码部署到这些应用程序。

为了最大限度地减少部署期间的停机时间，我首先部署到暂存槽，然后将暂存槽切换到生产槽以完成部署。

我已经配置了应用服务预热（详见此处）来调用一个端点，该端点将在槽交换过程中“预热”应用程序。

这似乎有效，但我有两个问题：

1. 即使预热已经运行，槽交换后向应用程序发出的第一个请求也需要很长时间。我怀疑这是由于生产插槽具有“粘性/插槽设置”，据我所知，这需要重新启动应用程序。为了测试这一点，我删除了插槽设置，但延迟仍然存在。

2. 应用程序相互依赖，并且插槽交换（即使在 Azure DevOps 中并行启动）不能保证同时完成，这意味着新代码可能与旧代码交互。虽然我们可以围绕这个进行设计，但这不是最佳的。

从我目前的调查来看，我能想到的解决这些问题的唯一方法是启动第二个应用服务计划，并将流量管理器配置为位于两个服务计划的前面。部署时，我会优先部署一个服务计划，同时部署到另一个服务计划，完成后将流量转移到新部署的服务计划，同时升级另一个，然后在两者之间再次平衡两者之间的流量在相同的代码级别。

在 Azure 中使用 WebApps 时，当前零停机部署的“最佳实践”是什么？

与交通管理器的重复服务计划是一个可行的选择，如果不是，您有什么建议？

Answer 1

请遵循这些更多最佳实践建议。

\n\n

根据状态代码进行交换

\n\n

在交换操作期间，通过向其根目录发出 HTTP 请求来预热暂存槽中的站点。有关该过程的更详细说明，请参阅如何在部署槽交换期间预热 Azure Web App。

\n\n

默认情况下，只要站点响应任何状态代码，交换就会继续。但是，如果您希望在应用程序无法预热时不进行交换，则可以使用以下应用程序设置进行配置：

\n\n

\n

• WEBSITE_SWAP_WARMUP_PING_PATH：发出预热请求的路径。\n 将其设置为以斜线开头的 URL 路径作为值。例如，\xe2\x80\x9c/warmup.php\xe2\x80\x9d。默认值为/。

\n

• WEBSITE_SWAP_WARMUP_PING_STATUSES：预热操作的预期 HTTP 响应代码。将此设置为以逗号分隔的 HTTP\n状态代码列表。例如： \xe2\x80\x9c200,202\xe2\x80\x9d 。如果返回的状态代码不在列表中，则交换操作将无法完成。默认情况下，\n所有响应代码都是有效的。

\n

\n\n

最大限度地减少随机冷启动

\n\n

\n
• WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG：将此设置为 \xe2\x80\x9c1\xe2\x80\x9d\n 将阻止 Web 应用程序\xe2\x80\x99s 工作进程和应用程序域在应用服务\xe2\x80\x99s 存储基础结构重新配置时\n回收。
\n

\n\n

https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/#prevent-cold-start

\n\n

控制插槽粘性配置

\n\n

但是，如果出于任何原因您需要恢复到交换这些设置的旧行为，则可以将应用程序设置 WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS 添加到应用程序的每个插槽，并将其值设置为 \xe2\x80\x9c0\xe2\x80\x9d 或 \ xe2\x80\x9c假\xe2\x80\x9d。

\n\n

https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/#slot-sticky-config

\n