Два проекта Django, запущенные одновременно, и mod_wsgi, действующие со странностями - PullRequest
11 голосов
/ 06 марта 2012

Я пытаюсь запустить два проекта 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, затем отображается сайт 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>

[ОБНОВЛЕНО]

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

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

Ответы [ 4 ]

14 голосов
/ 07 марта 2012

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

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.

4 голосов
/ 06 марта 2012

У меня также есть 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>
1 голос
/ 06 марта 2012

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

WSGIApplicationGroup %{GLOBAL}

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

0 голосов
/ 29 августа 2013

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

Проблема для меня действительно заключалась в интерпретаторе 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>
...