it-source

장고: 개발 및 생산 설정을 어떻게 관리합니까?

criticalcode 2023. 6. 6. 00:02
반응형

장고: 개발 및 생산 설정을 어떻게 관리합니까?

저는 기본 앱을 개발하고 있습니다.이제 구축 단계에서는 로컬 설정과 프로덕션 설정이 모두 필요하다는 것이 분명해졌습니다.

다음 사항을 알아두면 좋을 것 같습니다.

  • 개발 및 프로덕션 설정을 가장 잘 처리하는 방법.
  • django-debug-toolbar 등의 앱을 개발 환경에서만 유지하는 방법
  • 개발 및 배포 설정에 대한 기타 팁 및 모범 사례.

환경 변수는 Django가 로드할 설정 파일을 제어합니다.

각 별도의 할 수 있습니다( 두 모두 생성할 수 ).import * 설정"에서, "공유 설정" 파일)을 사용합니다.DJANGO_SETTINGS_MODULE어떤 것을 사용할지 제어합니다.

방법:

Django 설명서에 명시된 대로:

DJANO_SETTINGS_MODULE의 값은 mysite와 같은 Python 경로 구문에 있어야 합니다.설정.설정 모듈은 Python 가져오기 검색 경로에 있어야 합니다.

그럼, 당신이 창조했다고 가정해 보겠습니다.myapp/production_settings.py그리고.myapp/test_settings.py소스 저장소에 있습니다.

그 경우, 당신은 각각 다음과 같이 설정할 것입니다.DJANGO_SETTINGS_MODULE=myapp.production_settings와 자와를 DJANGO_SETTINGS_MODULE=myapp.test_settings후자를 사용합니다.


여기서부터, 문제는 설정으로 귀결됩니다.DJANGO_SETTINGS_MODULE환경 변수입니다.

DJANGO_SETTINGS_MODULE

설정을 시작하기 할 수 .export DJANGO_SETTINGS_MODULE=myapp.production_settings.

셸에서 이 내보내기를 언제든지 실행할 수 있습니다. 이 내보내기는 사용자의 작업 환경에 저장할 필요가 없습니다..bashrc뭐 그런 거.

DJANGO_SETTINGS_MODULE 관리자

환경을 설정하는 부트스트랩 스크립트를 작성하는 것을 좋아하지 않는다면(그리고 그렇게 느낄 수 있는 아주 좋은 이유가 있습니다!), 프로세스 관리자를 사용하는 것을 추천합니다.


마지막으로, 다음과 같은 이점을 활용할 수 있습니다.PYTHONPATH 프로덕션 서버에 )/etc/이렇게 하면 응용 프로그램 파일에서 구성을 분리할 수 있습니다.당신은 그것을 원할 수도 있고 원하지 않을 수도 있습니다. 그것은 당신의 앱이 어떻게 구성되어 있는지에 달려 있습니다.

설정을 하지만 파일 은 " " " 입니다." 입니다.settings_dev.py귀하의 사와동폴과 .settings.py 일파와 합니다. 다음과 같은 재정의를 추가합니다.DEBUG=True.

의 개에사컴서이에당것컴추요에 이것을 하세요.~/.bashrc파일 이름:

export DJANGO_DEVELOPMENT=true

또는 명령 앞에 다음과 같이 입력하여 한 번만 켭니다.

DJANGO_DEVELOPMENT=true python manage.py runserver

▁의 맨 에.settings.py파일, 다음을 추가합니다.

# Override production variables if DJANGO_DEVELOPMENT env variable is true
if os.getenv('DJANGO_DEVELOPMENT') == 'true':
    from settings_dev import *  # or specific overrides

(가져기항목오)) *일반적으로 Python에서는 피해야 합니다.)

기본적으로 프로덕션 서버는 아무것도 재정의하지 않습니다.알았어!

답들에 , 이 에 더 .PYTHONPATH 또는설정정을 설정DJANGO_SETTINGS_MODULE한 번에 하나의 장고 프로젝트만 수행할 수 있습니다.

