Azure App Service下docker-compose未配置ports致Node.js Worker容器崩溃原因咨询

• 平台定位的固有偏差：Azure App Service的核心设计目标是托管对外提供HTTP/HTTPS服务的Web应用，从平台底层内置了强制的启动校验逻辑：它会扫描容器环境，判定是否存在可供外部访问的HTTP端口，如果在30秒的启动窗口期内没有检测到符合预期的端口配置，就会直接判定容器启动失败，触发强制重启，也就是你观察到的崩溃现象。
• 配置的实际作用和你的认知不一致：你在compose里写的ports: - 443:3000配置，本质上根本没有实现真正的端口打通（因为你的应用压根没在3000端口监听任何服务）。之所以加了这个配置容器就不崩，是因为Azure App Service的多容器部署模式会解析compose文件里的ports声明，只要发现配置了对外暴露的端口，就会认为容器符合Web应用的运行预期，直接跳过启动失败的判定流程，哪怕这个端口上没有任何应用进程在监听。
• 本地运行的逻辑差异：本地直接执行docker-compose up时，Docker引擎本身不会对容器做任何Web端口的强制探测，只要你的容器主进程（也就是Node.js worker的任务逻辑）不主动退出，容器就会持续正常运行，完全不关心是否有端口被监听。

• 误以为Azure App Service是通用的全场景容器运行平台，可以托管任何类型的容器工作负载。实际上它从设计之初就锚定了Web工作负载的场景，内置了大量和HTTP服务绑定的预设逻辑，完全不适配无端口的纯后台worker类应用。
• 误以为ports配置的唯一作用是把容器内部的端口映射给外部网络访问。在Azure App Service的运行场景下，这份配置同时承担了给平台传递“容器是合规Web应用”信号的作用，和你的实际业务监听需求毫无关系。
• 把业务逻辑的需求和平台托管的需求混为一谈：你的Node.js应用作为worker确实不需要监听任何端口，但平台层的托管校验逻辑不会主动适配你的业务需求，它只会按照自己的预设规则做启动判定。

• 如果暂时不更换运行平台：不要靠无意义的空端口映射蒙混过关，可以在你的worker应用里增加一个零业务逻辑的轻量HTTP监听服务（绑定3000端口），专门用来响应平台的健康检查请求，不对外提供任何业务能力。
• 从长期适配性考虑：纯worker类的无端口工作负载，更适合部署到对无Web端口场景兼容的容器运行环境，从根本上避免被App Service的Web预设逻辑限制。

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