python - management - Celery & RabbitMQ ejecutándose como contenedores de ventana acoplable: se recibió una tarea no registrada de tipo ''...''
rabbitmq 3 management alpine (1)
Soy relativamente nuevo en docker, apio y rabbitMQ.
En nuestro proyecto, actualmente tenemos la siguiente configuración: 1 host físico con varios contenedores de ventana acoplable en ejecución:
1x rabbitmq: contenedor de 3 gestiones
# pull image from docker hub and install
docker pull rabbitmq:3-management
# run docker image
docker run -d -e RABBITMQ_NODENAME=my-rabbit --name some-rabbit -p 8080:15672 -p 5672:5672 rabbitmq:3-management
1x contenedor de apio
# pull docker image from docker hub
docker pull celery
# run celery container
docker run --link some-rabbit:rabbit --name some-celery -d celery
(Hay algunos contenedores más, pero no deberían tener que hacer nada con el problema)
Archivo de tareas
Para conocer un poco el apio y el conejo, creé un archivo tasks.py en el host físico:
from celery import Celery
app = Celery(''tasks'', backend=''amqp'', broker=''amqp://guest:[email protected]/'')
@app.task(name=''tasks.add'')
def add(x, y):
return x + y
La configuración completa parece estar funcionando bastante bien en realidad. Así que cuando abro un shell de python en el directorio donde se encuentra task.py y ejecuta
>>> from tasks import add
>>> add.delay(4,4)
La tarea se pone en cola y se saca directamente del trabajador de apio.
Sin embargo, el trabajador del apio no conoce el módulo de tareas con respecto a los registros:
$ docker logs some-celery
[2015-04-08 11:25:24,669: ERROR/MainProcess] Received unregistered task of type ''tasks.add''.
The message has been ignored and discarded.
Did you remember to import the module containing this task?
Or maybe you are using relative imports?
Please see http://bit.ly/gLye1c for more information.
The full contents of the message body was:
{''callbacks'': None, ''timelimit'': (None, None), ''retries'': 0, ''id'': ''2b5dc209-3c41-4a8d-8efe-ed450d537e56'', ''args'': (4, 4), ''eta'': None, ''utc'': True, ''taskset'': None, ''task'': ''tasks.add'', ''errbacks'': None, ''kwargs'': {}, ''chord'': None, ''expires'': None} (256b)
Traceback (most recent call last):
File "/usr/local/lib/python3.4/site-packages/celery/worker/consumer.py", line 455, in on_task_received
strategies[name](message, body,
KeyError: ''tasks.add''
Entonces, obviamente, el problema parece ser que los trabajadores del apio en el contenedor de apio no conocen el módulo de tareas. Ahora que no soy un especialista en estibadores, quería preguntarme cuál sería la mejor manera de importar el módulo de tareas al contenedor de apio.
Cualquier ayuda es apreciada :)
EDITAR 4/8/2015, 21:05:
Gracias a Isowen por la respuesta. Sólo para completar aquí es lo que hice:
Supongamos que mis tasks.py
se encuentra en mi máquina local en /home/platzhersh/celerystuff
. Ahora creé un celeryconfig.py
en el mismo directorio con el siguiente contenido:
CELERY_IMPORTS = (''tasks'')
CELERY_IGNORE_RESULT = False
CELERY_RESULT_BACKEND = ''amqp''
Como mencionó Isowen, las búsquedas de apio /home/user
del contenedor para tareas y archivos de configuración. Así que /home/platzhersh/celerystuff
el /home/platzhersh/celerystuff
en el contenedor al comenzar:
run -v /home/platzhersh/celerystuff:/home/user --link some-rabbit:rabbit --name some-celery -d celery
Esto hizo el truco para mí. Espero que esto ayude a otras personas con problemas similares. Ahora intentaré expandir esa solución colocando las tareas también en un contenedor de ventana acoplable por separado.
Como usted sospecha, el problema es porque el trabajador de apio no conoce el módulo de tareas. Hay dos cosas que debes hacer:
- Obtenga sus definiciones de tareas "en" el contenedor docker.
- Configurar el trabajador de apio para cargar esas definiciones de tareas.
Para el Artículo (1), la forma más fácil es probablemente usar un "Volumen de Docker" para montar un directorio de host de su código en la instancia de apilador. Algo como:
docker run --link some-rabbit:rabbit -v /path/to/host/code:/home/user --name some-celery -d celery
Donde /path/to/host/code
es la ruta de su host, y /home/user
es la ruta para montarlo en la instancia. ¿Por qué /home/user
en este caso? Porque el Dockerfile
para la imagen de apio define el directorio de trabajo ( WORKDIR
) como /home/user
.
(Nota: Otra forma de lograr el Elemento (1) sería construir una imagen de ventana acoplable personalizada con el código "incorporado", pero lo dejaré como un ejercicio para el lector).
Para el artículo (2), debe crear un archivo de configuración de apio que importe el archivo de tareas. Este es un problema más general, por lo que señalaré una respuesta de anterior: Celery recibió una tarea de tipo no registrada (ejemplo de ejecución)