다음은 간단한 6단계로 수행한 방법입니다.

  1. 를 만들고 합니다.settings.

    프로젝트 구조:

    myproject/
           myapp1/
           myapp2/              
           myproject/
                  settings/
    
  2. 에 4의파생성 파일 settings 즉, 디토리즉렉,__init__.py,base.py,dev.py그리고.prod.py

    설정 파일:

    settings/
         __init__.py
         base.py
         prod.py
         dev.py 
    
  3. 을 엽니다.__init__.py다음 내용으로 채웁니다.

    init.py :

    from .base import *
    # you need to set "myproject = 'prod'" as an environment variable
    # in your OS (on which your website is hosted)
    if os.environ['myproject'] == 'prod':
       from .prod import *
    else:
       from .dev import *
    
  4. 을 엽니다.base.py다음과 같은 모든 공통 설정(생산 및 개발 모두에 사용됨)을 입력합니다.

    base.py :

    import os
    ...
    INSTALLED_APPS = [...]
    MIDDLEWARE = [...]
    TEMPLATES = [{...}]
    ...
    STATIC_URL = '/static/'
    STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
    MEDIA_ROOT = os.path.join(BASE_DIR, '/path/')
    MEDIA_URL = '/path/'
    
  5. 을 엽니다.dev.py그리고 다음과 같은 개발에 특화된 것들을 포함합니다.

    dev.py :

    DEBUG = True
    ALLOWED_HOSTS = ['localhost']
    ...
    
  6. 을 엽니다.prod.py그리고 다음과 같은 생산에 특화된 것들을 포함합니다.

    prod.py :

    DEBUG = False
    ALLOWED_HOSTS = ['www.example.com']
    LOGGING = [...]
    ...
    

갱신하다

ANDRESMA가 댓글로 제안한 것처럼.BASE_DIR의 신의에base.py된 경로를 입니다..parent들어 다음과 같습니다.예:

BASE_DIR = Path(__file__).resolve().parent.parent.parent

일반적으로 환경당 하나의 설정 파일과 공유 설정 파일이 있습니다.

/myproject/
  settings.production.py
  settings.development.py
  shared_settings.py

각 환경 파일에는 다음이 있습니다.

try:
    from shared_settings import *
except ImportError:
    pass

이렇게 하면 필요한 경우 해당 스탠자 아래에 수정 사항을 추가하여 공유 설정을 재정의할 수 있습니다.

그런 다음 사용할 설정 파일을 설정에 연결하여 선택합니다.py:

ln -s settings.development.py settings.py

멋진 장고 구성을 사용하고 모든 설정이 내 컴퓨터에 저장됩니다.settings.py:

from configurations import Configuration

class Base(Configuration):
    # all the base settings here...
    BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
    ...

class Develop(Base):
    # development settings here...
    DEBUG = True 
    ...

class Production(Base):
    # production settings here...
    DEBUG = False

장고 프로젝트를 구성하기 위해 문서를 따라갔습니다.

개의 러개만기를 만듭니다.settings*.py환경별로 변경해야 하는 변수를 추정하는 파일입니다.그리고 당신의 주인의 마지막에settings.py파일 이름:

try:
  from settings_dev import *
except ImportError:
  pass

당신은 따로따로.settings_*각 단계에 대한 파일.

에의 맨 settings_dev.py을 추가합니다.

import sys
globals().update(vars(sys.modules['settings']))

수정해야 하는 변수를 가져옵니다.

Wiki 항목에는 설정을 분할하는 방법에 대한 자세한 내용이 나와 있습니다.

우리가 사용하는 접근 방식은 다음과 같습니다.

  • a settings을 위해 가독성을 위한 모듈;
  • a .env.jsonGit 저장소에서 제외하거나 환경별 자격 증명 및 매개 변수를 저장할 파일.
  • 하나의env.py을 읽을 수 .env.json

다음 구조를 고려할 때:

...
.env.json           # the file containing all specific credentials and parameters
.gitignore          # the .gitignore file to exclude `.env.json`
project_name/       # project dir (the one which django-admin.py creates)
  accounts/         # project's apps
    __init__.py
    ...
  ...
  env.py            # the file to load credentials
  settings/
    __init__.py     # main settings file
    database.py     # database conf
    storage.py      # storage conf
    ...
venv                # virtualenv
...

와 함께.env.json예:예:

{
    "debug": false,
    "allowed_hosts": ["mydomain.com"],
    "django_secret_key": "my_very_long_secret_key",
    "db_password": "my_db_password",
    "db_name": "my_db_name",
    "db_user": "my_db_user",
    "db_host": "my_db_host",
}

