Django + v (irtual) env + céleri + superviseur

Je ne veux pas prendre le temps de le mettre ensemble, c'est donc comme un mémo.

environnement

> lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 7.6 (wheezy)
Release:	7.6
Codename:	wheezy

Dans un autre cas, le superviseur est réglé sur 3.0r1-1 ~ bpo70 + 1 '' 'qui provient de Sid. Comme avec Ubuntu 12.04, la version 3.0a8 originale semble assez ancienne (2010). Ubuntu 14.04 est 3.0b2, un peu nouveau (2013?)

Est-ce maintenant 3.1.2? …… La date de sortie, 07/09/2014, est 3 jours avant (au moment de la rédaction de cet article)

Référence: http://supervisord.org/changes.html

Qu'est-ce que tu veux faire

Au début, je jouais avec Django avec le sentiment suivant.

Je pense que ça va, mais c'est un peu agressif

Je voulais faire quelque chose à ce sujet. Je souhaite réduire la dépendance aux packages standard du système d'exploitation.

Supervisor n'est pas le seul pip ici car je veux quelque chose comme /etc/init.d/supervisor. pip n'inclut pas les fichiers de configuration côté OS qui suivent le style de distribution. Merci aux distributeurs.

Un autre projet de test dans l'environnement de développement Un projet tornado (démarré à partir d'Apache en tant que proxy inverse) Il ne semble y avoir aucun problème à gérer en même temps avec le superviseur attaché à cet apt, donc Fais-le comme ça.

Donc, le fait est que vous devez "utiliser Supervisor pour que les ouvriers de Celery résident via Django dans venv".

Le réglage original du céleri (dj) est dans / etc / default / celeryd```. Malheureusement, il s'agit en fait d'un fichier bash appelé depuis bash ( / etc / init.d / celeryd ''), donc Doit être converti aux paramètres du superviseur.

En faisant cela, j'écrirai les points auxquels je devais prêter attention, donc j'espère que cela vous donnera quelques indices.

À qui appartient cette variable (environnementale)

Il ne sert à rien d'inclure CELERY_OPTS etc. dans les paramètres du superviseur. En d'autres termes, pour quelque chose comme une constante dans / etc / init.d / celeryd```

Les deux types sont mélangés. La seule distinction est de regarder la source.

manage.py celeryd_multi est désassemblé dans manage.py céleri ouvriers et défini comme superviseur.

Surtout si vous avez plusieurs ouvriers (céleri) J'écris les paramètres des files d'attente et des travailleurs dans / etc / default / celeryd```. celeryd_multi ne semble pas fonctionner très bien avec Supervisord.

celeryd_multi de djcelery En fait, céleri-multi céleri S'exécute en héritant des paramètres de Django (comme vous pouvez le voir sur celeryd_multi.py).

La commande céleri-multi de Celery est "start worker".

Même avec une configuration simple "Django + Celery" Il n'y a pas de "... / manage.py celery-multi" dans le processus résiduel qui peut être vu dans ps etc. Cela signifie que céleri-multi n'est pas un démon. Au lieu de cela, "... / manage.py céleri ouvrier" devrait être vivant en tant que plusieurs démons.

Avec ce sentiment, essayer d'exécuter manage.py celeryd_multi sur le superviseur semble inutile.

Référence: http://stackoverflow.com/questions/15558875/running-celeyd-multi-with-supervisor

Exemple de réglage

/etc/default/celery


ENABLED="true"
CELERYD_LOG_LEVEL="DEBUG"
CELERY_TIMEZONE='Asia/Tokyo'
CELERYD_NODES="manage build"
CELERYD_CHDIR="/opt/griflet/"

CELERYD_MULTI="$CELERYD_CHDIR/manage.py celeryd_multi"
CELERYCTL="$CELERYD_CHDIR/manage.py celeryctl"
#XXXX doit être un nombre
CELERYD_OPTS="--time-limit=XXXX --time-limit:build=XXXX -c 1 -Q:build build -Q manage"
CELERY_CONFIG_MODULE="myproject.celeryconfig"

CELERYD_LOG_FILE="/var/log/celery/%n.log"
CELERYD_PID_FILE="/var/run/celery/%n.pid"

CELERYD_USER="myproject"
CELERYD_GROUP="myproject"

export DJANGO_SETTINGS_MODULE="myproject.settings"

Ensuite, cela ressemble à ce qui suit. Cependant, cela n'a pas été vérifié.

text:conf.d/myproject.conf


[program:celery-myproject-manage]
command=/opt/myproject/venv/bin/python /opt/myprojcet/manage.py celery worker
  --loglevel=DEBUG
  -Q manage
  --logfile=/var/log/celery/manage.log
  --pidfile=/var/run/celery/manage.pid
  --hostname manage@hostname
  --concurrency 1
  --time-limit=XXXX
  --workdir=/opt/myproject/

user=myprojcet
directory=/home/myprojcet
numprocs=1
stdout_logfile=/var/log/celery/manage.stdout.log
stderr_logfile=/var/log/celery/manage.stderr.log
autostart=true
autorestart=true
startsecs=10
environment =
  DJANGO_SETTINGS_MODULE="myprojcet.settings",
  CELERY_TIMEZONE="Asia/Tokyo"


[program:celery-myprojcet-build]
command=/opt/myprojcet/venv/bin/python /opt/myprojcet/manage.py celery worker
  --loglevel=DEBUG
  -Q build
  --logfile=/var/log/celery/build.log
  --pidfile=/var/run/celery/build.pid
  --hostname build@hostname
  --concurrency 1
  --time-limit=XXXX
  --workdir=/opt/myprojcet/

user=myprojcet
directory=/home/myprojcet
numprocs=1
stdout_logfile=/var/log/celery/build.stdout.log
stderr_logfile=/var/log/celery/build.stderr.log
autostart=true
autorestart=true
startsecs=10
environment =
  DJANGO_SETTINGS_MODULE="myprojcet.settings",
  CELERY_TIMEZONE="Asia/Tokyo",

Si cela fonctionne du côté du superviseur

Il semble que SUPERVISOR soit inclus dans la variable d'environnement de processus de travail qui fonctionne de cette manière. Cela peut être utile si vous souhaitez modifier le comportement dans une configuration Celery uniquement et une configuration Supervisor. Il peut également être utilisé pour le débogage.

Après cela, si vous lisez le manuel, il devrait y avoir une description correcte de cet article.

Vérifiez que Celery est arrêté et que Supervisor démarre avec chkconfig ou sysv-rc-conf.

Si c'est un monde systemd, suivez-le.

C'est tout.

Si vous pouvez commenter etc., j'ajouterai la partie qui n'est pas expliquée plus tard.

Si vous faites une erreur, veuillez nous contacter à chaque fois.

Post-scriptum: Autour de GID (2014-09-10 17:12)

J'étais en difficulté car la gestion du groupe a changé entre le cas de l'utilisation de celeryd_multi et la méthode ci-dessus, donc c'est aussi un mot. Le GID spécifié par CELERYD_GROUP créé par celeryd_multi ne peut pas être spécifié par Supervisor. Le GID de l'utilisateur est simplement réutilisé.

L'ouvrier céleri a un moyen de spécifier --uid et --gid, de sorte que vous pouvez réellement changer l'UID et le GID du processus. Cependant, pour que cela fonctionne efficacement, il est nécessaire de commencer par arrêter de spécifier l'utilisateur de Superviser (démarrez-le en tant que root), et aussi La génération du fichier journal est effectuée "avant" que le travailleur ne mange cette option L'autorisation pour le journal nouvellement créé sera root: root. Lorsque vous utilisez RotatingFileHandler, etc., à un moment donné, il devient soudainement impossible d'écrire à partir de WSGI et cela tombe. Soyez prudent si vous avez des idées pour gérer les autorisations des fichiers journaux.

Dans mon cas, si l'utilisateur est cassé et que GID = nogroup et que je change en superviseur, Pour une raison quelconque, tous les fichiers créés appartiennent au groupe no group et je ne comprends pas la signification.

C'est une histoire de type Unix plutôt qu'une histoire de superviseur dans son ensemble, mais juste au cas où.

Recommended Posts

Django + v (irtual) env + céleri + superviseur
Notes de céleri sur Django