Deb-Paketierung: grouprise als systemd Prozess starten
Ich möchte vorschlagen, dass wir das grouprise in Zukunft als eigenständigen systemd Prozess starten. Bisher verlassen wir uns auf uWSGI und die Debian-spezifische Basiskonfiguration des uwsgi-Pakets. Als Seiteneffekt haben wir die pragmatische Entscheidung getroffen, Migrationen auszuführen, sobald unsere spezifische grouprise uWSGI-Konfiguration aktiviert wurde und starten aktuell den gesamten uWSGI-Dienst bei einer Paketaktualisierung neu.
Eine Umsetzung würde folgendermaßen aussehen:
- die uWSGI-Konfiguration wandert nach
/etc/grouprise
- den bisherigen grouprise systemd-Service, der (irritierenderweise) den huey-Dienst startet, benennen wir um
- für den Moment nutzen wir unsere bisherige uWSGI-Konfiguration und starten damit einen eigenen uWSGI-Prozess als grouprise systemd-Service
- etwaige Operationen wie Migrationen führen wir, soweit sie nicht eindeutig Teil der Paketkonfiguration sind, mittels
ExecStartPre
aus - wir fassen die verschiedenen grouprise-Dienste (grouprise selbst, LMTP, huey) mit der
PartOf
-Direktive zusammen (und lesen uns vielleicht noch etwas mehr in systemd-Prozessmanagement-Annehmlichkeiten ein)
Aus meiner Sicht ergeben sich ein paar klare Vorteile:
- Mit Blick auf Django 3.x, das offizielle Unterstützung für ASGI einführt, und für uns vielleicht die Integration von Websocket-Technologien oder nebenläufigen Prozessen als Teil des Request-Response-Cycles einführt, steht in mittelfristiger Zukunft evtl. ein Wechsel des Application-Servers auf irgendetwas ASGI-fähiges an. Im Falle eines solchen Wechsel ist das bisherige Modell so oder so hinfällig.
- Es gab bereits in der Vergangenheit immer mal wieder etwas Verwirrung darüber, wie grouprise eigentlich gestartet wird und wo sich entsprechende Log-Dateien dann finden. Da sich systemd samt seiner Systemwerkzeuge unter Debian klar etabliert hat, reduzieren wir hiermit wahrscheinlich ein paar Überraschungsmomente und flachen die Lernkurve etwas ab. Eine Unterstützung anderer Init-Systeme würde ich allerdings explizit ausschließen.
- die Konfiguration ist klar auf das
/etc/grouprise
-Verzeichnis bzw./etc/default/grouprise
-Datei begrenzt - Die Organisation von grouprise als eine Sammlung von Systemd-Units macht die Nutzung unter anderen Betriebssystem einfacher, da essentielle Operationen wie Datenbankmigrationen oder die
collectstatic
-Aufrufe nicht mehr Teil unserer Deb-Wartungsskripts mehr sind - Wir greifen nicht mehr in die Laufzeit anderer Web-Dienste ein, indem wir völlig unbeeindruckt den uWSGI-Systemdienst neustarten