그리고.project_name/env.py:

<!-- language: lang-python -->
import json
import os


def get_credentials():
    env_file_dir = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
    with open(os.path.join(env_file_dir, '.env.json'), 'r') as f:
        creds = json.loads(f.read())
    return creds


credentials = get_credentials()

다음 설정을 사용할 수 있습니다.

<!-- language: lang-py -->
# project_name/settings/__init__.py
from project_name.env import credentials
from project_name.settings.database import *
from project_name.settings.storage import *
...

SECRET_KEY = credentials.get('django_secret_key')

DEBUG = credentials.get('debug')

ALLOWED_HOSTS = credentials.get('allowed_hosts', [])

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    ...
]

if DEBUG:
    INSTALLED_APPS += ['debug_toolbar']

...

# project_name/settings/database.py
from project_name.env import credentials

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': credentials.get('db_name', ''),
        'USER': credentials.get('db_user', ''),
        'HOST': credentials.get('db_host', ''),
        'PASSWORD': credentials.get('db_password', ''),
        'PORT': '5432',
    }
}

이 솔루션의 이점은 다음과 같습니다.

  • git 저장소를 수정하지 않고 로컬 개발을 위한 사용자별 자격 증명 및 구성
  • 환경별 구성, 예를 들어 3개의 서로 다른 환경을 사용할 수 있습니다..env.jsondev, and 발스깅, 태작및제같것은과개것▁dev.
  • 자격 증명이 리포지토리에 없습니다.

도움이 되었으면 합니다. 이 솔루션에 대한 주의 사항이 있으면 알려 주십시오.

사용하다settings.py에 를 생성합니다.settings_dev.py오버라이드의 경우.

# settings_dev.py

from .settings import * 

DEBUG = False

개발 컴퓨터에서 다음을 사용하여 장고 앱을 실행합니다.

DJANGO_SETTINGS_MODULE=<your_app_name>.settings_dev python3 manage.py runserver

에서는 Prod를 방금 됩니다.settings.py그리고 그 외 아무것도 없다.

이점

  1. settings.py(운영 환경에 사용됨)는 다른 환경도 존재한다는 사실에 전혀 영향을 미치지 않습니다.
  2. prod와 dev의 차이를 보려면 한 곳만 들여다보면 됩니다.settings_dev.py 곳에 흩어져 있는 구성을 가 없습니다.settings_prod.py,settings_dev.py그리고.settings_shared.py.
  3. 프로덕션 문제를 해결한 후 누군가가 prod 구성에 설정을 추가하는 경우, 명시적으로 재정의되지 않는 한 개발 구성에도 설정이 표시됩니다.따라서 서로 다른 구성 파일 간의 차이가 최소화됩니다.

다음 파일 구조를 사용합니다.

project/
   ...
   settings/
   settings/common.py
   settings/local.py
   settings/prod.py
   settings/__init__.py -> local.py

그렇게__init__.py 또는 windows의 입니다.local.py또는 할 수 있습니다.prod.py 그서그 에 있습니다.project.settings, 하려면 환경 변수인 깨고구하있어으성며되특정구, 환변사수다있용수니습할경를면사려모를 .DJANGO_SETTINGS_MODULEproject.settings.prod운영 환경에 대한 명령을 실행해야 하는 경우

에 있습니다.prod.py그리고.local.py:

from .shared import *

DATABASE = {
    ...
}

리고그고.shared.py파일은 특정 구성 없이 글로벌로 유지됩니다.

cs01의 답변 구축:

환경 변수에 문제가 있는 경우 해당 값을 문자열로 설정합니다.DJANGO_DEVELOPMENT="true").

cs01의 파일 워크플로우도 다음과 같이 변경하였습니다.

#settings.py
import os
if os.environ.get('DJANGO_DEVELOPMENT') is not None:
    from settings_dev import * 
else:
    from settings_production import *
#settings_dev.py
development settings go here
#settings_production.py
production settings go here

이렇게 하면 장고는 적절한 설정 파일을 실행하기 전에 설정 파일 전체를 읽을 필요가 없습니다.이 솔루션은 프로덕션 파일에 프로덕션 서버에만 있는 항목이 필요한 경우 유용합니다.

