Plusieurs applications mod_wsgi sur un hôte virtuel dirigeant vers une mauvaise application

Question

Je vais essayer d'obtenir deux (ou plus) de Django applications à des sous-répertoires dans le même domaine, par exemple:

http://example.com/site1/
http://example.com/site2/

Je sais que normalement, cela fonctionne très bien par la création d'un virtualhost apache comme ceci:

<VirtualHost *:80>
    ...
    WSGIScriptAlias /site1 /path/to/site1.wsgi
    WSGIScriptAlias /site2 /path/to/site2.wsgi
</VirtualHost>

Maintenant, j'ai vérifié que chaque site individuellement. Mais lorsque j'essaie d'exécuter les deux side-by-side, apache envoie-moi quel que soit le site, du processus de travail est chargé en premier. Exemple:

1. Redémarrez apache configuré pour 6 fils
2. Charge example.com/site1/, obtenir la bonne page
3. Charge example.com/site2/, obtenir la bonne page
4. Répéter les étapes 2 et 3 2 fois plus.
5. Actualiser example.com/site1/ à plusieurs reprises, regarder cycle de site à site.

Effectivement, pour un nombre donné de processus de travail, il parcourt le nombre total de leur envoyer la demande à celui qu'il a frappé en premier, indépendamment de la WSGIScriptAlias directive. Peu importe ce que je fais (réglage WSGIProcessGroup, mode démon vs mode incorporé, ou directives), il continue à exposer ce problème.

Si quelqu'un peut comprendre ce que je fais mal ici, ce serait phénoménal!

Answer 1

J'ai eu plusieurs WSGI applications en cours d'exécution sur une seule installation d'Apache, et a constaté que la meilleure chose à faire est de simplement avoir plusieurs groupes de processus: une pour chacune des applications.

Seul inconvénient, contre le fait d'essayer d'obtenir un seul processus à exécuter les deux (ou plus) des applications, est qu'il pourrait utiliser un peu plus de résident de mémoire que vous pourriez vous en sortir autrement. Mais il tient assez bien séparés et évite les tracas. Et qui pourrait ne pas être une préoccupation pour vous (ce n'était pas pour moi).

(Il pourrait ne pas être si mal que ça non plus, ils pourraient être en mesure de partager beaucoup de pages de texte? C'est juste de la spéculation gratuite; je n'ai pas vérifié cela en aucune façon, que ma configuration n'a pas été à la mémoire de la faim)

Voici quelques extraits de mon httpd.conf, environ:

WSGIDaemonProcess khdx_wsgi user=galdosd group=galdosd maximum-requests=10000
WSGIScriptAlias /khdx /home/galdosd/khdxweb/rel/khdx/apache/django.wsgi
<Location /khdx>
WSGIProcessGroup khdx_wsgi
</Location>

WSGIDaemonProcess sauron_wsgi user=galdosd group=galdosd maximum-requests=10000
WSGIScriptAlias /sauron /home/galdosd/finalsauronweb/django-root/apache/django.wsgi
<Location /sauron>
WSGIProcessGroup sauron_wsgi
</Location>

Answer 2

Domingo Ignacio réponse m'ont mis sur la bonne voie. Je tiens à souligner un fait important à propos de le faire fonctionner: Les deux groupes de processus doivent être dans le même VirtualHost. (Ceci est basé sur mes tests avec Ubuntu 12.04.3 LTS, Apache 2.2.22 et un couple de WSGI applications écrites en Python.)

Par exemple, cela n'a pas fonctionné pour moi, ce qui entraîne la capacité d'accéder à app1 mais une erreur 404 pour app2:

<VirtualHost *>
        WSGIDaemonProcess app1 user=someuser group=somegroup threads=5
        WSGIScriptAlias /app1 /app1/app1.wsgi

        <Location /app1>
                WSGIProcessGroup app1
        </Location>
</VirtualHost>

<VirtualHost *>
        WSGIDaemonProcess app2 user=someuser group=somegroup threads=5
        WSGIScriptAlias /app2 /app2/app2.wsgi

        <Location /app2>
                WSGIProcessGroup app2
        </Location>
</VirtualHost>

Retrait du milieu et de balises, de façon à avoir un seul VirtualHost, a résolu le problème:

<VirtualHost *>
        WSGIDaemonProcess app1 user=someuser group=somegroup threads=5
        WSGIScriptAlias /app1 /app1/app1.wsgi

        <Location /app1>
                WSGIProcessGroup app1
        </Location>

        WSGIDaemonProcess app2 user=someuser group=somegroup threads=5
        WSGIScriptAlias /app2 /app2/app2.wsgi

        <Location /app2>
                WSGIProcessGroup app2
        </Location>
</VirtualHost>

Answer 3

J'ai moi-même eu des problèmes avec ça. Au lieu d'essayer d'obtenir la bonne configuration Apache, j'ai décidé à la place d'utiliser un seul WSGIScriptAlias et d'avoir un middleware WSGI qui acheminait les demandes vers les applications correctes. Mon code est à https://github.com/zhemao/flotilla . Je ne l'ai pas beaucoup testé, alors utilisez-le avec prudence, mais j'espère que cela vous aidera.