Нет, vault поднимать необязательно. Всё будет работать как с ним так и без него.
Ну в .env файлах хранятся конкретные данные обычно, так что понятное дело это выглядит так себе. Опять же конфигурацию можно просто встроить в бинарь и проблем не будет с развёртыванием где угодно.
Вы наверное в целом правы, конфигурация и авторизация vault через файлы это лишнее и по хорошему надо убрать чтобы не путало.
Согласен, оно и не "думает". Как это противоречит тому что конфиги для окружений разные? Сами конфиги никак не мешают сборке вместе с ними же быть побайтово идентичной на всех средах и успешно работать. Можете хеш сумму с бинаря снять и запустить во всех средах чтобы убедиться. Ну или обратите внимание что конфиги можно включить в бинарь (go embed) и разворачивать его в любой среде без изменений. И заметьте что я нигде не указывал пароли даже в примерах.
Ну будет оно знать и чего поменяется ? Это какая-то командная догма ? В данном случае приложение может "знать" где оно запущено по многим другим косвенным признакам, помимо прямого указания среды. Например по указанию собственного домена или по домену базы данных. "какие параметры прокинули, с теми и должно работает" - ну тоесть у вас на продовом окружении сборка спокойно заработает с настройками соединения например базы от дев среды ? Согласен что есть универсальные настройки, которые могут подойти в любом окружении, но есть и специфичные. Проблема проброса семантически статичных настроек в первую очередь в отсутствии наглядности. Конфигурационный файл обозначает где ожидаются данные и через какие источники. Сами данные при этом могут храниться где угодно.
Это просто пример, многое сделано для краткости и наглядности. Например я намеренно не обрабатывал ошибки, и делал другие допущения. Можно пробросить любые параметры которые захотите так как захотите, никто не запрещает.
Ну так если вы ожидаете что приложение упадет если smtp сервер недоступен то сделайте так, причем тут конфигуратор. Он предоставил данные, как он их проверять то будет ? Тем более работоспособность SMTP сервиса, про который он знать не знает, и падать с ошибкой если он недоступен ? Вообще извергать паники со сторонних библиотек это антипаттерн. Ну на крайний случай не используйте дефолтные источники данных, сама утилита как и её прародитель никак это не запрещают, особенно если вы допускаете ошибки и ничего не проверяете. По одному источнику конфигурации на все окружения и точно не ошибетесь.
Вы рассказываете примерно так "что-то где-то при каких-то условиях падает и то иногда, я потыкал первое что увидел и виноват оказался конфигуратор". Если у вас дефолтные пароли подошли к продовой базе при чём тут конфигуратор? Он отработал, дальше ваши проблемы. И при чём тут healthcheck? Это просто ручка, которую вы сами настраиваете. Я уже молчу, что её многие делают заглушкой и не парятся.
А если у вас соединение к базе данных устанавливается с ошибкой и этот момент игнорируется, а сервер продолжает работать и сыпет ошибками после запросов то почему этот момент должен обрабатываться конфигуратором? Ещё раз - его задача предоставить данные, как вы их используете, обрабатываете или игнорируете ошибки это ваша ответственность.
Я вообще молчу как такая сборка дошла до прода и почему крайним оказалась утилита конфигурирования, наверное полнейшее отсутствие тестирования и приверженность классическому эджайлу в купе с "потыкать в случайное место авось заведётся" сделали своё дело.
В любом случае я доделал возможность забора данных с конкретного указанного источника, завтра волью и повешу тег. Если например данные для продовой базы ожидаются с vault то можно указать его и тогда явно будет указано что они не найдены - до дефолтных значений конфигуратор опускаться не будет.
Если vault недоступен то во время создания инстанса конфигуратора (в момент авторизации) произойдёт ошибка. Если данные для соединения с postgresql берутся сильно отложено во времени, например в тот момент когда vault уже был по каким-то причинам выключен, то можно просто пересоздать инстанс и вывалится ошибка. Или воспользоваться методом для возвращения клиента vault и проверить его работоспособность через api. Возможно стоит действительно добавить способность в метод Get каким-то образом дать понять что какой-то из источников недоступен(особенно динамический), но вы должны понимать что задача стояла не пересоздать очередной api для работы с вольтом (он есть и отличный) а дать возможность делать простые операции более удобно. Если нужно именно понять что в конкретном источнике нет данных (например в vault) то эта идея не вписывается в концепцию первоисточника (node-config). Хотя вы правы, это полезная фишка и я подумаю как это можно реализовать максимально ненавязчиво. Вот только как вы заметили тот же postgresql всё равно не поднимется со значениями по умолчанию, приложение не поднимется и всё будет более чем очевидно.
Ну вам в любом случае нужно где-то хранить и как-то передавать данные для авторизации vault. Можно хранить их в k8s secret или docker-compose secret или ещё где, это не важно и выходит за рамки статьи. Несмотря на использование vault, статья про конфигурацию приложения а не про секьюрность передачи и хранения ключей доступа.
Ну на счёт шаблонов + баш скрипты не уверен что будет проще и нагляднее ... Вообще стараюсь избегать bash скрипты. Хотя кому как. А вот на счёт ini файлов согласен, очень удобный формат. Только как их ближайшую альтернативу предпочитаю более новый toml.
Проблема похожая на мою с кафкой в несте. Но у меня 3 решения было - написать сервис, кастомный транспорт(сделал так), или сделать правки в транспорте в репе. И в несте именно так, чуть шаг влево, вправо и ничего нет. Документация только по самым верхам. Вводится куча абстракций а зачастую как они ложатся на различные библиотеки непонятно. И тут видимо подводят к тому что надо платить.
Нет, vault поднимать необязательно. Всё будет работать как с ним так и без него.
Ну в .env файлах хранятся конкретные данные обычно, так что понятное дело это выглядит так себе. Опять же конфигурацию можно просто встроить в бинарь и проблем не будет с развёртыванием где угодно.
Вы наверное в целом правы, конфигурация и авторизация vault через файлы это лишнее и по хорошему надо убрать чтобы не путало.
Согласен, оно и не "думает". Как это противоречит тому что конфиги для окружений разные? Сами конфиги никак не мешают сборке вместе с ними же быть побайтово идентичной на всех средах и успешно работать. Можете хеш сумму с бинаря снять и запустить во всех средах чтобы убедиться. Ну или обратите внимание что конфиги можно включить в бинарь (go embed) и разворачивать его в любой среде без изменений. И заметьте что я нигде не указывал пароли даже в примерах.
Ну будет оно знать и чего поменяется ? Это какая-то командная догма ? В данном случае приложение может "знать" где оно запущено по многим другим косвенным признакам, помимо прямого указания среды. Например по указанию собственного домена или по домену базы данных. "какие параметры прокинули, с теми и должно работает" - ну тоесть у вас на продовом окружении сборка спокойно заработает с настройками соединения например базы от дев среды ? Согласен что есть универсальные настройки, которые могут подойти в любом окружении, но есть и специфичные. Проблема проброса семантически статичных настроек в первую очередь в отсутствии наглядности. Конфигурационный файл обозначает где ожидаются данные и через какие источники. Сами данные при этом могут храниться где угодно.
Это просто пример, многое сделано для краткости и наглядности. Например я намеренно не обрабатывал ошибки, и делал другие допущения. Можно пробросить любые параметры которые захотите так как захотите, никто не запрещает.
Ну так если вы ожидаете что приложение упадет если smtp сервер недоступен то сделайте так, причем тут конфигуратор. Он предоставил данные, как он их проверять то будет ? Тем более работоспособность SMTP сервиса, про который он знать не знает, и падать с ошибкой если он недоступен ? Вообще извергать паники со сторонних библиотек это антипаттерн. Ну на крайний случай не используйте дефолтные источники данных, сама утилита как и её прародитель никак это не запрещают, особенно если вы допускаете ошибки и ничего не проверяете. По одному источнику конфигурации на все окружения и точно не ошибетесь.
Вы рассказываете примерно так "что-то где-то при каких-то условиях падает и то иногда, я потыкал первое что увидел и виноват оказался конфигуратор". Если у вас дефолтные пароли подошли к продовой базе при чём тут конфигуратор? Он отработал, дальше ваши проблемы. И при чём тут healthcheck? Это просто ручка, которую вы сами настраиваете. Я уже молчу, что её многие делают заглушкой и не парятся.
А если у вас соединение к базе данных устанавливается с ошибкой и этот момент игнорируется, а сервер продолжает работать и сыпет ошибками после запросов то почему этот момент должен обрабатываться конфигуратором? Ещё раз - его задача предоставить данные, как вы их используете, обрабатываете или игнорируете ошибки это ваша ответственность.
Я вообще молчу как такая сборка дошла до прода и почему крайним оказалась утилита конфигурирования, наверное полнейшее отсутствие тестирования и приверженность классическому эджайлу в купе с "потыкать в случайное место авось заведётся" сделали своё дело.
В любом случае я доделал возможность забора данных с конкретного указанного источника, завтра волью и повешу тег. Если например данные для продовой базы ожидаются с vault то можно указать его и тогда явно будет указано что они не найдены - до дефолтных значений конфигуратор опускаться не будет.
Если vault недоступен то во время создания инстанса конфигуратора (в момент авторизации) произойдёт ошибка. Если данные для соединения с postgresql берутся сильно отложено во времени, например в тот момент когда vault уже был по каким-то причинам выключен, то можно просто пересоздать инстанс и вывалится ошибка. Или воспользоваться методом для возвращения клиента vault и проверить его работоспособность через api. Возможно стоит действительно добавить способность в метод Get каким-то образом дать понять что какой-то из источников недоступен(особенно динамический), но вы должны понимать что задача стояла не пересоздать очередной api для работы с вольтом (он есть и отличный) а дать возможность делать простые операции более удобно. Если нужно именно понять что в конкретном источнике нет данных (например в vault) то эта идея не вписывается в концепцию первоисточника (node-config). Хотя вы правы, это полезная фишка и я подумаю как это можно реализовать максимально ненавязчиво. Вот только как вы заметили тот же postgresql всё равно не поднимется со значениями по умолчанию, приложение не поднимется и всё будет более чем очевидно.
Ну вам в любом случае нужно где-то хранить и как-то передавать данные для авторизации vault. Можно хранить их в k8s secret или docker-compose secret или ещё где, это не важно и выходит за рамки статьи. Несмотря на использование vault, статья про конфигурацию приложения а не про секьюрность передачи и хранения ключей доступа.
Не знал про критику toml в таком виде, почитаю, спасибо
Ну на счёт шаблонов + баш скрипты не уверен что будет проще и нагляднее ... Вообще стараюсь избегать bash скрипты. Хотя кому как. А вот на счёт ini файлов согласен, очень удобный формат. Только как их ближайшую альтернативу предпочитаю более новый toml.
ООП хорошо работает там где можно представить себе объекты. Например в разработке игр. Но в целом конечно абсолютизировать любую технологию не стоит.
Проблема похожая на мою с кафкой в несте. Но у меня 3 решения было - написать сервис, кастомный транспорт(сделал так), или сделать правки в транспорте в репе. И в несте именно так, чуть шаг влево, вправо и ничего нет. Документация только по самым верхам. Вводится куча абстракций а зачастую как они ложатся на различные библиотеки непонятно. И тут видимо подводят к тому что надо платить.
Этот протокол не поддерживает логическое "соединение". Из сего следует что это конкурент UDP, а потому его безграмотно сравнивать с TCP.