웹사이트 검색

Nginx와 함께 uWSGI 웹 서버를 사용하여 Python WSGI 애플리케이션을 배포하는 방법

소개

Python 웹 서버 비교 기사에서 소개한 것처럼 uWSGI는 웹 애플리케이션만 제공하는 것보다 훨씬 더 많은 작업을 수행할 수 있는 방대한 프로젝트입니다. 그러나 상대적으로 쉽게 구성할 수 있는 광범위한 기능과 결합되어 특히 Nginx와 결합될 때 많은 배포 요구 사항에 탁월한 선택이 됩니다.

이 DigitalOcean 기사에서는 uWSGI에 대해 심도 있게 논의하고 서버를 설치하는 것뿐만 아니라 실제로 다양한 프레임워크를 기반으로 Python 애플리케이션을 배포하는 데 필요한 단계를 살펴보고 소규모, 중간 규모 및 상대적으로 큰 규모의 모든 중요한 단계를 다룹니다. 생산.

Nginx와 uWSGI는 기본적으로 서로 함께 작동하도록 구축되어 대부분의 배포를 위한 완벽한 스택을 형성하므로 이 설정과 함께 Nginx를 사용하는 방법(및 그 이유)에 대해서도 논의할 것입니다.

용어 사전

1. uWSGI의 이해와 Nginx 활용

  1. uWSGI 개요
  2. Nginx를 사용한 웹 애플리케이션 배포
  3. uWSGI와 함께 Nginx를 리버스 프록시로 사용

2. 생산을 위한 물방울 준비

  1. 기본 운영 체제 업데이트
  2. Python, pip 및 virtualenv 설정
  3. 가상(Python) 환경 만들기
  4. uWSGI 다운로드 및 설치
  5. Nginx 다운로드 및 설치

3. uWSGI로 Python WSGI 애플리케이션 제공

  1. WSGI
  2. WSGI 애플리케이션 개체(호출 가능): wsgi.py
  3. 서버 실행
  4. uWSGI 구성
  5. uWSGI의 공통 구성
  6. 신호로 uWSGI 서버 및 프로세스 관리

4. Nginx 구성

5. uWSGI 구성

6. 프로덕션 서버에 대한 기타 팁, 제안 및 설정

uWSGI 이해 및 Nginx 사용

uWSGI는 야심 찬 프로젝트입니다. 도구 세트를 사용하면 단순히 웹 응용 프로그램을 호스팅하는 것보다 훨씬 더 많은 작업을 수행할 수 있습니다. 매우 훌륭하고 성능이 뛰어난 방식으로 작업을 수행하기 때문에 수년 동안 응용 프로그램을 배포할 때 많은 시스템 관리자와 개발자 모두에게 없어서는 안 될 도구임이 입증되었습니다.

Nginx는 버전 0.8.40부터 uwsgi 프로토콜(uWSGI 자체)을 지원합니다. 이를 통해 uWSGI에서 실행되는 WSGI 애플리케이션이 Nginx와 가능한 최상의 통신을 할 수 있습니다. 이것이 의미하는 바는 매우 유연하고 기능적이며 함께 제공되는 많은 내부 최적화의 이점을 누리는 매우 구성하기 쉬운 배포의 가능성입니다. 전체적으로 이것은 Nginx와 결합된 uWSGI를 많은 배포 시나리오를 위한 탁월한 선택으로 만듭니다.

간략한 uWSGI

다음은 위에서 언급한 DigitalOcean Python 서버 비교 기사에서 발췌한 것입니다.

"매우 혼란스러운 명명 규칙에도 불구하고 uWSGI 자체는 호스팅 서비스 구축을 위한 전체 소프트웨어 스택을 제공하는 것을 목표로 하는 많은 구성 요소가 포함된 방대한 프로젝트입니다. 이러한 구성 요소 중 하나인 uWSGI 서버는 Python WSGI를 실행합니다. SCGI와 거의 동일한 자체 uwsgi 유선 프로토콜을 포함하여 다양한 프로토콜을 사용할 수 있습니다. 응용 프로그램 앞에 독립형 HTTP 서버를 사용하려는 이해할 수 있는 요구를 충족하기 위해 서버, NGINX 및 Cherokee 웹 서버는 uWSGI의 최고 성능 uwsgi 프로토콜을 지원하도록 모듈화되어 프로세스를 직접 제어할 수 있습니다.”

