我们在使用计划上有一个Azure Function v3示例，其中包括一个暂存槽，以减少部署期间的停机时间。
我们的部署流程是：
- 将代码部署到暂存插槽
- 启动分段插槽
- 将暂存插槽与生产插槽交换
- 停止分段插槽
我们使用Azure管道将代码.NET Core 3.1部署到暂存槽;以下是此步骤的YAML定义：
- task: AzureFunctionApp@1
displayName: 'Deploy to Staging Slot'
inputs:
azureSubscription: '****'
appType: functionApp
appName: '****'
package: '$(System.ArtifactsDirectory)/Build.zip'
deployToSlotOrASE: true
slotName: 'staging'
resourceGroupName: '****'我已经禁用了这一步之后的所有步骤，只运行这一步。一旦在Azure管道中完成了这一步，主应用程序，即生产插槽，重新启动，我开始收到503服务不可用约5秒钟，然后是冷启动。
我不明白的是，在没有交换的情况下将代码部署到暂存插槽如何会导致在生产插槽上重新启动。
我已确保禁用了自动交换，因此情况并非如此。
如何解释和修复？我们正在尝试完全移除503，并进行零停机部署。
**更新：**我已经尝试将WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG添加到暂存和生产插槽中。没有效果。
1条答案
按热度按时间muk1a3rh1#
我们遇到了一个相同的问题。即使我们的部署只部署ZIP（因此没有资源部署），我们也可以重现这个问题。所有建议的设置，如
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG和WEBSITE_RUN_FROM_PACKAGE已经是应用程序配置的一部分，所有其他设置对于两个插槽都是相同的，并且没有粘滞设置。在我们的情况下，有问题的设置是
WEBSITE_CONTENTSHARE。与WEBSITE_CONTENTAZUREFILECONNECTIONSTRING一起，这些设置对于在事件驱动的扩展计划（如消费计划）中存储函数应用代码和配置是必要的。根据说明文件，
WEBSITE_CONTENTSHARE必须是唯一的。可以从ARM模板中移除它，在这种情况下，将自动生成一个值。请检查Azure门户（或Kudo）中两个插槽的应用程序配置，以确保此设置具有唯一值。如果此设置的值不唯一，则会影响生产插槽的“缩放”，因为两个插槽现在共享相同的代码和配置。这似乎是在将代码部署到暂存插槽时重新启动生产插槽的原因。