Azure Web App for Containers运行非Web容器失败咨询

Azure Web App for Containers 不支持直接关闭内置的HTTP启动探测，但完全可以在不部署完整Web服务的前提下运行你的后台消息处理容器，不需要额外付费改造。

报错原因 #

你看到的启动失败是平台的固定逻辑：

• 容器启动后，平台会持续向你配置的暴露端口（当前是Dockerfile里声明的80端口）发送HTTP探测请求
• 只要容器在230秒的超时窗口内返回任意2xx/3xx状态码，平台就会判定容器启动成功，不会强制终止进程
• 你当前的容器没有任何进程监听80端口响应请求，超时后自然会被平台回收

最小改造方案 #

你不需要引入Flask、Django这类重型Web框架，两种零成本改法选一个就行：

方案1：启动命令加内置HTTP服务（不用改业务代码） #

你用的python:3.8-slim-buster基础镜像自带busybox，直接修改Dockerfile的启动命令，后台起一个极简HTTP服务响应探测，前台跑你的原有业务逻辑即可，修改后的CMD配置如下：

# 其他配置保持不变
CMD ["sh", "-c", "busybox httpd -f -p 80 & python ./main.py"]

这个命令启动的HTTP服务会默认对80端口的所有请求返回200状态码，完全满足平台探测要求，不会占用多少资源。

方案2：代码内加轻量探测响应逻辑 #

如果不想改Dockerfile，也可以在Python代码里用标准库自带的HTTP模块起一个后台线程响应ping，原有业务逻辑完全不用动，改造后的示例代码：

import logging
import time
import threading
from http.server import BaseHTTPRequestHandler, HTTPServer

class PingHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b'status: ok')
    # 屏蔽默认访问日志，避免冗余日志刷屏
    def log_message(self, format, *args):
        return

def start_ping_server():
    server = HTTPServer(('0.0.0.0', 80), PingHandler)
    server.serve_forever()

if __name__ == '__main__':
    logging.basicConfig(level=logging.INFO)
    # 守护线程启动HTTP服务，不阻塞主业务逻辑
    threading.Thread(target=start_ping_server, daemon=True).start()
    
    # 原有业务逻辑保持不变
    count = 0
    while True:
        time.sleep(30)
        count += 30
        logging.info(f'Busy counting: {count}')

配置注意事项 #

• 如果不想用80端口，可以自行修改监听端口，同时在Web App的应用设置中添加WEBSITES_PORT参数，值填你实际使用的端口号，和Dockerfile的EXPOSE声明保持一致即可
• 不要开启强制HTTPS、URL重写类的规则，避免拦截平台的HTTP探测请求
• 这种方式虽然能跑通后台任务，但Web App for Containers的设计定位是Web服务托管，长期运行队列消费类无状态后台任务，更推荐使用队列触发的Azure Functions、Azure Container Apps这类专门为后台工作负载设计的服务，稳定性会更好。

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