БС
в волтах ты хранишь и таймауты на всякое разное и всякие лимиты, и название сервиса, которое юзеру показывается?
и номер базы в редисе, имя эксченжа в кролике?
и номер базы в редисе, имя эксченжа в кролике?
Size: a a a
2021 February 26
SA
это можно и без волта прокинуть
БС
как?
БС
с волтом и подобными штуками есть одна проблема. Нет трекинга изменений. Оно тебе не покажет что и кто и когда и почему поменял.
и в секретах должны быть максимум пароли от баз данных и других систем.
и в секретах должны быть максимум пароли от баз данных и других систем.
БС
офигенно.. А почему нельзя сразу yaml файл дать приложению?
AS
так то хардкод или подразумевается что конфиги для кубера чем то генерятся?
SA
с волтом и подобными штуками есть одна проблема. Нет трекинга изменений. Оно тебе не покажет что и кто и когда и почему поменял.
и в секретах должны быть максимум пароли от баз данных и других систем.
и в секретах должны быть максимум пароли от баз данных и других систем.
Это все трекается, если такие секреты хранить в гите. Мы так и делали, секреты лежали прямо в том же репозитории, что и само приложение
SA
офигенно.. А почему нельзя сразу yaml файл дать приложению?
А откуда ты его возьмешь и где будешь хранить?
AS
о да.. все одинакого.. великий и ужасный settings.py и dotenv. И каждый выдумывает как прод/от не прод определить. А потом оказывается чтобы юниттесты работали, нужно вот этот env файл подсунуть, а если локально запутить вот такой. А при деплоее в кубере, надо девопсу как то сообщить какие переменные окружения нужно определить.
чем те dotenv для стендов не угодил- это как backend.cfg и backend_dev.cfg в buildout (вроде ты же сам это ввел)
БС
А откуда ты его возьмешь и где будешь хранить?
хранить в гите, где же еще?
AS
офигенно.. А почему нельзя сразу yaml файл дать приложению?
да по идее можно- засовываешь его в кубере в configmap и дальше скармливаешь как volume
https://gist.github.com/petitviolet/d36f33d145d0bbf4b54eb187b79d0244
https://gist.github.com/petitviolet/d36f33d145d0bbf4b54eb187b79d0244
SA
Хочу, кстати, заметить, что это уже все заморочки кубернетеса, которые к джанге-то отношения не имеют
БС
я хочу заметить, что в большинстве случаев получается так, что конфиг так или иначе лежит в yaml или в шаблоне, из которого получается yaml, а потом с помощью магии переводить в переменные окружения. И нифига не понятно почему нельзя сразу подсунуть этот yaml приложению.
БС
Только yaml из коробки можно делать иерархию, можно указывать конкретные типа, а не просто строки.
SA
В settings.py тоже так можно. А секреты брать из переменных окружения
БС
можно но сайд эффектов много.
Я видел и такое:
Я видел и такое:
stage = os.environ["stage"]
importlib.import_module(f"settings-{stage}.py")
БС
А потом получается что в одном стедж конфиге добавили параметр, в другом забыли.. Естественно упало на проде всё
SA
а как ямл тебе тут поможет?
БС
потом вводят разные полики, как и что хранить в settings.py и т.д.
А заканчивается тем, что рядовой разработчик лишний раз боится вынести какой то параметр в конфиг, "а в друг devops забудет или не то поставит".. ну его нафиг, захардхожу, глядишь на ревью не заметят
А заканчивается тем, что рядовой разработчик лишний раз боится вынести какой то параметр в конфиг, "а в друг devops забудет или не то поставит".. ну его нафиг, захардхожу, глядишь на ревью не заметят