Как хранить секреты django в dynaconf?

Question

[mkone112]

Я хочу вынести SECRET_KEY из репозитория - наткнулся на dynaconf. Правильно ли я понимаю что нужно удалить SECRET_KEY из settings.py и перенести его в .secrets.toml?

Answer 1

[Дмитрий Сергеев]

mkone112 рассказываю как делаю это я.
Для начала объясню что такое local_settings.py, это файл с локальными настройками, где вы можете переопределить любую глобальную настройку (в том числе и SECRET_KEY). Его содержимое выглядит примерно так

from .settings import *

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = False

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

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

from .settings import *

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'Мой самый секретный ключ'

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = False

Далее же вы используете файл настроек при запуске вот так, при разработке. В gunicorn соответственно эту же настройку добавить нужно.

$ python manage.py runserver --settings=myproject.local_settings

Таким образом решается ваша проблема. А ваш SECRET_KEY в репозитории, не будет иметь ничего общего с реальным SECRET_KEY который на продакт сервере.

Comments

[mkone112]

Да это понятно. Но так не решается проблема с конфигом для production/development.

[Дмитрий Сергеев]

mkone112, все решается. Не нужно придумывать проблем, там где их нет

[mkone112]

Дмитрий, что решается - я знаю, но мне хочется удобно и элегантно.

python manage.py runserver --settings=myproject.local_settings

Лишний гемор. Почему не использовать local по умолчанию, а production не указать например в wsgi.py.

Не нужно придумывать проблем, там где их нет

Так можно и на ассемблер вернуться.

[Дмитрий Сергеев]

mkone112, если бы --settings было лишним, то разработчики ее бы и не добавляли.