간단한 개발 및 배포를 위해 Django를 어떻게 구성합니까?

나는 Django 개발을 할 때 SQLite 를 사용하는 경향이 있지만 라이브 서버에서는 종종 더 강력한 것이 필요합니다 ( 예 : MySQL / PostgreSQL ). 변함없이 Django 설정에도 다른 변경 사항이 있습니다 : 다른 로깅 위치 / 강도, 미디어 경로 등.

배포를 간단하고 자동화 된 프로세스로 만들기 위해 이러한 모든 변경 사항을 어떻게 관리합니까?

업데이트 : django-configurations 가 출시되었습니다. 이것은 아마도 수동으로하는 것보다 대부분의 사람들에게 더 나은 옵션 일 것입니다.

수동으로 작업하려는 경우 이전 답변이 여전히 적용됩니다.

여러 설정 파일이 있습니다.

• settings_local.py -데이터베이스 이름, 파일 경로 등과 같은 호스트 별 구성
• settings_development.py-개발에 사용되는 구성 (예 : DEBUG = True.
• settings_production.py-생산에 사용되는 구성 (예 : SERVER_EMAIL.

이 모든 settings.py것을 먼저 가져 오는 파일 settings_local.py과 연결 한 다음 나머지 두 개 중 하나를 연결합니다. 그것은 내부의 두 설정에 의해로드 할 결정 settings_local.py- DEVELOPMENT_HOSTS와 PRODUCTION_HOSTS. 실행중인 시스템의 호스트 이름을 찾기 위해 settings.py호출 platform.node()한 다음 목록에서 해당 호스트 이름을 찾고 호스트 이름을 찾은 목록에 따라 두 번째 설정 파일을로드합니다.

이렇게 settings_local.py하면 호스트 별 구성을 사용 하여 파일을 최신 상태로 유지하고 나머지는 모두 자동으로 처리해야합니다.

여기 에서 예를 확인 하십시오 .

개인적으로 저는 프로젝트에 대해 하나의 settings.py를 사용합니다. 저는 단지 그것이있는 호스트 이름을 찾도록합니다 (제 개발 머신은 "gabriel"로 시작하는 호스트 이름을 가지고 있습니다. 그래서 저는 이것을 가지고 있습니다 :

import socket
if socket.gethostname().startswith('gabriel'):
    LIVEHOST = False
else: 
    LIVEHOST = True

다른 부분에는 다음과 같은 것이 있습니다.

if LIVEHOST:
    DEBUG = False
    PREPEND_WWW = True
    MEDIA_URL = 'http://static1.grsites.com/'
else:
    DEBUG = True
    PREPEND_WWW = False
    MEDIA_URL = 'http://localhost:8000/static/'

등등. 가독성이 조금 떨어지지 만 잘 작동하며 여러 설정 파일을 저글링해야하는 시간을 절약합니다.

settings.py의 끝에 다음이 있습니다.

try:
    from settings_local import *
except ImportError:
    pass

이렇게하면 기본 설정을 재정의하려면 settings.py 바로 옆에 settings_local.py를 배치하면됩니다.

두 개의 파일이 있습니다. settings_base.py공통 / 기본 설정을 포함하고 소스 제어에 체크인됩니다. 각 배포에는 처음에 settings.py실행 된 from settings_base import *다음 필요에 따라 재정의 하는 별도 의이 있습니다.

내가 찾은 가장 단순한 방법은 다음과 같습니다.

1) 로컬 개발을 위해 기본 settings.py 를 사용 하고 2) 다음으로 시작 하는 production-settings.py를 만듭니다 .

import os
from settings import *

그런 다음 프로덕션에서 다른 설정을 재정의하십시오.

DEBUG = False
TEMPLATE_DEBUG = DEBUG


DATABASES = {
    'default': {
           ....
    }
}

여러 데이터베이스에 Django 자체를 배포하는 문제와 관련하여 Djangostack 을 살펴볼 수 있습니다. Apache, Python, Django 등을 설치할 수있는 완전 무료 설치 프로그램을 다운로드 할 수 있습니다. 설치 과정의 일부로 사용할 데이터베이스 (MySQL, SQLite, PostgreSQL)를 선택할 수 있습니다. 내부적으로 배포를 자동화 할 때 설치 프로그램을 광범위하게 사용합니다 (무인 모드에서 실행할 수 있음).

내 settings.py 파일이 외부 디렉터리에 있습니다. 이렇게하면 소스 제어에 체크인되거나 배포시 덮어 쓰여지지 않습니다. 기본 설정과 함께 내 Django 프로젝트의 settings.py 파일에 넣습니다.

import sys
import os.path

def _load_settings(path):    
    print "Loading configuration from %s" % (path)
    if os.path.exists(path):
    settings = {}
    # execfile can't modify globals directly, so we will load them manually
    execfile(path, globals(), settings)
    for setting in settings:
        globals()[setting] = settings[setting]

_load_settings("/usr/local/conf/local_settings.py")

참고 : local_settings.py를 신뢰할 수없는 경우 매우 위험합니다.

짐에 의해 언급 된 여러 설정 파일뿐만 아니라, 나 또한 장소에 상단에 내 settings.py 파일에 두 가지 설정 경향 BASE_DIR과 BASE_URL코드와 사이트의베이스에 URL의 경로로 설정을, 다른 모든 설정을 수정 이것에 자신을 추가합니다.

BASE_DIR = "/home/sean/myapp/" 예 : MEDIA_ROOT = "%smedia/" % BASEDIR

따라서 프로젝트를 이동할 때 전체 파일을 검색하지 않고 이러한 설정 만 편집하면됩니다.

원격 배포의 자동화를 용이하게하는 패브릭 및 Capistrano (Ruby 도구이지만 Django 애플리케이션 배포에 사용할 수 있음) 도 살펴 보는 것이 좋습니다 .

이 구성을 사용합니다.

settings.py 끝에서 :

#settings.py
try:
    from locale_settings import *
except ImportError:
    pass

그리고 locale_settings.py에서 :

#locale_settings.py
class Settings(object):

    def __init__(self):
        import settings
        self.settings = settings

    def __getattr__(self, name):
        return getattr(self.settings, name)

settings = Settings()

INSTALLED_APPS = settings.INSTALLED_APPS + (
    'gunicorn',)

# Delete duplicate settings maybe not needed, but I prefer to do it.
del settings
del Settings

너무 많은 복잡한 답변!

모든 settings.py 파일은 다음과 함께 제공됩니다.

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

이 디렉토리를 사용하여 DEBUG 변수를 다음과 같이 설정합니다 (개발 코드가있는 디렉토리로 대체).

DEBUG=False
if(BASE_DIR=="/path/to/my/dev/dir"):
    DEBUG = True

그런 다음 settings.py 파일을 이동할 때마다 DEBUG가 False가되고 프로덕션 환경이됩니다.

개발 환경의 설정과 다른 설정이 필요할 때마다 다음을 사용하십시오.

if(DEBUG):
    #Debug setting
else:
    #Release setting

SQLite 사용에서 한 단계 올라갈 필요가 있는지 여부는 사이트의 크기에 따라 다르며 여러 소규모 라이브 사이트에서 SQLite를 성공적으로 사용했으며 훌륭하게 실행됩니다.

나는 환경을 사용합니다 :

if os.environ.get('WEB_MODE', None) == 'production' :
   from settings_production import *
else :
   from settings_dev import *

결국 테스트 환경에 대한 특수 설정이 필요하고이 조건에 쉽게 추가 할 수 있기 때문에 이것이 훨씬 더 나은 접근 방식이라고 생각합니다.

이것은 오래된 게시물이지만 유용하게 추가하면 library일이 단순화 될 것이라고 생각합니다 .

사용 장고 구성을

빠른 시작

pip install django-configurations

그런 다음 프로젝트의 settings.py 또는 설정 상수를 저장하는 데 사용하는 다른 모듈에 포함 된 configuration.Configuration 클래스를 하위 클래스로 지정합니다. 예 :

# mysite/settings.py

from configurations import Configuration

class Dev(Configuration):
    DEBUG = True

DJANGO_CONFIGURATION환경 변수를 방금 만든 클래스의 이름으로 설정합니다 . 예 ~/.bashrc:

export DJANGO_CONFIGURATION=Dev

그리고 DJANGO_SETTINGS_MODULE평소와 같이 모듈 가져 오기 경로에 대한 환경 변수 (예 : bash) :

export DJANGO_SETTINGS_MODULE=mysite.settings

또는--configuration Django의 기본 --settings명령 줄 옵션을 따라 Django 관리 명령을 사용할 때 옵션을 제공합니다 . 예 :

python manage.py runserver --settings=mysite.settings --configuration=Dev

Django가 구성을 사용할 수 있도록하려면 이제 manage.py 또는 wsgi.py 스크립트 를 수정하여 적절한 시작 기능의 django-configurations 버전을 사용해야합니다. 예를 들어 django-configurations를 사용 하는 일반적인 manage.py 는 다음과 같습니다.

#!/usr/bin/env python

import os
import sys

if __name__ == "__main__":
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
    os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

    from configurations.management import execute_from_command_line

    execute_from_command_line(sys.argv)

10 행에서 우리는 공통 도구를 사용하지 않고 django.core.management.execute_from_command_line대신 configurations.management.execute_from_command_line.

wsgi.py 파일 에도 동일하게 적용됩니다 . 예 :

import os

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

from configurations.wsgi import get_wsgi_application

application = get_wsgi_application()

여기서는 기본 django.core.wsgi.get_wsgi_application함수를 사용하지 않고 대신 configurations.wsgi.get_wsgi_application.

그게 다야! 이제 manage.py 및 선호하는 WSGI 지원 서버에서 프로젝트를 사용할 수 있습니다 .

실제로 개발 및 프로덕션 환경에 대해 동일한 (또는 거의 동일한) 구성을 갖는 것을 고려해야합니다. 그렇지 않으면 "내 컴퓨터에서 작동합니다"와 같은 상황이 때때로 발생합니다.

따라서 배포를 자동화하고 WOMM 문제를 제거하려면 Docker를 사용하십시오 .