Как управлять локальными и производственными настройками в Django?

Question

Каков рекомендуемый способ обработки настроек для локальной разработки и рабочего сервера? Некоторые из них (например, константы и т. Д.) Могут быть изменены / доступны в обоих, но некоторые из них (например, пути к статическим файлам) должны оставаться разными и, следовательно, не должны перезаписываться при каждом развертывании нового кода.

В настоящее время я добавляю все константы к settings.py. Но каждый раз, когда я изменяю некоторую константу локально, мне приходится копировать ее на рабочий сервер и редактировать файл для конкретных производственных изменений ... :(

Редактировать: похоже, что нет стандартного ответа на этот вопрос, я принял самый популярный метод.

Answer 1

Мое решение этой проблемы также представляет собой сочетание некоторых решений, уже заявленных здесь:

• У меня есть файл с именем local_settings.py, в котором содержится USING_LOCAL = True в dev и USING_LOCAL = False в prod
• В settings.py я выполняю импорт этого файла, чтобы получить USING_LOCAL значение

Затем я основываю все свои зависящие от среды настройки на этом:

DEBUG = USING_LOCAL
if USING_LOCAL:
    # dev database settings
else:
    # prod database settings

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

Конечно, каждый метод имеет свои недостатки, и этот не исключение. Проблема здесь в том, что я не могу перезаписать файл local_settings.py всякий раз, когда отправляю свои изменения в производство, то есть я не могу просто копировать все файлы вслепую, но я могу жить с этим.

Answer 2

Для большинства моих проектов я использую следующую схему:

1. Создайте settings_base.py, где я храню настройки, общие для всех сред
2. Всякий раз, когда мне нужно использовать новую среду с особыми требованиями, я создаю новый файл настроек (например, settings_local.py), который наследует содержимое settings_base.py и переопределяет / добавляет соответствующие переменные настроек (from settings_base import *)

(Для запуска manage.py с файлом пользовательских настроек вы просто используете параметр команды --settings: manage.py <command> --settings=settings_you_wish_to_use.py)

Answer 3

Есть также Django Classy Settings. Я лично большой поклонник этого. Он построен одним из самых активных людей в IRC Django. Вы должны использовать переменные окружения для установки вещей.

http://django -classy-settings.readthedocs.io / ен / последний /

Answer 4

Я использую вариант из упомянутых выше jpartogi, который я считаю немного короче:

import platform
from django.core.management import execute_manager 

computername = platform.node()

try:
  settings = __import__(computername + '_settings')
except ImportError: 
  import sys
  sys.stderr.write("Error: Can't find the file '%r_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file local_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % (computername, __file__))
  sys.exit(1)

if __name__ == "__main__":
  execute_manager(settings)

В основном на каждом компьютере (в разработке или производстве) у меня есть соответствующий файл hostname_settings.py, который загружается динамически.

Answer 5

Чтобы использовать другую конфигурацию settings в другой среде, создайте другой файл настроек. А в вашем сценарии развертывания запустите сервер, используя параметр --settings=<my-settings.py>, с помощью которого вы можете использовать различные настройки в другой среде.

Преимущества использования этого подхода :

1. Ваши настройки будут модульными в зависимости от каждой среды

2. Вы можете импортировать master_settings.py, содержащий базовую конфигурацию в environmnet_configuration.py и переопределить значения, которые вы хотите изменить в этой среде.

3. Если у вас огромная команда, у каждого разработчика может быть свой local_settings.py, который они могут добавить в репозиторий кода без риска изменения конфигурации сервера. Вы можете добавить эти локальные настройки к .gitnore, если вы используете git или .hginore, если вы Mercurial для Контроль версий (или любой другой). Таким образом, локальные настройки даже не будут частью реальной базы кода, поддерживающей его в чистоте.

Answer 6

Мои настройки были разделены следующим образом

settings/
     |
     |- base.py
     |- dev.py
     |- prod.py  

У нас есть 3 среды

• DEV
• постановка
• производство

Теперь, очевидно, постановка и производство должны иметь максимально возможную схожую среду. Таким образом, мы сохранили prod.py для обоих.

Но был случай, когда мне пришлось идентифицировать работающий сервер - это рабочий сервер. @T. Ответ Стоуна помог мне написать чек следующим образом.

from socket import gethostname, gethostbyname  
PROD_HOSTS = ["webserver1", "webserver2"]

DEBUG = False
ALLOWED_HOSTS = [gethostname(), gethostbyname(gethostname()),]


if any(host in PROD_HOSTS for host in ALLOWED_HOSTS):
    SESSION_COOKIE_SECURE = True
    CSRF_COOKIE_SECURE = True  

Answer 7

1 - Создайте новую папку внутри вашего приложения и присвойте ей настройки.

2 - Теперь создайте в нем новый init .py файл, а внутри него напишите

    from .base import *

    try:

        from .local import *

    except:

        pass

     try:

         from .production import *

     except:

         pass

3 - Создайте три новых файла в папке настроек с именем local.py и production.py и base.py

4 - Внутри base.py скопируйте все содержимое предыдущей папки settings.p и переименуйте его, используя другое имя, скажем old_settings.py

5 - В файле base.py измените путь BASE_DIR, чтобы он указывал на новый путь установки

Старый путь-> BASE_DIR = os.path.dirname (os.path.dirname (os.path.abspath ( file )))

Новый путь -> BASE_DIR = os.path.dirname (os.path.dirname (os.path.dirname (os.path.abspath ( file ))) *

теперь, таким образом, каталог проекта может быть структурирован и может управляться в рамках производства и местного развития.

Answer 8

В качестве альтернативы для сохранения другого файла, если вы: Если вы используете git или любую другую VCS для передачи кодов с локального на сервер, вы можете просто добавить файл настроек в .gitignore.

Это позволит вам без проблем иметь разный контент в обоих местах. Таким образом, на сервере вы можете настроить независимую версию settings.py, и любые изменения, сделанные на локальном компьютере, не будут отражаться на сервере и наоборот.

Кроме того, он также удалит файл settings.py из github, что является большой ошибкой, которую, как я видел, делают многие новички.

Answer 9

Я различаю его в manage.py и создал два отдельных файла настроек: local_settings.py и prod_settings.py.

В manage.py я проверяю, является ли сервер локальным или рабочим сервером. Если это локальный сервер, он загружает local_settings.py, а это рабочий сервер, он загружает prod_settings.py. В основном это выглядит так:

#!/usr/bin/env python
import sys
import socket
from django.core.management import execute_manager 

ipaddress = socket.gethostbyname( socket.gethostname() )
if ipaddress == '127.0.0.1':
    try:
        import local_settings # Assumed to be in the same directory.
        settings = local_settings
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'local_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file local_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)
else:
    try:
        import prod_settings # Assumed to be in the same directory.
        settings = prod_settings    
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'prod_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file prod_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)

if __name__ == "__main__":
    execute_manager(settings)

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

Answer 10

Создание нескольких версий файла settings.py - это шаблон для 12 Factor App методологии . используйте взамен python-decouple или django-environment .