Djangoの最初のステップ—Pythonドキュメント

提供：Dev Guides
Celery/docs/latest/django/first-steps-with-django
移動先:案内、検索

Djangoの最初のステップ

DjangoでCeleryを使用する

ノート

以前のバージョンのCeleryでは、Djangoと連携するために別のライブラリが必要でしたが、3.1以降、これは当てはまりません。 Djangoはすぐにサポートされるようになったため、このドキュメントにはCeleryとDjangoを統合する基本的な方法のみが含まれています。 Django以外のユーザーと同じAPIを使用するため、最初に Celeryの最初のステップチュートリアルを読んでから、このチュートリアルに戻ることをお勧めします。 実用的な例があれば、次のステップガイドに進むことができます。


ノート

Celery 5.0.xは、Django 1.11LTS以降のバージョンをサポートしています。 Django 1.11より古いバージョンには、Celery4.4.xを使用してください。


DjangoプロジェクトでCeleryを使用するには、最初にCeleryライブラリのインスタンス（「アプリ」と呼ばれる）を定義する必要があります。

次のような最新のDjangoプロジェクトレイアウトがある場合： 

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

次に、推奨される方法は、Celeryインスタンスを定義する新しい proj / proj / celery.py モジュールを作成することです。

ファイル
proj / proj / celery.py
import os

from celery import Celery

# Set the default Django settings module for the 'celery' program.
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings')

app = Celery('proj')

# Using a string here means the worker doesn't have to serialize
# the configuration object to child processes.
# - namespace='CELERY' means all celery-related configuration keys
#   should have a `CELERY_` prefix.
app.config_from_object('django.conf:settings', namespace='CELERY')

# Load task modules from all registered Django apps.
app.autodiscover_tasks()


@app.task(bind=True)
def debug_task(self):
    print(f'Request: {self.request!r}')

次に、このアプリをproj/proj/__init__.pyモジュールにインポートする必要があります。 これにより、Djangoの起動時にアプリが確実に読み込まれ、@shared_taskデコレータ（後述）がアプリを使用するようになります。

proj/proj/__init__.py： 

# This will make sure the app is always imported when
# Django starts so that shared_task will use this app.
from .celery import app as celery_app

__all__ = ('celery_app',)

このサンプルプロジェクトレイアウトは大規模なプロジェクトに適していることに注意してください。単純なプロジェクトでは、 Celeryの最初のステップチュートリアルのように、アプリとタスクの両方を定義する単一の含まれるモジュールを使用できます。

最初のモジュールで何が起こるかを分析してみましょう。最初に、 celery コマンドラインプログラムのデフォルトの DJANGO_SETTINGS_MODULE環境変数を設定します。 

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

この行は必要ありませんが、設定モジュールをceleryプログラムに常に渡す必要がありません。 次に行うことと同様に、アプリインスタンスを作成する前に必ず実行する必要があります。 

app = Celery('proj')

これはライブラリのインスタンスです。多くのインスタンスを持つことができますが、Djangoを使用する場合はおそらくその理由はありません。

また、Celeryの構成ソースとしてDjango設定モジュールを追加します。 つまり、複数の構成ファイルを使用する必要はなく、代わりにDjango設定から直接Celeryを構成します。 ただし、必要に応じてそれらを分離することもできます。 

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

大文字の名前空間は、すべての Celery構成オプションを小文字ではなく大文字で指定し、CELERY_で始める必要があることを意味します。たとえば、：setting： `task_always_eager` [ X208X]の設定はCELERY_TASK_ALWAYS_EAGERになり、：setting： `broker_url` の設定はCELERY_BROKER_URLになります。 これはワーカー設定にも適用されます。たとえば、：setting： `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

このようにして、個々のモジュールを手動で追加する必要はありません。 ：setting： `CELERY_IMPORTS ` 設定。

最後に、debug_taskの例は、独自の要求情報をダンプするタスクです。 これは、Celery3.1で導入された新しいbind=Trueタスクオプションを使用して、現在のタスクインスタンスを簡単に参照します。

@shared_taskデコレータの使用

作成したタスクはおそらく再利用可能なアプリに存在し、再利用可能なアプリはプロジェクト自体に依存できないため、アプリインスタンスを直接インポートすることもできません。

@shared_taskデコレータを使用すると、具体的なアプリインスタンスがなくてもタスクを作成できます。

demoapp/tasks.py： 

# Create your tasks here

from demoapp.models import Widget

from celery import shared_task


@shared_task
def add(x, y):
    return x + y


@shared_task
def mul(x, y):
    return x * y


@shared_task
def xsum(numbers):
    return sum(numbers)


@shared_task
def count_widgets():
    return Widget.objects.count()


@shared_task
def rename_widget(widget_id, name):
    w = Widget.objects.get(id=widget_id)
    w.name = name
    w.save()

も参照してください

Djangoサンプルプロジェクトの完全なソースコードは、 https://github.com/celery/celery/tree/master/examples/django/にあります。


拡張機能

django-celery-results-結果のバックエンドとしてDjangoORM / Cacheを使用する

：pypi： `django-celery-results` 拡張機能は、DjangoORMまたはDjangoCacheフレームワークのいずれかを使用して結果バックエンドを提供します。

これをプロジェクトで使用するには、次の手順に従う必要があります。

  1. ：pypi： `django-celery-results` ライブラリをインストールします。

    $ pip install django-celery-results

  2. Djangoプロジェクトのsettings.pyのINSTALLED_APPSにdjango_celery_resultsを追加します。

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

    モジュール名にはダッシュはなく、アンダースコアのみであることに注意してください。

  3. データベースの移行を実行して、Celeryデータベーステーブルを作成します。

    $ python manage.py migrate django_celery_results

  4. ：pypi： `django-celery-results` バックエンドを使用するようにCeleryを構成します。

    Djangoのsettings.pyを使用してCeleryも構成していると仮定して、次の設定を追加します。

    CELERY_RESULT_BACKEND = 'django-db'

    キャッシュバックエンドには、次のものを使用できます。

    CELERY_RESULT_BACKEND = 'django-cache'

    djangoのCACHES設定で定義されたキャッシュを使用することもできます。

    # celery setting.
CELERY_CACHE_BACKEND = 'default'

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

    追加の構成オプションについては、タスク結果バックエンド設定リファレンスを参照してください。


django-celery-beat-管理インターフェースを備えたデータベースに裏打ちされた定期的なタスク。

詳細については、カスタムスケジューラクラスの使用を参照してください。


ワーカープロセスの開始

実稼働環境では、ワーカーをデーモンとしてバックグラウンドで実行する必要があります（デーモン化を参照）が、テストと開発では、を使用してワーカーインスタンスを起動できると便利です。 celery worker は、Djangoの manage.py runserver を使用するのと同じように、コマンドを管理します。 

$ celery -A proj worker -l INFO

使用可能なコマンドラインオプションの完全なリストについては、helpコマンドを使用してください。 

$ celery help

ここからどこへ行くか

詳細については、次のステップチュートリアルに進む必要があります。その後、ユーザーガイドを学習できます。



「https://www.finddevguides.com/index.php?title=Celery/docs/latest/django/first-steps-with-django&oldid=94316」から取得
Powered by MediaWiki