트래픽이 적은 CherryPy 앱을 하위 디렉토리로 배포하기 위해 단일 VPS를 사용하려고합니다. 예 : example.com/app1, example.com/app2등

WSGI 배포를 조사한 후 앱을 배포하는 데 선호되는 방법은 리버스 프록시 설정에서 WSGI 서버 (Gunicorn, uWSGI 등)와 NGinx를 사용하는 것 같습니다. 특히 CherryPy 앱 자체가 웹 서버이기 때문에 두 개의 웹 서버를 동시에 사용하는 것은 과도한 것처럼 보이지만 아이디어가 어디에서나 나타나는 것처럼 무시하고 싶지 않습니다 . 나는 확실히 전문가가 아니므로 토론하고 싶습니다.

세 가지 옵션이 있습니다.

• CherryPy 자체를 배포하십시오.
• Gunicorn 또는 다른 WSGI 서버 아래에 배포하십시오.
• WSGI 서버 아래에 배치하고 리버스 프록시를 NGinx에 배포하십시오. 이는 모두의 솔루션 인 것 같습니다.

내 질문 :

• 이 패턴이 어디서나 나타나는 주된 이유는 무엇입니까? NGinx는 그렇게 좋은가요?
• 트래픽이 적은 앱의 경우 기본 CherryPy 서버가 충분합니까, 아니면 시도하지 않아야합니까?

모든 조언을 부탁드립니다. 감사합니다.

모든 사용자가 앱 서버 앞에 nginx (또는 Apache와 같은 다른 서버)를 배치하는 이유는 모든 사용자가 이미지, CSS 및 JavaScript와 같은 정적 컨텐츠와 애플리케이션에 고유 한 이상한 요구 사항을 가지고 있기 때문입니다.

앱 서버 (CherryPy, gunicorn 등)는 앱을 실행하고 출력을 제공하도록 최적화되어 있습니다. 앱 서버 는 정적 콘텐츠도 제공 할 수 있지만 앱 서버 의 주요 목적에 부수적이기 때문에이 작업에 최적화 된 적이 거의 없습니다. (일부 앱 서버는 CSS와 JS를 축소하고 압축하여 앞에있는 웹 서버가 이러한 리소스를 훨씬 빠르게 제공 할 수 있도록 도와줍니다.)

또한 실제 웹 서버는 고성능 콘텐츠 서비스 이상의 기능을 수행 할 수 있습니다. 캐싱, 헤더 조작, URL 재 작성, 지리적 위치 및 응용 프로그램 서버를 부단히 사용하는 다른 많은 기능과 같은 것들.

일반적으로 응용 프로그램을 개발할 때, 유일한 사용자 일 때만 성능이 문제가되지 않는 경우에만 앱 서버를 단독으로 실행합니다. 사이트의 트래픽이 적더라도 더 빠르기를 원하십니까? 트래픽이 적은 사이트는 일반적으로 트래픽이 많은 사이트로 성장하지 않습니다 ...

사람들이 왜 Nginx를 앞에 두었습니까?

1. Nginx는 비동기 웹 서버입니다. 연결 당 스레드 또는 프로세스를 전용으로 사용하지 않음을 의미합니다. 대신 OS의 기본 소켓 폴링 라이브러리를 사용하므로 수십만 개의 연결을 처리 할 수 ​​있습니다. 애플리케이션 개발자로서 왜 관심을 가져야합니까? Nginx는 연결을 버퍼링하고 요청을 완전히 읽을 때 요청을 CherryPy 업스트림 인스턴스로 전달하기 때문입니다. 응답도 동일합니다. 이런 식으로 Nginx 뒤에있는 스레드 서버 인 CherryPy 응용 프로그램은 비동기 적으로됩니다. 특히, 느린 클라이언트 문제 및 느린 loris DOS 공격에 손을 흔 듭니다.
2. Nginx의 연결 속도는 기본적으로 제한되어 있습니다. 같은 IP에서 8 개 이상의 동시 연결을 원하지 않습니다.
3. CherryPy에 SSL 문제가 있습니다. Nginx는 그렇지 않습니다.
4. 파이썬은 거의 C만큼 바이트를주고받을 수 있습니다. 파이썬 zlib은 C 라이브러리를 둘러싼 래퍼입니다. 그러나 Nginx는 연결을 효과적으로 처리하기 때문에 CherryPy 작업자 스레드가 프로덕션에서 정적 컨텐츠를 제공하지 못하게하고 동적 컨텐츠에만 전념하는 것이 좋습니다.
5. 동일한 포트, 도메인, 경로 등에서 여러 CherryPy 인스턴스를 다중화. 일반적으로 다른 구성 수준의 추가 유연성.

CherryPy를 단독으로 사용하는 것이 안전합니까?

원저자 중 한 명에 따르면 그렇습니다 . CherryPy로 할 수있는 대부분의 웹 관련 작업

CherryPy에는 애플리케이션 개념이 있으며 하나의 CherryPy 인스턴스로 여러 애플리케이션 을 제공 할 수 있습니다 . CherryPy는 다른 WSGI 응용 프로그램을 제공 할 수도 있습니다 .

CherryPy 배포

전통적인 * nix 스타일 배포에서는 init 스크립트를 작성하고, 프로세스를 디먼 화하고, 권한을 삭제하고, PID를 작성하는 등의 작업을 수행합니다. 몇 개의 CherryPy 인스턴스가있을 때는 별 문제가되지 않습니다. 수십 개가 있으면 지루해지고 프로세스 관리를 Gunicorn 또는 uWGSI로 넘겨 CherryPy 인스턴스를 HTTP에서 WSGI로 전환하는 것이 합리적입니다.

나는 웹 개발자를 위해 데비안에서 실제 CherryPy 응용 프로그램을 배포 (전통적인)하는 격차를 메우기위한 튜토리얼 / 프로젝트 골격 인 cherrypy-webapp-skeleton 을 작성했습니다.

마무리

1. 트래픽이 적고 특별한 요구 사항이 없습니다 CherryPy * 1 ⇐ HTTP ⇒ Client. → .
2. 트래픽이 많은 특수 요구 사항 → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. 동일한 서버에있는 수십 개의 개별 CherryPy 인스턴스가 모든 사람의 솔루션 을 과도하게 사용하고 싶어 합니다 → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.