Redis y RabbitMQ pueden ser los intermediarios preferidos cuando se utiliza Celery, pero cuando se desarrolla localmente pueden parecer excesivos. La documentación de Celery 5.4 menciona que puede utilizar SQLite como intermediario experimental para el desarrollo local. Sin embargo, cuando navega a la página de backends y brokers de Celery, las únicas menciones de SQL son para el backend de SQLAlchemy . Afortunadamente, la página señala que "esta sección no incluye todos los backends y brokers".

Esta publicación le mostrará cómo implementar un broker SQLite (¡o cualquier SQL!) para Celery en un proyecto Django. Esta publicación no le enseñará a usar Celery: consulte la documentación oficial de Celery para eso.

Antes de comenzar

Para los propósitos de esta publicación, asumiremos que ya tienes un proyecto Django existente con Celery instalado siguiendo los pasos de la guía oficial "Primeros pasos con Django" de Celery. Un backend de Celery no es requerido, pero es posible que quieras seguir los pasos de la guía para instalar y configurar django-celery-results. Si no tienes claro cuál es la diferencia entre backends y brokers, consulta mi artículo "Comprensión de tareas, brokers, trabajadores y backends en Celery".

Todos los enlaces a la documentación fuente serán para las versiones actuales de Django, Celery y SQLAlchemy en el momento de la publicación (julio de 2024), excepto que se indique explícitamente lo contrario. Si estás leyendo esto en un futuro lejano, es posible que las cosas hayan cambiado.

Configurar el corredor SQL

Mientras Celery administra tareas y colas, delega en otra biblioteca llamada Kombu el intercambio de mensajes con el corredor. RabbitMQ y Redis son los transportes (brokers) con más funciones de Kombu, pero también tiene transportes virtuales para Amazon SQS, ZooKeeper y MongoDB.

Escondido en los rincones más alejados de la documentación de Kombu, hay un modelo de transporte SQLAlchemy que admite PostgreSQL, MySQL y SQLite. Érase una vez, el corredor SQLAlchemy incluso estaba documentado en el sitio web de Celery, pero desde entonces se eliminó de los documentos en las versiones más recientes de la biblioteca. No obstante, todavía funciona bastante bien para el desarrollo local.

Para usar una base de datos secuela como broker de Apio en tu aplicación Django, primero instala SQLAlchemy:

pip install SQLAlchemy

Dentro del archivo settings.py de tu proyecto Django, puedes configurar el backend de tu broker usando la configuración CELERY_BROKER_URL:

# BASE_DIR is the directory of your project's main directory.

CELERY_BROKER_URL = f"sqlalchemy sqlite:////{BASE_DIR}/broker.sqlite3"

La URL del corredor de SQLAlchemy consta de 3 partes:

1. La cadena sqlalchemy o sqla (son intercambiables)
2. Una señal
3. Una cadena de conexión SQLAlchemy

Las cadenas de conexión son diferentes para SQLite en Mac/Unix y Windows:

# MacOS/Unix
CELERY_BROKER_URL = "sqla sqlite:////your/project/path/broker.sqlite3"

# Windows
CELERY_BROKER_URL = "sqla sqlite:///C:your\\project\\path\\broker.sqlite3"

También puedes usar Postgres como broker de Celery, o puedes usar MySQL como broker de Celery con la misma facilidad:

# MySQL
CELERY_BROKER_URL = "sqlalchemy mysql://scott:tiger@localhost/foo"

# PostgreSQL
CELERY_BROKER_URL = "sqla postgresql://scott:tiger@localhost/mydatabase"

# PosgreSQL connecting using pg8000
CELERY_BROKER_URL = "sqla postgresql pg8000://scott:tiger@localhost/mydatabase"

Es posible que necesite instalar otras bibliotecas para conectarse a MySQL o PostgreSQL, y la biblioteca que instale puede afectar la cadena de conexión de SQLAlchemy. Consulte los documentos URL de la base de datos SQLAlchemy para obtener más detalles.

Independientemente de la base de datos que elija, es posible que desee considerar almacenar la URL del agente en una variable de entorno para facilitar el cambio en diferentes entornos:

CELERY_BROKER_URL = os.getenv("CELERY_BROKER_URL")

Una palabra de precaución

El transporte SQLAlchemy probablemente se considere experimental y, por lo tanto, no estaría destinado a uso en producción. Es posible que se pierdan datos o que los mensajes se entreguen varias veces. Considere cambiar a un corredor más sólido que figura en la página Brokers and Backends de Celery.

Dicho esto, podría estar bien para el desarrollo local, o incluso para pequeños proyectos paralelos. Pero no me sorprendería que la capacidad de utilizar SQLAlchemy como intermediario desapareciera en el futuro.

Próximos pasos

Con Celery ejecutándose localmente, puede comenzar a trabajar en su aplicación alimentada por cola. Sin embargo, es posible que la falta de recarga automática sea un punto de fricción. Si desea configurar la recarga automática de Celery en su aplicación Django, lea mi publicación "Recargar automáticamente los trabajadores de Celery con un comando Django personalizado".