Dos proyectos de Django ejecutándose simultáneamente y mod_wsgi actuando werid

Question

Estoy tratando de ejecutar dos proyectos de Django simultáneamente. Yo estaba usando mod_wsgi, y descubrí que el sitio está actuando de forma extraña. Tal vez habría una solución alternativa, pero me gustaría saber qué es lo que me falta y cómo resolver el problema.

En la configuración de Apache

# Setup the Python environment 
# As root owns basically everything on a Amazon AMI and root 
# cannot be used. Create a folder under /var/run/wsgi 
# with the owner as ec2-user and group ec2-user. 
WSGISocketPrefix /var/run/wsgi 
# Call your daemon process a name 
WSGIDaemonProcess pydaemon processes=1 threads=5 
# Call your daemon process group a name 
WSGIProcessGroup pydaemon 
# Point to where the handler file is. This will be different 
# If you are using some other framework. 
WSGIScriptAlias /test /var/www/html/test/wsgi.py 
WSGIScriptAlias /proto /var/www/html/proto/wsgi.py 

Después de Apache reinicia, si conecto a '/ proto', entonces el sitio proto se muestra. Sin embargo, luego me conecto a '/ test', sin reiniciar Apache, el sitio proto aún se muestra y no puedo acceder al sitio de prueba.

Ahora reinicio Apache, esta vez voy a '/ test' primero. ¡El sitio de prueba aparece! Sin embargo, si voy a '/ proto' todavía muestra el sitio de prueba, no el sitio de proto.

¿Qué podría hacer que esto suceda? Agregué SESSION_COOKIE_PATH de manera diferente para cada aplicación por si acaso, pero el problema aún existe.

---

[ACTUALIZADO]

También probé como el siguiente, para dar diferentes nombres de grupos de aplicaciones WSGI, pero sin suerte.

Alias /cuedit /var/local/test/wsgi.py 
<Location /test> 
SetHandler wsgi-script 
Options +ExecCGI 
WSGIApplicationGroup test 
</Location> 
Alias /proto /var/local/proto/wsgi.py 
<Location /proto> 
SetHandler wsgi-script 
Options +ExecCGI 
WSGIApplicationGroup proto 
</Location> 

---

[ACTUALIZADO]

I cambió desde el modo demonio al modo incrustado. Supongo que el problema fue que dos instancias compartieron el mismo proceso de demonio mod_wsgi por lo que su espacio de nombres colisionó.

Supongo que deberían manejarse correctamente, pero en el modo daemon no pude hacerlo bien.

Answer 1

utilizar esto como una solución:

WSGIDaemonProcess pydaemon-1 processes=1 threads=5 
WSGIDaemonProcess pydaemon-2 processes=1 threads=5 

WSGIScriptAlias /test /var/www/html/test/wsgi.py 

<Location /test> 
WSGIProcessGroup pydaemon-1 
WSGIApplicationGroup %{GLOBAL} 
</Location> 

WSGIScriptAlias /proto /var/www/html/proto/wsgi.py 

<Location /proto> 
WSGIProcessGroup pydaemon-2 
WSGIApplicationGroup %{GLOBAL} 
</Location> 

Esto forzará a cada aplicación a un grupo de procesos de daemon por separado y no habrá manera de que puedan interferir entre sí.

Si eso todavía no funciona, tiene problemas con su archivo de script WSGI de alguna manera.

Answer 2

El problema podría estar relacionado con que Apache comparta el subinterpretador Python entre las aplicaciones WSGI. Trate de añadir esto a la configuración de Apache para evitar compartir:

WSGIApplicationGroup %{GLOBAL} 

Comprobar this blog post para la explicación en profundidad y consejos adicionales (verifique en los comentarios también).

Answer 3

También tengo 2 proyectos Django sin embargo, cada uno se está ejecutando en un puerto diferente (httpd config), se ve algo como esto:

<VirtualHost *:80> 
    ServerAdmin xx 
    ServerName xx 
    ServerAlias xx 
    ErrorLog /path/to/first/project/logs/error.log 
    CustomLog /path/to/first/project/logs/access.log combined 

    Alias /static/ /path/to/first/project/sitestatic 

    WSGIDaemonProcess app processes=1 threads=15 display-name=%{GROUP} 
    WSGIProcessGroup app 

    WSGIScriptAlias//path/to/first/project/django.wsgi 

    <Directory /path/to/first/project/apache> 
     Order deny,allow 
     Allow from all 
    </Directory> 
</VirtualHost> 

<VirtualHost *:8080> 
    ServerAdmin xx 
    ServerName xx 
    ServerAlias xx 
    ErrorLog /path/to/second/project/logs/error.log 
    CustomLog /path/to/second/project/logs/access.log combined 

    WSGIDaemonProcess app1 processes=1 threads=15 display-name=%{GROUP} 
    WSGIProcessGroup app1 

    WSGIScriptAlias//path/to/second/project/apache/django.wsgi 

    <Directory /path/to/second/project/apache> 
     Order deny,allow 
     Allow from all 
    </Directory> 
</VirtualHost> 

Answer 4

No puedo comentar la respuesta dada por Graham, por lo que agrego una mía propia.

El problema para mí era realmente el intérprete de Python, pero también tuve que agregar el camino de python para cada intérprete.Aquí sigue una configuración de ejemplo:

WSGIDaemonProcess py_app1 processes=1 threads=5 python-path=/path/to/app1 
WSGIScriptAlias /app1 /path/to/app1/wsgi.py 
<Directory /path/to/app1> 
    <Files wsgi.py> 
     Order deny,allow 
     Allow from all 
    </Files> 
</Directory> 
<Location /app1> 
    WSGIProcessGroup py_app1 
    WSGIApplicationGroup %{GLOBAL} 
</Location> 

WSGIDaemonProcess py_app2 processes=1 threads=5 python-path=/path/to/app2 
WSGIScriptAlias /app2 /path/to/app2/wsgi.py 
<Directory /path/to/app2> 
    <Files wsgi.py> 
     Order deny,allow 
     Allow from all 
    </Files> 
</Directory> 
<Location /app2> 
    WSGIProcessGroup py_app2 
    WSGIApplicationGroup %{GLOBAL} 
</Location>