部署 Azure Web 应用程序时最小化停机时间的最佳实践答案

【问题标题】：Best practice for minimizing downtime when deploying Azure Web Apps部署 Azure Web 应用程序时最小化停机时间的最佳实践
【发布时间】：2019-11-18 12:23:52
【问题描述】：

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

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

我已将应用服务预热（详细信息 here）配置为调用一个端点，该端点将在插槽交换过程中“预热”应用程序。

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

即使已运行预热，在插槽交换后向应用发出的第一个请求仍需要很长时间。我怀疑这是由于生产插槽具有“粘性/插槽设置”，据我所知，这需要重新启动应用程序。为了测试这一点，我删除了插槽设置，但延迟仍然存在。
应用程序相互依赖，并且插槽交换（即使在 Azure DevOps 中并行启动）不能保证同时完成，这意味着更新的代码可以与旧代码交互。虽然我们可以围绕这个进行设计，但这并不是最优的。

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

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

使用流量管理器的重复服务计划是一个可行的选择吗？如果不是，您有什么建议？

【问题讨论】：

你为什么不想做 a\b 发布？
我想我的问题可能不清楚。 A/B 是我在我的问题中提出的可能解决方案，只是想知道这是否是“最佳实践”。 A/B 还带有额外的基础设施来支持它，因此成本也很高。
不，a\b 可以用相同的方法完成（使用插槽）。所以它不需要额外的费用

标签： azure azure-devops

【解决方案1】：

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

根据状态码进行交换

在交换操作期间，暂存槽中的站点通过向其根目录发出 HTTP 请求来预热。有关该过程的更详细说明，请访问 How to warm up Azure Web App during deployment slots swap。

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

WEBSITE_SWAP_WARMUP_PING_PATH：发出预热请求的路径到。将此设置为以斜杠作为值开头的 URL 路径。为了例如，“/warmup.php”。默认值为 /。
WEBSITE_SWAP_WARMUP_PING_STATUSES：预期的 HTTP 响应代码预热操作。将此设置为以逗号分隔的 HTTP 列表状态码。例如：“200,202”。如果返回的状态码是不在列表中，则交换操作将无法完成。默认情况下，所有响应代码均有效。

尽量减少随机冷启动

WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG：将此设置为“1” 将阻止 web 应用的工作进程和应用域回收当应用服务的存储基础架构重新配置时。

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

控制卡槽配置

但是，如果出于任何原因您需要恢复到交换这些设置的旧行为，则可以将应用设置 WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS 添加到应用的每个插槽，并将其值设置为“0”或“false”。

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

【讨论】：

感谢您的回复。我已经将上述所有“最佳实践”用于热身（花了很多时间阅读 Ruslan 关于该主题的博客文章）。应用程序预热不是主要问题。主要问题是插槽交换发生在不同时间的可能性，以及旧代码与新代码交互的可能性

【解决方案2】：

我建议将 Local cahce 与 Deployment Slots 结合使用，以防止停机。

将值为 Always 的粘性应用设置 WEBSITE_LOCAL_CACHE_OPTION 添加到您的 Production slot。如果您使用的是 WEBSITE_LOCAL_CACHE_SIZEINMB，请将其作为粘性设置添加到您的 Production slot。

• 创建一个暂存槽并发布到您的暂存槽。如果您在生产槽中获得本地缓存的好处，您通常不会将暂存槽设置为使用 本地缓存 来启用无缝的构建-部署-测试生命周期进行暂存。

• 对照您的临时广告位测试您的网站。

• 准备就绪后，在 Staging 和 Production 插槽之间发出交换操作。

• 粘性设置包括名称和对插槽的粘性。因此，当 Staging slot 切换到 Production 时，它会继承本地缓存应用设置。新交换的 生产槽 将在几分钟后针对本地缓存运行，并将作为交换后槽预热的一部分进行预热。 因此，当插槽交换完成后，您的生产插槽将针对本地缓存运行。

请参阅 Azure 最佳实践文档：

https://docs.microsoft.com/en-us/azure/app-service/deploy-best-practices

https://docs.microsoft.com/en-us/azure/app-service/overview-local-cache

【讨论】：

感谢您的回复。问题不是“如何让插槽交换工作？”，而是“在单个服务计划中同时部署多个 web 应用程序的最佳方法是什么”。我已经查看了链接的文档，并在插槽交换场景中遵循了所有这些内容。

【解决方案3】：

在加热网站之前，我会使用“预览交换”功能。

交换槽的主要问题是交换时工作进程会重新启动。这意味着网站需要重新加热。

当您将 Swap 与 Preview 结合使用时，工作进程会重新启动，但交换不会完成，这意味着您可以相应地预热站点。一旦您对测试和性能感到满意，您只需“完成交换”，网站就会做出同样的反应。

【讨论】：