centosflask uWSGI + + Nginx에 배포

centosflask uWSGI + + Nginx에 배포

 

1. 개념

자신의 웹 서버를 플라스크 - WERKZEUG, 당신은 사이트를 실행하는 서비스를 구축 할 수 있습니다. 그러나, 일반적으로 전문 --uWSGI와 개발한다.

또한,이 종종의 nginx와.

 

1.1. uWSGI

uWSGI는 응용 프로그램 서버 (여러 프로그래밍 언어를 지원), 대리인, 프로세스 관리자, 모니터를 구현하는 풀 중지 호스팅 서비스입니다. 처음 WSGI 파이썬 것을 알게 되었기 때문에 UWSGI라는.

WSGI : 구문 분석 파이썬을 구현하기위한 공통 인터페이스 / 프로토콜은 보편적 인 인터페이스 표준 인터페이스 프로토콜, 또는 서버 프로그램 pythonweb 상호 작용 사이의 공통점을 달성하기 위해.

그것은, web.py 또는 병 또는 쉽게 다른 웹 서버에 배포 할 수 있습니다 장고 등 pythonweb 개발 프레임 워크를 사용하여;

uwsgi :처럼 WSGI는 통신 프로토콜입니다

uwsgi uWSGI 서버 프로토콜, 그것은 WSGI와 비교 정보 송신의 유형을 정의하는 독점 프로토콜 인 두 가지이다.

uWSGI : 서버 / 게이트웨이 한 종류 또는 pythonwebserver라고

uWSGI 유사한 tornadoweb 또는 flup하는 pythonwebserver는 uWSGI는 웹 서버와 WSGI uwsgi 두 프로토콜, 웹 요청에 응답 할 책임이 파이썬을 달성하는 것입니다.

등 아파치, nginx를, 때문에, 그들 자신은 PHP 함수와 같은 동적 언어가 해결되지 않지만, 같은 내장 된 PHP 모듈,이 같은 아파치 지원 PHP 같은 느낌 말할 수 아파치로 할 수있는 다른 모듈에 할당.

uWSGI는 WSGI 협정, uwsgi 프로토콜, HTTP 및 기타 프로토콜을 깨달았다. HttpUwsgiModule uWSGI에서 Nginx의 역할은 서버와 교환된다.

uWSGI는 C 언어로 작성되어 성능이 상대적으로 높다. uWSGI 네 부분을 포함한다 :

 

1.2. Nginx에

 

Nginx에 효율적으로 웹 서버와 역방향 프록시 서버가 부하 분산을 사용할 수 있습니다, 그것은 보안 필터링, 안티 DDoS 공격 할 수있다 (N 사용자가 서버에 액세스 할 때, 션트을 달성 할 수 있으며, 서버에 압력을 완화). 아파치에 비해 Nginx에 배포하는 간단한 백만의 TCP 연결, 동시 연결 십만 수준, 적은 메모리 소비, 낮은 비용을 지원할 수있는 높은 동시성을 지원하지만, Nginx의 아파치 모듈은 풍부하지 않습니다.

uwsgi 협정의 Nginx에는 지원 uWSGI, 그래서 우리는 uWSGI 과정 uwsgi_pass 동적 콘텐츠로 Nginx에, Nginx와 함께 uWSGI 수 있습니다.

 

1.3. 왜의 nginx를 사용

uWSGI 웹 서버의 역할을 할 수 있기 때문에, 다음 uWSGI Nginx에 필요한 이유있다?

가장 일반적인 인수는 Nginx의 장점, 정적 파일에 대한 더 나은 성능입니다. 사이트가 작 으면 사실, 정적 파일을 처리 할 필요가 없습니다 만 uWSGI도 가능하지만, Nginx에이 층으로, 장점은 매우 구체적 일 수있다 :

서버가 IP 스푸핑은 uWSGI가, 다음 코드를 수정해야하는 경우 Nginx에 구성 파일의 블랙리스트에 IP를 추가 할 경우, 운영 및 유지 보수를 들어, 더 편리합니다.

반면에, Nginx의 웹 서버는 이전 버전의가 HTTPS를 지원하지 않습니다, 당신은 Nginx에 안전하게 말할 수있는 예를 uWSGI를 들어, uWSGI의 성능에보다 전문적인 것으로 보인다 베테랑이다.

