Django settings¶
A Django settings file contains all the configuration of your Django installation. This document explains how settings work and which settings are available.
The basics¶
A settings file is just a Python module with module-level variables.
Here are a couple of example settings:
If you set DEBUG to False , you also need to properly set the ALLOWED_HOSTS setting.
Because a settings file is a Python module, the following apply:
It doesn’t allow for Python syntax errors.
It can assign settings dynamically using normal Python syntax. For example:
It can import values from other settings files.
Designating the settings¶
When you use Django, you have to tell it which settings you’re using. Do this by using an environment variable, DJANGO_SETTINGS_MODULE .
The value of DJANGO_SETTINGS_MODULE should be in Python path syntax, e.g. mysite.settings . Note that the settings module should be on the Python import search path.
The django-admin utility¶
When using django-admin , you can either set the environment variable once, or explicitly pass in the settings module each time you run the utility.
Example (Unix Bash shell):
Example (Windows shell):
Use the —settings command-line argument to specify the settings manually:
On the server ( mod_wsgi )¶
In your live server environment, you’ll need to tell your WSGI application what settings file to use. Do that with os.environ :
Read the Django mod_wsgi documentation for more information and other common elements to a Django WSGI application.
Default settings¶
A Django settings file doesn’t have to define any settings if it doesn’t need to. Each setting has a sensible default value. These defaults live in the module django/conf/global_settings.py.
Here’s the algorithm Django uses in compiling settings:
Load settings from global_settings.py .
Load settings from the specified settings file, overriding the global settings as necessary.
Note that a settings file should not import from global_settings , because that’s redundant.
Seeing which settings you’ve changed¶
The command python manage.py diffsettings displays differences between the current settings file and Django’s default settings.
For more, see the diffsettings documentation.
Using settings in Python code¶
In your Django apps, use settings by importing the object django.conf.settings . Example:
Note that django.conf.settings isn’t a module – it’s an object. So importing individual settings is not possible:
Also note that your code should not import from either global_settings or your own settings file. django.conf.settings abstracts the concepts of default settings and site-specific settings; it presents a single interface. It also decouples the code that uses settings from the location of your settings.
Altering settings at runtime¶
You shouldn’t alter settings in your applications at runtime. For example, don’t do this in a view:
The only place you should assign to settings is in a settings file.
Security¶
Because a settings file contains sensitive information, such as the database password, you should make every attempt to limit access to it. For example, change its file permissions so that only you and your web server’s user can read it. This is especially important in a shared-hosting environment.
Available settings¶
For a full list of available settings, see the settings reference .
Creating your own settings¶
There’s nothing stopping you from creating your own settings, for your own Django apps, but follow these guidelines:
Setting names must be all uppercase.
Don’t reinvent an already-existing setting.
For settings that are sequences, Django itself uses lists, but this is only a convention.
Using settings without setting DJANGO_SETTINGS_MODULE ¶
In some cases, you might want to bypass the DJANGO_SETTINGS_MODULE environment variable. For example, if you’re using the template system by itself, you likely don’t want to have to set up an environment variable pointing to a settings module.
In these cases, you can configure Django’s settings manually. Do this by calling:
django.conf.settings. configure ( default_settings , ** settings ) ¶
Pass configure() as many keyword arguments as you’d like, with each keyword argument representing a setting and its value. Each argument name should be all uppercase, with the same name as the settings described above. If a particular setting is not passed to configure() and is needed at some later point, Django will use the default setting value.
Configuring Django in this fashion is mostly necessary – and, indeed, recommended – when you’re using a piece of the framework inside a larger application.
Consequently, when configured via settings.configure() , Django will not make any modifications to the process environment variables (see the documentation of TIME_ZONE for why this would normally occur). It’s assumed that you’re already in full control of your environment in these cases.
Custom default settings¶
If you’d like default values to come from somewhere other than django.conf.global_settings , you can pass in a module or class that provides the default settings as the default_settings argument (or as the first positional argument) in the call to configure() .
In this example, default settings are taken from myapp_defaults , and the DEBUG setting is set to True , regardless of its value in myapp_defaults :
The following example, which uses myapp_defaults as a positional argument, is equivalent:
Normally, you will not need to override the defaults in this fashion. The Django defaults are sufficiently tame that you can safely use them. Be aware that if you do pass in a new default module, it entirely replaces the Django defaults, so you must specify a value for every possible setting that might be used in the code you are importing. Check in django.conf.settings.global_settings for the full list.
Either configure() or DJANGO_SETTINGS_MODULE is required¶
If you’re not setting the DJANGO_SETTINGS_MODULE environment variable, you must call configure() at some point before using any code that reads settings.
If you don’t set DJANGO_SETTINGS_MODULE and don’t call configure() , Django will raise an ImportError exception the first time a setting is accessed.
If you set DJANGO_SETTINGS_MODULE , access settings values somehow, then call configure() , Django will raise a RuntimeError indicating that settings have already been configured. There is a property for this purpose:
Also, it’s an error to call configure() more than once, or to call configure() after any setting has been accessed.
It boils down to this: Use exactly one of either configure() or DJANGO_SETTINGS_MODULE . Not both, and not neither.
Calling django.setup() is required for “standalone” Django usage¶
If you’re using components of Django “standalone” – for example, writing a Python script which loads some Django templates and renders them, or uses the ORM to fetch some data – there’s one more step you’ll need in addition to configuring settings.
Настройки Django ¶
Файл настроек Django содержит всю конфигурацию вашей установки Django. В этом документе объясняется, как работают настройки и какие настройки доступны.
Основы ¶
Файл настроек — это просто модуль Python с переменными уровня модуля.
Вот несколько примеров настроек:
Если вы установили DEBUG значение False , вам также необходимо правильно установить ALLOWED_HOSTS настройку.
Поскольку файл настроек является модулем Python, применяется следующее:
Это не допускает синтаксических ошибок Python.
Он может назначать настройки динамически, используя обычный синтаксис Python. Например:
Он может импортировать значения из других файлов настроек.
Назначение настроек ¶
Когда вы используете Django, вы должны указать ему, какие настройки вы используете. Сделайте это с помощью переменной среды, DJANGO_SETTINGS_MODULE .
Значение DJANGO_SETTINGS_MODULE должен быть в синтаксисе пути Python, например mysite.settings . Обратите внимание, что модуль настроек должен находиться на пути поиска импорта Python .
django-admin Утилита ¶
При использовании django-admin вы можете либо установить переменную среды один раз, либо явно передавать модуль настроек при каждом запуске утилиты.
Пример (оболочка Unix Bash):
Пример (оболочка Windows):
Используйте —settings аргумент командной строки, чтобы указать настройки вручную:
На сервере ( mod_wsgi ) ¶
В среде реального сервера вам необходимо указать приложению WSGI, какой файл настроек использовать. Сделайте это с помощью os.environ :
Прочтите документацию Django mod_wsgi для получения дополнительной информации и других общих элементов приложения Django WSGI.
Настройки по умолчанию ¶
В файле настроек Django нет необходимости определять какие-либо настройки, если это не нужно. У каждой настройки есть разумное значение по умолчанию. Эти значения по умолчанию сохраняются в модуле django/conf/global_settings.py .
Вот алгоритм, который Django использует при компиляции настроек:
- Загрузить настройки из global_settings.py .
- Загрузите настройки из указанного файла настроек, при необходимости переопределив глобальные настройки.
Обратите внимание, что файл настроек не следует импортировать из global_settings , потому что он избыточен.
Как посмотреть, какие настройки вы изменили ¶
Команда отображает различия между текущим файлом настроек и настройками Django по умолчанию. python manage.py diffsettings
Для получения дополнительной информации см. diffsettings Документацию.
Использование настроек в коде Python ¶
В ваших приложениях Django используйте настройки, импортировав объект django.conf.settings . Пример:
Обратите внимание, что django.conf.settings это не модуль — это объект. Таким образом, импорт индивидуальных настроек невозможен:
Также обратите внимание, что ваш код не должен импортировать ни из global_settings вашего собственного файла настроек, ни из вашего. django.conf.settings абстрагирует концепции настроек по умолчанию и настроек для конкретного сайта; он представляет собой единый интерфейс. Он также отделяет код, использующий настройки, от местоположения ваших настроек.
Изменение настроек во время выполнения ¶
Вы не должны изменять настройки в ваших приложениях во время выполнения. Например, не делайте этого в представлении:
Единственное место, которое вы должны назначить настройкам, — это файл настроек.
Безопасность ¶
Поскольку файл настроек содержит конфиденциальную информацию, такую как пароль базы данных, вы должны делать все возможное, чтобы ограничить доступ к нему. Например, измените права доступа к файлу так, чтобы его могли читать только вы и пользователь вашего веб-сервера. Это особенно важно в среде общего хостинга.
Доступные настройки ¶
Полный список доступных настроек см. В справке по настройкам .
Создание собственных настроек ¶
Вам ничего не мешает создать свои собственные настройки для ваших собственных приложений Django, но следуйте этим рекомендациям:
- Имена настроек должны быть полностью прописными.
- Не изобретайте заново уже существующий сеттинг.
Для настроек, являющихся последовательностями, сам Django использует списки, но это всего лишь соглашение.
Использование настроек без настройки DJANGO_SETTINGS_MODULE ¶
В некоторых случаях может потребоваться обойти DJANGO_SETTINGS_MODULE переменная окружения. Например, если вы используете систему шаблонов отдельно, вы, вероятно, не захотите настраивать переменную среды, указывающую на модуль настроек.
В этих случаях вы можете настроить параметры Django вручную. Сделайте это, позвонив:
django.conf.settings. configure ( default_settings , ** настройки ) ¶
Передайте configure() столько аргументов ключевого слова, сколько хотите, причем каждый аргумент ключевого слова представляет параметр и его значение. Имя каждого аргумента должно быть написано заглавными буквами и иметь то же имя, что и настройки, описанные выше. Если конкретная настройка не передана configure() и понадобится позже, Django будет использовать значение настройки по умолчанию.
Подобная настройка Django в основном необходима — и даже рекомендуется — когда вы используете часть фреймворка внутри более крупного приложения.
Следовательно, при настройке с помощью settings.configure() Django не будет вносить никаких изменений в переменные среды процесса (см. Документацию о том, TIME_ZONE почему это обычно происходит). В таких случаях предполагается, что вы уже полностью контролируете свою среду.
Пользовательские настройки по умолчанию ¶
Если вы хотите, чтобы значения по умолчанию поступали откуда-то, кроме django.conf.global_settings , вы можете передать модуль или класс, который предоставляет настройки по умолчанию в качестве default_settings аргумента (или первого позиционного аргумента) при вызове configure() .
В этом примере настройки по умолчанию взяты из myapp_defaults , и для DEBUG параметра установлено значение True , независимо от его значения в myapp_defaults :
Следующий пример, который используется myapp_defaults в качестве позиционного аргумента, эквивалентен:
Обычно вам не нужно переопределять значения по умолчанию таким образом. Значения по умолчанию в Django достаточно просты, чтобы их можно было безопасно использовать. Имейте в виду, что если вы передадите новый модуль по умолчанию, он полностью заменит значения по умолчанию Django, поэтому вы должны указать значение для всех возможных параметров, которые могут использоваться в этом коде, который вы импортируете. Проверьте django.conf.settings.global_settings полный список.
Либо configure() либо DJANGO_SETTINGS_MODULE требуется ¶
Если вы не устанавливаете DJANGO_SETTINGS_MODULE переменную среды, вы должны вызвать ее configure() в какой-то момент, прежде чем использовать любой код, считывающий настройки.
Если вы не установите DJANGO_SETTINGS_MODULE и не вызывать configure() , Django вызовет ImportError исключение при первом обращении к параметру.
Если вы установите DJANGO_SETTINGS_MODULE , получить доступ к значениям параметров каким-либо образом, затем вызовите configure() Django, чтобы RuntimeError указать, что параметры уже настроены. Для этого есть свойство:
Кроме того, ошибкой является вызов configure() более одного раза или вызов configure() после доступа к любой настройке.
Это сводится к следующему: используйте ровно одно из configure() или DJANGO_SETTINGS_MODULE . Ни то, ни другое.
Вызов django.setup() необходим для «автономного» использования Django ¶
Если вы используете компоненты Django «автономно» — например, пишете скрипт Python, который загружает некоторые шаблоны Django и отображает их, или использует ORM для получения некоторых данных — помимо настройки параметров вам понадобится еще один шаг. .
После того, как вы установили DJANGO_SETTINGS_MODULE или configure() позвоните, вам нужно будет позвонить, django.setup() чтобы загрузить настройки и заполнить реестр приложений Django. Например:
Обратите внимание, что вызов django.setup() необходим только в том случае, если ваш код действительно автономен. При запуске вашим веб-сервером или через django-admin Django сделает это за вас.
django.setup() может быть вызван только один раз.
Поэтому избегайте размещения повторно используемой логики приложения в автономных сценариях, чтобы вам пришлось импортировать из сценария в другое место в вашем приложении. Если вы не можете этого избежать, поместите вызов django.setup() внутрь if блока:
Справочник по настройкам Содержит полный список основных и дополнительных настроек приложения.
Django settings¶
A Django settings file contains all the configuration of your Django installation. This document explains how settings work and which settings are available.
The basics¶
A settings file is just a Python module with module-level variables.
Here are a couple of example settings:
If you set DEBUG to False , you also need to properly set the ALLOWED_HOSTS setting.
Because a settings file is a Python module, the following apply:
It doesn’t allow for Python syntax errors.
It can assign settings dynamically using normal Python syntax. For example:
It can import values from other settings files.
Designating the settings¶
When you use Django, you have to tell it which settings you’re using. Do this by using an environment variable, DJANGO_SETTINGS_MODULE .
The value of DJANGO_SETTINGS_MODULE should be in Python path syntax, e.g. mysite.settings . Note that the settings module should be on the Python import search path.
The django-admin utility¶
When using django-admin , you can either set the environment variable once, or explicitly pass in the settings module each time you run the utility.
Example (Unix Bash shell):
Example (Windows shell):
Use the —settings command-line argument to specify the settings manually:
On the server ( mod_wsgi )¶
In your live server environment, you’ll need to tell your WSGI application what settings file to use. Do that with os.environ :
Read the Django mod_wsgi documentation for more information and other common elements to a Django WSGI application.
Default settings¶
A Django settings file doesn’t have to define any settings if it doesn’t need to. Each setting has a sensible default value. These defaults live in the module django/conf/global_settings.py.
Here’s the algorithm Django uses in compiling settings:
- Load settings from global_settings.py .
- Load settings from the specified settings file, overriding the global settings as necessary.
Note that a settings file should not import from global_settings , because that’s redundant.
Seeing which settings you’ve changed¶
The command python manage.py diffsettings displays differences between the current settings file and Django’s default settings.
For more, see the diffsettings documentation.
Using settings in Python code¶
In your Django apps, use settings by importing the object django.conf.settings . Example:
Note that django.conf.settings isn’t a module – it’s an object. So importing individual settings is not possible:
Also note that your code should not import from either global_settings or your own settings file. django.conf.settings abstracts the concepts of default settings and site-specific settings; it presents a single interface. It also decouples the code that uses settings from the location of your settings.
Altering settings at runtime¶
You shouldn’t alter settings in your applications at runtime. For example, don’t do this in a view:
The only place you should assign to settings is in a settings file.
Security¶
Because a settings file contains sensitive information, such as the database password, you should make every attempt to limit access to it. For example, change its file permissions so that only you and your web server’s user can read it. This is especially important in a shared-hosting environment.
Available settings¶
For a full list of available settings, see the settings reference .
Creating your own settings¶
There’s nothing stopping you from creating your own settings, for your own Django apps, but follow these guidelines:
- Setting names must be all uppercase.
- Don’t reinvent an already-existing setting.
For settings that are sequences, Django itself uses lists, but this is only a convention.
Using settings without setting DJANGO_SETTINGS_MODULE ¶
In some cases, you might want to bypass the DJANGO_SETTINGS_MODULE environment variable. For example, if you’re using the template system by itself, you likely don’t want to have to set up an environment variable pointing to a settings module.
In these cases, you can configure Django’s settings manually. Do this by calling:
django.conf.settings. configure ( default_settings , ** settings )¶
Pass configure() as many keyword arguments as you’d like, with each keyword argument representing a setting and its value. Each argument name should be all uppercase, with the same name as the settings described above. If a particular setting is not passed to configure() and is needed at some later point, Django will use the default setting value.
Configuring Django in this fashion is mostly necessary – and, indeed, recommended – when you’re using a piece of the framework inside a larger application.
Consequently, when configured via settings.configure() , Django will not make any modifications to the process environment variables (see the documentation of TIME_ZONE for why this would normally occur). It’s assumed that you’re already in full control of your environment in these cases.
Custom default settings¶
If you’d like default values to come from somewhere other than django.conf.global_settings , you can pass in a module or class that provides the default settings as the default_settings argument (or as the first positional argument) in the call to configure() .
In this example, default settings are taken from myapp_defaults , and the DEBUG setting is set to True , regardless of its value in myapp_defaults :
The following example, which uses myapp_defaults as a positional argument, is equivalent:
Normally, you will not need to override the defaults in this fashion. The Django defaults are sufficiently tame that you can safely use them. Be aware that if you do pass in a new default module, it entirely replaces the Django defaults, so you must specify a value for every possible setting that might be used in the code you are importing. Check in django.conf.settings.global_settings for the full list.
Either configure() or DJANGO_SETTINGS_MODULE is required¶
If you’re not setting the DJANGO_SETTINGS_MODULE environment variable, you must call configure() at some point before using any code that reads settings.
If you don’t set DJANGO_SETTINGS_MODULE and don’t call configure() , Django will raise an ImportError exception the first time a setting is accessed.
If you set DJANGO_SETTINGS_MODULE , access settings values somehow, then call configure() , Django will raise a RuntimeError indicating that settings have already been configured. There is a property for this purpose:
Also, it’s an error to call configure() more than once, or to call configure() after any setting has been accessed.
It boils down to this: Use exactly one of either configure() or DJANGO_SETTINGS_MODULE . Not both, and not neither.
Calling django.setup() is required for “standalone” Django usage¶
If you’re using components of Django “standalone” – for example, writing a Python script which loads some Django templates and renders them, or uses the ORM to fetch some data – there’s one more step you’ll need in addition to configuring settings.
After you’ve either set DJANGO_SETTINGS_MODULE or called configure() , you’ll need to call django.setup() to load your settings and populate Django’s application registry. For example:
Note that calling django.setup() is only necessary if your code is truly standalone. When invoked by your web server, or through django-admin , Django will handle this for you.
django.setup() may only be called once.
Therefore, avoid putting reusable application logic in standalone scripts so that you have to import from the script elsewhere in your application. If you can’t avoid that, put the call to django.setup() inside an if block:
The Settings Reference Contains the complete list of core and contrib app settings.
Настройка Django Settings: лучшие практики
Эта статья предназначена для программистов, которые используют фреймворк Django. В ней рассматривается способы использования конфигурационных параметров проекта Django, а также плюсы и минусы различных подходов. В ней вы также найдете рекомендации, касающиеся инструментов, лучших практик и архитектурных решений, проверенные временем и проверенные успешными проектами.
Table of contents:
Управление настройками Django: проблемы
Разные окружения. Обычно в разработке используется несколько сред: локальная, dev, ci, qa, staging (промежуточная) , производственная и т. д. Каждая среда может иметь свои собственные конкретные настройки (например: DEBUG = True, более подробное ведение журнала, дополнительные приложения, некоторые фальшивые (mocked) данные и т. д.). Поэтому нам нужен подход, который позволяет сохранять все эти настройки Django для каждой среды отдельно.
Чувствительные данные. У нас есть SECRET_KEY в каждом проекте Django. Кроме того, могут быть пароли и токены БД для сторонних API, таких как Amazon или Twitter. Все данные желательно сохранять в системах VCS.
Обмен настройками между членами команды. Так же обычно нужен общий подход для устранения человеческих ошибок при работе с настройками. Например, разработчик может добавить стороннее приложение или некоторую интеграцию с API в одну конфигурацию и не добавляет определенные настройки в другие. В больших (или даже средних) проектах это может вызвать реальные проблемы.
Настройки Django – это обычный код на Python. Это проклятие и благословение одновременно. Это дает большую гибкость, но также может быть проблемой – вместо пар ключ-значение у settings.py может быть очень сложная логика.
Настройка конфигурации: разные подходы
Не существует встроенного универсального способа настройки параметров Django без их жесткого кодирования. Но книги, проекты с открытым исходным кодом и рабочие проекты предоставляют множество рекомендаций и подходов, как сделать это лучше всего. Давайте кратко рассмотрим наиболее популярные из них, чтобы изучить их слабые и сильные стороны.
settings_local.py
Это самый старый метод. Я использовал его, когда впервые настраивал проект Django на производственном сервере. Я видел, как многие люди использовали это в свое время, и я все еще вижу это сейчас.
Основная идея этого метода заключается в расширении всех специфических для среды настроек в файле settings_local.py, который игнорируется системой VCS. Вот пример:
Плюсы:
- Секреты коды не попадают в VCS.
Недостатки:
- settings_local.py отсутствует в VCS, поэтому вы можете потерять некоторые настройки среды Django.
- Файл настроек Django представляет собой код Python, поэтому settings_local.py может иметь некоторую неочевидную логику.
- У вас должен быть файл settings_local.example (в VCS), чтобы поделиться настройками по умолчанию со всеми разработчиками.
Отдельный файл настроек для каждой среды
Это расширение предыдущего подхода. Оно позволяет сохранять все конфигурации в VCS и делиться настройками по умолчанию между разработчиками.
В этом случае вы создаете каталог (пакет) settings со следующей структурой:
Чтобы запустить проект с определенной конфигурацией, вам нужно использовать дополнительный параметр:
Плюсы:
- Все среды находятся в VCS.
- Легко обмениваться настройками между разработчиками.
Недостатки:
- Нужно найти способ обработки секретных паролей и токенов.
- «Наследование» настроек может быть сложно отслеживать и контролировать.
Переменные окружения
Чтобы решить проблему с конфиденциальными данными, вы можете использовать переменные среды.
Это самый простой пример использования Python os.environ, и у него есть несколько проблем:
- Необходимо обработать исключения KeyError.
- Необходимо конвертировать типы вручную (см. Использование DATABASE_PORT).
Чтобы исправить KeyError, вы можете написать свою собственную оболочку. Например:
Кроме того, вы можете установить значения по умолчанию для этой оболочки и добавить преобразование типов. Но на самом деле нет необходимости писать эту обертку, потому что вы можете использовать стороннюю библиотеку (мы поговорим об этом позже).
Плюсы:
- Конфигурация отделена от кода.
- Паритет среды – у вас одинаковый код для всех сред.
- Нет наследования в настройках, и более чистый и согласованный код.
- Существует теоретическое обоснование использования переменных среды – 12 факторов.
Недостатки:
- Вы должны управлять совместным использованием конфигурации по умолчанию между разработчиками.
12 факторов
12 Факторов – это набор рекомендаций о том, как создавать распределенные веб-приложения, которые будут легко развертывать и масштабировать в облаке. Он был создан Heroku, известным провайдером облачного хостинга.
Как следует из названия, коллекция состоит из двенадцати частей:
- Базы кода (Codebase)
- Зависимости (Dependencies)
- Конфигурация (Config)
- Вспомогательные сервисы (Backing services)
- Сборка, релиз, запуск (Build, release, run)
- Процессы (Processes)
- Привязка к портам (Port binding)
- Параллелизм (Concurrency)
- Disposability
- Dev/prod паритет (Dev/prod parity)
- Логгирование (Logs)
- Процессы администратора (Admin processes)
Каждый пункт описывает рекомендуемый способ реализации определенного аспекта проекта. Некоторые из этих пунктов освещаются такими инструментами, как Django, Python, pip. Некоторые покрыты шаблонами проектирования или настройкой инфраструктуры. В контексте этой статьи нас интересует одна часть: Конфигурация.
Его главное правило – хранить конфигурацию в среде. Следование этой рекомендации даст нам строгое отделение конфига от кода.
Вы можете прочитать больше на 12factor.net.
django-environ
Исходя из вышесказанного, мы видим, что переменные окружения являются идеальным местом для хранения настроек.
Теперь пришло время поговорить о наборе инструментов.
Написание кода с использованием os.environ иногда может быть сложным и потребовать дополнительных усилий для обработки ошибок. Вместо этого лучше использовать django-environment.
Технически это слияние следующих проектов:
Это приложение предоставляет хорошо работающий API для чтения значений из переменных среды или текстовых файлов, небольшого преобразования типов и т. д. Давайте рассмотрим несколько примеров.
файл settings.py перед:
файл settings.py после:
Файл .env:
Структура настроек
Вместо разделения настроек по средам вы можете разделить их по источникам: Django, сторонним приложениям (Celery, DRF и т. д.) И пользовательским настройкам.
файл __init__.py:
Каждый модуль может быть выполнен в виде пакета, и вы можете разбить его более детально:
Соглашения об именах
Именование переменных является одной из самых сложных частей разработки. Так называется наименование настроек. Мы не можем ссылаться на Django или сторонние приложения, но мы можем следовать этим простым правилам для наших пользовательских (проектных) настроек:
- Дайте значимые имена вашим настройкам.
- Всегда используйте префикс с именем проекта для пользовательских настроек (проекта).
- Пишите описания ваших настроек в комментариях.
Плохой пример:
Хороший пример:
Измените MYAWESOMEPROJECT на ваше реальное название проекта.
Настройки Django: лучшие практики
- Сохраняйте настройки в переменных среды.
- Запишите значения по умолчанию для производственной конфигурации (исключая секретные ключи и токены).
- Не задавайте жесткие настройки и не помещайте их в VCS.
- Разделите настройки на группы: Django, third-party, проект.
- Следуйте правилам именования для пользовательских (проектных) настроек.
Заключение
Файл настроек – это небольшая, но очень важная часть любого проекта Django. Если вы сделаете это неправильно, у вас будет много проблем на всех этапах разработки. Но если вы все сделаете правильно, это станет хорошей основой для вашего проекта, которая позволит ему расти и масштабироваться в будущем.
Используя подход с использованием переменных сред, вы можете легко перейти от монолитной архитектуры к микросервису, обернуть свой проект в контейнеры Docker и развернуть его на любой платформе хостинга VPS или Cloud, такой как: Amazon, Google Cloud или ваш собственный кластер Kubernetes.
Оригинальная статья: Alexander Ryabtsev Configuring Django Settings: Best Practices