Что за магия в работе Celery с использованием Docker?

Question

[dimonkoz]

Проект с двумя сервисами на django и flask добрался до момента, что некоторые запросы требует страта запуска тяжелых асинхронных задач. Раньше уже использовал Celery+Django с брокером Redis в небольшом проекте для работы таска по расписанию. Но...
Не могу понять как это работает внутри Docker-контейнеров
Допустим есть 3 контейнера:
- django_web
- redis
- celery_worker
django_web и celery_worker используют redis как брокер. Таски определены в контейнере django_web
Вопрос: Каким образом Celery-воркер в celery_worker-контейнере выполняет такс? У контейнера с воркером нет доступа к функции и операциям. Неужели все содержимое такса каким-то образом передается через брокер и ему неважно, где располагается код? Или передается только имя+сигнатура.
Не могу найти практику как правильно использовать Celery в контейнерах

Answer 1

[Anton Kuzmichev]

Воу-воу, сам на днях буду переносить celery в docker.
Но ваш вопрос немного не о том. Он скорее о понимании, как вообще работает celery.

Неужели все содержимое такса каким-то образом передается через брокер и ему неважно, где располагается код? Или передается только имя+сигнатура.

Только описание, какое задание надо выполнить, с какими входными параметрами. Никакого кода не передаётся.

Возьмём Django + Celery.
Типичный, описанный в документации и используемым самим celery для интеграции с django, шаблон использования таков: вы создаёте в django-приложениях файл tasks.py, в котором создаются функции, декорируемые @task. В этих функциях вы описываете логику этих заданий.

В таком случае, веб-приложение и воркеры используют один и тот же код. И в контейнеры django_web и celery_worker надо упаковывать одно и то же. Просто запускаться это будет по разным сценариям: django_web будет обрабатывать http-запросы, celery_worker будет обрабатывать поступающие задания.

Comments

[dimonkoz]

Антон, вот я тоже видел некоторые ответы на Stack Overflow об упаковки кода задач в каждый контейнер. Но вот другой пример.
https://blog.syncano.io/configuring-running-django...
Как раз таким же подобным образом, я выполнил задачу сложения двух чисел (с описанием и вызовом в django на локалхосте, worker и redis в контейнерах), и каким-то образом (по логам) контейнер с воркером не только получил команду на вызов задачи, но и успешно выполненил тело (напечатал результат сложения). Вот это меня удивило. Я понял, где-то я плыву
Так нужно ли упаковывать код в контейнер?

[Anton Kuzmichev]

dimonkoz: посмотрел ссылку, там же в compose-файле видно, что образы веб и воркера создаются из одного докерфайла, монтируется вольюм с кодом. Только запускаются разные скрипты: run_web.sh для веба, run_worker.sh для воркера

[dimonkoz]

Да спасибо, не заметил монтирования папки приложения. Но это никак не объясняет то, как воркер в докер-контейнере умудрился выполнить функцию, которой у этом контейнере нет в моем тесте?
Я сегодня еще раз исследую и проверю этот вопрос, может у меня руки оказались кривыми)) Напишу результат тогда

[Павел]

services:
    web:
        build: ./web
        command: /usr/local/bin/gunicorn -w 4 -b :5000 autoapp:app
    celery:
        build: ./web
        command: celery worker --app=autoapp.celery

В данном случае создаётся 2 контейнера на основе одно и того же образа. Таким образом, м само приложение и celery использует один и тот же код. А задания проходят через брокер.

[Anton Kuzmichev]

dimonkoz, ну как в итоге, получилось?

Answer 2

[Алексей Черемисин]

Я тут недавно сделал задачи на RQ - очень все просто и комфортно, правда многого нет, того что в celery, но оно мне и не нужно. - python-rq.org
Рекомендую, если есть вопросы - задавайте.
И да, а в чем проблема с докером? Передаются имя метода и параметры, так как все воркеры имеют доступ к тому же самому коду, что и паблишер, то воркер спокойно вызывает нужный метод с нужными аргументами, только позаботьтесь о внешних ресурсах типа коннекта к базе, перед вызовом воркер-инстанса.