There are a vast majority of tutorials and documentation on the web where Flask is running in development state. The log looks like this in development mode:
* Serving Flask app "app" (lazy loading)
* Environment: production
WARNING: Do not use the development server in a production environment.
Use a production WSGI server instead.
* Debug mode: on
* Running on http://0.0.0.0:5555/ (Press CTRL+C to quit)
I want to know more about how to make it production ready. I've seen documentation on this as well using production ready WSGI servers and nginx as reverse proxy in front. But can somebody tell me why WSGI and reverse proxy is needed?
If my Flask application is dockerized and running in Google Kubernetes Engine is it even necessary then? Will GKE not take care of the purpose of WSGI and reverse proxy?
As Flask's documentation states:
Flask’s built-in server is not suitable for production
Why WSGI? It's a standard way to deploy Python web apps, it gives you options when choosing a server (i.e. you can choose the best fit for your application/workflow without changing your application), and it allows offloading scaling concerns to the server.
Why a reverse proxy? It depends on the server. Here is Gunicorn's rationale:
... we strongly advise that you use Nginx. If you choose another proxy server you need to make sure that it buffers slow clients when you use default Gunicorn workers. Without this buffering Gunicorn will be easily susceptible to denial-of-service attacks.
Here is Waitress's rationale for the same:
Often people will set up "pure Python" web servers behind reverse proxies, especially if they need TLS support (Waitress does not natively support TLS). Even if you don't need TLS support, it's not uncommon to see Waitress and other pure-Python web servers set up to only handle requests behind a reverse proxy; these proxies often have lots of useful deployment knobs.
Other practical reasons for a reverse proxy may include needing a reverse proxy for multiple backends (some of which may not be Python web apps), caching responses, and serving static content (something which Nginx, for example, happens to be good at). Not all WSGI servers need a reverse proxy: uWSGI and CherryPy treat it as optional.
P.S. Google App Engine seems to be WSGI-compliant and doesn't require any additional configuration.