uWSGI 하이라이트

  • uWSGI는 WSGI 어댑터와 함께 제공되며 WSGI에서 실행되는 Python 애플리케이션을 완벽하게 지원합니다.\n
  • libpython과 연결됩니다. 시작 시 애플리케이션 코드를 로드하고 Python 인터프리터처럼 작동합니다. 들어오는 요청을 구문 분석하고 Python 콜러블을 호출합니다.\n
  • 인기 있는 NGINX 웹 서버(Cherokee+ 및 lighttpd와 함께)를 직접 지원합니다.\n
  • C로 작성되었습니다.
  • 그것의 다양한 구성 요소는 응용 프로그램을 실행하는 것보다 훨씬 더 많은 일을 할 수 있으며 확장에 편리할 수 있습니다.\n
  • 현재(2013년 말 기준) 활발히 개발되고 있으며 출시 주기가 빠릅니다.\n
  • 애플리케이션 실행을 위한 다양한 엔진(비동기 및 동기)이 있습니다.\n
  • 실행할 메모리 사용량이 적다는 의미일 수 있습니다.\n

Nginx를 사용한 웹 애플리케이션 배포

Nginx는 고성능 웹 서버/(역) 프록시입니다. 가벼운 무게와 상대적으로 작업하기 쉽고 확장(애드온/플러그인 사용)이 쉽기 때문에 인기를 얻었습니다. 아키텍처 덕분에 응용 프로그램이나 웹 사이트 로드에 따라 다른 오래된 대안을 사용하여 처리하기 정말 어려울 수 있는 많은 요청(사실상 무제한)을 처리할 수 있습니다.

기억하세요: "연결 처리\는 기술적으로 연결을 끊지 않고 무언가로 연결을 제공할 수 있음을 의미합니다. Nginx가 오류 메시지가 아닌 클라이언트 응답을 제공하도록 하려면 애플리케이션과 데이터베이스가 잘 작동해야 합니다. .

uWSGI와 함께 Nginx를 리버스 프록시로 사용

많은 프레임워크와 애플리케이션 서버는 실제 애플리케이션의 응답과 함께 정적 파일(예: javascript, css, 이미지 등)을 제공할 수 있습니다. 그러나 더 좋은 방법은 Nginx와 같은 (역 프록시) 서버가 이러한 파일을 제공하고 연결(요청)을 관리하는 작업을 처리하도록 하는 것입니다. 이렇게 하면 애플리케이션 서버의 많은 부하가 줄어들어 훨씬 더 나은 전체 성능을 얻을 수 있습니다.

애플리케이션이 성장함에 따라 애플리케이션을 최적화하고 시간이 되면 서버(VPS)에 분산하여 동시에 더 많은 연결을 처리하고 일반적으로 더 강력한 아키텍처를 가질 수 있습니다. 응용 프로그램 서버 앞에 리버스 프록시가 있으면 처음부터 도움이 됩니다.

Nginx의 확장성(예: 장애 조치 및 기타 메커니즘과 함께 기본 캐싱)은 또한 (더 간단한) 애플리케이션 서버와 달리 웹 애플리케이션에 이점을 제공하는 뛰어난 기능입니다.

기본 서버 아키텍처의 예:

Client Request ----> Nginx (Reverse-Proxy)
                        |
                       /|\                           
                      | | `-> App. Server I.   127.0.0.1:8081
                      |  `--> App. Server II.  127.0.0.1:8082
                       `----> App. Server III. 127.0.0.1:8083

참고: 응용 프로그램이 127.0.0.1에서 들어오는 연결을 수신하도록 설정되면 로컬에서만 액세스할 수 있습니다. 그러나 0.0.0.0을 사용하면 외부로부터의 연결도 허용됩니다.

생산을 위한 물방울 준비

이 섹션에서는 프로덕션(즉, 애플리케이션 배포)을 위해 가상 서버를 준비할 것입니다.

우리는 다음과 같이 시작할 것입니다:

  • 기본 운영 체제 업데이트
  • 일반적인 Python 도구(예: pip, virtualenv) 다운로드 및 설치
  • 애플리케이션을 포함할 가상 환경 생성(uWSGI와 같은 종속성이 있는 내부)\n

참고: 여기에 제공된 지침은 간략하게 유지됩니다. 자세한 내용은 pip 및 virtualenv에 대한 방법 문서인 일반 Python 도구: virtualenv 사용, Pip으로 설치 및 패키지 관리를 확인하세요.

기본 운영 체제 업데이트

참고: 최신 버전의 운영 체제를 사용하여 새 VPS에서 다음 설정 및 준비를 수행할 예정입니다. 이론적으로 서버에서 시도하는 데 문제가 없어야 합니다. 그러나 이미 적극적으로 사용하고 계시다면 시도하기 전에 새로운 시스템으로 전환하는 것이 좋습니다.

사용 가능한 최신 버전의 기본 응용 프로그램이 있는지 확인하려면 시스템을 업데이트해야 합니다.

Debian 기반 시스템(예: Ubuntu, Debian)의 경우 다음을 실행합니다.

aptitude    update
aptitude -y upgrade

RHEL 기반 시스템(예: CentOS)의 경우 다음을 실행합니다.

yum -y update

Python, pip 및 virtualenv 설정

CentOS/RHEL 사용자 참고 사항:

기본적으로 CentOS/RHEL은 매우 적은 서버로 제공됩니다. 귀하의 필요에 따라 날짜가 변경될 수 있는 도구 세트는 애플리케이션을 실행하기 위한 것이 아니라 서버의 시스템 도구(예: YUM)에 전원을 공급하기 위한 것입니다.

CentOS 시스템을 준비하려면 Python을 설정(즉, 소스에서 컴파일)하고 pip/virtualenv를 해당 인터프리터를 사용하여 설치해야 합니다.

pip 및 virtualenv를 사용하여 CentOS 6.4 및 5.8에서 Python 2.7.6 및 3.3.3을 설정하는 방법에 대해 알아보려면 CentOS에서 Python 2.7.6 및 3.3.3을 설정하는 방법을 참조하십시오.

Ubuntu 및 Debian에서는 사용할 수 있는 최신 버전의 Python 인터프리터가 기본적으로 제공됩니다. 설치할 추가 패키지의 수가 제한되어 있습니다.

  • python-dev(개발 도구)
  • pip(패키지 관리용)
  • virtualenv(격리된 가상 환경 생성)\n

파이썬 개발:

python-dev는 Python 모듈을 빌드하기 위한 확장된 개발 도구가 포함된 운영 체제 수준 패키지입니다.

aptitude를 사용하여 python-dev를 설치하려면 다음 명령을 실행하십시오.

aptitude install python-dev

씨:

pip는 필요한 애플리케이션 패키지를 설치하는 데 도움이 되는 패키지 관리자입니다.

다음 명령을 실행하여 pip를 설치합니다.

curl https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py | python -
curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python -
export PATH="/usr/local/bin:$PATH"

sudo 권한이 필요할 수 있습니다.

가상 환경:

모든 종속성과 함께 자체 환경 내에 Python 애플리케이션을 포함하는 것이 가장 좋습니다. 환경은 모든 것이 상주하는 격리된 위치(디렉토리)로 가장 잘 설명될 수 있습니다(단순한 용어로). 이를 위해 virtualenv라는 도구가 사용됩니다.

pip를 사용하여 virtualenv를 설치하려면 다음을 실행하십시오.

sudo pip install virtualenv

독립형 가상(Python) 환경 만들기

필요한 모든 도구를 마음대로 사용할 수 있으므로 애플리케이션 배포 환경을 만들 수 있습니다.

기억하세요: 프로젝트를 위한 개발(로컬) 컴퓨터에 virtualenv가 없는 경우 가상 환경을 만들고 애플리케이션(및 해당 종속성)을 내부로 이동하는 것을 고려해야 합니다.

가상 환경과 애플리케이션 모듈을 모두 포함할 폴더를 만드는 것으로 시작하겠습니다.

여기에서 필요에 맞게 이름을 사용할 수 있습니다.

mkdir my_app

계속해서 이 폴더에 들어가 내부에 새 가상 환경을 만들 수 있습니다.

가상 환경에 대해 원하는 이름을 선택할 수도 있습니다.

cd my_app
virtualenv my_app_venv

Python 애플리케이션 모듈도 포함할 새 폴더를 생성해 보겠습니다.

애플리케이션 모듈이 상주할 폴더입니다.

mkdir app

그리고 가상 환경 내에서 인터프리터를 활성화하여 사용하십시오.

"my_app_venv\가 아닌 다른 이름으로 이동한 경우 가상 환경에 선택한 이름을 사용해야 합니다.

source my_app_venv/bin/activate

최종적으로 기본 애플리케이션 배포 디렉터리는 다음과 같아야 합니다.

my_app              # Main Folder to Contain Everything Together
  |
  |=== my_app_venv  # V. Env. folder with the Python Int.
  |=== app          # Your application module
  |..
  |.

uWSGI 다운로드 및 설치

가능한 한 가상 환경 내부에 모든 응용 프로그램 관련 요소를 함께 포함하는 것이 항상 권장되는 방법입니다. 따라서 uWSGI를 다운로드하여 설치합니다.

환경 내에서 작업하지 않는 경우 uWSGI는 전역적으로 설치됩니다(즉, 시스템 전체에서 사용 가능). 권장하지 않습니다. 항상 virtualenv를 사용하도록 선택하십시오.

pip를 사용하여 uWSGI를 설치하려면 다음을 실행하십시오.

pip install uwsgi

기억하세요: pip, 그 사용법 및 기능에 대해 자세히 알아보려면 일반 Python 도구에 대한 다음 문서를 참조하세요: Using virtualenv, Installation with Pip, and Managing Packages.

Nginx 다운로드 및 설치

CentOS/RHEL 사용자 참고 사항:

아래 지침은 CentOS 시스템에서 작동하지 않습니다. CentOS에 대한 지침은 여기를 참조하십시오.

다음 명령을 실행하여 기본 시스템 패키지 관리자 aptitude 설치 Nginx를 사용합니다.

sudo aptitude install nginx

Nginx를 실행하려면 다음을 사용할 수 있습니다.

sudo service nginx start

Nginx를 중지하려면 다음을 사용할 수 있습니다.

sudo service nginx stop

Nginx를 다시 시작하려면 다음을 사용할 수 있습니다.

Nginx를 재구성할 때마다 새 설정을 적용하려면 다시 시작하거나 다시 로드해야 합니다.

sudo service nginx restart

참고: Ubuntu의 Nginx에 대해 자세히 알아보려면 Ubuntu 12.04에 Nginx를 설치하는 방법 문서를 참조하십시오.

uWSGI로 Python WSGI 애플리케이션 제공

이 섹션에서는 Python WSGI 애플리케이션이 uWSGI 웹 서버와 작동하는 방식을 살펴봅니다. Python WSGI 애플리케이션을 제공하기 위해 uWSGI와 함께 작업하는 것은 다른 애플리케이션 컨테이너와 다르지 않습니다. 다른 서버와 마찬가지로 uWSGI에 필요한 것은 애플리케이션이 진입점(호출 가능)을 제공하는 것입니다. 시작하는 동안 이 콜러블은 구성 변수와 함께 uWSGI로 전달되고 작업을 시작합니다. 요청이 도착하면 요청을 처리하고 애플리케이션의 컨트롤러로 전달하여 처리합니다.

건축학:

........
      /|\                           
     | | `-> App. Server I.   127.0.0.1:8080  <--> Application
     |  `--> App. Server II.  127.0.0.1:8081  <--> Application
      .....

WSGI

간단히 말해서 WSGI는 웹 서버와 애플리케이션 자체 간의 인터페이스입니다. 다양한 서버와 애플리케이션(프레임워크) 간의 표준화된 방식을 보장하기 위해 존재하며, 오늘날 필수 요구 사항인 필요한 경우(예: 개발 환경에서 프로덕션 환경으로 전환) 상호 교환성을 허용합니다.

참고: WSGI 및 Python 웹 서버에 대해 자세히 알아보려면 Python 기반 웹 애플리케이션에 대한 웹 서버 비교 기사를 확인하십시오.

WSGI 애플리케이션 객체(호출 가능): \wsgi.py\

위에서 언급했듯이 WSGI에서 실행되는 웹 서버에는 응용 프로그램 개체(즉, 응용 프로그램의 개체)가 필요합니다.

대부분의 프레임워크 및 애플리케이션에서 이는 서버에서 사용할 애플리케이션 객체(또는 호출 가능)를 포함하고 제공하는 wsgi.py로 구성됩니다.

예시적인 wsgi.py 생성부터 시작하여 응용 프로그램을 실행하기 위해 uWSGI에서 가져오고 사용할 것입니다.

wsgi.py 대신 아무 이름이나 선택할 수 있습니다. 그러나 이들은 일반적으로 사용되는 것입니다(예: Django).

기본 WSGI 애플리케이션을 포함할 wsgi.py 파일을 생성하는 것으로 시작하겠습니다.

다음 명령을 실행하여 텍스트 편집기 nano를 사용하여 wsgi.py를 생성합니다.

nano wsgi.py

그리고 계속해서 기본 WSGI 애플리케이션 코드를 내부로 이동(복사/붙여넣기)해 보겠습니다(프로덕션을 위해 호출할 수 있는 자체 애플리케이션으로 교체해야 함).

def application(env, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    return ["Hello!"]

이것은 서버에 의해 포함된 파일이며 요청이 올 때마다 서버는 URL(예: mysite.tld/controller/method/variable)을 구문 분석할 때 애플리케이션의 요청 핸들러(즉, 컨트롤러)를 실행하기 위해 호출 가능한 이 애플리케이션을 사용합니다.

애플리케이션 코드를 배치한 후 CTRL+X를 누른 다음 Y로 확인하여 실제 애플리케이션을 포함하는 가상 환경 및 앱 모듈과 함께 "my_app” 폴더 안에 이 파일을 저장합니다.

참고: 이 WSGI 애플리케이션은 해당 종류의 가장 기본적인 예입니다. 응용 프로그램 모듈에서 자신의 응용 프로그램 개체를 포함하려면 이 코드 블록을 교체해야 합니다.

작업이 완료되면 기본 애플리케이션 배포 디렉터리는 다음과 같이 표시됩니다.

my_app              # Main Folder to Contain Everything Together
  |
  |=== my_app_venv  # V. Env. folder with the Python Int.
  |=== app          # Your application module
  |
  |--- wsgi.py      # File containing application callable
  |..
  |.

서버 실행

uWSGI는 유연성 덕분에 다양한 사용 방법으로 많은 옵션과 구성을 제공합니다. 처음부터 복잡하게 만들지 않고 가능한 한 간단하게 작업을 시작하고 더 발전된 방법으로 계속 진행할 것입니다.

간단한 사용 예:

uwsgi [option] [option 2] .. -w [wsgi file with app. callable]

uWSGI를 실행하여 wsgi.py에서 애플리케이션 제공을 시작하려면 다음을 실행하십시오.

uwsgi --socket 127.0.0.1:8080 --protocol=http -w wsgi

포그라운드에서 서버를 실행합니다. 중지하려면 CTRL+C를 누르십시오.

백그라운드에서 서버를 실행하려면 다음을 실행하십시오.

uwsgi --socket 127.0.0.1:8080 --protocol=http -w wsgi &

[!] 중요: Nginx 구성 섹션의 구성을 사용하여 Nginx와 함께 작동하도록 서버를 실행할 때 다음 체인에서 --protocol=http를 제거해야 합니다. 그렇지 않으면 Nginx와 uWSGI가 서로 통신할 수 없습니다.

백그라운드에서 애플리케이션을 실행할 때 이를 종료(또는 중지)하려면 프로세스 관리자(예: htop)를 사용해야 합니다. 자세한 내용은 아래 섹션을 참조하십시오.

신호로 uWSGI 서버 및 프로세스 관리

uWSGI 관리는 런타임 동안 수행되는 작업으로 구성됩니다. 프로세스를 조작하기 위해 이 작업에 설정된 다양한 명령이 있습니다.

  • SIGHUP -HUP는 작업자와 애플리케이션을 정상적으로 다시 로드합니다.\n
  • SIGTERM -TERM "잔인하게\ 새로고침\n
  • SIGINT -INT 및 SIGQUIT -QUIT는 모든 작업자를 즉시 종료합니다.\n
  • SIGUSR1 -USR1 통계 출력(stdout)
  • SIGUSR2 -USR2 작업자 상태 출력
  • SIGURG -URG는 스냅샷을 복원합니다.\n
  • SIGTSTP -TSTP는 인스턴스를 일시 중지, 일시 중단 또는 재개합니다.\n
  • SIGWINCH -WINCH는 syscall에서 차단된 작업자를 깨웁니다.

신호를 사용한 관리 예:

SIGHUP으로 서버 재시작

이 명령은 서버를 정상적으로 다시 시작합니다. 이것이 의미하는 바는 현재 작업자의 작업이 완료될 때까지 기다린 다음 해당 설정을 상속하여 작업자를 다시 생성하기 전에 종료한다는 것입니다.

사용법: kill -HUP [PID]

PID를 지정하지 않으려면 pidfile 옵션을 사용하여 uWSGI가 PID를 파일에 쓰도록 할 수 있습니다. 그런 다음 이를 사용하여 프로세스를 관리할 수 있습니다.

SIGINT로 서버 중지

서버와 해당 프로세스를 중지하려면 -INT 신호를 사용해야 합니다. 그러면 백그라운드의 모든 것이 종료됩니다.

예: kill -INT [PID]

Nginx 구성

응용 프로그램을 실행하기 위해 uWSGI를 설정한 후 uWSGI 서버와 통신하려면 Nginx와 동일한 작업을 수행해야 합니다. 이를 위해 Nginx의 구성 파일을 수정해야 합니다: nginx.conf

다음 명령을 실행하여 nginx.conf를 열고 nano 텍스트 편집기를 사용하여 편집합니다.

sudo nano /etc/nginx/nginx.conf

그런 다음 파일을 다음 예제 구성으로 대체하여 Nginx가 애플리케이션과 통신하는 리버스 프록시로 작동하도록 할 수 있습니다.

참고: SSL 지원 통합에 대해 알아보려면 먼저 Nginx에서 SSL 인증서 생성 문서를 읽어보세요.

웹 애플리케이션의 구성 예:

worker_processes 1;

events {

    worker_connections 1024;

}

http {

    sendfile on;
    
    gzip              on;
    gzip_http_version 1.0;
    gzip_proxied      any;
    gzip_min_length   500;
    gzip_disable      "MSIE [1-6]\.";
    gzip_types        text/plain text/xml text/css
                      text/comma-separated-values
                      text/javascript
                      application/x-javascript
                      application/atom+xml;

    # Configuration containing list of application servers
    upstream uwsgicluster {
    
        server 127.0.0.1:8080;
        # server 127.0.0.1:8081;
        # ..
        # .
    
    }

    # Configuration for Nginx
    server {
    
        # Running port
        listen 80;

        # Settings to by-pass for static files 
        location ^~ /static/  {
        
            # Example:
            # root /full/path/to/application/static/file/dir;
            root /app/static/;
        
        }
        
        # Serve a static file (ex. favico) outside static dir.
        location = /favico.ico  {
        
            root /app/favico.ico;
        
        }

        # Proxying connections to application servers
        location / {
        
            include            uwsgi_params;
            uwsgi_pass         uwsgicluster;

            proxy_redirect     off;
            proxy_set_header   Host $host;
            proxy_set_header   X-Real-IP $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Host $server_name;
        
        }
    }
}

구성 수정을 마쳤으면 CTRL+X를 누르고 Y를 눌러 저장하고 종료합니다. 변경 사항을 적용하려면 Nginx를 다시 시작해야 합니다.

다음을 실행하여 Nginx를 다시 시작합니다.

sudo service nginx stop
sudo service nginx start

참고: Nginx에 대한 자세한 내용은 VPS에서 Nginx 웹 서버를 구성하는 방법 문서를 참조하십시오.

uWSGI 구성

응용 프로그램을 제공하기 위해 uWSGI를 시작할 때 실행할 소켓, 프로세스 수, 마스터 프로세스 설정 등과 같은 필수 구성을 제공하는 방법에는 여러 가지가 있습니다. 이 섹션에서는 그 중 세 가지에 대해 설명합니다.

  • 구성을 인수로 전달
  • 구성에 .ini 파일 사용
  • 구성에 .json 파일 사용

참고: uWSGI는 stdin 및 HTTP와 같은 이러한 구성 파일을 검색하는 다양한 프로토콜과 방법을 지원합니다.

옵션 #1: 구성을 인수로 전달:

때때로 쉽게 혼동되고 관리하기 어렵지만 uWSGI를 실행하는 가장 기본적인 방법은 다른 쉘 스크립트와 마찬가지로 필요한 구성을 인수로 제공하는 것입니다.

사용 예:

# uwsgi [option] [option 2] .. -w [wsgi.py with application callable]

# Simple server running *wsgi*
uwsgi --socket 127.0.0.1:8080 -w wsgi

# Running Pyramid (Paster) applications
uwsgi --ini-paste production.ini

# Running web2py applications
uwsgi --pythonpath /path/to/app --module wsgihandler

# Running WSGI application with specific module / callable names
uwsgi --module wsgi_module_name --callable application_callable_name
uwsgi -w wsgi_module_name:application_callable_name

uWSGI를 실행하는 방법에 대한 더 많은 예제를 보려면 예제 구성에 대한 설명서를 방문하십시오.

옵션 #2: 구성에 .ini 파일 사용

uWSGI에 구성을 제공하는 또 다른(아마도) 더 좋은 방법은 .ini 파일을 이용하는 것입니다. 이러한 파일은 간단한 구조(아래 예 참조)를 가지며 uWSGI 시작 스크립트가 실행될 때마다 명시적으로 전달되어야 합니다.

.ini 구조 예(example_config.ini):

[uwsgi]
# -------------
# Settings:
# key = value
# Comments >> #
# -------------

# socket = [addr:port]
socket = 127.0.0.1:8080

# Base application directory
# chdir = /full/path
chdir  = /my_app

# WSGI module and callable
# module = [wsgi_module_name]:[application_callable_name]
module = app:application

# master = [master process (true of false)]
master = true

# processes = [number of processes]
processes = 5

..

사용 예:

uwsgi --ini example_config.ini

옵션 #3: 구성에 .json 파일 사용

.json 파일로 작업하는 것은 구조를 제외하면 위에 표시된 예제와 동일합니다.

.json 구조 예(example_config.json):

{
    "uwsgi": {
        "socket": ["127.0.0.1:8080"],
        "module": "my_app:app",
        "master": true,
        "processes": 5,
    }
}

사용 예:

uwsgi --json example_config.json

uWSGI 구성에 대해 자세히 알아보려면 해당 구성 문서를 읽어보십시오.

uWSGI의 일반적인 구성

기본적으로 이 서버는 기본적으로 프레임워크/애플리케이션/플랫폼에 구애받지 않도록 설계되었습니다. 필요한 모든 것을 지원할 수 있지만 요구 사항을 준수하려면 특정 옵션을 명시적으로 설정해야 합니다.

자체 문서에 명시된 바와 같이 uWSGI를 구성하는 가능한 방법의 수는 거의 무한합니다. 이 섹션에서는 가장 일반적으로 사용되거나 중요한 것을 살펴보고 이전 섹션과 결합할 때 uWSGI가 필요한 방식으로 정확하게 실행되도록 하는 구현을 설명하려고 합니다.

최적화에 대해서는 다음 섹션을 참조하십시오.

아래 예제에 사용된 구문은 .ini 파일을 대상으로 합니다. 원하는 대로 특정 요구 사항에 맞게 수정할 수 있습니다(예: 이전 섹션에서 설명한 대로 .json 기반 구성의 경우).

소켓

http 소켓

uWSGI가 특정 HTTP 소켓에 바인딩되도록 설정합니다.

예: http 소켓=:8080

소켓

기본 프로토콜을 사용하여 지정된 소켓에 바인딩되도록 uWSGI를 설정합니다.

예: 소켓=127.0.0.1:8080

프로세스(작업자)

두 용어 모두 요청을 수락하기 위해 생성된 프로세스의 양과 같은 의미로 사용될 수 있습니다.

예: 프로세스 = 5

규약

기본적으로 uWSGI는 자체 uwsgi 프로토콜에서 실행됩니다. 이 속성을 사용하면 변경할 수 있습니다.

예: 프로토콜 = http

관리

주인

이 옵션은 마스터 uWSGI 프로세스를 활성화 또는 비활성화하는 데 사용됩니다. 이러한 프로세스는 들어오는 요청을 수락하고 처리하는 작업자를 관리하는 데 사용됩니다. 중단 시간 없이 업그레이드할 수 있는 소켓을 건드리지 않고 작업자를 정상적으로 다시 시작하는 등 많은 이점이 있습니다.

예: 마스터=참

최대 요청

메모리 누수가 걱정되고 이를 처리하는 더 확실한 방법이 생각나지 않는 경우 이 옵션을 사용하면 지정된 양의 요청을 처리한 후 자동으로 프로세스를 다시 시작할 수 있습니다.

예: 최대 요청 수=1001

스레드

rethread 모드에서 지정된 양의 스레드로 각 프로세스를 실행하기 위한 설정. 다양한 정도의 동시성을 얻기 위해 이 옵션을 프로세스와 결합하는 것이 가능합니다.

예: 스레드=2

벌채 반출

로깅 비활성화

로깅 기능을 비활성화하는 데 사용됩니다.

예: disable-logging=true

uWSGI 프로세스

이름

프로세스 이름을 원하는 이름으로 설정할 수 있습니다.

예: procname = 내 애플리케이션

액체

uWSGI 서버 사용자 uid를 지정된 것으로 설정합니다.

예: uid=1001

기드

uWSGI 서버 gid를 지정된 것으로 설정합니다.

예: gid=555

진공

종료 시 생성된 모든 pidfile/소켓을 제거합니다.

악마화하다

이 설정은 uWSGI를 데몬화하고 제공된 인수(로그 파일)에 메시지를 기록합니다.

예: daemonize=/tmp/uwsgi_daemonize.log

pidfile

옵션으로 지정된 파일에 프로세스 PID를 쓰도록 uWSGI를 설정합니다. 이 옵션은 실행 중인 uWSGI 프로세스 관리에 매우 편리합니다(자세한 내용은 uWSGI 관리 섹션 참조).

예: pidfile=/tmp/proj_pid.pid

다양한

하라키리

이 설정은 프로세스가 메모리/관리 목적으로 종료 및 재활용되기 전에 작업을 완료할 수 있는 최대 시간을 설정하는 데 사용됩니다.

예: harakiri=30

사용 가능한 수백 가지 구성에 대해 모두 알아보려면 공식 구성 옵션 설명서에 있는 전체 목록을 확인해야 합니다.

기타 팁 및 제안

방화벽:

  • IP 테이블을 사용하여 방화벽 설정

SSH 보안:

  • Ubuntu에서 fail2ban으로 SSH를 보호하는 방법
  • CentOS 6에서 fail2ban으로 SSH를 보호하는 방법

경고 생성:

  • 시스템 모니터링을 위해 CentOS VPS에서 이메일 알림을 보내는 방법

매일 서버 액세스 로그 모니터링 및 감시:

  • Logwatch 로그 분석기 및 리포터 설치 및 사용 방법

제출자: