CODEWITHSUNDEEP
celerysupervisordcelerybeat
May.D
May.D

Reputation: 1910

Supervisord, Celery and Daemonization - Does my configuration respect good practice?

I've deployed a Django application using Apache2 and have been struggling with Celery configuration.

1st try:

I used systemd for daemonization of celery and celery_beat as stated in celery documentation. It was sort of working with this configuration (which is not advised for production)

ExecStart=/path/to/celery/bin/ -A proj worker
ExecStart=/path/to/celery/bin/ -A proj beat

But I couldn't get the "official" configuration working, something like this:

ExecStart=/bin/sh -c '${CELERY_BIN} multi start ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'

Service was running but scheduled tasks didn't execute.

Current configuration:

I've read this article (Celery 4 Periodic Tasks on Medium) advising to use supervisord. That's what I did, and my configuration files look like this

[program:projworker]

command=/path/to/celery/bin/-A proj worker -l info

So it's actually the same command as disadvised in Celery documentation.(Though for both configurations I correctly set up project dir, user and group, etc). However everything is going smoothly.

So in the end, my question is: does this actually respect good practices ? According to this piece of documentation supervisord handles daemonization but I'm actually not sure I got it right.

Upvotes: 0

Views: 263

Answers (1)

2ps
2ps

Reputation: 15926

Generally speaking, I'd recommend using multi. The reason to use multi is that multi offers a syntax to allow you to gracefully start, stop, or restart celery workers. That said, if you don't need that functionality or you have a good way to handle start, stop, and restart with supervisord without using multi, go ahead and do it the way you did.

Here is the sample recommended configuration for celery beat with supervisord.

Upvotes: 2

Related Questions