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/debianmemberportfolio/__init__.py#L27 und in dem Virtual-Environment sind die Abhängigkeiten aus https://git.dittberner.info/jan/debianmemberportfolio/src/branch/master/requirements.txt 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 -- Jan Dittberner - Debian Developer GPG-key: 4096R/0xA73E0055558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD https://jan.dittberner.info/
signature.asc
Description: PGP signature