Nginx의 기능은로드 밸런싱 및 HTTP 캐싱을 할 수있는 능력, 더 이상의 서버 경우, Nginx에의 기본은 필수이며, Nginx에 의해, 자원이 아니라 성능을 향상시킬 수 있습니다, 하나 개의 서버, 다른 서버 노드에 할당 할 수 있습니다 Nginx에 등 잘 결국 C 언어로 작성 ExpiresorE 태그, GZIP 압축의 헤더를 통해 정적 자원을 처리 할 수 ​​있기 때문에, 함수 호출은이 동적 자원, O / I에 최적화 네이티브 Nginx에 또한 CDN 최적화와 캐싱 기능을, (uWSGI이 불가능) 구현할 수 있습니다. 같은 효율적으로 Nginx의 지원는 epoll / kqueue 네트워크 라이브러리는 uWSGI 높은 가야 알지 짧은 연결 요청 동시 고성능 비와 함께 잘 작동합니다.

여러 응용 프로그램 PHP, 파이썬과 서버 호스트에 기록 된 다른 언어를 실행하는 경우, 당신은 포트 80에서 수신 할 필요가,이 시간의 Nginx은 필요한 옵션입니다. 우리는 포워딩 서비스를 필요로하기 때문에.

그래서, Nginx에 기본적으로 필수입니다. uWSGI 자체가 웹 서비스를하지만, 여기 다시는 역방향 프록시로 Nginx에 Nginx에의 도입을 넣어하는 것입니다 그래서 다른 사람들이 왜 우리를 인 uWSGI에 전달하는 동안 그래서, 일부 사진은, JS 등의 정적 리소스는 Nginx에와 서비스를 제공 할 수 있습니다 이 배포 아키텍처의 궁극적 인 목표.

 

2. 배포

2.1. 시스템 환경

centos6.5

python3.6.5

nginxn 1.10.3

uwsgi 2.0.18

 

2.2. uWSGI

uWSGI는 파이썬 웹 컨테이너에 의해 구현되고, 더 나은 호환성 등 pythonweb 응용 프로그램 프레임 워크 장고, 플라스크 등을 게시 할 수 있습니다. 본질적 uwsgi 파이썬 모듈이기 때문에,이 설치 pipinstalluwsgi 직접적으로 사용될 수있다.

설치가 완료된 후 Uwsgi 적절한 디렉토리 서버 구성 파일을 만들 수 있습니다. 예를 들어, 나는 프로젝트의 루트 디렉토리 uwsgiconfig.ini의 파일을 생성을 선택합니다. 또한, 구성 INI 형식 외에 JSON 지지체 및 구성의 XML 포맷의 다른 다양한 uwsgi한다. 여기서, INI 형식으로, 예를 들어.

 

2.2.1. 구성

직접 다음과 같이 구성 파일을 실행 uwsgi :

[Uwsgi]

HTTP = 0.0.0.0:9000

CHDIR = / 가정 / web_server / 플라스크 / 웹 사이트

WSGI 파일 = run.py

호출 = 응용 프로그램

프로세스 = 4

스레드 = 2

pidfile = /home/web_server/flask/uwsgi.pid

데몬으로 = /home/web_server/flask/server.log

 

매개 변수는 다음과 같습니다

