我现在正在为同样的事情而苦苦挣扎。这就是我的看法:
执行任务的通信应用程序和执行任务的worker有两端。
工人不需要知道应用程序!对于工人部分来说,了解 celeryconfig 就足够了。您可以使用 celery worker --config=mypackage.celeryconfig 传递它。工作人员将使用 BROKER_URL 连接到队列。记得在那里声明 CELERY_IMPORTS 以便工人知道在哪里寻找任务定义。
客户端应用程序必须知道将其请求发送到何处。因此必须使用传递配置文件的方法之一传递相同的配置。我选了这个:
from __future__ import absolute_import
from celery import Celery
celery = Celery()
import backend.async.celeryconfig
celery.config_from_object(backend.async.celeryconfig)
当我在没有守护程序的情况下运行它时,此设置对我有用,但由于某种原因,守护程序会忽略我的 CELERY_CONFIG_MODULE 设置。
更新:
CELERY_CONFIG_MODULE 不在任何地方的 /etc/init.d/celeryd 脚本中使用!
相反,我把它放在 CELERYD_OPTS 中,它就像一个魅力。:
CELERYD_OPTS="--config=backend.async.celeryconfig"
另一件事是 VIRTUAL_ENV 变量在 celeryd 脚本中也被忽略了。另一方面,celerybeat scirpt 激活了虚拟环境,所以我建议的配置是:
CELERYBEAT_OPTS="--schedule=/var/run/celerybeat-schedule --config=backend.async.celeryconfig"
VIRTUAL_ENV="/path/to/.virtualenvs/your_env"
# Python interpreter from environment.
ENV_PYTHON="$VIRTUAL_ENV/bin/python"
# How to call "celeryd-multi"
CELERYD_MULTI="$VIRTUAL_ENV/bin/celeryd-multi"
#CELERYD="$VIRTUAL_ENV/celeryd"
# How to call "celeryctl"
CELERYCTL="$VIRTUAL_ENV/bin/celeryctl"
# How to call "celerybeat"
CELERYBEAT="$VIRTUAL_ENV/bin/celerybeat"