Czy serwer WSGI i serwer HTTP są wymagane do obsługi aplikacji Flask?

Question

Konfiguracja Flask z uWSGI i Nginx jest dość trudna, a nawet ze skryptami buildout zajmuje trochę czasu i musi zostać zapisana w instrukcjach do późniejszego odtworzenia.

Jeśli nie planuję dużego obciążenia na serwerze (jest to ukryte przed dostępem publicznym), czy ma sens uruchamianie go bez użycia interfejsu usWSGI? (Flask może nasłuchiwać portu.) Czy Nginx może przesyłać dalej żądania?)

Czy nie warto używać nawet Nginx, po prostu uruchamiając aplikację na kolbę?

Answer 1

Kiedy "uruchamiasz Flask", w rzeczywistości uruchamiasz serwer WSCI dla Werkzeug i przekazujesz swoją aplikację Flask jako podpowiedź WSGI.

Serwer programistyczny nie jest przeznaczony do użycia w produkcji. Nie jest zaprojektowany tak, aby był szczególnie wydajny, stabilny lub bezpieczny.

Wymień serwer Werkzeug na gotowy do pracy serwer WSGI, taki jak Gunicorn lub uWSGI, gdy przejdziesz do produkcji, bez względu na to, gdzie aplikacja będzie dostępna.

---

Odpowiedź jest podobna dla "powinienem używać serwera WWW". Serwery WSGI mogą mieć serwery HTTP, ale nie będą tak dobre, jak dedykowany serwer produkcyjny HTTP (Nginx, Apache itp.).

---

Flask documents jak rozmieścić na różne sposoby. Wielu dostawców hostingu posiada również dokumentację dotyczącą wdrażania Pythona lub Flasku.

Answer 2

Przypuszczalnie masz już kolbie aplikacji przedmiotu oraz tras skonfigurowane, ale jeśli tworzysz aplikację tak:

import flask 

app = flask.Flask(__name__) 

następnie skonfigurować @app.route() s, a następnie, gdy chcemy uruchomić aplikację:

import gevent 

app_server = gevent.wsgi.WSGIServer((host, port), app) 
app_server.serve_forever() 

Następnie można po prostu uruchomić aplikację bezpośrednio zamiast powiedzieć gunicorn lub uWSGI lub cokolwiek innego, aby uruchomić go dla Ciebie.

Miałem przypadek, w którym chciałem, aby narzędzie do budowy kolby zbudowało aplikację sieciową (usługa REST API) i stwierdziło, że problemem jest niezdolność do komponowania kolby z innymi nie-kolbowymi, nie obsługującymi sieci elementami. W końcu znalazłem gevent.wsgi.WSGIServer i właśnie tego potrzebowałem. Po wywołaniu app_server.serve_forever() możesz zadzwonić pod numer app_server.stop(), gdy aplikacja chce wyjść.

W moim wdrożeniu, moja aplikacja nasłuchuje na localhost: przy użyciu flask i gevent, a następnie mam odwrotne proxy proxy HTTPS na innym porcie i przekazuje je do mojej usługi skrzynki na localhost.