uWSGI + Nginx + Django 구성 요약 (Ubuntu 및 Centos 모두 사용 가능)

환경 : Centos7.5 또는 Ubuntu16.04.6. 구성에 문제가 발생하면 메시지를 남겨주세요. 블로그에서 문제를 수정하십시오. 수정 해주세요. nginx 용 포트 80과 uwsgi 용 포트 8000을 열었습니다.
프레임 : Django
설명 : 콘텐츠의 일부는 특히 큰 사람의 블로그 덕분에 재현됩니다. https://blog.csdn.net/u012145252/article/details/82147440 이 문서는 자체에 기반한 몇 가지 레코드입니다. 학습 및 사용을위한 실제 상황.

正式将之前先说一下大概步骤，我们先将uwsgi与django服务配置好，再将nginx与uwsgi服务之间的联系给配置好，如果你在看这篇文章之前对于这三者的关系不太清楚的话也不要紧，耐心的看完你就明白了，现在开始之前，你只需要了解他们三者的这个配置顺序就行了。配置顺序不是固定的，本文以这种顺序进行配置，主要是为了方便调试与理解，现在我们开始！

하나, uWSGI 배포

먼저 자신의 서버에 uwsgi를 설치해야합니다. 가상 환경에서 사용하는 경우 가상 환경에 설치합니다. 서버에 직접 구성한 경우 직접 설치합니다.

pip3 install uwsgi

설치가 완료된 후 uwsgi --version을 사용하여 버전 정보를 볼 수 있습니다.

uWSGI 테스트 실행

우선, 거대한 웹 사이트 소스 코드를 직접 사용하지 않도록 테스트를 통과 할 수 있도록 테스트 코드가 필요합니다.

프로젝트 루트 디렉토리에 하나를 만듭니다 test-uwsgi.py. 코드는 다음과 같습니다. 함수 이름은 여야합니다 application. uwsgi 서비스가 기본적으로 Dajngo에 알리는 인터페이스이기 때문입니다. 우리가 자주 사용하는 Django 프레임 워크 wsgi.py의 구성 파일에서도 볼 수 있습니다 .

def application(env,start_response):
    start_response('200 OK',[('Content-Type','text/html')])
    return [b"Hello Hero, all for one "]

다음 명령은 uwsgi 서비스를 실행하고 포트 8000에서 웹 액세스를 여는 것을 의미합니다.

• 주 – http 다음에는 공백과 포트 번호가옵니다.

uwsgi --http :8000 --wsgi-file test-uwsgi.py

웹 서버 포트 8000에 액세스하고 test-uwsgi.py 스크립트에 반환 된 텍스트를 정상적으로 표시합니다.

이제 우리가 할 일은 nginx와 uwsgi를 기반으로 Django를 배포하는 것입니다. 클라이언트가 요청을 시작하면 서버가 요청에 응답하므로 여러 링크가 있습니다.

the web client <-> the web server(nginx) <-> the socket <-> uwsgi <-> Django

uWSGI가 별도로 테스트되고 액세스 표시가 정상이면 다음 세 링크가 원활하다는 의미입니다.

the web client <-> uWSGI <-> Python

Ctrl + c를 눌러 프로그램을 중지하고 다음 테스트를 수행합니다.

uWSGI로 django 프로젝트 실행

가상 환경에서 django 루트 디렉터리를 입력하고 다음 명령을 입력합니다.

 uwsgi --http :8000 --module projectname.wsgi

효과와 다음 명령을 직접 치십시오

python manage.py runserver 0.0.0.0:8000

그것은 동일합니다.

참고 : 위 projectname.wsgi는 프로젝트 루트 폴더 아래의 wsgi.py게이트웨이 서비스 구성 파일 을 호출하는 것으로 기본적으로 사용자는 변경할 필요가 없습니다. 장고 프로젝트 폴더 경로가 떨리지 않고 배운 후에 알 수 있으며 확인하면 알 수 있습니다. 따라서 프로젝트의 루트 디렉터리에서 명령을 실행해야합니다.

