Gunicorn: Un moyen de servir de nombreuses applications WSGI via la même instance de gunicorn.

Je pense que ce genre de comportement est mieux résolu par l'utilisateur final. Il existe une différence nette dans la façon dont gunicorn fonctionne avec des "sites multiples" par rapport à un serveur Web conventionnel.
Je suggérerais d'utiliser une bibliothèque python simple telle que werkzeug et de faire en sorte que vos deux applications répondent sur des itinéraires différents.

Je dois convenir avec jbergstroem que cela n'appartient pas au noyau. Mais je suis allé de l'avant et j'ai ajouté un exemple décrivant comment vous pouvez accomplir cela avec Routes :

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

au lieu d'avoir un point de montage spécifique par applications, serait-il possible d'avoir un exemple avec un hôte virtuel par nom ?

Oui, c'est tout à fait possible. Vous pouvez écrire un mappage trivial d'environ['HTTP_HOST'] aux applications.

Je pense que cela pourrait être construit en gunicorn, qu'en pensez-vous?

Cela pourrait être une partie facultative de gunicorn, comme des trucs de contrib, oui.

Je pense que ce serait mieux en tant qu'application multiplexeur autonome avec une configuration séparée. La spécialisation Django/Paste doit également y aller. Comme ça:

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

Ici, gunicorn n'exécute qu'une seule application wsgi_multi, d'autres arguments lui sont transmis via une API spéciale. Ou via config ou autrement.

J'ai passé beaucoup de temps à essayer d'écrire quelque chose comme ce qui est suggéré dans ce billet. J'ai d'abord essayé d'avoir un code qui changeait virtualenv basé sur HTTP_HOST. Il s'avère que vous ne pouvez vraiment pas désactiver virtualenvs en python pur, donc c'était un lavage.

Ensuite, j'ai pensé : peut-être que nous pouvons simplement exiger qu'il s'agisse d'un seul virtualenv, alors j'ai écrit le code pour basculer vers différentes applications WSGI basées sur HTTP_HOST uniquement pour découvrir que vous ne pouvez pas exécuter deux applications Django côte à côte car Django conserve un nombre vraiment étonnant de variables globales partout.

Donc, fondamentalement, ce que je dis, c'est que tout n'est pas aussi facile ou même faisable que suggéré ci-dessus.

Peut-être est-il plus faisable de faire une sorte d'équilibrage de charge où les travailleurs s'exécutent dans différents environnements virtuels en fonction de l'application et un maître gunicorn central s'assure que les applications qui ont besoin de plus de travailleurs les obtiennent ? Probablement pas facile ou amusant à écrire :(

J'aimerais vraiment que Django soit nettoyé pour rendre ce genre de chose possible...