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

Question

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

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

主机环境：Azure 应用服务（带插槽）

应用设置：

分期：

• WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG：1
• DatabaseMode：只读（特定于插槽）
• 其他

直播：

• WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG：1
• 其他

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

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

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

我们所看到的：

• 新版本部署到暂存 - 应用重新启动，内容不同步（好）
• 交换开始，实时设置应用于暂存 - 应用重启，内容同步（良好）
• 交换发生
• 暂存设置应用于“旧直播” - 应用重新启动，内容同步（错误），即使 (DatabaseMode: ReadOnly) 被应用为粘性暂存设置。
• 交换完成
• 暂存槽启用了 DatabaseMode: ReadOnly，进一步手动重启不会同步内容。

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

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

Answer 1

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

现在，只是想分享一些您可能知道的更多细节。 应用程序设置 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>

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

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

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