Слишком много файлов настроек

Обновлено: 21.11.2024

Если вы используете систему управления исходным кодом (CVS, SVN, . ) или хотите опубликовать свое приложение в Интернете, может быть хорошей идеей перенести конфиденциальные или специфичные для компьютера/пользователя настройки, такие как пароли базы данных и т. д., из основной файл settings.py.

Как показали обсуждения в списке рассылки django-developers, у всех разные требования и идеи, как это сделать. На этой странице собраны некоторые из этих идей для дальнейшего использования.

Одна вещь, которую следует иметь в виду, это то, что файлы конфигурации Django — это чистый Python. Это дает вам максимальную гибкость для работы с конфигурациями так, как вы считаете лучшим. Или, цитируя Адриана Головатого:

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

файл в стиле ini для развертывания

Это решение, которое Майкл Радзией опубликовал для разработчиков django. Его мотивация заключалась в том, чтобы иметь возможность хранить настройки приложения, которое он опубликовал, в /etc вместе со всеми другими файлами конфигурации системы.

Похожее, но более прозрачное решение см. в методе лисы

/etc/whatever/settings.ini (Django /path/to/whatever/settings.py (файл Django settings.py.

/path/to/whatever/settings.py (Django settings.py включает * из другого файла конфигурации для конкретной машины, который может выглядеть примерно так.

/path/to/whatever/settings_local.py (Django urls.py

settings.py входит в CVS, SVN (укажите здесь ваш любимый RCS)
settings_local.py _не_ входит в RCS

При желании файл settings_local.template можно поставить под контроль версий с инструкциями скопировать его в settings_local.py, изменить его в соответствии со средой и никогда не фиксировать его в системе RCS.

Конфигурация параметров, зависящих от разработки/машины

Я лично использую это решение.

Этот загрузчик настроек импортирует соответствующий модуль настроек. Я храню свои файлы настроек в каталоге конфигурации в корне проекта.

/path/to/project/config/prod.py (Django /path/to/project/config/user1.py (Django settings.py

Это позволяет локальным настройкам как считывать, так и изменять значения основных настроек (и это просто).

В качестве улучшения можно добиться небольшого разделения привилегий, сделав файл local_settings.conf нечитаемым для идентификатора uid, который запускает веб-приложение, открыв local_settings.conf в оболочке setuid и передав его файловый дескриптор процессу Django. и используя exec os.fdopen(. 'r') в globals() . Это не идеально, так как любые секреты, прочитанные из этого файла, по-прежнему хранятся в процессе Django, но это затрудняет обнаружение ваших секретов тем, кто получил доступ к идентификатору пользователя, запустившего приложение Django. (Очевидно, что все файлы Python, используемые приложением, также должны принадлежать пользователю, отличному от того, от имени которого запускается приложение.)

Использование списка файлов конфигурации (Transifex)

Компания Transifex приняла решение, использующее упорядоченный список нескольких файлов .conf внутри каталога настроек. Это помогает разделить параметры конфигурации, упаковать в дистрибутивы Linux и поместить файлы настроек в /etc .

Чтобы применить локальные изменения, создайте файл XX-local.conf , который можно игнорировать с выбранной системой контроля версий:

Доступ к существующим настройкам и их изменение

Я (Антти Кайхола) использую следующее решение для определения локальных настроек. Он обеспечивает доступ к исходным настройкам при определении локальных настроек. Примечание: это работает, только если вы импортируете из базы settings.py или settings/__init__.py .

Старые и неуклюжие методы, которые я использовал:

замените файл more_settings.py дополнительным волшебным:

Наследование настроек

Я (Сергей Юшкеев) расширил предлагаемое решение:

Настройка наследования с помощью иерархии

Мне ( Карим А. Нассар ) необходимо иметь возможность наследовать от файла базовых настроек, а затем для каждой среды предоставлять переопределения. В dev env нам нужны настройки для конкретного разработчика. Следующее расширяет решение Сергея Юшкеева выше.

Этот скрипт объединяет settings/common.py , settings/$APP_ENV.py и settings/ .py в указанном порядке.

Затем переместите settings.py в settings/common.py .

Вышеупомянутое значение по умолчанию — dev env. Вы можете передать что угодно в manage.py через переменную среды APP_ENV. Распространенными являются prod , staging , qa и т. д. Для каждого APP_ENV вы создаете файл $APP_ENV.py . Наконец, создайте файл $USER.py с переопределениями для конкретного разработчика. Примеры файлов (кроме settings/common.py ) ниже..

Конечно, вы можете обнаружить, что вам нужны некоторые из вышеуказанных настроек в common.py . Настройте, как вам нужно для вашей ситуации.

Простая организация пакетов для сред

Я использовал организацию пакетов Python, подобную той, что описана выше, для настроек для каждой среды, но намного упрощенную: оставив наследование для обработки простыми модулями Python, без магии словаря глубокого слияния. Просто будьте откровенны! Легче понять, что настраивает production.py с первого взгляда, без необходимости копаться в структурах данных в других файлах. Наличие настроек для каждого разработчика требует проблем с несогласованными конфигурациями, возникающими в средах развертывания.

Первоначальный файл settings.py был перемещен в settings/defaults.py . По умолчанию пакет настроек будет использовать конфигурацию разработки, чтобы локальная разработка работала как обычно:

Для производства (или подготовки и т. д.) просто добавьте соответствующий модуль и задайте обычную переменную среды Django DJANGO_SETTINGS_MODULE в настройках развертывания, чтобы загрузить его:

Везде, где это подходит для вашего развертывания (например, директива Apache SetEnv, включите эквивалент:

Использование django-admin.py в развертывании вместо manage.py должно автоматически помещать пакет вашего приложения в sys.path, чтобы путь импорта, указанный таким образом, работал.

Если по какой-то причине вам необходимо использовать файл settings/local.py, хуки postactivate/postdeactivate в virtualenvwrapper — это хорошее место, чтобы настроить DJANGO_SETTINGS_MODULE так, чтобы он указывал на него для локальной разработки каждого проекта. Однако желательно устранить как можно больше потенциальных несоответствий между конфигурацией разработки и рабочей среды.

Метод Йипита

Адам Нельсон из Yipit написал в блоге об их методе управления настройками Django. См. Расширение настроек Django для реального мира. TODO: резюмируйте сообщение в блоге здесь.

Метод Роба Голдинга

Роб Голдинг опубликовал в своем блоге, как он решил эту проблему. На самом деле это немного хак, но он прекрасно работает и позволяет вам переопределять или расширять что-либо в settings.py .

Добавьте это в конец файла settings.py:

Теперь создайте файл local_settings.py со следующим:

Теперь вы можете добавлять вещи в local_settings.py следующим образом:

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

метод лисы

Сначала напишите файл конфигурации с паролями и секретными ключами. Сохраните его где-нибудь. Это external_config.py

Это файл production_settings.py

Теперь импорт * из production_settings.py будет импортировать данные из файла конфигурации

Каталог настроек, используемый в Read The Docs, доступен в их репозитории.

модульный метод

Переместите настройки в пакет, разделите все на модули, а затем импортируйте в __init__.py .

django-flexisettings

django-split-settings

Подробности см. в записи блога и на странице проекта GitHub. Основные характеристики:

  • Настройки можно разделить на файлы и каталоги.
  • Файлы, расположенные ниже в списке, могут изменять конфигурации, например добавлять или удалять приложения из INSTALLED_APPS.
  • В основном файле настроек перечислены файлы, составляющие настройки проекта.
  • Файлы можно пометить как необязательные. Дополнительные файлы можно использовать для переопределения настроек для каждого экземпляра.
  • В путях к файлам можно использовать подстановочные знаки.
  • Сохранена поддержка автоматической перезагрузки сервера выполнения Django.

django-configglue

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

  • файлы конфигурации в стиле ini
  • конфигурация на основе схемы
  • интеграция с командной строкой
  • проверка конфигурации
  • поддержка нескольких файлов конфигурации с наслоением

настройки класса django

Этот проект позволяет вам определять настройки вашего проекта Django, используя классы вместо модулей. Помимо прочего, это позволяет использовать наследование и вычисляемые свойства. Репозиторий Github.

django-конфигурации

django-configurations упрощает настройку проекта Django, полагаясь на возможность компоновки классов Python. Он расширяет понятие загрузки настроек на основе модулей Django с помощью хорошо зарекомендовавших себя шаблонов объектно-ориентированного программирования. Репозиторий Github.

Читайте также: