WSGI, uwsgi 및 uWSGI의 차이점과 uWSGI 및 gunicorn 기반 Python 웹 배포에 대한 간략한 설명

WSGI, uwsgi 및 uWSGI의 차이점과 uWSGI 및 gunicorn 기반 Python 웹 배포에 대한 간략한 설명

 

소개

최근에 저는 Flask 웹 프레임 워크를 기반으로하는 백엔드 프로젝트를 개발하고 있습니다. 웹 서버와 Flask 애플리케이션 간의 상호 작용 중에이 기사의 주제에서 언급 한 WSGI, uwsgi 및 uWSGI의 개념을 접하게됩니다. 다음과 같이.

WSGI

영어 전체 이름 : 웹 서버 게이트웨이 인터페이스, 웹 서비스 네트워크 관리 인터페이스, 간단히 말해서 웹 서버와 응용 프로그램 간의 통신 사양입니다.

Uwsgi

uwsgi는 통신 프로토콜이지만 WSGI의 두 가지 항목에 속하며이 프로토콜에서는 더 빠릅니다.

uWSGI

uWSGI는 웹 서버이며 독점적 인 uwsgi 프로토콜이지만 WSGI 프로토콜, HTTP 프로토콜 등도 지원하며, 그 기능은 Python이 사용할 수 있도록 HTTP 프로토콜을 언어 지원 네트워크 프로토콜로 변환하는 것입니다.

 

Flask는 사용이 매우 간편하고 내장 된 app.run(host="0.0.0.0", port=7001)디버깅이 매우 편리하지만 높은 동시성이든 견고성이든 프로덕션 환경에서 사용됩니다. 일반적으로 WGSI 컨테이너에는 부족합니다. [프로덕션 환경에서의 배포]

 

uWSGI 사용

Django 프로젝트에서 작업 할 때는 일반적으로 Django의 내장 웹 서버를 테스트 및 개발에 직접 사용하지만 프로젝트를 프로덕션 환경에서 사용하고 동시성 및 기타 성능을 고려할 경우 uwsgi 및 nginx가 필요할 수 있습니다. uwsgi의 일반적인 사용법에 대해 설명합니다. nginx의 구성에 대해서는 후속 조치를 위해 특별히 블로그 게시물을 작성하겠습니다.

1. 설치

 

pip install uwsgi

2. 구성

일반적으로 uwsgi를 실행하는 방법에는 명령 줄과 파일 구성의 두 가지가 있지만 명령 줄은 많은 매개 변수를 기억해야 할 수 있으므로 파일 구성이보다 일반적인 접근 방식입니다. 파일 형식은 ini, xml, yaml 등과 같은 다양한 유형을 지원합니다. 저자는 비교적 간단한 키-값 형식 ini 모드 사용을 권장합니다. 간단한 uwsgi ini 구성 예제는 다음과 같습니다.

 

[uwsgi]
socket = 127.0.0.1:8001
master = false
chdir = /var/www/cmpvirtmgr/
module = cmpvirtmgr.wsgi
home = /var/www/env
workers = 2
reload-mercy = 10
vacuum = true
max-requests = 1000
limit-as = 512
buffer-size = 30000
pidfile = /etc/uwsgi/uwsgi.pid

실행 : uwsgi --ini /path/to/uwsgi.ini

매개 변수 설명 :

  • 소켓 : 소켓 파일, 주소 + 포트 일 수도 있습니다.
  • 마스터 : 다른 프로세스를 관리하기 위해 기본 프로세스를 시작할지 여부;
  • chdir : 프로젝트의 루트 디렉토리.
  • 모듈 : wsgi 파일의 상대 경로;
  • 홈 : 가상 환경 디렉토리;
  • 작업자 : 열린 프로세스의 수;
  • reload-mercy : 원활한 재시작 (수신 된 요청이 처리 될 때까지 재시작)에서 작업중인 하위 프로세스의 작업이 끝날 때까지 대기하는 최대 시간 (초)을 설정합니다.
  • vacuum : 서비스가 종료되면 해당 소켓 및 pid 파일을 삭제합니다.
  • max_requests : 각 작업자 프로세스에서 설정 한 요청의 상한.
  • limit_as : 각 uwsgi 프로세스가 차지하는 가상 메모리 수를 제한합니다.
  • buffer_size : uwsgi 패키지 구문 분석에 사용되는 내부 버퍼 영역의 크기를 설정합니다.
  • pid_file : pid 파일을 지정하십시오.
  • harakiri : 요청의 시간 초과 기간.
  • daemonize : 프로세스가 백그라운드에서 실행되고 로그를 특정 경로에 저장합니다. uwsgi 프로세스가 감독자가 관리하는 경우이 매개 변수를 설정할 수 없습니다.

더 많은 uwsgi 매개 변수는 공식 문서를 참조하십시오 : https://uwsgi-docs.readthedocs.io/en/latest/


gunicorn을 사용하여 플라스크 프로젝트 배포

 

1. WSGI 프로토콜

웹 프레임 워크는 HTML 코드를 생성하거나 Restful을 기반으로 API 인터페이스 데이터를 생성하는 방법에 전념하며 웹 서버는 HTTP 요청을 처리하고 응답하는 데 사용됩니다. 웹 프레임 워크와 웹 서버 간의 통신에는 양 당사자가 준수하는 일련의 인터페이스 프로토콜이 필요합니다. WSGI 프로토콜은 두 인터페이스를 통합하는 데 사용됩니다.

2, WSGI 용기

일반적으로 사용되는 WSGI 컨테이너는 Gunicorn 및 uWSGI이지만 Gunicorn은 구성 파일을 작성하지 않고 명령으로 직접 시작되므로 uWSGI보다 훨씬 쉽습니다. 그래서 여기서도 Gunicorn을 컨테이너로 사용하도록 선택합니다.

3. gunicorn 소개

Gunicorn은 Ruby의 unicorn 프로젝트에서 파생 된 Unix 시스템에서만 실행을 지원하는 Python Wsgi http 서버입니다. Gunicorn은 다양한 wsgi 웹 프레임 워크에서 작동 할 수있는 prefork master-worker 모델 (gunicorn에서는 마스터를 중재자라고 함)을 사용합니다.

4. Gunicorn 설치

gunicorn의 설치는 매우 간단합니다. pip install gunicorn 명령을 사용하면됩니다. 일반적으로 주로 비동기 작업자 모델을 사용하기 위해 사용하지만 해당 비동기 모듈도 설치해야합니다.

$ pip install gunicorn 
$ pip install greenlet # 使用异步必须安装
$ pip install eventlet # 使用eventlet workers
$ pip install gevent   # 使用gevent workers

5. gunicorn 사용

다음은 gunicorn을 사용하여 플라스크 프로젝트를 배포하는 예입니다. 여기에서 플라스크 프레임 워크를 사용하는 것은 너무 복잡하지 않으며이 기사의 초점도 아닙니다.

다음 예제는 app.py로 저장합니다.

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

일반적으로 gunicorn에서 사용하는 매개 변수는 다음과 같습니다.

-c CONFIG, --config=CONFIG
# 设定配置文件。
-b BIND, --bind=BIND
# 设定服务需要绑定的端口。建议使用HOST:PORT。
-w WORKERS, --workers=WORKERS
# 设置工作进程数。建议服务器每一个核心可以设置2-4个。
-k MODULE
# 选定异步工作方式使用的模块。

다음과 같이 셸에 시작 구성을 입력합니다.

$ gunicorn -w 3 -b 127.0.0.1:8080 app:app
# 此处app:app中,第一个app为flask项目实例所在的启动模块,第二个app为生成的flask项目实例

서버는 정상적으로 실행될 때 시작할 수 있습니다.

6. 바인딩 포트

Linux는 일반적으로 루트 사용자 권한이 아닌 한 1024 미만의 포트 사용을 금지합니다. 많은 사람들이 gunicorn을 사용할 때 포트 80 또는 443에 바인딩하려고 시도했지만 유효하지 않은 것으로 나타났습니다. 이러한 포트에 바인딩하려는 경우 다음과 같은 몇 가지 일반적인 방법이 있습니다.

  • Nginx 프록시 전달을 사용합니다.
  • sudo는 gunicorn을 시작합니다.
  • 추가 프로그램을 설치하십시오.

7. gunicorn 서비스 프로세스 종료

gunicorn의 모든 프로세스를 찾으려면 ps -ef | grep gunicorn 명령을 사용합니다.

[root@VM_0_12_centos ~]# ps -ef | grep gunicorn
root     16843 23035  0 Oct14 ?        00:00:02 /root/Envs/myflask/bin/python3.6 /root/Envs/myflask/bin/gunicorn -w 3 -b 172.17.0.12:80 app:app
root     22445 23035  0 Oct04 ?        00:00:15 /root/Envs/myflask/bin/python3.6 /root/Envs/myflask/bin/gunicorn -w 3 -b 172.17.0.12:80 app:app
root     22581 23035  0 Oct11 ?        00:00:05 /root/Envs/myflask/bin/python3.6 /root/Envs/myflask/bin/gunicorn -w 3 -b 172.17.0.12:80 app:app
root     23035     1  0 Sep27 ?        00:04:11 /root/Envs/myflask/bin/python3.6 /root/Envs/myflask/bin/gunicorn -w 3 -b 172.17.0.12:80 app:app

그런 다음 kill -9 process ID 명령을 사용하여 프로세스를 종료합니다. 주 프로세스를 찾아서 종료하면 자식 프로세스가 종료됩니다. 위의 예에서 기본 프로세스 ID는 23035입니다.

[root@VM_0_12_centos ~]# kill -9 23035
[root@VM_0_12_centos ~]# ps -ef | grep gunicorn

프로세스를 종료 한 후 몇 초간 기다린 다음 ps -ef | grep gunicorn을 사용하여 모든 gunicorn 서비스 프로세스가 종료되었는지 확인하고 찾습니다.

추천

출처blog.csdn.net/smilejiasmile/article/details/110821259