Нормально ли иметь файл настроек для каждого экземпляра / версии постановки в проекте Django?

Question

Некоторые люди используют только один файл настроек для своего проекта. Хорошей альтернативой является написание модулей, заменив один файл настроек каталогом с конфигурациями для каждой конкретной потребности:

...    
|    
settings    
|    
|-base.py    
|-local.py    
|-local_alex.py    
|-production.py    
|-staging.py    
|-test.py   

Полагаю, нормально иметь один файл настроек для производства.

Но что произойдет, если у меня будет больше инсценировок / версий? Предположим, у меня есть база данных postgresql для каждого промежуточного экземпляра / среды. Можно ли иметь больше промежуточных файлов? Или я должен по-разному относиться к различиям между постановочными версиями?

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

Какой рекомендуемый подход?

DjangoTwoScoops рекомендует иметь больше файлов настроек local.py, но никто не упоминает о нескольких промежуточных файлах.

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

DATABASES = {  
    'default': {    
        ...   
        'NAME': 'dbname1',    
        'USER': 'username1',   
       ...    
    }   
}    

and the second one:

DATABASES = {    
    'default': {    
        ...   
        'NAME': 'dbname2',   
        'USER': 'username2',   
       ...     
    }     
}   

Answer 1

Рекомендуется использовать файл базовых настроек для определения общих настроек, которые могут быть переопределены переменными среды. Таким образом, настройки вашей базы данных могут выглядеть так:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'HOST': os.environ.get('DATABASE_HOST', 'localhost'),
        'PORT': os.environ.get('DATABASE_PORT', '3306'),
        'USER': os.environ.get('DATABASE_USER', 'root'),
        'PASSWORD': os.environ.get('DATABASE_PASSWORD', ''),
        'NAME': os.environ.get('DATABASE_NAME'),
    },
}

Пример, который вы предоставили, является хорошей практикой, но я бы избегал конкретных файлов для человека или, если можно, конкретных локальных настроек. Вместо этого посмотрите, есть ли переменные окружения для учета того, что иначе получило бы свой собственный файл настроек. Таким образом, меньше кода для поддержки и легко настраивается на каждом сервере / среде. Каждая среда, в которой работает ваш проект, будет определять DJANGO_SETTINGS_MODULE в переменных среды, чтобы сообщить django, какие настройки использовать.

Используйте специфические для среды файлы настроек для наследования базы, а затем включайте такие вещи, как ведение журнала и уведомления об ошибках, если вы подписываетесь на услугу, такую ​​как Sentry , которую вы не хотели бы интегрировать вне производства. Так что production.py может включать дополнительные настройки безопасности, которые вы захотите при работе в этой среде;

DEBUG = False

CSRF_COOKIE_SECURE = True
SESSION_COOKIE_SECURE = True

SECURE_BROWSER_XSS_FILTER = True
SECURE_CONTENT_TYPE_NOSNIFF = True
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = False

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

Answer 2

Если вы хотите, чтобы эти файлы отслеживались с помощью git, у вас на самом деле нет выбора - вы помещаете все общие настройки в один отслеживаемый файл (settings.py), настройки подключения для каждой среды в отдельный файл (settings_prod.py).), а затем получить доступ к ключам в одном неотслеживаемом состоянии (settings_local.py).

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