Комментарии 21
Предлагаю изжить вариативность конфигов и перегрузку как класс.
У нас тут в одни приложении тоже используют разные варианты конфигурации- а потом на пробе треш лезет. И что откуда куда фиг разберешься
Берём самый простой формат:
Ini файлы.
Пишем простой конфиг, превращаем в «template” и bash скриптом или make файлом генерируем нужны кб конфигурацию хоть для прода хоть для чего угодно.
Реализация на 15 минут. Проблем разобраться и понять что там к чему -0 просто один файл конфигурации.
Поскольку у нас не новомодный json, а старый добрый ini - файл, то в качестве бонуса идут комментарии
Кто как хочет, так и ...
Ну на счёт шаблонов + баш скрипты не уверен что будет проще и нагляднее ... Вообще стараюсь избегать bash скрипты. Хотя кому как. А вот на счёт ini файлов согласен, очень удобный формат. Только как их ближайшую альтернативу предпочитаю более новый toml.
И напрасно:
https://github.com/madmurphy/libconfini/wiki/An-INI-critique-of-TOML
С баш/make лучше потому что конфигурационный файл в результате один. Плюс все параметры, участвующие в подстановке хранятся в файле в виде key=value. Полюс при необходимости поддержка значений по умолчанию из коробки. Плюс все отлажено веками.
о! любимая тема не тонет)
Дано. Для "повышения безопасности", вы храните в ПровайдереСекретов Секреты для доступа к Серверам.
Вопрос: Где вы храните Секреты для доступа к самому ПровайдеруСекретов?
как видно из текста статьи:
секрет в конфиге для доступа к PostgreSQL - аяяй плохо!
но секрет в конфиге для доступа к Vault - вах хорошо!
Указание полей секции [goconfig.vault] и [goconfig.vault.auth] это только один из способов сконфигурировать и авторизовать vault клиент.
я открою вам Страшную Тайну:
безопасно хранить пароли для доступа к Vault1 можно только в Vault2. а к нему тоже надо пароли...
Ну вам в любом случае нужно где-то хранить и как-то передавать данные для авторизации vault. Можно хранить их в k8s secret или docker-compose secret или ещё где, это не важно и выходит за рамки статьи. Несмотря на использование vault, статья про конфигурацию приложения а не про секьюрность передачи и хранения ключей доступа.
Можно хранить в хранилище секретов операционки. Это лучше, чем текстовым файлом.
Вся конфигурация обтекаемая, потому если по каким-то причинам не удалось загрузить из vault (например такого секрета не существует) то конфигуратор будет дальше идти по источникам вплоть до default значений.
То есть, если что-то пошло не так, то ошибка будет в рантайме с сообщением: не могу подключиться к базе данных.
Не хочу так. Я хочу на старте приложения проверку, что все параметры удалось достать.
Если vault недоступен то во время создания инстанса конфигуратора (в момент авторизации) произойдёт ошибка. Если данные для соединения с postgresql берутся сильно отложено во времени, например в тот момент когда vault уже был по каким-то причинам выключен, то можно просто пересоздать инстанс и вывалится ошибка. Или воспользоваться методом для возвращения клиента vault и проверить его работоспособность через api. Возможно стоит действительно добавить способность в метод Get каким-то образом дать понять что какой-то из источников недоступен(особенно динамический), но вы должны понимать что задача стояла не пересоздать очередной api для работы с вольтом (он есть и отличный) а дать возможность делать простые операции более удобно. Если нужно именно понять что в конкретном источнике нет данных (например в vault) то эта идея не вписывается в концепцию первоисточника (node-config). Хотя вы правы, это полезная фишка и я подумаю как это можно реализовать максимально ненавязчиво. Вот только как вы заметили тот же postgresql всё равно не поднимется со значениями по умолчанию, приложение не поднимется и всё будет более чем очевидно.
Вот только как вы заметили тот же postgresql всё равно не поднимется со значениями по умолчанию, приложение не поднимется и всё будет более чем очевидно.
Зависит от использования и самого секрета. Пару раз была ситуация: Сервер стартовал, healthckeck работает, но некоторые запросы падают. Заметили это в породе и то с задержкой. Выпили дефолтные значения, стало падать при старте и сразу стало заметно на препроде.
Для меня типичная ситуация, когда я зупуская скрипты, с которым слабо знаком. Поэтому простота конфига и хорошие сообщения об ошибках важны. в питоне click с кастомными обёртками эти вопросы закрывает.
Вы рассказываете примерно так "что-то где-то при каких-то условиях падает и то иногда, я потыкал первое что увидел и виноват оказался конфигуратор". Если у вас дефолтные пароли подошли к продовой базе при чём тут конфигуратор? Он отработал, дальше ваши проблемы. И при чём тут healthcheck? Это просто ручка, которую вы сами настраиваете. Я уже молчу, что её многие делают заглушкой и не парятся.
А если у вас соединение к базе данных устанавливается с ошибкой и этот момент игнорируется, а сервер продолжает работать и сыпет ошибками после запросов то почему этот момент должен обрабатываться конфигуратором? Ещё раз - его задача предоставить данные, как вы их используете, обрабатываете или игнорируете ошибки это ваша ответственность.
Я вообще молчу как такая сборка дошла до прода и почему крайним оказалась утилита конфигурирования, наверное полнейшее отсутствие тестирования и приверженность классическому эджайлу в купе с "потыкать в случайное место авось заведётся" сделали своё дело.
В любом случае я доделал возможность забора данных с конкретного указанного источника, завтра волью и повешу тег. Если например данные для продовой базы ожидаются с vault то можно указать его и тогда явно будет указано что они не найдены - до дефолтных значений конфигуратор опускаться не будет.
Это не от базы был пароль, а от smtp сервера. А письма шлются очень редко. Дефолтные значения не подошли.
Healthcheck это не просто ручка, это часть автоматического деплоя. Если новая версия не поднялась, старая продолжает работать.
Мои ожидания от приложения, это падать при старте. и наличие нескольких источников для конфигов, увеличивают шанс совершить ошибку.
Ну так если вы ожидаете что приложение упадет если smtp сервер недоступен то сделайте так, причем тут конфигуратор. Он предоставил данные, как он их проверять то будет ? Тем более работоспособность SMTP сервиса, про который он знать не знает, и падать с ошибкой если он недоступен ? Вообще извергать паники со сторонних библиотек это антипаттерн. Ну на крайний случай не используйте дефолтные источники данных, сама утилита как и её прародитель никак это не запрещают, особенно если вы допускаете ошибки и ничего не проверяете. По одному источнику конфигурации на все окружения и точно не ошибетесь.
причем тут конфигуратор
Разговор начался с примера где в случае человеческой ошибки конфигуратор берёт дефолтные значения которые кривые.
Вообще извергать паники со сторонних библиотек это антипаттерн.
Это в вашем примере ошибка конфигуратора игнорируется. В нормальном коде приложение обработает её и упадёт. Паника не нужна.
особенно если вы допускаете ошибки и ничего не проверяете.
Мне нравится подход к библиотекам, когда библиотека немного думает за меня и предупреждает о потенциальных ошибках.
По одному источнику конфигурации на все окружения и точно не ошибетесь.
Это хорошее решения для меня. Правда тогда отпадает надобность в библиотеке. Двойной выигрыш.
Подход своеобразный, честно говоря.
Мы в команде исповедуем принцип, что приложение не должно знать про среду, в которой оно работает. Стейдж, прод, дев - куда положили, какие параметры прокинули, с теми и должно работает. Это ж как инверсия зависимостей, только на уровне пробрасывания настроек окружения.
И если вы итак через переменные окружения передаете название площадки для которой конфиг фетчить, то почему сами параметры подключения к БД тоже бы не пробросить через переменные окружения?
Ну будет оно знать и чего поменяется ? Это какая-то командная догма ? В данном случае приложение может "знать" где оно запущено по многим другим косвенным признакам, помимо прямого указания среды. Например по указанию собственного домена или по домену базы данных. "какие параметры прокинули, с теми и должно работает" - ну тоесть у вас на продовом окружении сборка спокойно заработает с настройками соединения например базы от дев среды ? Согласен что есть универсальные настройки, которые могут подойти в любом окружении, но есть и специфичные. Проблема проброса семантически статичных настроек в первую очередь в отсутствии наглядности. Конфигурационный файл обозначает где ожидаются данные и через какие источники. Сами данные при этом могут храниться где угодно.
Это просто пример, многое сделано для краткости и наглядности. Например я намеренно не обрабатывал ошибки, и делал другие допущения. Можно пробросить любые параметры которые захотите так как захотите, никто не запрещает.
Почему приложение должно вообще об этом думать? Ему снаружи дали логин/пароль/хост от базы данных и оно пытается к ней подключиться. Если не получается, то оно падает на этапе инициализации и девопс/разраб видит ошибку. Если случайно передали на прод пароль от стейджа, то прод просто не стартанет.
Согласен, оно и не "думает". Как это противоречит тому что конфиги для окружений разные? Сами конфиги никак не мешают сборке вместе с ними же быть побайтово идентичной на всех средах и успешно работать. Можете хеш сумму с бинаря снять и запустить во всех средах чтобы убедиться. Ну или обратите внимание что конфиги можно включить в бинарь (go embed) и разворачивать его в любой среде без изменений. И заметьте что я нигде не указывал пароли даже в примерах.
У вас в примере пароль от базы лежит во внешнем хранилище. Получается, что даже для локальной разработки мне нужен этот vault сервис?
Конфиги на файлах мне очень напоминают .env файлы, которые удобны локально, но ужасно неудобны при деплое в AWS и прочий kubernetes.
Нет, vault поднимать необязательно. Всё будет работать как с ним так и без него.
Ну в .env файлах хранятся конкретные данные обычно, так что понятное дело это выглядит так себе. Опять же конфигурацию можно просто встроить в бинарь и проблем не будет с развёртыванием где угодно.
Вы наверное в целом правы, конфигурация и авторизация vault через файлы это лишнее и по хорошему надо убрать чтобы не путало.
Про конфигурацию go приложений и при чём тут vault