Gunicorn: Alguna forma de servir muchas aplicaciones WSGI a través de la misma instancia de gunicorn.

Creo que este tipo de comportamiento lo resuelve mejor el usuario final. Existe una clara diferencia en la forma en que gunicorn funciona con "varios sitios" en comparación con un servidor web convencional.
Sugeriría usar alguna biblioteca de Python simple como werkzeug y hacer que sus dos aplicaciones respondan en diferentes rutas.

Tengo que estar de acuerdo con jbergstroem en que esto no pertenece al núcleo. Pero seguí adelante y agregué un ejemplo que describe cómo puede lograr esto con Rutas:

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

en lugar de tener un punto de montaje específico por aplicación, ¿sería posible tener un ejemplo con un host virtual por nombre?

Sí, es totalmente posible. Puede escribir un mapeo trivial del entorno ['HTTP_HOST'] a las aplicaciones.

Creo que esto podría construirse en gunicorn, ¿qué piensas?

Esto podría ser una parte opcional de gunicorn, como contrib, sí.

Creo que sería mejor como una aplicación multiplexor independiente con una configuración separada. La especialización de Django / Paste también debe ir allí. Como esto:

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

Aquí, gunicorn ejecuta solo una aplicación wsgi_multi, otros argumentos se le pasan a través de alguna API especial. O a través de la configuración o de alguna otra manera.

Pasé mucho tiempo tratando de escribir algo como lo que se sugiere en este boleto. Primero intenté tener un código que cambiara virtualenv basado en HTTP_HOST. Resulta que realmente no puedes desactivar virtualenvs en python puro, así que fue un lavado.

Luego pensé: tal vez podamos tener un requisito de que sea un solo virtualenv, así que escribí el código para cambiar a diferentes aplicaciones WSGI basadas en HTTP_HOST solo para descubrir que no se pueden ejecutar dos aplicaciones de django una al lado de la otra porque django mantiene un realmente asombroso número de variables globales en todas partes.

Básicamente, lo que estoy diciendo es que no todo es tan fácil o incluso factible como se sugirió anteriormente.

¿Quizás es más factible hacer algún tipo de equilibrio de carga en el que los trabajadores se ejecuten en diferentes virtualenvs dependiendo de la aplicación y un maestro de gunicorn central se asegure de que las aplicaciones que necesitan más trabajadores los obtengan? Probablemente no sea fácil o divertido de escribir :(

Realmente me gustaría que django se limpiara para hacer posible este tipo de cosas ...