Первые шаги в работе с Django

Использование Celery с Django

Примечание

Предыдущие версии Celery требовали отдельной библиотеки для работы с Django, но начиная с версии 3.1 это больше не так. Теперь Django поддерживается из коробки, поэтому этот документ содержит только базовый способ интеграции Celery и Django. Вы будете использовать тот же API, что и пользователи не-Django, поэтому рекомендуем вам сначала прочитать учебник Первые шаги с сельдереем и вернуться к этому учебнику. Когда у вас будет рабочий пример, вы сможете перейти к руководству Следующие шаги.

Примечание

Celery 5.0.x поддерживает Django 1.11 LTS или более новые версии. Пожалуйста, используйте Celery 4.4.x для версий старше Django 1.11.

Чтобы использовать Celery в вашем проекте Django, вы должны сначала определить экземпляр библиотеки Celery (называемый «app»)

Если у вас есть современный макет проекта Django, например:

- proj/
  - manage.py
  - proj/
    - __init__.py
    - settings.py
    - urls.py

то рекомендуемый способ - создать новый модуль proj/proj/celery.py, определяющий экземпляр Celery:

файл:

proj/proj/celery.py

Затем вам нужно импортировать это приложение в ваш модуль proj/proj/__init__.py. Это гарантирует, что приложение будет загружено при запуске Django, чтобы декоратор @shared_task (о котором будет сказано позже) использовал его:

proj/proj/__init__.py:

Обратите внимание, что этот пример компоновки проекта подходит для больших проектов, для простых проектов вы можете использовать один содержащийся модуль, определяющий и приложение, и задачи, как в учебнике Первые шаги с сельдереем.

Давайте разберем, что происходит в первом модуле, во-первых, мы устанавливаем переменную окружения по умолчанию DJANGO_SETTINGS_MODULE для программы командной строки celery:

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings')

Эта строка не нужна, но она избавляет вас от необходимости постоянно передавать модуль настроек в программу celery. Он должен быть всегда перед созданием экземпляров приложения, что мы и делаем далее:

app = Celery('proj')

Это наш экземпляр библиотеки, у вас может быть много экземпляров, но при использовании Django для этого, вероятно, нет причин.

Мы также добавили модуль настроек Django в качестве источника конфигурации для Celery. Это означает, что вам не нужно использовать несколько конфигурационных файлов, а вместо этого конфигурировать Celery непосредственно из настроек Django; но вы также можете разделить их, если хотите.

app.config_from_object('django.conf:settings', namespace='CELERY')

Прописное имя означает, что все Celery configuration options должны быть указаны в верхнем регистре, а не в нижнем, и начинаться с CELERY_, поэтому, например, параметр task_always_eager становится CELERY_TASK_ALWAYS_EAGER, а параметр broker_url становится CELERY_BROKER_URL. Это относится и к рабочим параметрам, например, параметр worker_concurrency становится CELERY_WORKER_CONCURRENCY.

Например, конфигурационный файл проекта Django может включать:

settings.py
...

# Celery Configuration Options
CELERY_TIMEZONE = "Australia/Tasmania"
CELERY_TASK_TRACK_STARTED = True
CELERY_TASK_TIME_LIMIT = 30 * 60

Вы можете передать объект настроек напрямую, но лучше использовать строку, так как в этом случае рабочий не должен сериализовать объект. Пространство имен CELERY_ также необязательно, но рекомендуется (для предотвращения дублирования с другими настройками Django).

Далее, обычной практикой для многократно используемых приложений является определение всех задач в отдельном модуле tasks.py, и у Celery есть способ автоматического обнаружения таких модулей:

app.autodiscover_tasks()

С помощью приведенной выше строки Celery будет автоматически обнаруживать задачи из всех установленных приложений, следуя соглашению tasks.py:

- app1/
    - tasks.py
    - models.py
- app2/
    - tasks.py
    - models.py

Таким образом, вам не придется вручную добавлять отдельные модули к настройке CELERY_IMPORTS.

Наконец, пример debug_task - это задача, которая сбрасывает информацию о своем собственном запросе. Здесь используется новая опция задачи bind=True, представленная в Celery 3.1, чтобы легко ссылаться на текущий экземпляр задачи.

Использование декоратора @shared_task

Задачи, которые вы пишете, вероятно, будут жить в многоразовых приложениях, а многоразовые приложения не могут зависеть от самого проекта, поэтому вы также не можете импортировать экземпляр приложения напрямую.

Декоратор @shared_task позволяет создавать задачи, не имея конкретного экземпляра приложения:

demoapp/tasks.py:

См.также

Вы можете найти полный исходный код проекта примера Django по адресу: https://github.com/celery/celery/tree/master/examples/django/.

Относительный импорт

Вы должны быть последовательны в том, как вы импортируете модуль задач. Например, если у вас есть project.app в INSTALLED_APPS, то вы должны также импортировать задачи from project.app, иначе имена задач будут разными.

См. Автоматическое именование и относительный импорт

Расширения

django-celery-results - Использование Django ORM/Cache в качестве бэкенда результатов

Расширение django-celery-results предоставляет бэкенды результатов, использующие либо Django ORM, либо Django Cache framework.

Чтобы использовать это в своем проекте, необходимо выполнить следующие шаги:

  1. Установите библиотеку django-celery-results:

    $ pip install django-celery-results

  2. Добавьте django_celery_results к INSTALLED_APPS в settings.py вашего проекта Django:

    INSTALLED_APPS = (
    ...,
    'django_celery_results',
)

    Обратите внимание, что в имени модуля нет тире, только подчеркивание.

  3. Создайте таблицы базы данных Celery, выполнив миграцию базы данных:

    $ python manage.py migrate django_celery_results

  4. Настройте Celery на использование бэкенда django-celery-results.

    Предполагая, что вы используете settings.py от Django, чтобы также настроить Celery, добавьте следующие параметры:

    CELERY_RESULT_BACKEND = 'django-db'

    Для бэкенда кэша вы можете использовать:

    CELERY_RESULT_BACKEND = 'django-cache'

    Мы также можем использовать кэш, определенный в настройках CACHES в django.

    # celery setting.
CELERY_CACHE_BACKEND = 'default'

# django setting.
CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.db.DatabaseCache',
        'LOCATION': 'my_cache_table',
    }
}

    Дополнительные параметры конфигурации см. в справочнике Настройки бэкенда результатов задачи.

django-celery-beat - Периодические задачи с поддержкой базы данных и интерфейсом администратора.

Дополнительную информацию см. в разделе Использование пользовательских классов планировщика.

Запуск рабочего процесса

В производственной среде вы захотите запускать worker в фоновом режиме как демон - см. Демонизация - но для тестирования и разработки полезно иметь возможность запускать экземпляр worker с помощью команды управления celery worker, так же как вы используете команду Django manage.py runserver:

$ celery -A proj worker -l INFO

Для получения полного списка доступных опций командной строки используйте команду help:

$ celery help

Куда двигаться дальше

Если вы хотите узнать больше, вам следует перейти к учебнику Next Steps, а после него вы можете изучить User Guide.

Django
<no title>
Вернуться на верх