[PYTHON] Django + v (irtual) env + Sellerie + Supervisor

Ich möchte mir nicht die Zeit nehmen, es zusammenzustellen, also ist es wie ein Memo.

Umgebung

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

In einem anderen Fall wird der Supervisor auf `` `3.0r1-1 ~ bpo70 + 1``` gesetzt, das von sid bezogen wird. Wie bei Ubuntu 12.04 scheint das ursprüngliche 3.0a8 ziemlich alt zu sein (2010). Ubuntu 14.04 ist 3.0b2, ein wenig neu (2013?)

Ist es jetzt 3.1.2? …… Erscheinungsdatum, 07.09.2014 ist 3 Tage vorher (zum Zeitpunkt des Schreibens dieses Artikels)

Referenz: http://supervisord.org/changes.html

Was möchten Sie tun

Zuerst spielte ich mit Django mit dem folgenden Gefühl.

Ich denke es ist okay, aber es ist ein bisschen aggressiv

Supervisor ist hier nicht der einzige Pip, weil ich so etwas wie /etc/init.d/supervisor möchte. pip enthält keine betriebssystemseitigen Konfigurationsdateien, die dem Verteilungsstil folgen. Vielen Dank an die Distributoren.

Ein weiteres Testprojekt in der Entwicklungsumgebung Ein Tornado-Projekt (gestartet von Apache als Reverse-Proxy) Es scheint kein Problem zu geben, alles auf einmal mit dem Supervisor zu verwalten, der dieser Wohnung zugeordnet ist Mach es so.

Der Punkt ist also, dass Sie "Supervisor verwenden müssen, um Sellerie-Arbeiter über Django in Venv ansässig zu machen".

Die ursprüngliche (dj) Sellerieeinstellung befindet sich in `/ etc / default / celeryd```. Leider ist dies effektiv eine Bash-Datei, die von Bash ( `/ etc / init.d / celeryd```) aufgerufen wird Muss in Supervisor-Einstellungen konvertiert werden.

Wenn ich das mache, werde ich die Punkte aufschreiben, auf die ich achten musste, also hoffe ich, dass es Ihnen einige Hinweise gibt.

Wem gehört diese (Umwelt-) Variable?

Es macht keinen Sinn, CELERY_OPTS usw. in die Supervisor-Einstellungen aufzunehmen. Mit anderen Worten, für so etwas wie eine Konstante in `` `/ etc / init.d / celeryd```

Die beiden Typen werden miteinander gemischt. Der einzige Unterschied besteht darin, die Quelle zu betrachten.

manage.py celeryd_multi wird in Sellerie-Arbeiter von manage.py zerlegt und als Supervisor festgelegt.

Besonders wenn Sie mehrere (Sellerie-) Arbeiter haben Ich schreibe die Einstellungen von Warteschlangen und Arbeitern in `` `/ etc / default / celeryd```. celeryd_multi scheint mit Supervisord nicht sehr gut zu funktionieren.

celeryd_multi von djcelery Eigentlich Sellerie-multi von Sellerie Wird ausgeführt, während die Django-Einstellungen geerbt werden (wie Sie aus celeryd_multi.py sehen können).

Selleries Sellerie-Multi-Befehl lautet "Arbeiter starten".

Auch mit einer einfachen "Django + Sellerie" -Konfiguration Es gibt kein "... / manage.py Sellerie-Multi" im Restprozess, das in ps usw. zu sehen ist. Dies bedeutet, dass Sellerie-Multi kein Dämon ist. Stattdessen sollte "... / manage.py Sellerie-Arbeiter" als mehrere Dämonen am Leben sein.

Mit diesem Gefühl scheint der Versuch, manage.py celeryd_multi auf dem Supervisor auszuführen, nutzlos zu sein.

Referenz: http://stackoverflow.com/questions/15558875/running-celeyd-multi-with-supervisor

Einstellungsbeispiel

/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 sollte eine Zahl sein
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"

Dann sieht es wie folgt aus. Es wurde jedoch nicht verifiziert.

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",

Wenn es auf der Supervisord-Seite funktioniert

Es scheint, dass SUPERVISOR in der Umgebungsvariablen des Arbeitsprozesses enthalten ist, die auf diese Weise funktioniert. Dies kann nützlich sein, wenn Sie das Verhalten in einer Nur-Sellerie-Konfiguration und einer Supervisor-Konfiguration ändern möchten. Es kann auch zum Debuggen verwendet werden.

Wenn Sie danach das Handbuch lesen, sollte dieser Artikel eine korrekte Beschreibung enthalten.

Überprüfen Sie, ob Sellerie gestoppt ist und Supervisor mit chkconfig oder sysv-rc-conf startet.

Wenn es eine systemd Welt ist, folgen Sie ihr.

Das ist es.

Wenn Sie usw. kommentieren können, werde ich den Teil hinzufügen, der später nicht erklärt wird.

Wenn Sie einen Fehler machen, kontaktieren Sie uns bitte jedes Mal.

Nachtrag: Around GID (2014-09-10 17:12)

Ich war in Schwierigkeiten, weil sich der Umgang mit Gruppen zwischen dem Fall der Verwendung von celeryd_multi und der obigen Methode geändert hat, so dass dies auch ein Wort ist. Die von CELERYD_GROUP angegebene GID, die von celeryd_multi erstellt wurde, kann vom Supervisor nicht angegeben werden. Die GID des Benutzers wird einfach wiederverwendet.

Der Sellerie-Arbeiter hat die Möglichkeit, --uid und --gid anzugeben, sodass Sie die UID und GID des Prozesses tatsächlich ändern können. Damit dies jedoch effektiv funktioniert, müssen Sie zunächst die Angabe des Benutzers von Superviser beenden (als Root starten) Die Generierung der Protokolldatei erfolgt "bevor" der Worker diese Option verwendet Die Berechtigung für das neu erstellte Protokoll lautet root: root. Bei Verwendung von RotatingFileHandler usw. wird es an einem Punkt plötzlich unmöglich, aus WSGI zu schreiben, und es fällt. Seien Sie vorsichtig, wenn Sie Ideen zum Verwalten von Protokolldateiberechtigungen haben.

In meinem Fall, wenn der Benutzer defekt ist und GID = nogroup und ich zu Supervisor wechsle, Aus irgendeinem Grund gehören alle erstellten Dateien zur Gruppe ohne Gruppe, und ich verstehe die Bedeutung nicht.

Dies ist eher eine Unix-ähnliche Geschichte als eine Supervisor-Geschichte insgesamt, aber nur für den Fall.

Recommended Posts

Django + v (irtual) env + Sellerie + Supervisor
Sellerie-Notizen zu Django