Django: два веб-сайта с одинаковой кодовой базой и отдельным доменом, Settings.py, файлом WSGI, но не может создавать отдельную базу данных

Я думаю, что это, вероятно, проблема с конфигурацией WSGI/Apache.

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

Мои файлы конфигурации WSGI, похоже, загружают правильные отдельные файлы settings.py. Однако кажется, что второй домен загружает данные из исходной базы данных, а не из новой. Это происходит только в моей производственной среде с настройкой Apache.

Мои файлы settings.py загружают общую информацию через файл с именем common.py, а затем загружают имя базы данных.

I.e.

settings1.py

from common import *
DATABASES['default']['NAME'] = 'database1'
...

settings2.py

from common import *
DATABASES['default']['NAME'] = 'database2'
...

Эти настройки загружаются из соответствующих файлов WSGI:

www.domain1.com -> index1.wsgi:

import os, sys
sys.path.insert(0,'/location/to/code/')
sys.path.insert(0,'/location/to/code/application')
sys.path.insert(0,'/virtual/env/python2.7/site-packages/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'application.settings1'
os.environ['PYTHON_EGG_CACHE'] = '/location/to/.python-eggs'  

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

www.domain2.com -> index2.wsgi:

import os, sys
sys.path.insert(0,'/location/to/code/')
sys.path.insert(0,'/location/to/code/application')
sys.path.insert(0,'/virtual/env/python2.7/site-packages/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'application.settings2'
os.environ['PYTHON_EGG_CACHE'] = '/location/to/.python-eggs'  

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

Как видите, все, что я сделал, это изменил расположение настроек. Расположение кода остается прежним. Я убежден, что эта часть работает, основываясь на том факте, что места сохранения и загрузки статических файлов на сервере изменились в зависимости от свойств settings1.py и settings2.py. Однако информация, вызываемая приложением, поступает из базы данных1 даже при вызове с www.domain2.com. Я даже не уверен, как это стало возможным, поскольку это имя базы данных доступно только в settings1.py, а не в common.py. У кого-нибудь есть понимание этой проблемы?

Изменить:

Я добавляю в Apache include, который направляет домены к соответствующим файлам WSGI. Обратите внимание, что виртуальные хосты прослушивают локальный хост, потому что NGINX прослушивает порт 80 и перенаправляет соответствующий запрос через Apache.

AddHandler wsgi-script .wsgi 

NameVirtualHost 127.0.0.1:80
Listen 127.0.0.1:80

<IfModule mod_wsgi.c>
<VirtualHost 127.0.0.1:80>
    ServerName domain1.com
    ServerAlias www.domain1.com

    ErrorDocument 500 "We are experiencing difficulties.  Please contact [email protected] if you feel you are receiving this page in error."

    WSGIScriptAlias / /path/to/index1.wsgi
    Alias /static/ /path/to/static_files/static/
    WSGIDaemonProcess djangodomain1 python-path=/virtual/env/python2.7/site-packages processes=8 threads=4 display-name=%{GROUP}
    WSGIProcessGroup djangodomain1
    WSGIApplicationGroup %{GLOBAL}

    ExpiresActive On
    ExpiresDefault "access plus 10 days"
    ExpiresByType text/css "access plus 1 second"
    ExpiresByType text/js "access plus 1 second"

    ServerAdmin [email protected]
    UseCanonicalName Off
    CustomLog /path/to/logs/access_log combined
    CustomLog /path/to/domlogs/domain1.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."

    ErrorLog /path/to/logs/error_log

    ## User group1 # Needed for Cpanel::ApacheConf
    <IfModule mod_suphp.c>
        suPHP_UserGroup group1 group1
    </IfModule>
    <IfModule !mod_disable_suexec.c>
        SuexecUserGroup group1 group1
    </IfModule>

</VirtualHost>

<VirtualHost 127.0.0.1:80>
    ServerName domain2.com
    ServerAlias www.domain2.com

    ErrorDocument 500 "We are experiencing difficulties.  Please contact [email protected] if you feel you are receiving this page in error."

    WSGIScriptAlias / /path/to/index2.wsgi
    Alias /static/ /path/to/static/
    WSGIDaemonProcess djangodomain2 python-path=/virtual/env/python2.7/site-packages processes=8 threads=4 display-name=%{GROUP}
    WSGIProcessGroup djangodomain2
    WSGIApplicationGroup %{GLOBAL}

    ExpiresActive On
    ExpiresDefault "access plus 10 days"
    ExpiresByType text/css "access plus 1 second"
    ExpiresByType text/js "access plus 1 second"

    ServerAdmin [email protected]
    UseCanonicalName Off
    CustomLog /path/to/logs/domain2/access_log combined
    CustomLog /path/to/domlogs/domain2.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."

    ErrorLog /path/to/logs/domain2/error_log

    ## User group1 # Needed for Cpanel::ApacheConf
    <IfModule mod_suphp.c>
        suPHP_UserGroup group1 group1
    </IfModule>
    <IfModule !mod_disable_suexec.c>
        SuexecUserGroup group1 group1
    </IfModule>

</VirtualHost>

django apache2 mod-wsgi multiple-domains multiple-databases
person garromark    schedule 02.12.2012    source источник
comment
Добавьте свою конфигурацию mod_wsgi, чтобы ее можно было проверить.   -  person Graham Dumpleton    schedule 03.12.2012
comment
Убедитесь, что common.py не указывает WSGI_APPLICATION на ваш файл settings1.py. Это должно повлиять только на встроенную в Django команду runserver, но, поскольку это довольно странная ситуация, ее стоит хотя бы проверить.   -  person orokusaki    schedule 03.12.2012
comment
Грэм, я добавил конфигурацию Apache, которая обрабатывает запросы в этих двух доменах. Orokusaki, я сделал grep для WSGI_APPLICATION (и даже просто WSGI) внутри своей кодовой базы и ничего не нашел. Спасибо за ваши идеи.   -  person garromark    schedule 03.12.2012

Ответы (2)


arrow_upward
0
arrow_downward

Я думаю, что настройка WSGIApplicationGroup сбивает вас с толку. Я бы удалил его из обеих записей VirtualHost.

person Jeff Sheffield    schedule 03.12.2012
comment
Я попытался удалить его, как вы сказали, я также попытался установить его на $ {SERVER}, чтобы он мог варьироваться в зависимости от доменного имени, и ни один из них не помог. - person garromark; 03.12.2012

arrow_upward
0
arrow_downward

Хорошо, изучив вашу конфигурацию, я убежден, что «скорее всего» apache не соответствует вашему виртуальному хосту и направляется на первый. Это объясняет, почему это происходит только во 2-й окр.

Прочтите последнюю строфу этой записи в блоге: блог Gram по настройке django Возврат к определению VirtualHost по умолчанию.

--- скинуть ---

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

<VirtualHost _default_:*>
   Deny from all
</VirtualHost>

--- конец фрагмента ---

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

person Jeff Sheffield    schedule 05.01.2014