2012-07-08 2 views
1

최근에 정적 페이지 웹 사이트 두 개와 django 프로젝트 두 개를 호스팅하는 웹 서버를 최근 설정했습니다.여러 장고 사이트 호스팅 문제 (설정 교차)

두 개의 django 프로젝트는 각각 'abc'와 'xyz'이고 홈 폴더에 각각 별도의 디렉토리에 있습니다. 각각은 각각의 settings.py 파일을 가리키는 자체 wsgi 스크립트를 가지고 있습니다.

최근에 'xyz'에 몇 가지 오류가 나타났습니다. 일반적으로 새로 고침으로 문제가 해결되지만 허용되지 않으므로 아파치 error.log를 확인하고 'xyz'을 눌렀을 때 예외가 발생하여 xyz 프로젝트에서 abc.settings를 찾을 수 없다는 사실을 알게되었습니다. 어떻게 든이 두 프로젝트는 서로 교차하고 서로 간섭하고 있습니다. 아직 문제가 다른 방향으로 발생했는지 알기에는 아직 abc에서 작업하지 않았습니다. 아래는 제 예외입니다.

[Sun Jul 08 13:30:34 2012] [error] Traceback (most recent call last): 
[Sun Jul 08 13:30:34 2012] [error] File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 219, in __call__ 
[Sun Jul 08 13:30:34 2012] [error] self.load_middleware() 
[Sun Jul 08 13:30:34 2012] [error] File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", line 39, in load_middleware 
[Sun Jul 08 13:30:34 2012] [error]  for middleware_path in settings.MIDDLEWARE_CLASSES: 
[Sun Jul 08 13:30:34 2012] [error] File "/usr/local/lib/python2.7/dist-packages/django/utils/functional.py", line 184, in inner 
[Sun Jul 08 13:30:34 2012] [error]  self._setup() 
[Sun Jul 08 13:30:34 2012] [error] File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 42, in _setup 
[Sun Jul 08 13:30:34 2012] [error]  self._wrapped = Settings(settings_module) 
[Sun Jul 08 13:30:34 2012] [error] File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 95, in __init__ 
[Sun Jul 08 13:30:34 2012] [error]  raise ImportError("Could not import settings '%s' (Is it on sys.path?): %s" % (self.SETTINGS_MODULE, e)) 
[Sun Jul 08 13:30:34 2012] [error] ImportError: Could not import settings 'abc.settings' (Is it on sys.path?): No module named scalamoosh.settings 

어떤 도움이나 조언을 주시면 감사하겠습니다. 건배

답변

4

당신이 실행중인 문제에 mod_wsgi에 각 장고가 자신의 파이썬 인터프리터되는 앱 제공하는 동안, 그들은 여전히 ​​장고 설정 모듈의 이름을 저장하는 곳이다 같은 OS 환경을 공유하는 것입니다. 해결 방법은 장고가 WSGI 응용 프로그램 객체를 만들기 전에 설정 모듈을 찾을 환경 변수의 이름을 변경하는 것입니다.

약간 wsgi.py이 같은 형태의 수정 내 : mod_wsgi에 대한

import os 

# change the env variable where django looks for the settings module 
import django.conf 
django.conf.ENVIRONMENT_VARIABLE = "DJANGO_SECOND_SETTINGS_MODULE" 

os.environ.setdefault("DJANGO_SECOND_SETTINGS_MODULE", "second.settings") 

# This application object is used by any WSGI server configured to use this 
# file. This includes Django's development server, if the WSGI_APPLICATION 
# setting points here. 
from django.core.wsgi import get_wsgi_application 
application = get_wsgi_application() 
+0

위대한 작품. 고마워요! :) – Scalamoosh

2

현재 두 프로젝트에 대해 별도의 가상 환경을 사용하고있는 것처럼 보이지 않으며 그렇지 않은 경우 문제가 계속되는 지 확인하는 것이 좋습니다. 여전히 동일한 Apache 인스턴스를 사용할 수 있지만 Django의 두 인스턴스를 별도로 실행합니다 (프로젝트의 다른 모든 요구 사항은 다를 수도 있고 다를 수도 있음). 이는 보통 Django 프로젝트에서 권장되는 접근 방식입니다.

가상 환경에 대해 잘 모르는 경우 virtualenv 및 Django 사용에 대해서는 quickstart tutorial을 사용하고 Doug Hellman이 제공 한 Virtualenv Wrapper을 사용하는 것이 좋습니다. 희망이 도움이!

+0

동일한 문제가 발생하지만 virtualenv가 해결할 수 있는지 확실하지 않습니다. 진짜 문제는 다른 앱에 의해 덮어 쓰여지는 DJANGO_SETTINGS_MODULE 환경 변수입니다. – stschindler

+0

virtualenv 관련 정보를 제공해 주셔서 감사합니다. 나는 잠시 동안 그것을 설정하고 싶었지만 결코 그것에 도달하지 못했습니다. 불행히도, 그것은 내 문제를 해결하지 못했습니다. 언급 된 @ 탱크와 마찬가지로, 다른 앱이 사용될 때마다 (자바 스크립트()의) DJANGO_SETTING_MODULE 변수가 덮어 쓰기됩니다. – Scalamoosh

0

캐시에 대해 memcached을 사용하고 있습니까? 아니면 두 인스턴스가 동일한 캐시 파일에 쓸 수있는 다른 캐싱 방법을 사용하고 있습니까? 그것은 두 환경이 왜 섞여 있는지 설명 할 수 있습니다. 이 경우 KEY_PREFIX 개의 변수를 설정 'CACHES 사전에 추가하기 만하면됩니다.

CACHES = { 
    'default': { 
     'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 
     'LOCATION': '127.0.0.1:11211', 
     'KEY_PREFIX': 'scalamoosh' 
    } 
} 
+0

현재 사이트 중 하나에 캐싱이 설정되어 있지 않으므로 문제가 해결 될지 의심 스럽습니다. 정보를 가져 주셔서 감사합니다. – Scalamoosh

2

기본 구성은 동일한 프로세스의 별도의 서브 인터프리터에서 실행되는 두 개의 장고 사이트가 있습니다. 안타깝게도 Django는 생성 된 wsgi.py를 1.4로 변경했으며 새로운 파일은 mod_wsgi의 기본 동작으로 중단됩니다.

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings") 

에 :

입니다
os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings" 

는 os.environ.setdefault 사용하지 않기 때문에) (장고 1.4을 사용하여 wsgi.py 파일에 가서 변경하는 경우이 문제를 해결하려면 서브 인터프리터 사이의 환경 변수 유출 방식 때문에 다른 서브 인터프리터의 다른 장고 사이트에서 이미 변수를 설정 한 경우에는 아무 것도하지 않습니다.

mod_wsgi 데몬 모드를 사용하고 각 사이트에 대해 고유 한 데몬 프로세스 그룹을 만들고 다른 프로세스 집합에서 실행하도록 위임하십시오. 이것은 VirtualHosts에 대한 Apache 설정이 올바르지 않은 이전 Django 버전과 비슷한 문제를 해결할 수 있습니다.

관련 문제