Запуск веб-приложения Flask в Google Kubernetes Engine

Question

Существует огромное количество учебных пособий и документации в Интернете, где Flask работает в состоянии разработки.В режиме разработки журнал выглядит следующим образом:

* 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)

Я хочу узнать больше о том, как подготовить его к производству.Я также видел документацию по этому вопросу, используя готовые к работе серверы WSGI и nginx в качестве обратного прокси-сервера.Но кто-нибудь может мне сказать, зачем нужен WSGI и обратный прокси-сервер?

Если мое приложение Flask докеризовано и запущено в Google Kubernetes Engine, тогда нужно ли это вообще?Разве GKE не позаботится о назначении WSGI и обратного прокси-сервера?

Answer 1

Как указано в документации Flask :

Встроенный сервер Flask не подходит для производства

Почему WSGI?Это стандартный способ для развертывания веб-приложений Python, он дает вам варианты при выборе сервера (т. Е. Вы можете выбрать наиболее подходящее для вашего приложения / рабочего процесса, не меняя приложение), и позволяет разгрузить задачи масштабирования досервер.

Почему обратный прокси?Это зависит от сервера.Вот обоснование Гуникорна :

... мы настоятельно рекомендуем вам использовать Nginx.Если вы выбираете другой прокси-сервер, вам нужно убедиться, что он буферизует медленных клиентов, когда вы используете рабочих Gunicorn по умолчанию.Без этой буферизации Gunicorn будет легко восприимчив к атакам типа «отказ в обслуживании».

Вот Обоснование официантки для того же:

Часто людиустановит веб-серверы "чистого Python" за обратными прокси, особенно если им нужна поддержка TLS (Waitress не поддерживает TLS).Даже если вам не нужна поддержка TLS, довольно часто можно увидеть, как Waitress и другие веб-серверы на чистом Python настроены на обработку запросов только через обратный прокси-сервер;эти прокси-серверы часто содержат множество полезных ручек развертывания.

Другие практические причины использования обратного прокси-сервера могут включать необходимость обратного прокси-сервера для нескольких бэкэндов (некоторые из которых могут не являться веб-сайтами Python).приложения), кеширование ответов и обслуживание статического контента (например, что Nginx хорошо умеет).Не всем серверам WSGI требуется обратный прокси-сервер: uWSGI и CherryPy рассматривают его как необязательный.

_{PS Похоже, что Google App Engine быть WSGI-совместимым и не требует дополнительной настройки.}