Подтвердить что ты не робот

Несколько приложений mod_wsgi на одном виртуальном хосте, направляющем неправильное приложение

Я пытаюсь получить два (или более) приложения Django, настроенные в подкаталогах в том же домене, например:

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

Я знаю, что обычно это нормально работает, настраивая виртуальный хост apache следующим образом:

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

Теперь я проверил, что каждый сайт работает индивидуально. Но когда я пытаюсь запустить оба бок о бок, apache отправляет меня на тот сайт, на который загружен рабочий процесс. Пример:

  • Перезапустить apache, настроенный для обслуживания 6 потоков
  • Загрузите example.com/site1/, верните правильную страницу
  • Загрузите example.com/site2/, верните правильную страницу
  • Повторите 2 и 3 еще 2 раза.
  • Повторно обновите example.com/site1/, следите за тем, чтобы цикл выполнялся с сайта на сайт.

Эффективно, для любого заданного количества рабочих процессов он циклически проходит через общее количество отправивших запрос в зависимости от того, что он первым ударил, независимо от директивы WSGIScriptAlias. Независимо от того, что я делаю (настройка WSGIProcessGroup, режим демон или встроенный режим или директивы), он продолжает демонстрировать это поведение.

Если кто-то может указать, что я делаю неправильно здесь, это было бы феноменально!

4b9b3361

ОТВЕТЫ

Ответ 1

У меня было несколько приложений WSGI, работающих на одной установке Apache, и выяснилось, что проще всего просто иметь несколько групп процессов - по одному для каждого из приложений.

Один недостаток, а на самом деле попытка получить один процесс для запуска обоих (или более) приложений - это то, что это может использовать немного более резидентную память, чем вы могли бы уйти в противном случае. Но он держит их довольно хорошо отделенными и позволяет избежать хлопот. И это может не беспокоить вас (это было не для меня).

(Возможно, это также не так уж плохо, они могут делиться множеством текстовых страниц, что просто бездельничает, я не проверял это каким-либо образом, поскольку моя установка не была полностью голодной)

Вот некоторые фрагменты моего httpd.conf, приблизительно:

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>

Ответ 2

Доминго Игнасио ответил мне на правильный путь. Я хотел бы указать на важный факт, что он работает: две группы процессов должны находиться в пределах той же VirtualHost. (Это основано на моих тестах с Ubuntu 12.04.3 LTS, Apache 2.2.22 и несколькими приложениями WSGI, написанными на Python.)

Например, для меня работала не, в результате появилась возможность доступа к app1, но ошибка 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>

Удаление середины и тегов, чтобы иметь один VirtualHost, решили проблему:

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

Ответ 3

У меня были проблемы с этим самим. Вместо того, чтобы пытаться правильно настроить Apache, я решил вместо этого использовать один WSGIScriptAlias ​​и иметь промежуточное ПО WSGI, которое направило запросы на правильные приложения. Мой код находится в https://github.com/zhemao/flotilla. Я не тестировал это так, поэтому используйте его с осторожностью, но я надеюсь, что это поможет.