时间戳

首页 > 解决方案 > Azure 应用服务插槽配置并在交换期间重新启动

azure - Azure 应用服务插槽配置并在交换期间重新启动

问题描述

我们将 Azure 应用服务与插槽部署一起使用，并且在执行交换时我们看到了意外行为。我们正在尝试DatabaseMode: ReadOnly在每次插槽交换期间防止 CMS 内容在暂存（具有插槽设置）上同步。

我们怀疑在应用设置之前可能会发生额外的重启？

宿主环境：Azure App Service（带槽）

应用设置：

分期：

居住：

Staging 和 Live 插槽都使用相同的数据库，Staging 已使用应用服务应用设置启用只读。DatabaseMode：ReadOnly 在插槽上工作（在我们的例子中阻止同步），即使重新启动登台，我们也确认了这一点。

在部署期间： https ://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#what-happens-during-a-swap

我们立即部署到分期并触发交换。

我们看到的：

交换期间是否发生了一些我们不知道的鲜为人知的操作，哪些操作会导致在应用暂存设置之前重新启动？或者还有什么可能导致这种情况？

当然有一个选项是 CMS 不获取价值或 smth，我们正在单独研究它，但这仅在重新启动时发生，因此希望了解 Azure 方面发生的一切，并确定它是否是 Azure问题与否

标签： azureazure-web-app-serviceazure-deployment-slots

解决方案

我已经解决了上述问题，对我来说，插槽特定的粘性设置应该可以工作，并且可以避免与数据库同步。由于这是应用程序代码，我建议在您的代码中使用插槽类型的额外条件来处理它。

现在，只是想分享一些您可能知道的更多细节。应用程序设置WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1可避免由于绑定而导致的任何重新启动操作，而绑定又会更改应用程序域。但是，您可以尝试使用WEBSITE_SKIP_ALL_BINDINGS_IN_APPHOST_CONFIG = 1来查看是否适合您。

需要重新启动工作进程才能使目标插槽的以下设置生效。默认情况下，在点击插槽“/”的根目录后重新启动考虑完成。为了获得更好的性能并避免延迟，请考虑使用多个路径进行应用程序初始化，这可能需要更多时间或可能执行缓存或长时间执行。例如 web.config 文件看起来像：

<system.webServer>
<applicationInitialization>
  <add initializationPage="/pagetowarmup1.php" />
  <add initializationPage="/pagetowarmup2.php" />
  <add initializationPage="/pagetowarmup3.php" />
</applicationInitialization>
</system.webServer>

现在是时候了解swap 会发生什么了。

  1. 暂存站点（源）应获取应用程序设置和生产槽（目标）的连接字符串 2）如果源（暂存）的 web.config 文件中提供，则重新启动源并使用应用程序初始化路径进行预热。
  2. 现在请注意，源（暂存）和目标（生产）具有相同的设置（应用程序设置和连接字符串）

我建议检查https://ruslany.net/2015/09/how-to-warm-up-azure-web-app-during-deployment-slots-swap/

推荐阅读