참고 : –module projectname.wsgi는 지정된 wsgi 모듈을로드하는 것입니다. 프로젝트 이름은 일반적으로 프로젝트 이름 .wsgi입니다.
이 테스트 후 uWSGI를 통해 Django까지 웹 클라이언트가 원활하다는 것을 증명할 수 있습니다.

the web client <-> uWSGI <-> Django

프로그램을 중지하려면 ctrl + c를 누른 후 다음 테스트를 수행하십시오.

uWSGi 핫 로딩 Djangoa 프로젝트

시작 명령 뒤에 매개 변수를 추가합니다.

uwsgi --http :8000 --module pojectname.wsgi --py-autoreload=1

마찬가지로, 이때 서버의 8000 번 포트에 접근한다는 것은 django 프로젝트 (pojectname)에 접근하는 것을 의미합니다.

그리고 또 하나의 매개 변수가 있습니다 :
--py-autoreloadpython 모듈을 모니터링하여 재로드를 트리거합니다 (개발에서만 사용됨).

유사한 실행 명령

/..dir../uwsgi --http 0.0.0.0 :8000 --chdir /home/operation/work/luffy --module luffy.wsgi` 
 #此时修改django代码，uWSGI会自动加载django程序，页面生效 # 除此外，还可以接上很多参数

uwsgi 배포 향상

첫째, uwsgi 구성 파일을 사용하여 django 프로젝트를 실행합니다.

위 구성은 테스트 단계에 해당하며 테스트 후 문제가 없으면 시스템을 구성 할 수 있습니다. uwsgi는 ini, xml 및 기타 구성 방법을 지원합니다. ini를 예로 들어 프로젝트 루트 디렉토리에 새 uwsgi.ini를 만듭니다. 구성 예제는 다음과 같습니다.

[uwsgi] #代表这里是uwsgi的配置文件，必须要写这个在第一行

# 指定运行目录，其实就是项目的根目录
# 导入django项目的wsgi模块，我的项目叫GradingSystem,其中application就是默认的网关配置文件的那个函数
module = GradingSystem.wsgi:application
dir=/web/GradingSystem
# 载入wsgi-file，这里是指明网关配置文件在项目文件夹下的路径
wsgi-file = GradingSystem/wsgi.py

# 补充，uwsgi启动时的用户和用户组,注意要按你自己的实际权限进行配置
# 我这边是因为项目属主是gxa，而gxa我设置了添加进了gxa组
# 但这种情况下uid仍不能设置gxa，除非你的项目目录所有文件属主都改为了gxa
uid = centos
gid = www

# 开启master主进程
master = true

# 开启多少个进程数，workers项也等同processes
# threads项则是设置运行线程，测试倒不用设置上线程
processes = 10

# 设置使用的socket端口或socket地址
# socket = 0.0.0.0:8000
# 上面的socket建议配置成一个GradingSystem.socket文件后使用nginx来连接uWSGI运行,不然容易报socket的请求头错误和权限错误等。
#socket = /web/GradingSystem/GradingSystem.socket

#以上信息来源于转载，是大佬博主的建议，但是我采用之后出现了网关错误的问题，可能是我哪里没有搞明白，但是换成下面的配置后就正常了，这个socket指定的端口代表的是uwsgi服务监听的端口

# 在配置uwsgi时，如果直接使用socket进行配置，那么浏览器无法通过http协议进行访问，必须在前面加上nginx转发才可以通过nginx间接访问，因此只测试uwsgi时使用http进行配置。
#socket = 0.0.0.0:8000
http = 0.0.0.0:8000

# 配置生成的sock文件的权限，一般对网站用户的权限都设置为如此，较为安全
chmod-socket = 664

# 退出时清空环境，其实就是将自动生成的GradingSyster.sock和相关pid文件给干掉。
vacuum = true

#设置uwsgi服务的缓存区大小
auffer-size = 65536

uwsgi는 django 프로젝트를 시작할 구성 파일을 지정하고 웹에서 지정한 사용자를 사용하여 실행하는 것이 좋습니다.

uwsgi --ini /..dir../uwsgi.ini

(여기서 ... dir ...은 서버의 프로젝트 경로입니다.)

둘째, 웹 사이트의 사용자 그룹 구성 문제

우선 루트 디렉터리 권한 설정의 필요성 :
웹 사이트 서버의 보안 및 운영을 위해 특정 사용자 및 사용자 그룹을 사용해야합니다. 기존 관행에 따라 www 사용자 그룹 아래에 www 사용자를 사용하도록 선택합니다. 웹 사이트를 실행하려면 서버가 nginx이든 아파치이든 상관없이이 작업을 수행 할 수 있습니다.

www 사용자가 실행하는 서버는 php 스크립트와 같은 동적 스크립트 또는 html, css 및 javaScript와 같은 파일을 포함하여 웹 사이트의 루트 디렉토리에있는 다양한 리소스를 읽어야합니다. 물론 php 스크립트에서 다른 사용자로 전환하여 특수 스크립트를 실행할 수도 있습니다. 이는 쉘 스크립트에서 사용자를 전환하는 것과 동일합니다.

또한 새 사용자 지정 사용자를 만들고, 새 사용자 지정 사용자 그룹을 만들고, 프로젝트 파일의 소속을 사용자 그룹의 사용자로 설정하고, 해당 디렉터리 액세스 권한을 설정할 수도 있습니다.

1. 웹 서버가 아파치 인 경우 사용자가 웹 페이지에 액세스 할 때 아파치 서비스 (httpd) 소유자의 신원을 통해 액세스하므로 아파치, httpd 서비스 소유자 및 모든 그룹은 apache 또는 self로 설정 사용자를 설정하고 루트를 사용하지 마십시오.이 일반 설치 중에 기본 설정이 적용됩니다 (또는 Apache 구성 파일에서 사용자 및 그룹 항목 수정).

2. 일반 방문자에게 웹 파일을 운영 할 수있는 모든 권한을 부여하는 것과 동일하다면 웹 사이트 프로그램의 소유자는 아파치 서비스의 소유자와 동일하지 않아야합니다! 웹 프로그램에 허점이 생기면
끝났습니다! 기본값은 일반적으로 루트이며, 직접 데몬을 생성하는 등 다른 사용자로 변경해보십시오. 아파치 서비스의 소유자와 동일하지 않도록하십시오.

3. 웹 사이트 루트 디렉토리 권한의 경우 최소 권한 원칙에 따라 755로 설정해야합니다.

4. 캐시 디렉토리 또는 업로드 디렉토리 (예 : cache directory : caches directory)의 경우이 디렉토리에는 쓰기 권한이 있어야합니다. 즉, 디렉토리에도 rwx의 세 가지 권한이 있어야합니다. 이때
빈 캐시를 직접 만들 수 있습니다. 디렉토리, chown daemon.daemon
./caches, 캐시 및 모든 그룹의 소유자를 사용자 정의 데몬으로 변경해도 괜찮습니다. 웹 페이지에 액세스하면
캐시 를 아파치로 입력 하여 캐시 디렉토리 및 파일 을 생성합니다. 기본적으로 시스템은 최소한의 권한으로 생성됩니다!

5. 일반 디렉토리의 경우 최소 권한은 755이고 일반 사용자는 쓰기 권한을 부여하지 않습니다.

6. 일반 파일의 경우 최소 권한은 644이고 일반 사용자는 실행 권한을 부여하지 않습니다.
간단히 말해서 디렉토리에 대한 쓰기 권한을 부여하지 않고 파일에 대한 실행 권한을 부여하지 않습니다 (예 : 업로드 할 디렉토리)

위는 비교적 엄격한 웹 사이트 디렉토리 권한 설정입니다. 내가 직접 구성했을 때이 정보를 찾지 못했기 때문입니다. 따라서 권한 관리는 위에서 언급 한 것처럼 자세하지 않지만 작동 방법은 동일합니다. 다음 작업은 루트 권한으로 수행됩니다.

1. 사용자 그룹을 생성합니다 (생성 할 필요는 없습니다. 동일한 사용자 이름을 가진 기본 그룹을 사용하십시오).

groupadd groupname

2. 사용자 생성 및 사용자 그룹 지정

useradd -g groupname username

또는 웹 사이트 서비스를 구성하는 사용자에게는 권장되지 않는 기본 사용자 그룹을 사용합니다.

useradd username

3. 사용자 비밀번호 수정

passwd username

4. 사용자에게 특정 루트 권한을 부여합니다 (특별한 필요가없는 경우 일반 웹 사이트 서비스에는 필요하지 않음).

visudo

마지막 줄에 추가하십시오.

username ALL=(root) /usr/bin/*, /usr/local/elasticsearch-2.4.4/*, !/usr/bin/passwd [A-Za-z]*

참고 : ALL = (root)는 su가 root 사용자로만 전환 될 수 있음을 의미합니다. 사용자의 권한은 쉼표로 구분됩니다. / usr / bin / *는 기본 명령을 실행할 수 있음을 의미합니다. / usr / local / elasticsearch- 2.4.4 / *는 내 Elasticsearch의 파일 경로에있는 모든 권한입니다.! / usr / bin / passwd [A-Za-z] *는 자신을 제외한 모든 사용자의 비밀번호를 수정할 수 없음을 의미합니다.

5. 웹 사이트의 프로젝트 루트 디렉토리 소유자를 새 사용자에게 할당합니다.
http 서버를 실행하는 사용자 및 사용자 그룹은 www, 웹 사이트 사용자는 centos, 웹 사이트 루트 디렉토리는 / home / centos /라고 가정합니다. 편물.
방법 / 단계 :

1
먼저 웹 사이트 디렉토리 및 파일의 소유자와 모든 그룹을 centos, www 및 다음 명령으로 설정합니다.
chown -R centos:www /home/centos/web

2
웹 사이트 디렉토리 권한을 750으로 설정합니다. 750은 centos 사용자가 디렉토리에 대한 읽기, 쓰기 및 실행 권한을 가지고 있음을 의미합니다. 따라서 centos 사용자는 모든 디렉토리에서 파일을 만들 수 있고 사용자 그룹은 읽기 및 실행 권한을 갖습니다. 디렉토리에 들어갈 수 있습니다. 다른 사용자에게는 권한이 없습니다.
find -type d -exec chmod 750 {} \;

3
웹 사이트 파일 권한을 640으로 설정합니다. 640은 centos 사용자 만 웹 사이트 파일을 변경할 수 있음을 의미합니다. http 서버는 파일을 읽을 수있는 권한 만 있고 파일을 변경할 수 없습니다. 다른 사용자는 권한이 없습니다. 쓰기 권한을위한 개별 디렉토리의 경우
find -not -type d -exec chmod 640 {} \;
4
입니다. 예를 들어 웹 사이트의 일부 캐시 디렉토리에는 http 서비스에 대한 쓰기 권한이 있어야합니다. 예를 들어, discuz x2의 / data / 디렉토리에는 쓰기 권한이 있어야합니다.
find data -type d -exec chmod 770 {} \;

위의 설정 후에는 위의 테스트 환경에서와 같이 루트로 서비스를 시작하는 대신 지정된 사용자를 사용하여 웹 사이트의 서비스를 시작할 수 있습니다. 루트로 서비스를 시작하는 것은 안전하지 않습니다.

uWSGI 시작 서비스

계속해서 django 프로젝트를 예로 들어, uWSGI가 부팅 할 때 서비스를 시작하고, 파일을 편집하고 /etc/rc.local,이 코드 줄 앞에 다음 내용을 추가하도록합니다 exit 0.

/..uwsgi再系统中的路径../uwsgi --ini /..Django项目中uwsgi配置文件的路径../uwsgi_luffy.ini

ini 구성 파일 에서 사용자 사용자 그룹, sock파일 sock文件的权限및 后台运行기타 구성을 설정하는 것을 잊지 마십시오 .

둘째, Nginx 배포

• Nginx의 역할은 주로 모니터링하는 것입니다. 클라이언트가 정적 요청을 받으면 요청에 지정된 정적 파일이 클라이언트로 반환되고, 클라이언트가 동적 URL 요청을 보내면 수신 포트에서 uwsgi로 요청을 가져옵니다. service 포트를 수신합니다. 요청을 수신 한 후 uwsgi 포트는 처리를 위해 프로젝트 폴더 아래의 각 Django 서비스 (보기의 함수)로 넘겨집니다. 처리 후 uwsgi는 nginx로 돌아가고 마지막으로 nginx는 해당 콘텐츠를 고객.
• 당연히 이것은 세 사람이 협력하는 과정입니다. 따라서이 단계의 구성은 주로 nginx의 수신 대기 포트를 구성하는 것이며 동적 요청을 수신 한 후 처리에 전달해야하는 uwsgi 수신 포트를 구성하는 것입니다. 또한 프로젝트의 루트 디렉토리, 프로젝트의 정적 폴더의 정적 경로 및 미디어 폴더의 미디어 경로를 포함하여 nginx 자체의 정적 요구 사항 폴더를 구성해야합니다.

다음은 내 프로젝트 구성입니다.

---

nginx는 uwsgi 및 django 구성

• uwsgi_params프로젝트 폴더에 파일을 복사하십시오 .
  uwsgi_params이 파일은 일반적입니다 /etc/nginx/디렉토리, 또한 할 수있다 다운로드 에서 페이지입니다.nginxgithub

• uwsgi_params구성 파일은 다음과 같습니다.

uwsgi_param  QUERY_STRING       $query_string;
uwsgi_param  REQUEST_METHOD     $request_method;
uwsgi_param  CONTENT_TYPE       $content_type;
uwsgi_param  CONTENT_LENGTH     $content_length;

uwsgi_param  REQUEST_URI        $request_uri;
uwsgi_param  PATH_INFO          $document_uri;
uwsgi_param  DOCUMENT_ROOT      $document_root;
uwsgi_param  SERVER_PROTOCOL    $server_protocol;
uwsgi_param  REQUEST_SCHEME     $scheme;
uwsgi_param  HTTPS              $https if_not_empty;

uwsgi_param  REMOTE_ADDR        $remote_addr;
uwsgi_param  REMOTE_PORT        $remote_port;
uwsgi_param  SERVER_PORT        $server_port;
uwsgi_param  SERVER_NAME        $server_name;

• 프로젝트에 복사 :

sudo cp /etc/nginx/uwsgi_params /..项目目录../

• 소유자, 그룹 등의 권한을 다시 수정하십시오.

sudo chown www:centos uwsgi_params
sudo chmod 664 /..项目所在的目录../uwsgi_params

• 프로젝트 폴더 아래에 nginx.conf 파일을 만들고 다음 내용을 채우고 수정합니다.

http{
    
    
	include  /etc/nginx/mime.types;
	upstream django {
    
    
    # server unix:///path/to/your/mysite/mysite.sock; 
    # 用于文件套接字
    server 127.0.0.1:8000; 
    # 用于Web端口套接字（我们将首先使用它）
	}
	# //解决web部署到ｎｇｉｎｘ后js,css等不能访问。
# 服务器配置
server {
    
    
    #您的网站将在其上服务的端口
    listen  80; #nginx的监听端口，相当于是我们提供服务的第一道墙

    # 指定提供服务的主机地址，我们将uwsgi服务于nginx服务配置再一台服务器的，因此指定本机即可
    server_name 127.0.0.1; 
    # 设置nginx传送内容的字符集格式，解决网页乱码问题
    charset utf-8;

    # 设置请求体大小；可用于解决大文件上传不了的问题
    client_max_body_size 500M;   # adjust to taste

    location / {
    
    
        uwsgi_pass  django;
        include  /web/GradingSystem/uwsgi_params; 
        # 您安装的uwsgi_params文件（这个很重要，我是将uwsgi的这个文件拷贝到了项目文件夹下面）
    }

    location /static/ {
    
    
        alias /web/GradingSystem/static/; 
        # 您的Django项目的静态文件-根据需要进行修改
    }

    # Django media
    location /media/  {
    
    
        alias /web/GradingSystem/static/media/;  
        # 您的Django项目的媒体文件-根据需要进行修改
    }

    # 最后，将所有非静态和媒体请求发送到Django服务器。
    
	}
}
events {
    
    
  worker_connections  1024;  ## Default: 1024
}

• 일부 관련 매개 변수의 의미를 추가합니다.

1.client_max_body_size
	-  限制请求体的大小，若超过所设定的大小，返回413错误。
2.client_header_timeout
	- 读取请求头的超时时间，若超过所设定的大小，返回408错误。
3.client_body_timeout
	- 读取请求实体的超时时间，若超过所设定的大小，返回413错误。
4.proxy_connect_timeout
	- http请求无法立即被容器(tomcat, netty等)处理，被放在nginx的待处理池中等待被处理。此参数为等待的最长时间，默认为60秒，官方推荐最长不要超过75秒。
5.proxy_read_timeout
	- http请求被容器(tomcat, netty等)处理后，nginx会等待处理结果，也就是容器返回的response。此参数即为服务器响应时间，默认60秒。
6.proxy_send_timeout
	- http请求被服务器处理完后，把数据传返回给Nginx的用时，默认60秒。

이 구성 파일은 nginx에게 파일 시스템에서 미디어 및 정적 파일을 서비스로 가져
오고 동시에 Django 요청에 응답하도록 지시합니다.

이를 위해 해당 프로젝트 디렉토리에 미디어 및 정적 폴더도 생성했습니다.

nginx가 실행 중일 때 구성 정보를 쉽게 사용하려면 nginx.conf의 소프트 링크 sites-enabled를 nginx의 기본 디렉토리에 만듭니다.

sudo ln -s /..项目所在../nginx.conf /etc/nginx/sites-enabled/nginx.conf

이 소프트 연결이 생성되지 않으면 Nginx 시작시 기본적으로로드되는 구성 파일이 기본 구성 파일이됩니다. 물론 nginx -c /.../nginx.conf명령을 사용하여 nginx를 시작하면 지정된 구성 파일의 구성 정보를로드하고 nginx를 시작할 수 있습니다 .

---

Django는 정적 파일을 배포합니다 (프로젝트에 이미 정적이있는 경우 디렉터리 경로가 올바른지 확인할 수 있음)

• 프로젝트 폴더 아래에 정적 파일 디렉토리를 만듭니다.

mkdir static

• django 설정 파일에 다음 줄을 추가합니다.

STATIC_ROOT = os.path.join(BASE_DIR, “static/”)

• 실행 ( 这个必须得运行)

python manage.py collectstatic

• 프로젝트 폴더에서 미디어 파일 디렉터리를 만듭니다 (테스트를 위해 사진, 음악 및 기타 파일을 저장하는 데 사용됨).

mkdir media

• 미디어 디렉토리에서 nginx를 테스트하기 위해 2333.png 그림 파일을 전달했습니다.

• STATIC_ROOT 매개 변수는 어디에 사용됩니까? 사용하는 모든 정적 파일을 수집하여 STATIC_ROOT
  에 python3 manage.py collectstatic저장하십시오!

• STATIC_ROOT 폴더는 STATICFILES_DIRS의 모든 폴더에있는 모든 파일과 각 앱의 static에있는 파일을 복사하는 데 사용됩니다. 이러한 파일은 nginx 등으로 배포의 편의를 위해 함께 모입니다.

테스트를 위해 nginx 구성 파일 다시로드

• 먼저 이전 구성 파일에 오류가 있는지 확인하십시오.

sudo /usr/sbin/nginx -t

• nginx를 다시로드하여 소프트 링크의 luffy_nginx.conf를 적용하십시오.

sudo /usr/sbin/nginx -s reload

• http://..ip_advers..:80/media/2333.png이미지 리소스에 정상적으로 액세스 할 수 있는지 확인하려면 여기를 방문하세요 . 여기서 사용하는 서비스 포트는 nginx 서비스를 위해 실행되는 포트입니다.

이 단계를 수행하기 전에 도메인 이름을 구성하고 테스트 용 사진을 서버로 보냈습니다.
이 단계를 수행 할 때 많은 구덩이가 발생하고 설명 할 수없는 많은 실수를보고했지만 요약하자면 nginx 서비스에 문제가있는 systemctl status nginx경우 서비스 상태 를 확인하는 데 사용하고 systemctl restart nginx명령을 사용 하여 nginx 서비스를 다시 시작한 다음 테스트.

리소스에 성공적으로 액세스 할 수 있었으므로 다음 테스트 단계를 수행하겠습니다.

nginx 애플리케이션 uWSGI 및 test.py 테스트

이전에 작성한 테스트의 test-uwsgi.py 파일을 기억하십니까?
구성된 nginx를 사용하여 uwsgi에서 시작한 test-uwsgi.py에 액세스 해 보겠습니다.
먼저 uwsgi를 시작하고 포트는 nginx 구성에서로드 밸런싱 풀의 8000 포트입니다.

uwsgi --socket :8000 --wsgi-file test-uwsgi.py

방문은 http://ip:80/실제로 uwsgi의 포트 8000을 방문합니다.

정상적으로 액세스 할 수있는 경우. 다음 링크가 방해받지 않음을 나타냅니다.

the web client <-> the web server <-> the socket <-> uWSGI <-> Python

테스트가 성공하면 프로그램이 종료됩니다. 지금까지 서버의 uwsgi, nginx 및 Django 간의 관계를 열었습니다. 마지막으로 Nginx, WSGI 및 Django 간의 대화를 통해 세 가지 관계를 설명합니다.

Nginx : 안녕하세요, WSGI, 방금 요청 (동적 http 요청)을 받았습니다. 몇 가지 준비를해야합니다. 그러면 Flask가 요청을 처리합니다.
WSGI : 네, Nginx. 환경 변수를 설정 한 다음 처리를 위해 Django에 요청을 전달합니다. Django : 감사합니다
WSGI! 시간을내어 요청에 대한 응답을 보내 드리겠습니다. WSGI : 좋아, 그럼 기다릴게.
Django : 좋아요, 끝났습니다. 요청의 응답 결과는 다음과 같습니다. 요청은 결과를 Nginx에 전달합니다. WSGI : 잘
했어요! Nginx, 여기에 필요에 따라 다시 전달 된 응답 결과가 있습니다. Nginx : 멋지네요. 저는 그것을 받고 응답 결과를 클라이언트에 반환합니다. 모두 행복한 협력 ~

댓글란에 메시지를 남겨 주셔서 감사합니다. 잘못된 글이 있으시면 올려주세요. 제 시간에 수정 해 드리겠습니다. 함께 진행하겠습니다!