Два проекта Django, выполняющиеся одновременно, и mod_wsgi, действующие werid

Я пытаюсь запустить два проекта Django одновременно. Я случайно использовал mod_wsgi, и нашел, что сайт действует странно. Возможно, было бы обходным путем, но я хотел бы знать, чего мне не хватает, и как решить проблему.

В конфигурации 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

После перезапуска Apache, если я подключусь к '/proto', появится прото-сайт. Однако, затем я подключаюсь к '/test', не перезапуская Apache, прото-сайт все еще отображается, и я не могу получить доступ к тестовому сайту.

Теперь я перезапускаю Apache, на этот раз я сначала '/test'. Появился тестовый сайт! Однако, если я перейду к '/proto', он покажет тестовый сайт, а не прото-сайт.

Что может произойти? Я добавил SESSION_COOKIE_PATH по-разному для каждого приложения на всякий случай, но проблема все еще существует.

[ОБНОВЛЕНО]

Я также попытался использовать следующие имена групп приложений WSGI, но не повезло.

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>

[ОБНОВЛЕНО]

Я перешел из режима демона во встроенный режим. Я предполагаю, что проблема заключалась в том, что два экземпляра разделяли один и тот же процесс daemon mod_wsgi, чтобы их пространство имен сталкивалось.

Я бы ожидал, что их нужно обработать правильно, но в режиме демона я не мог понять это правильно.

Ответ 1

Используйте это как обходной путь:

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>

Это приведет к тому, что каждое приложение войдет в отдельную группу процессов демона и никак не сможет помешать друг другу.

Если это все еще не работает, у вас есть проблемы с вашим WSGI script файлом.

Ответ 2

У меня также есть 2 проекта Django, но каждый из них работает на другом порту (httpd config), он выглядит примерно так:

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

Ответ 3

Проблема может быть связана с тем, что Apache использует суб-интерпретатор Python между приложениями WSGI. Попробуйте добавить это в конфигурацию Apache, чтобы избежать совместного использования:

WSGIApplicationGroup %{GLOBAL}

Отметьте этот пост в блоге для подробного объяснения и дополнительных советов (также проверьте комментарии).

Ответ 4

Не могу прокомментировать ответ, данный Грэмом, поэтому добавив один из моих собственных.

Проблема для меня действительно была интерпретатором Python, но мне также пришлось добавить python-путь для каждого интерпретатора. Ниже приведен пример конфигурации:

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>