Comments 10
В общем, в Go так не делается. Проще всего - передавать конфиг через переменные среды в структуру с помощью, например, https://github.com/kelseyhightower/envconfig
Я видел данные подходы, такое же есть и в https://github.com/ilyakaznacheev/cleanenv. Вся проблема этих подходов в том, что если завтра у команды DevOps поменяются правила на названия переменных среды, то меня обязывают идти и исправлять это внутри кода. А это уже процесс проверки/отладки приложения.
Основная задача, которая я поставил - это развязать зависимости кода и конфигурации. И мое расширение это решает, при этом встраиваясь в любые решения работы с конфигурацией
Переменные среды для микросервиса обычно определяются разработчиком в deployment.yaml/statefulset.yaml/...
Каким боком здесь devops?
Вам повезло если так
Обратите внимание на мое изложение.
Переменные, которые определяются разработчиком НЕ РАВНО название переменных среды. Вы, как разработчик, определяете левую часть, а правая не должна вас касаться (пример: host: ${SERVER_HOST}) по всем принципам разработки. Если вы работаете в крупном проекте, то у вас и доступа нет до того же прода. Вы просто пилите свою часть и все. А название переменной SERVER_HOST вообще может меняться в рамках деплоймента как угодно (не только значение, но и название) Например, поменялись стандарны названия переменных и т.д. То, что вы пытаетесь доказать - это путь к тому, что нужно будет условно лет через 5 брать и пересобирать и затем проверять приложение. Надеюсь, объяснил понятным языком.
если завтра у команды DevOps поменяются правила на названия переменных среды
Это уже не DevOps, а старый-добрый (не очень) Operations, если кто-то решает за разработчиков как им называть переменные окружения для конфигурирования их же приложения ;)
Вы исказили мое сообщение. Разработчикам никто не запрещает как угодно называть переменные окружения. Но разработчики не должны накладывать ограничения и правила название переменных окружения командам деплоя/поставки и т.д.
Мы уходим в другую степь диалога и контекст стал теряться.
Причем вы процитировали мое сообщение и совершенно отдельно стоящую мысль транслировали (даже популистскую больше, а не смысловую)
Можно же просто обойти все настройки в конфиге viper и строковые значения пропустить через os.ExpandEnv (https://pkg.go.dev/os#ExpandEnv) без велосипедов и рефлексии
А смотрели ли вы https://github.com/spf13/viper? Выглядит так, как-будто решает проблему. Можно пойти дальше и взять https://github.com/spf13/cobra как фреймворк для написания CLI.
Расширение для стандартных модулей управления конфигурациями в Go