交换插槽时，为什么Azure应用服务会重新启动？

Question

这个问题在生产中已经存在很长时间了，并且阅读了我能找到的所有内容（例如this或this或that）之后，我进行了一个简单的测试。

1. 创建一个空的asp.net网站
2. 在Application_Start中，向您发送电子邮件或消息（我已经使用过PushBullet），以便您知道应用何时启动
3. 创建新的应用服务计划和资源组
4. 在Azure上创建网站并发布
5. 创建临时部署插槽
6. 交换演出/制作
7. 再次发布网站，以便两个插槽都具有相同版本的网站

所以我有一个空的网站，没有连接字符串，没有插槽设置：

单击交换时，我将收到有关插槽重新启动的通知（每个插槽至少重新启动一次）。

为什么会这样？

更新：

研究了Mohit的答案后，我需要进一步澄清。

• 我们以Application_Start方法发送通知，如果我理解正确，则该通知由AppInit事件触发。

• 我不理解您所解释的行为。该顺序似乎对确保没有停机时间非常重要，但是您说不一定按该顺序进行。为什么需要重新启动生产槽的应用程序域？为什么用户会为该网站关闭而烦恼（应该不会）？

• 什么是“新交换”功能？ “旧交换”有什么区别？为了测试，我只是使用门户进行了交换。

• 您提到“新交换”在交换之前暂停。我想这只是意味着它等待applicationInitialization完成（例如/上的HTTP 200）？

• 从昨天开始，我做了更多测试。在Application_Start方法中，我添加了一些Thread.Sleep来延长应用程序的启动时间。但是，当我调换产品时，无论是分期还是生产，都不会停机。我是否应该至少在应用程序启动期间经历登台停机时间？这是否意味着预热然后与生产交换的插槽实际上是另一个既不是临时也不是生产的临时插槽？

Answer 1

交换操作可能导致重新启动。但是，它保证的是，在将插槽更换为生产环境之前，已经对其进行了预热，因此，站点用户因此不会看到任何停机时间。

也根据此线程，Preventing staging site restart during a swap

如果没有重新启动，则在交换期间将不会重新执行appinit模块，因为它仅在初始化工作进程时运行。如果要确保始终重启，则可以创建一些虚拟应用程序设置并将其标记为插槽设置。

您是否通过AppInit事件触发电子邮件？

交换执行以下活动：

•源插槽将被预热。 Azure通过将几个请求触发到插槽的根中来做到这一点。您还可以配置自定义预热规则。

•Azure交换源插槽和目标插槽的虚拟IP地址，从而交换插槽的URL。

•它还适用于（或保留，取决于您如何看待）特定于目标插槽的某些设置。  o发布端点  o自定义域名  o SSL证书和绑定  o比例设置  o WebJobs调度程序  o网站扩展

假设有一个“ staging”和“ production”插槽，其行为大致如下（不一定按此顺序）：

•开始交换

•用于“生产”的配置已应用于“登台”站点-应用域已重新启动

•用于“登台”的配置已应用于“生产”站点-应用域已重新启动

•DNS / IP设置已更新，交换已完成

•用户对网站现在暂时“关闭”感到恼火

如果您使用“新交换”选项，它仍将重新启动应用程序域，但会在其实际应用交换之前暂停，从而使您有时间在重新启动“暂存”实例之前对其进行热身。

请详细了解此线程-https://stackify.com/azure-deployment-slots/

Answer 2

我有一个非常相似的问题，应用切换到生产版位后会重新启动，这会导致不必要的停机时间。经过大量搜索，我发现了以下内容：

在某些情况下，交换后，生产版位中的Web应用可能稍后会重新启动，而应用所有者没有采取任何措施。当Azure App Service的基础存储基础结构进行某些更改时，通常会发生这种情况。发生这种情况时，该应用程序将同时在所有VM上重新启动，这可能会导致冷启动和HTTP请求的高延迟。虽然您无法控制基础存储事件，但是可以将其对生产插槽中的应用程序的影响降至最低。在应用程序的每个插槽上设置此应用程序设置：

WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG：将其设置为“ 1”将防止Web应用程序的工作进程和应用程序域在重新配置App Service的存储基础结构时被回收。

您可以找到整个Ruslany帖子，我发现这很有帮助here