참고: Python 3에서 가져온 파일은 다음과 같아야 합니다..첨부(예:from .settings_dev import *)

1개의 설정 파일을 유지하려는 경우 개발 운영 체제가 운영 운영 운영 체제와 다르다면 설정의 맨 아래에 이 파일을 둘 수 있습니다.py:

from sys import platform
if platform == "linux" or platform == "linux2":
    # linux
    # some special setting here for when I'm on my prod server
elif platform == "darwin":
    # OS X
    # some special setting here for when I'm developing on my mac
elif platform == "win32":
    # Windows...
    # some special setting here for when I'm developing on my pc

자세히 보기:파이썬에서 운영체제를 확인하려면 어떻게 해야 합니까?

현재 Git 브랜치를 기반으로 설정, 비밀, 환경 변수 등을 전환할 수 있고 다른 설정 파일에 의존하는 것은 괜찮지만 엔터프라이즈 상황에서는 중요한 정보를 모두 repo에서 숨기고자 합니다.모든 환경 변수, 모든 환경의 비밀(개발, 스테이징, 프로덕션, QA 등)을 모든 개발자에게 노출하는 것은 최상의 보안 모범 사례가 아닙니다.다음은 2를 달성해야 합니다.

  1. 배포 환경에 따라 설정 분리
  2. gitrepo에서 중요한 정보 숨기기

나의 run.sh

#!/bin/bash
# default environment
export DJANGO_ENVIRONMENT="develop"
BRANCH=$(git rev-parse --abbrev-ref HEAD)

if [ $BRANCH == "main" ]; then
    export DJANGO_ENVIRONMENT="production"
elif [ $BRANCH == "release/"* ]; then
    export DJANGO_ENVIRONMENT="staging"
else
    # for all other branches (feature, support, hotfix etc.,)
    echo ''
fi

echo "
BRANCH: $BRANCH
ENVIRONMENT: $DJANGO_ENVIRONMENT
"
python3 myapp/manage.py makemigrations
python3 myapp/manage.py migrate --noinput
python3 myapp/manage.py runserver 0:8000

django의 settings.py 과 동일한 폴더에 있는 내 vars.py (또는 secrets.py 또는 어떤 이름이든)

vars = {
    'develop': {
        'environment': 'develop',
        'SECRET_KEY': 'mysecretkey',
        "DEBUG": "True"
        },
    'production': {
        'environment': 'production',
        'SECRET_KEY': 'mysecretkey',
        "DEBUG": "False"
        },
    'staging': {
        'environment': 'staging',
        'SECRET_KEY': 'mysecretkey',
        "DEBUG": "True"
        }
    }

그런 다음 settings.py 에서 다음을 수행합니다.

from . import vars # container environment specific vars
import os

DJANGO_ENVIRONMENT = os.getenv("DJANGO_ENVIRONMENT")  # declared in run.sh
envs = vars.vars[DJANGO_ENVIRONMENT] # SECURITY WARNING: keep the secret key 
used in production secret!
SECRET_KEY = envs["SECRET_KEY"]

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = envs["DEBUG"]

개발자들이 로컬 컴퓨터에 자신의 vars.py 을 가지고 있도록 하지만 배포하는 동안 cicd 파이프라인은 실제 값을 가진 실제 vars.py 을 삽입하거나 일부 스크립트가 삽입해야 합니다.gitlab cicd를 사용하는 경우 전체 vars.py 을 환경 변수로 저장할 수 있습니다.

이것은 해결된 것으로 보이지만, 버전 제어와 결합하여 사용하는 방법은 다음과 같습니다.

.gitignore에 추가하는 로컬 개발 환경의 설정과 동일한 디렉토리에 env.py 파일을 설정합니다.

env.py :

#!usr/bin/python

DJANGO_ENV = True
ALLOWED_HOSTS = ['127.0.0.1', 'dev.mywebsite.com']

.gitignore:

mywebsite/env.py

설정.py:

if os.path.exists(os.getcwd() + '/env.py'):
    #env.py is excluded using the .gitignore file - when moving to production we can automatically set debug mode to off:
    from env import *
else:
    DJANGO_ENV = False

DEBUG = DJANGO_ENV

저는 이것이 작동하고 훨씬 더 우아하다는 것을 알게 되었습니다. env.py 을 사용하면 로컬 환경 변수를 쉽게 확인할 수 있고 여러 개의 settings.py 파일 등이 없어도 이 모든 것을 처리할 수 있습니다.이 방법을 사용하면 프로덕션 서버에 설정하지 않을 모든 종류의 로컬 환경 변수를 사용할 수 있습니다.버전 제어를 통해 .gitignore를 활용하여 모든 것을 원활하게 통합할 수 있습니다.

파일 설정 문제로 복사하기로 했습니다.

Project
   |---__init__.py   [ write code to copy setting file from subdir to current dir]
   |---settings.py  (do not commit this file to git)
   |---setting1_dir
   |         |--  settings.py
   |---setting2_dir
   |         |--  settings.py

장고를 실행하면 __init__py가 실행됩니다. 이때,settings.py in setting1_dir대할것다니입을 입니다.settings.py in Project.

어떻게 다른 환경을 선택합니까?

  • 수정하다, 수정하다, 수정하다, 수정하다, 수정하다, 수정하다__init__.py직접적으로.
  • . bash 파일을 만듭니다.__init__.py.
  • env를 사용하도록 하십시오.__init__.py이 변수를 읽습니다.

왜 이런 방법을 사용합니까?

동일한 디렉터리에 있는 파일이 너무 많은 것을 좋아하지 않기 때문에 너무 많은 파일은 다른 파트너를 혼란스럽게 하고 IDE에 적합하지 않습니다.(IDE에서 사용하는 파일을 찾을 수 없음)

이러한 세부 정보를 모두 표시하지 않으려면 프로젝트를 두 부분으로 나눌 수 있습니다.

  1. 프로젝트 설정을 위해 Spring Initializr과 같은 작은 도구를 만듭니다. (파일 복사와 같은 작업)
  2. 프로젝트 코드

구글 클라우드 앱 엔진에서 환경 간 구성을 변경하기 위해 다른 app.yaml 파일을 사용하고 있습니다.

이를 사용하여 터미널 명령에 프록시 연결을 만들 수 있습니다.

./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:1433

https://cloud.google.com/sql/docs/sqlserver/connect-admin-proxy#macos-64-bit

파일: app.yaml

# [START django_app]
service: development
runtime: python37

env_variables:
  DJANGO_DB_HOST: '/cloudsql/myproject:myregion:myinstance'
  DJANGO_DEBUG: True

handlers:
# This configures Google App Engine to serve the files in the app's static
# directory.
- url: /static
  static_dir: static/

# This handler routes all requests not caught above to your main app. It is
# required when static routes are defined, but can be omitted (along with
# the entire handlers section) when there are no static files defined.
- url: /.*
  script: auto
# [END django_app]

저는 프로덕션의 작업 디렉터리에 "production"이라는 이름의 파일을 만듭니다.

#settings.py
production = Path("production")
DEBUG = False

#if it's dev mode
if not production.is_file():
    INSTALLED_APPS +=[
       #apps_in_development_mode,
       #...
    ]
    DEBUG = True
    #other settings to override the default production settings

당신은 아마 wsgi를 사용할 것입니다.프로덕션용 py 파일(이 파일은 django 프로젝트를 만들 때 자동으로 생성됨).이 파일은 설정 파일을 가리킵니다.따라서 별도의 생산 설정 파일을 만들어 wsgi에 참조하십시오.파이 줄

여기서는 각 환경에 대한 .ENV 파일을 사용합니다.에는 이파에다같변은많있이습다와 같은 변수가 .ENV=development

.py으로 설정과 같은입니다.py 파일은 기본적으로 다음과 같은 os.environment.get.gets입니다.ENV = os.environ.get('ENV')

액세스가 필요할 때 사용할 수 있습니다.ENV = settings.ENV.

생산, 테스트, 개발을 위해서는 .env 파일이 있어야 합니다.

개발, 테스트 및 운영 환경이 서로 다른 솔루션입니다.

import socket

[...]

DEV_PC = 'PC059'
host_name = socket.gethostname()

if host_name == DEV_PC:
   #do something
   pass
elif [...]

언급URL : https://stackoverflow.com/questions/10664244/django-how-to-manage-development-and-production-settings

반응형