Это вторая часть в серии о Джанго в производстве. Если вы еще этого не сделали, прочитайте часть 1 здесь .
В своем последнем посте я подробно описал основной стек, который обеспечивает работу приложения Django. Во второй части я расскажу о том, что стало обычным явлением в современных веб-приложениях, — о фоновых задачах.
Часто веб-сайты выполняют сложные задачи, выполнение которых занимает много времени. Эти задачи не всегда нужно выполнять перед отправкой ответа в браузер, поэтому их можно выполнить в другом месте. В подобных случаях задачи могут выполняться асинхронно одним или несколькими «работниками», которые используют очередь задач.
Сельдерей
Наиболее распространенная очередь задач, используемая с Django, по крайней мере, по моему опыту, называется Celery .
Celery — это асинхронная очередь задач / очередь заданий, основанная на распределенной передаче сообщений. Он ориентирован на работу в режиме реального времени, но также поддерживает планирование.
Сельдерей никак не зависит от Django — это совершенно отдельное приложение. Однако он очень хорошо интегрируется с проектами Django. Установив пакет django-celery и добавив djcelery в список INSTALLED_APPS, можно запускать и управлять Celery через сам Django — благодаря набору удобных команд управления.
Этот пост не о том, как заставить работать сельдерей, поэтому я пропущу детали. Для получения дополнительной информации об использовании Celery с Django документация проекта превосходна.
Сельдерей в производстве
Запускать Celery локально легко: простой python manage.py celeryd делает свое дело. В производстве, однако, требуется что-то более надежное.
К счастью, это совсем не сложно. Так же, как Gunicorn, Celery может находиться под наблюдением Supervisor.
Если вы не читали Часть 1 Django in Production (The Stack) , сейчас самое время сделать это.
Чтобы добавить Celery в нашу конфигурацию Supervisor, необходимо выполнить следующее:
[program:app_name_celery_worker] command=/path/to/env/bin/python manage.py celeryd -E -l info directory=/path/to/app/ user=www-data autostart=true autorestart=true stdout_logfile=/path/to/app/django_logs/celeryd.log redirect_stderr=true
На самом деле, Celery даже поставляется с некоторыми примерами файлов конфигурации Supervisor , которые можно адаптировать к конкретным потребностям производственной установки.
Эту конфигурацию можно добавить в тот же файл, который содержит программные директивы сервера приложений. Таким образом все демоны приложения будут аккуратно собраны в одном файле.
Рабочие узлы
В процессе разработки рабочий Celery обычно запускается в другом окне терминала, рядом с сервером разработки. Этот же метод не может быть принят, хотя, для производственной установки.
Сначала, возможно, работники очереди задач могут работать на том же сервере, что и само приложение. По мере роста приложения наступает момент, когда имеет смысл иметь хотя бы один сервер, выделенный для выполнения асинхронных задач. Затем его можно масштабировать для соответствия, добавляя все больше и больше рабочих серверов по мере необходимости.
RabbitMQ
Сельдерей использует передачу сообщений для постановки в очередь задач для рабочих. Это обеспечивается совершенно отдельным приложением — брокером сообщений .
Наиболее часто используемый брокер сообщений в Celery, который пользуется наибольшей поддержкой — RabbitMQ . Детали того, как настроить RabbitMQ, немного выходят за рамки этого поста, но документация по серверу полна и является хорошей отправной точкой.
Виртуальные Хосты
В большом приложении с более чем одним рабочим узлом брокер сообщений обычно размещается на выделенном хосте (или даже кластеризуется на нескольких хостах). В этом случае несколько приложений могут использовать один и тот же брокер сообщений.
RabbitMQ поддерживает этот тип конфигурации посредством использования виртуальных хостов (или VHosts). Подобно виртуальным хостам, используемым в Apache, они позволяют «разбить» одного брокера на несколько отдельных частей. Контроль доступа может быть настроен для каждого отдельного хоста, поэтому любое отдельное приложение не может повлиять на другое с помощью общего брокера.
Даже если ваш брокер сообщений используется только одним приложением, это приложение должно быть настроено с собственным виртуальным хостом и учетными данными.
Мониторинг
Трудно точно знать, что делает очередь задач, такая как Celery, так как она не представляет собой симпатичный веб-интерфейс для наблюдения. Однако за ним можно следить — и об этом я подробно расскажу в следующем посте этой серии.
Источник: http://www.robgolding.com/blog/2011/11/27/django-in-production-part-2—background-tasks/