部署在AWS Elastic Beanstalk的Django 2集成Celery后发布报错

我之前帮好几个开发者解决过EB上Celery部署的这类问题，这个错误本质是部署过程中脚本尝试和已经处于关机状态的Celery worker进程通信导致的。下面是几个亲测有效的解决方案，按推荐程度排序：

1. 用Supervisor管理Celery进程（最稳定的方案） #

EB默认不会帮你管理Celery这类自定义后台进程，用Supervisor来托管Celery，能自动处理部署时的启停，从根源避免进程状态冲突。

步骤如下：

• 在项目根目录创建.ebextensions文件夹（如果还没有的话）
• 新建supervisor_celery.config文件，内容如下：

  packages:
    yum:
      supervisor: []
  
  files:
    "/etc/supervisord.d/celery.ini":
      mode: "000755"
      owner: root
      group: root
      content: |
        [program:celery]
        command=/opt/python/run/venv/bin/celery -A 你的Django项目名 worker --loglevel=info
        directory=/opt/python/current/app
        user=wsgi
        numprocs=1
        autostart=true
        autorestart=true
        startsecs=10
        stopwaitsecs=600
        redirect_stderr=true
        stdout_logfile=/var/log/celery-worker.log
  
  container_commands:
    01_start_supervisor:
      command: "supervisord -c /etc/supervisord.conf"
    02_restart_celery:
      command: "supervisorctl restart celery"
      ignoreErrors: true
  

• 替换上面的你的Django项目名为实际项目名称（即settings.py所在的模块名）
• 部署时Supervisor会自动确保Celery进程处于正确状态，不会出现关机状态下的通信错误

2. 添加Pre-Deploy钩子提前停止Celery进程 #

如果暂时不想用Supervisor，可以在部署前强制停止现有Celery进程，避免后续操作碰到已关机的worker：

• 在.ebextensions里新建celery_stop.config：

  container_commands:
    01_stop_celery:
      command: "if ps aux | grep celery | grep -v grep > /dev/null; then sudo killall celery; fi"
      ignoreErrors: true
  

• 这里的ignoreErrors: true很关键——第一次部署时还没有Celery进程，不加的话会导致部署失败。这个钩子会在代码更新前杀掉所有Celery worker，确保部署环境干净。

3. 禁用Celery的远程控制功能 #

如果你的Celery配置启用了远程控制（比如用celery inspect、celery control这类命令），部署时脚本可能会尝试连接已关闭的worker，触发xmlrpclib的Fault 6错误。可以直接禁用远程控制：

在Django的settings.py里添加：

CELERY_WORKER_DISABLE_REMOTE_CONTROL = True

或者启动Celery worker时加上参数：

celery -A 你的项目名 worker --loglevel=info --without-gossip --without-mingle --without-heartbeat

这样能减少Celery worker之间的远程交互，避免状态冲突。

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