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>

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

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

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

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

1 个答案: