FEDOR BORSHEV

settings.local.py



Ещё один антипаттерн, который я часто встречаю в проектах Django (да, мне приносят их на ревью: напишите на [email protected], чтобы я посмотрел ваш) — это несколько файлов settings.py для разных сред. Чем это вызвано, в общем-то понятно: думаю авторы джанги до сих пор краснеют от своей идеи хранить настройки в гигантском питоньем файле.



Но раз уж от settings.py мы никуда не денемся, давайте хотя бы попробуем его сделать более понятным. Представьте, что ваше приложение крутится в трёх местах: прод, стейджинг и машина фронтендера. Во всех — разные настройки доступа к БД, на дев-машинах могут быть отключены какие-то фичи и и.д. Если вы заведете settings.prod.py и settings.dev.py то, вам придётся заводить два разных докер-образа для этих целей, либо писать код, который в зависимости от среды будет определять нужный файл настроек. А правильно определять среду — весьма интересная задача, учитывая то, что делать это придётся изнутри изолированного контейнера.



Решать проблему разных настроек нужно при помощи третьего правила 12-факторного приложения — переменных окружения. Вся конфигурация вроде доступов к базе и фиче-флагов должна храниться в переменных окружения. Так вы сможете запускать одну и ту же кодовую базу через один контейнер в удобной конфигурации в любой среде — ведь переменные окружения так приятно хранить в docker-compose.py или в настройках UWSGI если вы олдфаг.



Для Джанго существует пакет django-environ: просто поставьте его и забудьте про settings.local.py.