2011-07-06 6 views
39

estoy tratando de conseguir dos (o más) aplicaciones Django establecidos en subdirectorios bajo el mismo dominio, por ejemplo:aplicaciones mod_wsgi múltiples en una máquina virtual que dirigen a la aplicación incorrecta

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

Sé que normalmente esto funciona bien al configurar un apache virtualhost como este:

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

Ahora, he verificado que cada sitio funciona individualmente. Pero cuando trato de ejecutar ambos uno al lado del otro, apache me envía al sitio que cargó primero el proceso de trabajo. Ejemplo:

  1. Reiniciar Apache configurado para servir 6 hilos
  2. carga example.com/site1/, obtener la página correcta
  3. carga example.com/site2/, obtener la página correcta
  4. Repetir 2 y 3 2 veces más.
  5. Actualice example.com/site1/ repetidamente, mire ciclo de un sitio a otro.

Efectivamente, para cualquier número de procesos de trabajo, hace un ciclo a través del número total de ellos que envían la solicitud a la que golpeó primero independientemente de la directiva WSGIScriptAlias. Independientemente de lo que haga (configuración de WSGIProcessGroup, modo daemon frente a modo incrustado o directivas), continúa mostrando este comportamiento.

Si alguien puede señalar lo que estoy haciendo mal aquí, ¡eso sería fenomenal!

+0

¿Qué se obtiene al reemplazar los archivos de script WSGI con que se describe en 'http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used'? –

Respuesta

48

He tenido varias aplicaciones de WSGI ejecutándose en una sola instalación de Apache, y he descubierto que lo más fácil es tener varios grupos de procesos, uno para cada una de las aplicaciones.

Una desventaja, en lugar de tratar de obtener un solo proceso para ejecutar ambas (o más) aplicaciones, es que esto podría utilizar un poco más de memoria residente de lo que podría conseguir si no fuera así. Pero los mantiene bastante bien separados y evita molestias. Y eso podría no ser una preocupación para ti (no fue para mí).

(¿No sería tan malo tampoco, podrían compartir muchas páginas de texto? Eso es solo una especulación ociosa, no he verificado esto de ninguna manera, ya que mi configuración no estaba para nada anulada por la memoria)

He aquí algunos fragmentos de mi httpd.conf, aproximadamente: la respuesta de

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> 
+3

Se desaconseja el uso de solicitudes máximas para los sitios de producción, a menos que realmente tenga una fuga de memoria paralizante que no pueda solucionar de inmediato. –

+1

¡Brillante! Los grupos de procesos separados definidos dentro de los bloques de Ubicación trabajados. Lo único que lamento es que no pregunté aquí antes ;-) –

+0

¡Gracias, Graham! ¿Eso es debido a la demora de reinicio ocasional? –

1

He tenido problemas con esto yo mismo. En lugar de intentar obtener la configuración de Apache correcta, decidí utilizar WSGIScriptAlias ​​y tener el middleware WSGI que enrutaba las solicitudes a las aplicaciones correctas. Mi código está en https://github.com/zhemao/flotilla. No lo he probado tanto, así que úselo con precaución, pero espero que ayude.

+1

No puede hacer eso con dos sitios diferentes de Django debido a la dependencia de Django de la variable de entorno única DJANGO_SETTINGS_MODULE, el valor que no se puede cambiar de una solicitud a la siguiente. –

+0

Ah bien, se olvidó de eso. –

10

Domingo Ignacio me puso en el camino correcto. Me gustaría señalar un hecho importante sobre cómo hacer que funcione: los dos grupos de proceso deben estar dentro del mismo mismo VirtualHost. (Esto se basa en mis pruebas con Ubuntu 12.04.3 LTS, Apache 2.2.22 y un par de aplicaciones WSGI escritas en Python.)

Por ejemplo, esto hizo no trabajo para mí, lo que resulta en la posibilidad de acceder app1 pero un error de 404 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> 

Extracción de la media y etiquetas, con el fin de tener una sola VirtualHost, resolvió el problema:

<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> 
Cuestiones relacionadas