Cookiecutter Django项目Celery本地正常生产不工作排查

1. django-cookiecutter 集成Celery生产环境是否需要额外特殊配置 #

默认生成的cookiecutter-django生产配置已经覆盖绝大多数常规场景，不需要做大量特殊改动，仅需确认以下配置和部署逻辑符合要求即可：

• 确认CELERY_ALWAYS_EAGER = False（你当前配置正确，已排除本地同步执行任务的干扰）
• 确认CELERY_BROKER_URL和CELERY_RESULT_BACKEND指向生产环境可正常访问的Redis服务地址，容器部署场景不要填写localhost/127.0.0.1，需替换为服务名或Redis实际内网地址
• 确认生产配置中Celery日志级别未被设置为静默，默认生成的配置日志级别为INFO，可正常输出运行日志
• 不要将Celery进程和Django Web进程放在同一个容器内运行，cookiecutter-django默认生产部署为多服务拆分架构，Celery Worker/Beat/Flower都是独立进程，需要单独启动

2. 问题根因定位&可行调试方案 #

从你提供的Dockerfile可以直接定位核心问题：镜像默认CMD只执行/start脚本，该脚本仅启动Gunicorn Web服务，不会启动任何Celery相关进程，自然不会产生Celery日志，任务也不会被消费。

cookiecutter-django默认的生产Docker部署基于docker-compose编排多容器，每个服务单独运行一个进程：

• Web服务：执行/start启动Gunicorn
• Celery Worker服务：执行/start-celeryworker启动任务消费进程
• Celery Beat服务：执行/start-celerybeat启动定时任务调度进程
• Flower服务：执行/start-flower启动Celery监控面板
• Redis、PostgreSQL作为独立基础服务运行

你使用CapRover部署时如果仅部署了单个Web容器，没有单独配置Celery相关服务实例，Celery进程压根不会运行。

分步调试排查步骤 #

按以下顺序排查可快速定位问题：

• 第一步：确认进程存活状态
  进入运行中的Django容器内部，执行ps aux | grep celery，如果没有任何celery相关进程，就说明Celery未启动，这也是你当前遇到的核心问题。
• 第二步：验证Redis连通性
  在Django容器内执行celery -a config.celery inspect ping（如果你的Celery入口文件路径不是config/celery.py，替换为项目实际的Celery app路径即可），如果返回pong说明Worker和Redis连通正常，如果报连接错误，就检查CELERY_BROKER_URL配置和Redis服务的网络访问权限。
• 第三步：前台手动启动Celery看报错
  在容器内直接手动执行/start-celeryworker，查看前台输出的报错信息，常见报错包括配置文件加载失败、Redis密码错误、依赖缺失、文件权限问题，前台输出信息可直接定位启动失败原因。
• 第四步：检查日志重定向配置
  打开项目内compose/production/django/celery/worker/start脚本，确认启动命令没有把日志重定向到本地文件，默认配置是将日志输出到stdout/stderr，Docker才能正常捕获日志，如果被重定向到容器内本地文件，用docker logs命令就看不到日志内容。
• 第五步：修正CapRover部署配置
  需要在CapRover里单独新增Celery Worker、Celery Beat的应用实例，使用和Web服务相同的镜像，但是把启动命令分别改成/start-celeryworker和/start-celerybeat，不需要暴露端口，和Web服务共用同一个Redis、数据库服务即可。

你当前Dockerfile存在的额外问题 #

你在Dockerfile中写了VOLUME captain---voldata:/app，该配置会把整个/app目录挂载为外部卷，后续重新构建镜像发布时，如果不清理旧卷，容器会一直使用旧卷内的代码，新构建的代码不会生效，很容易导致配置改动不生效的问题，建议删除该挂载配置，或者仅挂载需要持久化的media、static目录，不要挂载整个/app目录。

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