당신이 uwsgi에 의해 지정된 포트를 지정한 후 더 이상)합니다 (uwsgi에 의해 실행 수행 실제로 변수 후 호출 주어진 포트의 플라스크를 실행 할 필요가 없습니다

소켓 : 소켓 통신 포트, uWSGI 서버를 떠날 상응하는, Nginx와 함께 의사 소통을 담당하는 외부 세계에 대한 인터페이스,하지만 참고 소켓을 직접 성공 HTTP 요청을 통해 액세스 할 수 없습니다.

PYTHONPATH : 프로젝트 디렉토리.

호출 : 응용 프로그램은 = 플라스크 (__ name__) 그래서 여기에 응용 프로그램입니다 있습니다 일반적으로 응용 프로그램에서 변수 이름을 사용합니다.

프로세스 : 프로세서의 수.

스레드 : 스레드의 수.

프로세스와 스레드 서버를 시작 uwsgi 지적 후, 여러 병렬 프로세스가 열립니다 서버는, 각 프로세스는 요청이 처리 성능을 만들 것입니다 분명이 숫자가 너무 작하지, 합리적인해야하며 너무 많이 기다리고 처리하기 위해 몇 스레드 열립니다 그것은 서버 자체에 너무 많은 부담을 가져올 것이다.

통계 : 통계 정보 서비스 주소를 획득 uwsgi

데몬으로 : uWSGI 프로세스가 백그라운드에서 실행하고 지정된 로그 파일 또는 UDP 서버를 남깁니다.

 

 

 

2.2.2. 시작 / 중지

uWSGI가 xxx.ini 시작 파일에 의해 같은 디렉토리에 xxx.pid을 생성, 단 하나의 선이 uWSGI의 주요 프로세스의 프로세스 ID입니다있다.

시작 uWSGI :

uwsgi --ini xxx.ini

 

uwsgi 재부팅 :

uwsgi --reload xxx.pid

 

uwsgi 정지 :

uwsgi --stop xxx.pid

 

PID 파일을 지정 수동으로 생성 할

 

2.2.3. 문제

 

닫기 문제

수동으로 PID 파일을 지정한 후, 실제 과정은 -stop 만 만 죽일 수 나머지 세에 기록 된 프로세스 PID 파일을 닫습니다 꺼져 사용하여, 네,하지만 하나의 PID의 PID를 시작했다

일괄 프로세스를 종료 :

pkill에 uwsgi

pkill에 -f uwsgi -9 # 비해 일반적으로 더 적은을

 

 

2.3. nginx를

2.3.1. 설치

냠의 nginx를 설치

 

보기 버전

의 nginx 버전 : nginx를 / 1.10.3

 

2.3.2. 구성

얌에 CentOS에 설치된 프로필 경로는 일반적인 프로파일을 변화 /etc/nginx/nginx.conf

구성 파일을 수정 Nginx.conf 있지만, 직접 수정하지 않고, 다른 방법을 사용 (권장)

 

기본 설치 구성 파일을 nginx를하면 꼬리 /etc/nginx/nginx.conf을 다음과

              /etc/nginx/conf.d/*.conf을 포함한다;

즉 다른 구성 파일을 소개 /etc/nginx/conf.d/ 폴더 외부 디렉토리입니다.

따라서, 기본 구성 파일을 수정하지 않는하여 프로파일 시스템 견고성을 증가 /etc/nginx/conf.d/ 디렉토리에 새로운 webapp.conf를 추가합니다.

 

다음과 같이 webapp.conf 읽

서버 {

    9002을 듣고; // 웹 액세스 포트

    서버 _ 로컬 호스트; // 서버 이름

    문자셋 UTF-8;

    ACCESS_LOG /var/www/webapp/access.log; // 서버, 그렇지 않으면 Nginx에 오류를 요청 로그를 수신 만들 수있을 필요가있는 경우 디렉토리를 기록

    의 error_log /var/www/webapp/error.log; // 오류 로그

    100M를 client_max_body_size;

    위치 / {

       uwsgi_params을 포함한다;

       127.0.0.1:9000 uwsgi_pass, 주소 소켓 // uwsgi 요구와 같은 항목의 프로파일, 또는 uwsgi가 요청을 수신 할 수 없습니다.

       #uwsgi_param UWSGI_PYHOME의 / var / www /에서 웹 애플리케이션 / Venv;

       uwsgi_param UWSGI_CHDIR / 홈 / web_server / 플라스크 / web_test; // 루트 디렉토리 프로젝트

       #uwsgi_param UWSGI_SCRIPT 실행 : 응용 프로그램은, 메인 프로그램의 프로젝트를 시작 // (로컬에서 실행

                                 // 메인 프로그램의 플라스크에 내장 될 수있다

                                 // 서버의 프로젝트에 액세스), 사실, uwsgi 지정할 수 있습니다

       }

 

    404을 /404.html을 error_page;

        위치 = {/40x.html

        }

   

    500 502 503 504 /50x.html을 error_page;

        위치 = {/50x.html

        }

}

 

문제 :

알 수없는 지시문에서 "수신"

구성 파일 탭 공간은, 보통의 공간으로 대체 될 수있다.

 

2.3.3. 시작 / 중지

시작의 nginx -c /usr/local/nginx/conf/nginx.conf

 

중지 :

닫기의 nginx 방법 :

(1) 명령

nginx를 시작할 때, 당신은의 nginx를 nginx를 관리 프로세스 (즉, 마스터 프로세스)을 제어하기 위해 "-s"매개 변수를 사용할 수있는 것은 신호를 보냅니다의 nginx -s 신호를

어떤 신호는 다음 값이 될 수 있습니다 :

  [1] 중지 : 빠른 닫기

  [2] 종료하십시오 안전 종료

  [3] 장전 : 구성 파일을 다시

  [4] 다시 : 로그 파일을 다시 열고, 주로 로그를 절단하는 데 사용

종료 후 현재 요청을 완료 통지의 nginx 작업자 프로세스 대기 신호를 종료,이 명령은 리눅스 계정의 nginx를 시작 수행 할 수 있습니다.

Nginx에 리로드 구성 파일 nginx.conf을 알리는 신호를 다시로드합니다. 구성 파일에 대한 변경 사항은 실시간 프로세스가 이미 적용의 nginx에서 실행되지 후 외부 다시로드를 사용하는 것 외에도, nginx를 만 시작시 구성 파일을로드합니다.

이 명령을 실행하면 프로필이 아무 문제가없는 경우, 마스터 프로세스는 구성 파일을 읽으려고합니다 (해당 구성 파일을 확인하는 방법은 아래를 참조하십시오는?) :

마스터 프로세스는 새 구성 파일을 실행하기 위해 새로운 작업자 프로세스를 시작하고 요청을 처리하고 현재 작업을 처리 한 후 새 요청하고 종료를 처리하지 않습니다 이전 작업자 프로세스를 통지합니다.

실행할 수없는 문제가 구성 파일, 마스터 프로세스가 파일 작업을 계속 이전 구성을 롤백하는 경우, 전체 프로세스는 nginx를 비정상 종료로 이어질하지 않습니다.

리눅스 킬 명령은 다음에, 동일한 효과를 다시 그만 123456 종료 -s HUP 123456 죽이고 이들 두 명령 앞에 -s 죽의 nginx의 마스터 처리 ID (PID) 123456는 가정, 동일한 효과를 얻을 수있다.

닫기의 nginx 명령 1 :

nginx를 종료 -s

 

[3] 장전 구성

구성 파일을 다시로드

(1) 명령

의 nginx -s 다시로드

 

2.4. UWSGI 재구성

uwsgi 구성 할 때와 독립적으로 동작 Nginx의 사용과 동일하지

프로필 : uwsgi_nginx.ini

[Uwsgi]

소켓 = 9000

CHDIR = / 가정 / web_server / 플라스크 / 웹 사이트

WSGI 파일 = run.py

호출 = 응용 프로그램

프로세스 = 4

스레드 = 2

pidfile = /home/web_server/flask/uwsgi.pid

데몬으로 = /home/web_server/flask/server.log

 

3. 테스트 결과

3.1. uWSGI

nginx를 사용하지 마십시오, 직접 실행 uWSGI

uwsgi uwsgi_independent.ini

 

3.1.1. 결과는 보여

방문 에 http : // IP : 9000 / 성공.

 

3.2. uWSGI +의 nginx

먼저 시작 uwsgi, 당신은 절대 경로를 작성하지 않는 경우하면 현재 경로에 INI 파일에서 수행 될 필요가

[소프트 플라스크 @ 루트] # uwsgi uwsgi_nginx.ini

 

nginx를 시작합니다

의 nginx -c /etc/nginx/nginx.conf

 

3.2.1. 결과는 보여

방문 에 http : // IP : 9002 / 성공.

참고 :의 nginx를 구성 할 때 지정합니다.

 

 

4. 부록

4.1. 일반적인 명령

추신 -ef | 그렙 uwsgi

uwsgi uwsgi.ini

uwsgi --stop uwsgi.pid

죽일 -9