Gunicorn: 동일한 gunicorn 인스턴스를 통해 많은 WSGI 앱을 제공하는 방법입니다.

이런 종류의 행동은 최종 사용자가 가장 잘 해결한다고 생각합니다. gunicorn이 기존 웹 서버와 비교하여 "여러 사이트"에서 작동하는 방식에는 뚜렷한 차이가 있습니다.
werkzeug와 같은 간단한 파이썬 라이브러리를 사용하고 두 앱이 다른 경로에서 응답하도록 하는 것이 좋습니다.

나는 이것이 핵심에 속하지 않는다는 점에 동의해야 합니다. 하지만 Routes를 사용하여 이를 수행하는 방법을 설명하는 예제를 추가했습니다.

http://github.com/benoitc/gunicorn/blob/master/examples/multiapp.py

앱마다 특정 마운트 지점을 지정하는 대신 이름으로 가상 호스트가 있는 예를 가질 수 있습니까?

예, 완전히 가능합니다. 앱에 대한 환경['HTTP_HOST']의 간단한 매핑을 작성할 수 있습니다.

나는 이것이 gunicorn에 내장 될 수 있다고 생각합니다. 어떻게 생각하십니까?

이것은 contrib 항목과 같은 gunicorn의 선택적 부분일 수 있습니다.

별도의 구성이 있는 독립형 멀티플렉서 응용 프로그램으로 가장 좋을 것이라고 생각합니다. Django/Paste 전문화도 거기에 가야 합니다. 이와 같이:

$ gunicorn wsgi_multi django:project1 myblog.wsgi:wsgi_app anotherapp.foo

여기에서 gunicorn은 하나의 응용 프로그램 wsgi_multi만 실행하고 다른 인수는 일부 특수 API를 통해 전달됩니다. 또는 구성을 통해 또는 다른 방법으로.

나는 이 티켓에서 제안된 것과 같은 것을 쓰려고 많은 시간을 보냈습니다. 먼저 HTTP_HOST를 기반으로 virtualenv를 전환하는 코드를 사용해 보았습니다. 순수한 파이썬에서 virtualenvs를 비활성화할 수 없다는 것이 밝혀졌습니다. 그래서 그것은 세척이었습니다.

그런 다음 생각했습니다. 단일 virtualenv라는 요구 사항이 있을 수 있으므로 HTTP_HOST를 기반으로 다른 WSGI 앱으로 전환하는 코드를 작성했습니다. django는 정말 놀라운 수의 전역 변수가 도처에 있습니다.

그래서 기본적으로, 내가 말하는 것은 위에서 제안한 것만큼 쉽거나 실현 가능하지 않다는 것입니다.

작업자가 앱에 따라 다른 virtualenv에서 실행되고 중앙 gunicorn 마스터가 더 많은 작업자가 필요한 앱이 이를 얻도록 하는 일종의 로드 밸런싱 작업을 수행하는 것이 더 실현 가능합니까? 아마도 쓰기가 쉽지 않거나 재미가 없을 것입니다 :(

이런 일을 가능하게 하기 위해 django를 정리하고 싶습니다...