如何无60秒停机通过ZipDeploy部署ASP.NET Core到Azure Linux应用服务

可能的原因 #

1. Visual Studio发布的部署策略差异 #

VS的默认发布流程可能采用了直接替换容器实例的方式，而非az webapp deploy/VS Code使用的平滑部署策略（如渐进式滚动更新、蓝绿部署）。这种直接替换会导致新容器启动时，旧容器先保留，但新容器因启动探针未通过被重建，期间出现站点无响应的间隙。而az webapp deploy等工具会等待新容器启动就绪后再切换流量，避免停机。

2. 启动探针配置与容器启动时机不匹配 #

Azure Linux应用服务的默认启动探针可能初始延迟时间过短，在ASP.NET Core应用完成初始化前就开始检测健康状态。VS发布生成的容器可能在启动时需要加载更多依赖或执行初始化操作，导致探针首次检测失败，触发容器重建。尽管偶尔成功的案例耗时未缩短，但可能是探针重试周期刚好赶上了应用启动完成的节点。

3. VS发布的镜像构建差异 #

VS发布时生成的容器镜像可能与az webapp deploy/VS Code的构建产物存在差异：

• 可能使用了不同的基础镜像或打包参数，导致容器启动时间变长；
• 可能包含了不必要的调试文件或依赖，增加了启动负载；
• 未启用ReadyToRun编译等优化，导致应用启动初始化耗时增加。

4. 部署初始化逻辑缺失 #

VS发布流程可能未配置部署钩子或预启动脚本，比如数据库迁移、缓存预热等操作被放到容器启动后执行，导致应用启动初期负载过高，无法及时响应启动探针。而az webapp deploy等工具可能默认执行了这些预启动操作，降低了容器启动后的压力。

排查与解决建议 #

• 调整启动探针配置：在Azure门户的应用服务「配置」->「容器」->「启动探针」中，增加初始延迟时间（例如从5秒调整为30秒），提高重试次数和超时时间，给ASP.NET Core足够的启动初始化时间。
• 修改VS发布策略：在VS的发布配置中，尝试启用「渐进式部署」或「蓝绿部署」选项（若支持），确保新容器就绪后再切换流量，避免直接替换导致的停机。
• 对比镜像启动日志：查看Azure「日志流」中容器启动的详细日志，记录ASP.NET Core输出Now listening on:的时间点，对比启动探针的首次检测时间，确认是否是探针检测过早。
• 优化应用启动速度：
  • 启用ASP.NET Core的ReadyToRun编译，减少JIT编译时间；
  • 将非必要的初始化操作（如数据库迁移）移至后台任务；
  • 移除调试依赖和不必要的静态资源，减小镜像体积。

内容的提问来源于stack exchange，提问作者eikuh