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