Diagnose failures before creat…

# FastAPI + Celery 容器崩溃诊断与修复

一、典型根因分析（按概率排序）

由于你未提供具体报错日志，以下是“加Celery后容器重启3次”最常见的原因，请对照排查：

1. 单容器试图同时跑两个进程（最常见）

• 原Dockerfile的CMD/entrypoint只启动uvicorn，加了Celery后有人改成 python app.py && celery worker... 之类的写法
• && 要求前者持续运行，& 后台进程随主进程退出被杀，导致容器异常退出，触发restart policy循环重启

2. Celery worker 与 FastAPI 用同一个 CMD，配置缺失导致立即崩溃

• Celery broker（Redis/RabbitMQ）连接串未配置或环境变量没传入
• Celery在容器内连不上broker，抛异常退出 → restart policy反复拉起

3. 依赖/导入问题

• tasks模块import了应用内其他模块，触发循环导入或缺少依赖包（镜像未重新build）
• Celery 5.x 要求应用实例显式命名空间，app.autodiscover_tasks() 路径写错也会启动即崩

4. 资源与信号问题

• 容器内存限制过低，worker并发prefork进程数超限被OOM kill
• 未设置 --max-tasks-per-child 或没正确处理SIGTERM（pid 1问题）

二、诊断步骤（先做这个）

1. 看日志定位真实报错：docker logs <容器id> --tail 100，重点看退出码（137=OOM，1=应用错误）

2. 确认退出原因：docker inspect <容器id> | grep -A5 State

3. 本地复现：进容器手动跑 celery -A yourapp worker --loglevel=debug，看具体堆栈

4. 检查broker连通性：容器内 telnet/nc redis主机端口

三、修复计划

阶段1：架构修正（当天）

• Celery worker 单独一个容器，与FastAPI用同一镜像但不同command（docker-compose中定义两个service）
• 通过环境变量统一注入broker URL，加入healthcheck

阶段2：健壮性加固（1-2天）

• 镜像确认包含所有Celery依赖后重新build（docker compose build --no-cache）
• broker连接加指数退避重试（broker_connection_retry_on_startup=True）
• 调整worker并发数适配容器内存限制，启用 --prefetch-multiplier=1

阶段3：验证

• docker compose up 后观察5分钟无重启，触发一个测试任务验证全链路

如果你把 docker logs 的最后几十行贴出来，我可以直接告诉你具体是哪一条原因。