Hallo Leute!
Ich muss sehen, dass ich eine Flask-Applikation als Systemdienst starte (und ggfs. stoppe). So einfach ist die Dokumentation der Applikation leider nicht, denn der Entwickler geht davon aus, dass man die Applikation immer im Docker startet, und das will ich in meinem Fall nicht...
Der Entwickler hat mir bestätigt, dass es auch ohne Docker laufen soll und das habe ich auch geschafft, indem ich Flask per Hand starte.
Nun will ich, dass die Applikation als Dienst läuft. Dafür gibt es uwsgi, so wie ich verstehe...
Was ich nicht verstehen kann ist, wie ich das Programm so konfiguriere, dass die Applikation auch gestartet wird... Theoretisch sollte ich eine app.ini (oder wie ich das nennen will) in /etc/uwsgi/apps-enabled/ kopieren/verlinken, aber wenn ich das mache, schmiert uwsgi bei start. Leider ohne geistreiche Fehlermeldung:
Mar 11 07:22:06 tiles systemd[1]: Starting LSB: Start/stop uWSGI server instance(s)... Mar 11 07:22:06 tiles uwsgi[1610]: Starting app server(s): uwsgi -> ! failed! Mar 11 07:22:06 tiles systemd[1]: uwsgi.service: Control process exited, code=exited, status=1/FAILURE Mar 11 07:22:06 tiles systemd[1]: uwsgi.service: Failed with result 'exit-code'. Mar 11 07:22:06 tiles systemd[1]: Failed to start LSB: Start/stop uWSGI server instance(s).
Kennt jemand das Programm und kann mir ein Tipp geben? Ein extra Systemd-Modul für das Programm ist für mich wirklich nur die "Reserve", denn eigentlich sollte es schon so gehen...
Tausend Dank Luca Bertoncello (lucabert@lucabert.de)
On Thu, Mar 11, 2021 at 07:23:20AM +0100, Luca Bertoncello wrote:
Ich muss sehen, dass ich eine Flask-Applikation als Systemdienst starte (und ggfs. stoppe). So einfach ist die Dokumentation der Applikation leider nicht, denn der Entwickler geht davon aus, dass man die Applikation immer im Docker startet, und das will ich in meinem Fall nicht...
Der Entwickler hat mir bestätigt, dass es auch ohne Docker laufen soll und das habe ich auch geschafft, indem ich Flask per Hand starte.
Nun will ich, dass die Applikation als Dienst läuft. Dafür gibt es uwsgi, so wie ich verstehe...
Was ich nicht verstehen kann ist, wie ich das Programm so konfiguriere, dass die Applikation auch gestartet wird... Theoretisch sollte ich eine app.ini (oder wie ich das nennen will) in /etc/uwsgi/apps-enabled/ kopieren/verlinken, aber wenn ich das mache, schmiert uwsgi bei start.
Kennt jemand das Programm und kann mir ein Tipp geben?
Hallo Luca,
soll uwsgi die Anwendung direkt per HTTP ausliefern oder das uwsgi-Protokoll sprechen? Ich habe vor Python-Anwendungen im uwsgi noch einen nginx, der die TLS-Terminierung macht. Die UWSGI-Konfiguration (bei dir app.ini) für eine Flask-Anwendung sieht bei mir so aus:
[uwsgi] uid = jan plugin = python3 chdir = /srv/www/portfolio.debian.net virtualenv = /home/jan/.virtualenvs/debianmemberportfolio module = debianmemberportfolio callable = app master = True processes = 4 threads = 2
Bei module steht der Python-Modul-Name für in dem sich eine Funktion namens app befindet, die der Einstiegspunkt in die Flask-Anwendung ist. Ein Virtualenv brauchst du nur, wenn die Dependencies nicht schon über Packages im Python-Interpreter deines Systems installiert wurden. Bei der Applikation im Beispiel findet sich app hier https://git.dittberner.info/jan/debianmemberportfolio/src/branch/master/debi... und in dem Virtual-Environment sind die Abhängigkeiten aus https://git.dittberner.info/jan/debianmemberportfolio/src/branch/master/requ... installiert.
Im nginx ist das dann folgendermaßen integriert:
server { server_name portfolio.debian.net;
listen 443 ssl; listen [::]:443;
ssl_certificate /etc/letsencrypt/live/portfolio.debian.net/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/portfolio.debian.net/privkey.pem;
# OCSP stapling ssl_trusted_certificate /etc/letsencrypt/live/portfolio.debian.net/chain.pem;
access_log /var/log/nginx/portfolio.debian.net-ssl.access.log; error_log /var/log/nginx/portfolio.debian.net-ssl.error.log; root /srv/www/portfolio.debian.net/ddportfolioservice/public/;
location /favicon.ico { try_files $uri =404; }
location /static/javascript/jquery/jquery.js { alias /usr/share/javascript/jquery/jquery.js; }
location / { try_files $uri @wsgi; }
location @wsgi { include uwsgi_params; uwsgi_pass unix:/run/uwsgi/app/debianmemberportfolio/socket; uwsgi_param SCRIPT_NAME ''; } }
uwsgi kann zwar auch direkt http sprechen aber z.B. statische Resourcen darüber auszuliefern ist für den Produktivbetrieb keine so gute Idee.
Ein extra Systemd-Modul für das Programm ist für mich wirklich nur die "Reserve", denn eigentlich sollte es schon so gehen...
Sowohl uwsgi als auch nginx werden bei mir über die systemd-Units aus den System-Packages gestartet.
Viele Grüße Jan
Am 11.03.2021 09:21, schrieb Jan Dittberner:
Hallo Jan,
soll uwsgi die Anwendung direkt per HTTP ausliefern oder das uwsgi-Protokoll sprechen? Ich habe vor Python-Anwendungen im uwsgi noch einen nginx, der die
Gerne gleich auch HTTP, ich werde das sowieso hinter einen Apache-Proxy laufen lassen.
TLS-Terminierung macht. Die UWSGI-Konfiguration (bei dir app.ini) für eine Flask-Anwendung sieht bei mir so aus:
Meine Datei /etc/uwsgi/apps-enabled/opentopodata.ini sieht so aus:
[uwsgi] strict = true need-app = true
http-socket = :9090 vacuum = true uid = www-data gid = www-data
master = true wsgi-file = /home/opentopodata/opentopodata/api.py callable = app manage-script-name = true die-on-term = true buffer-size = 65535
wenn ich uwsgi manuell starte (/usr/local/bin/uwsgi --ini /home/opentopodata/uwsgi.ini --processes 10s) hat gestern geklappt, jetzt, ohne dass ich was geändert habe, spuckt diese Fehler aus:
[uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/opentopodata.ini *** Starting uWSGI 2.0.19.1 (64bit) on [Thu Mar 11 10:28:33 2021] *** compiled with version: 8.3.0 on 10 March 2021 11:38:27 os: Linux-4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) nodename: tiles.srv.lucabert.intra machine: x86_64 clock source: unix detected number of CPU cores: 4 current working directory: /etc/uwsgi/apps-enabled detected binary path: /usr/local/bin/uwsgi !!! no internal routing support, rebuild with pcre support !!! setgid() to 33 setuid() to 33 your processes number limit is 63566 your memory page size is 4096 bytes detected max file descriptor number: 1024 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uwsgi socket 0 bound to TCP address :9090 fd 3 Python version: 3.7.3 (default, Jul 25 2020, 13:03:44) [GCC 8.3.0] *** Python threads support is disabled. You can enable it with --enable-threads *** Python main interpreter initialized at 0x562646528a20 your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 1477949 bytes (1443 KB) for 10 cores *** Operational MODE: preforking *** Traceback (most recent call last): File "/home/opentopodata/opentopodata/api.py", line 8, in <module> from opentopodata import backend, config, utils ModuleNotFoundError: No module named 'opentopodata' unable to load app 0 (mountpoint='') (callable not found or import error) *** no app loaded. GAME OVER ***
Die Datei existiert... Ich verstehe wirklich nicht... Hast du ein Tipp?
Danke Luca Bertoncello (lucabert@lucabert.de)
Am 11.03.2021 09:21, schrieb Jan Dittberner:
Hallo Jan
soll uwsgi die Anwendung direkt per HTTP ausliefern oder das uwsgi-Protokoll sprechen? Ich habe vor Python-Anwendungen im uwsgi noch einen nginx, der die TLS-Terminierung macht. Die UWSGI-Konfiguration (bei dir app.ini) für eine Flask-Anwendung sieht bei mir so aus:
Also, ich habe das Problem gefunden warum vorher nicht ging. Es fehlte die Direktive chdir.
Aber trotzdem kann ich uwsgi weiterhin per systemctl nicht starten...
Ideen?
Tausend Dank Luca Bertoncello (lucabert@lucabert.de)
Am 11.03.2021 09:21, schrieb Jan Dittberner:
Hallo
Bei module steht der Python-Modul-Name für in dem sich eine Funktion namens app befindet, die der Einstiegspunkt in die Flask-Anwendung ist. Ein Virtualenv brauchst du nur, wenn die Dependencies nicht schon über Packages im
Ich komme immer nicht weiter, uwsgi einfach so zu starten geht, per systemctl überhaupt nicht... Mit jede Menge Debug habe ich jetzt noch was gefunden, und zwar den Fehler:
[strict-mode] unknown config directive: deb-confname
wo diese Directive aber benutzt wird, finde ich das überhaupt nicht, sicherlich nicht in meiner .ini-Datei... Hat jemand noch eine Idee?
Danke Luca Bertoncello (lucabert@lucabert.de)
Am Freitag, dem 12.03.2021 um 09:14 +0100 schrieb Luca Bertoncello:
Am 11.03.2021 09:21, schrieb Jan Dittberner:
[..]
Ich komme immer nicht weiter, uwsgi einfach so zu starten geht, per systemctl überhaupt nicht... Mit jede Menge Debug habe ich jetzt noch was gefunden, und zwar den Fehler:
[strict-mode] unknown config directive: deb-confname
wo diese Directive aber benutzt wird, finde ich das überhaupt nicht, sicherlich nicht in meiner .ini-Datei... Hat jemand noch eine Idee?
Vielleicht hilft das, um die Direktive zu finden.
https://codesearch.debian.net/search?q=deb-confname&literal=1 https://gist.github.com/digital-shokunin/226f9cd8b4f430eedfeb
HTH, Daniel
Am 12.03.2021 um 15:34 schrieb Daniel Leidert:
Hallo Daniel,
Vielleicht hilft das, um die Direktive zu finden.
https://codesearch.debian.net/search?q=deb-confname&literal=1 https://gist.github.com/digital-shokunin/226f9cd8b4f430eedfeb
Inzwischen habe ich das gefunden... Es ist was verstecktes in dem Start-Skript bei Debian. Ich würde vermuten, ein Bug...
Da ich trotzdem nicht zum Laufen bekommen habe, habe ich mich entschieden, ein eigenes systemd-Skript zu packen und uwsgi so zu verwalten. Klappt...
Grüße Luca Bertoncello (lucabert@lucabert.de)
lug-dd@mailman.schlittermann.de
-
Daniel Leidert -
Jan Dittberner -
Luca Bertoncello