使用 Nginx、Gunicorn 和 Supervisor 部署 Django

Question

我正在尝试按照tutorial 使用 Nginx 和 Gunicorn 部署我的 Django 应用程序，但我修改了一些步骤，以便可以使用 Conda 而不是 ViritualEnv。

设置如下：

1. Nginx 回复我的 Vue 应用程序
2. Vue 向 api.example.com 发出请求
3. Nginx 监听 api.example.com 并将请求定向到 Gunicorn 的 unix 套接字

我检查过的内容：

1. 我可以在 Nginx 的access.log 中看到 Vue 请求。
2. 我还可以通过journalctl -f -u gunicorn、supervisor.log 和 gunicorn 的 access.log 看到这些请求
3. 当我的 Django 应用程序启动时，它会创建一个日志文件，因此我可以看到 Gunicorn 启动了它。但是 Django 没有响应来自 unix 套接字的请求。
4. 当我 ssh 进入并运行以下命令时，我可以看到来自 Django 的响应： curl --no-buffer -XGET --unix-socket /var/www/example/run/gunicorn.sock http://localhost/about。仅当我的任何 ALLOWED_HOSTS 用于代替 localhost 时，此命令才会给出响应。
5. 我的 Nginx、Supervisor 和 Gunicorn 配置都使用 gunicorn.sock 的完整路径。

如果我执行nmap localhost 之类的操作，我应该看到 Django 在端口 8000 上运行吗？ 我看到另一个 post 提到 Nginx 应该指向 8000 端口，并且 gunicorn 应该使用以下任一方式运行：

1. gunicorn --bind 0.0.0.0:8000 <djangoapp>.wsgi --daemon
2. gunicorn <djangoapp>.wsgi:application --bind <IP>:8000 --daemon
3. gunicorn <djangoapp>.wsgi:application --bind=unix:/var/www/example/run/gunicorn.sock

但是暴露 8000 端口不会破坏使用 Nginx 作为反向代理和 Gunicorn 的 unix 套接字的目的吗？暴露 8000 不会增加攻击向量的表面积吗？还是公开端口 8000 是最佳做法？我有点困惑，为什么我会同时使用暴露该端口并同时使用 Nginx 和 Gunicorn。

我的主要问题：为什么我可以通过带有 curl 的 unix 套接字从 Django 获得响应，而不是通过来自 Vue 的请求？为什么 Vue 的请求不能通过 unix 套接字从 Gunicorn 发送到 Django？

我真的被困住了。有什么建议吗？

前端 Nginx 配置

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        # server_name example.com;
        # server_name myIP;
        root /var/www/example/frontend/dist;
        server_name example.com www.example.com;

        location =/robots.txt {
                root /opt/example;
        }

        location /thumbnail/ {
                alias /opt/example/static/img/thumbnail/;
        }

        location /bg/ {
                alias /opt/example/static/img/bg/;
        }

        location / {
                try_files $uri $uri/ /index.html;
        }
}

API Nginx 配置

upstream backend_server {
        server unix:/var/www/example/run/gunicorn.sock fail_timeout=0;
}

server {
        listen 80;
        server_name api.example.com
        client_max_body_size 4G;

        access_log /var/log/nginx/api-access.log;
        error_log /var/log/nginx/api-error.log;

        location / {
                include proxy_params;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_headers_hash_max_size 512;
                proxy_headers_hash_bucket_size 128; 
                proxy_redirect off;
                if (!-f $request_filename) {
                        proxy_pass http://backend_server;
                }
        }
}

Gunicorn 配置

#!/bin/bash

NAME=”backend”
DJANGODIR=/var/www/example/backend
SOCKFILE=/var/www/example/run/gunicorn.sock
USER=django
GROUP=example
NUM_WORKERS=3
DJANGO_SETTINGS_MODULE=backend.settings
DJANGO_WSGI_MODULE=backend.wsgi
CONDA_SRC=/home/justin/anaconda3/etc/profile.d/conda.sh
GUNICORN=/home/justin/anaconda3/envs/production/bin/gunicorn

echo “starting backend”

cd $DJANGODIR
    source $CONDA_SRC
conda activate production
    export DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULE
    export PYTHONPATH=$DJANGODIR:$PYTHONPATH
    
RUNDIR=$(dirname $SOCKFILE)
test -d $RUNDIR || mkdir -p $RUNDIR

exec $GUNICORN
 ${DJANGO_WSGI_MODULE}:application \
  --name $NAME \
  --workers $NUM_WORKERS \
  --user=$USER --group=$GROUP \
  --bind=unix:$SOCKFILE \
  --log-level=debug \
  --log-file=- \
  --error-logfile=/var/www/example/backend/logs/gunicorn-error.log \
  --access-logfile=/var/www/example/backend/logs/gunicorn-access.log

Gunicorn access.log

- - [08/Sep/2020:01:51:24 -0400] "OPTIONS /c/about/ HTTP/1.0" 200 0 "http://example.com/c/about" "Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Mobile Safari/537.36"
- - [08/Sep/2020:01:51:24 -0400] "POST /c/about/ HTTP/1.0" 400 143 "http://example.com/c/about" "Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Mobile Safari/537.36"

Answer 1

但是暴露 8000 端口不会破坏使用 Nginx 作为反向代理和 Gunicorn 的 unix 套接字的目的吗？

在 gunicorn 中，您必须像 gunicorn --bind 127.0.0.1:8000 <djangoapp>.wsgi --daemon 这样在 localhost 上公开 8000 端口。考虑到您的 nginx 在同一台服务器上，将其暴露在 0.0.0.0 上显然是一个安全漏洞。

暴露 8000 不也会增加攻击向量的表面积吗？还是公开端口 8000 是最佳做法？我有点困惑，为什么我会同时使用暴露该端口并同时使用 Nginx 和 Gunicorn。

您不需要公开端口 8000，您可以公开任何端口，但您需要告诉 gunicon 至少侦听一个端口，以便 nginx 可以将请求传递给它。

关于同时使用 nginx 和 gunicorn，它们都非常不同，并且处理应用程序的非常不同的用例/功能。

Nginx 使用“事件驱动”的方法来处理请求，因此单个 nginx 工作人员可以同时处理 1000 多个请求。但另一方面，Gunicorn 主要（默认情况下）使用同步工作者，这意味着请求将保留在工作者中，直到它被处理。 （今天发了两次：p）

因此，如果您删除 nginx，则您需要两者，所有请求都将返回 50X，但当前由 gunicorn 处理的请求除外，直到工作人员空闲。而且 gunicorn 不是用来处理用户流量的，或者在更大的应用程序中，负载平衡等事情只能由 nginx 完成。所以 nginx 在应用中有它自己的用途。

Answer 2

在neeraj9194 指出400 之后，我做了更多的搜索与 Nginx、Gunicorn 400 和 Django 相关的问题，并且遇到了大量类似的问题。看起来主要是 Nginx 的问题。这个blog 的答案解决了我的问题。

我将 API Nginx 配置中的 location 块替换为：

location / {
      proxy_set_header Host $host;
      proxy_pass http://backend_server;
      proxy_set_header X-Forwarded-Host $server_name;
      proxy_set_header X-Real-IP $remote_addr;
  }