Gunicorn: Alguma maneira de servir a muitos aplicativos WSGI por meio da mesma instância do gunicorn.

Acho que esse tipo de comportamento é mais bem resolvido pelo usuário final. Há uma diferença distinta na maneira como o gunicorn funciona com "vários sites" em comparação com um servidor web convencional.
Eu sugeriria usar alguma biblioteca python simples, como werkzeug, e fazer seus dois aplicativos responderem em rotas diferentes.

Tenho que concordar com jbergstroem que isso não pertence ao núcleo. Mas eu fui em frente e adicionei um exemplo que descreve como você pode fazer isso com o Routes:

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

em vez de ter um ponto de montagem específico por aplicativos, seria possível ter um exemplo com host virtual por nome?

Sim, é totalmente possível. Você pode escrever um mapeamento trivial do ambiente ['HTTP_HOST'] para os aplicativos.

Eu acho que isso poderia ser construído em gunicorn, o que você acha?

Isso poderia ser alguma parte opcional do gunicorn, como material contrib, sim.

Acho que seria melhor como um aplicativo multiplexador autônomo com configuração separada. A especialização Django / Paste também deve ir para lá. Como isso:

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

Aqui, o gunicorn executa apenas um aplicativo wsgi_multi, outros argumentos são passados ​​para ele por meio de alguma API especial. Ou via configuração ou de alguma outra forma.

Passei muito tempo tentando escrever algo como o que é sugerido neste tíquete. Primeiro, tentei ter um código que mudou o virtualenv com base em HTTP_HOST. Acontece que você realmente não pode desativar o virtualenvs em Python puro, então isso foi uma lavagem.

Então eu pensei: talvez possamos apenas ter um requisito de que seja um único virtualenv, então eu escrevi o código para mudar para diferentes aplicativos WSGI baseados em HTTP_HOST apenas para descobrir que você não pode executar dois aplicativos django lado a lado porque o django mantém um número verdadeiramente surpreendente de variáveis ​​globais em todos os lugares.

Então, basicamente, o que estou dizendo é que nem tudo é tão fácil ou viável como sugerido acima.

Talvez seja mais viável fazer algum tipo de balanceamento de carga em que os workers sejam executados em ambientes virtuais diferentes dependendo do aplicativo e um gunicorn master central certifique-se de que os aplicativos que precisam de mais workers os recebam? Provavelmente não é fácil ou divertido de escrever :(

Eu realmente gostaria que o django fosse limpo para tornar esse tipo de coisa possível ...