Question

我正在按照以下tutorial的要求使用Nginx和Gunicorn部署Django应用，但是我修改了一些步骤，以便可以使用Conda代替ViritualEnv。

设置如下：

Nginx用我的Vue应用程序回复
来自Vue的请求发送到api.example.com
Nginx监听api.example.com并将请求定向到Gunicorn的Unix套接字

我检查过的东西

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

如果执行nmap localhost之类的命令，我应该看到Django在8000端口上运行吗？我看到另一个post提到Nginx应该指向8000端口，而gunicorn应该与以下任一端口一起运行：

gunicorn --bind 0.0.0.0:8000 <djangoapp>.wsgi --daemon
gunicorn <djangoapp>.wsgi:application --bind <IP>:8000 --daemon
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

独角兽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;
  }

使用Nginx，Gunicorn和Supervisor部署Django

2 个答案: