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

WinMerge - инструмент (FOSS) Diff с объединяющимися возможностями

Примечание: FOSS - Бесплатное Программное обеспечение с открытым исходным кодом

284
задан fifi finance 16 October 2016 в 10:04
поделиться

6 ответов

In settings.py :

try:
    from local_settings import *
except ImportError as e:
    pass

Вы можете переопределить то, что необходимо в local_settings. py ; тогда он должен оставаться вне вашего контроля версий. Но поскольку вы упомянули о копировании, я предполагаю, что вы ничего не используете;)

127
ответ дан 23 November 2019 в 01:52
поделиться

Помните, что settings.py - это файл живого кода. Предполагая, что у вас нет DEBUG, установленного в производственной среде (что является наилучшей практикой), вы можете сделать что-то вроде:

if DEBUG:
    STATIC_PATH = /path/to/dev/files
else:
    STATIC_PATH = /path/to/production/files

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

4
ответ дан 23 November 2019 в 01:52
поделиться

Я использую слегка измененную версию стиля настроек «if DEBUG», который опубликовал Харпер Шелби. Очевидно, что в зависимости от среды (win / linux / и т. Д.) Код может потребоваться немного подправить.

Раньше я использовал «if DEBUG», но обнаружил, что иногда мне нужно проводить тестирование с набором DEUBG к False. Я действительно хотел различать, является ли среда производственной или разрабатываемой, что дало мне свободу выбора уровня DEBUG.

PRODUCTION_SERVERS = ['WEBSERVER1','WEBSERVER2',]
if os.environ['COMPUTERNAME'] in PRODUCTION_SERVERS:
    PRODUCTION = True
else:
    PRODUCTION = False

DEBUG = not PRODUCTION
TEMPLATE_DEBUG = DEBUG

# ...

if PRODUCTION:
    DATABASE_HOST = '192.168.1.1'
else:
    DATABASE_HOST = 'localhost'

Я все еще считаю этот способ настройки незавершенным. Я не видел ни одного способа обработки настроек Django, который бы охватывал все основы и в то же время не представлял особых хлопот для настройки (я не отказывался от методов файлов настроек 5x).

20
ответ дан 23 November 2019 в 01:52
поделиться

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

Когда вы используете mod_python / mod_wsgi для своего проекта Django, вам нужно указать его на свой файл настроек . Если вы укажете его на app / settings_local.py на вашем локальном сервере и app / settings_production.py на вашем производственном сервере, тогда жизнь станет легкой. Просто отредактируйте соответствующий файл настроек и перезапустите сервер (сервер разработки Django перезапустится автоматически).

14
ответ дан 23 November 2019 в 01:52
поделиться

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

  • Я храню файл с именем 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, которые мне нужно поддерживать, поскольку я могу упростить структуру моих настроек в одном файле чем распространение их на несколько файлов. Таким образом, когда я обновляю параметр, я не забываю сделать это для обеих сред.

Конечно, у каждого метода есть свои недостатки, и этот не является исключением.

3
ответ дан 23 November 2019 в 01:52
поделиться

Я различаю его в 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 внутри файла настроек.

1
ответ дан 23 November 2019 в 01:52
поделиться
Другие вопросы по тегам:

Похожие вопросы: