为什么我们必须使用带有 gunicorn 的 nginx 在容器内部署烧瓶答案

【问题标题】：Why do we must use nginx with gunicorn for flask deployment inside container为什么我们必须使用带有 gunicorn 的 nginx 在容器内部署烧瓶
【发布时间】：2020-12-22 17:17:41
【问题描述】：

我一直使用 nginx 作为 gunicorn 的反向代理；在 docker 容器内的生产环境中运行烧瓶服务器。我的问题是为什么我们在容器内使用 nginx，因为 gunicorn 本身就是 http 服务器。我正在使用 Istio 在 kubernetes 中部署图像。因为我已经在使用 Istio，所以我应该删除 nginx 吗？

我想从图片中删除 nginx，因为很难同时配置 nginx 和 gunicorn，它们都可以完美运行，但是当上传大数据时，例如 800MB json 文件，nginx 会抛出 504 bad gateway。我尝试将 nginx 和 gunicorn 配置为不超时，但它不起作用。在 nginx 通过查看 pod/container 日志以 504 bad gateway 响应后，gunicorn 仍在处理数据，因此这意味着 gunicorn 不会仅抛出此错误 nginx是。这是配置。

Nginx http 部分

proxy_connect_timeout       3600;
proxy_send_timeout          3600;
proxy_read_timeout          3600;
send_timeout                3600;

location @proxy_to_app {
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Host $http_host;
  proxy_connect_timeout 3600s;
  proxy_read_timeout 3600s;
  proxy_send_timeout 3600s;
  send_timeout 3600s;
  proxy_redirect off;
  proxy_pass http://app_server;
}

Gunicorn 配置：

gunicorn --worker-tmp-dir /dev/shm/ --workers=2 --threads=4 --worker-class=gthread --limit-request-field_size 125000000 --limit-request-line 125000000 --timeout 3600 --keep-alive 3600 --bind unix:/tmp/gunicorn.sock run:app

【问题讨论】：

两个问题：1）这是一个内部应用程序，我的意思是不接触互联网？ 2) 你的应用需要多少时间来处理这 800MB？
@snahor 1. 不，它不是内部应用程序，它使用 kubernetes 中的 istio 暴露在互联网上。 2. 处理 800 MB 大约需要 12 分钟。

标签： docker nginx gunicorn nginx-reverse-proxy nginx-config

【解决方案1】：

在研究了这个话题后，我自己回答了。不建议在容器 ref 中运行多个进程：here 所以在容器内部不应该使用 nginx 将请求重定向到实际的 uwsgi 服务器。我们可以直接使用 uwsgi 服务，将单个进程分配给多个工作人员。

【讨论】：