Gunicorn: Eine Möglichkeit, viele WSGI-Apps über dieselbe gunicorn-Instanz bereitzustellen.

Ich denke, diese Art von Verhalten wird am besten vom Endbenutzer gelöst. Es gibt einen deutlichen Unterschied in der Arbeitsweise von gunicorn mit "mehreren Sites" im Vergleich zu einem herkömmlichen Webserver.
Ich würde vorschlagen, eine einfache Python-Bibliothek wie werkzeug zu verwenden und Ihre beiden Apps auf verschiedenen Routen reagieren zu lassen.

Ich muss jbergstroem zustimmen, dass dies nicht in den Kern gehört. Aber ich habe ein Beispiel hinzugefügt, in dem beschrieben wird, wie Sie dies mit Routen erreichen können:

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

Wäre es möglich, anstelle eines bestimmten Mount-Punkts pro Apps ein Beispiel mit einem virtuellen Host mit Namen zu haben?

Ja, es ist durchaus möglich. Sie können eine triviale Zuordnung von environ['HTTP_HOST'] zu Apps schreiben.

Ich denke, das könnte in Gunicorn gebaut werden, was meinst du?

Dies könnte ein optionaler Teil von Gunicorn sein, wie z. B. contrib-Zeug, ja.

Ich denke, es wäre am besten als eigenständige Multiplexor-Anwendung mit separater Konfiguration. Django/Paste Spezialisierung muss auch dorthin gehen. So was:

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

Hier führt gunicorn nur eine Anwendung wsgi_multi aus, andere Argumente werden ihr über eine spezielle API übergeben. Oder per config oder irgendwie anders.

Ich habe viel Zeit damit verbracht, etwas zu schreiben, wie es in diesem Ticket vorgeschlagen wird. Zuerst habe ich versucht, Code zu haben, der virtualenv basierend auf HTTP_HOST wechselte. Es stellte sich heraus, dass Sie Virtualenvs in reinem Python wirklich nicht deaktivieren können, also war das ein Waschgang.

Dann dachte ich: Vielleicht können wir einfach eine einzige virtuelle Umgebung verlangen, also habe ich den Code geschrieben, um auf Basis von HTTP_HOST zu verschiedenen WSGI-Apps zu wechseln, nur um festzustellen, dass Sie nicht zwei Django-Apps nebeneinander ausführen können, weil Django ein wirklich erstaunliche Anzahl von globalen Variablen überall.

Im Grunde sage ich also, dass nicht alles so einfach oder sogar machbar ist, wie oben vorgeschlagen.

Vielleicht ist es machbarer, eine Art Lastausgleich durchzuführen, bei dem Arbeiter je nach App in verschiedenen virtuellen Umgebungen laufen und ein zentraler Gunicorn-Master dafür sorgt, dass die Apps, die mehr Arbeiter benötigen, sie bekommen? Wahrscheinlich nicht einfach oder lustig zu schreiben :(

Ich möchte wirklich, dass Django aufgeräumt wird, um so etwas zu ermöglichen...