данные из kv и делают конфиг для приложения… зачем придумыывать велосипед?
Тоже вариант, да
Потому что логика генерации конфигов должна быть глобальная и в одном месте, тогда она может реагировать на события вроде здоровья сервисов или хотя б просто может быть обновлена легко, а не так что надо каждый образ пересобрать
мммм… ну заставь разрабов написать приложение так, чтобы оно само ходило в консул-волт за нужными значениями своих конфигов смысл тот же будет или как ты считаешь?
написать не вопрос, но потом слушать “разработка замедлилась потому что девопсы опять что-то придумали - мне тперь тикет надо создавать чтобы девопс прописал в консуле значение для моего локального енва” )
ну это нормальная ситуация но видишь, тут горит у человека с другой стороны 😕
не получится, потому что консул волт не умеет выполнять логику. Конфиг должен собираться под каждый инстанс приложения прямо в момент запроса и уже на стороне генерации конфига решается куда оно будет ходить, какие параметры использовать и т.д. сейчас это логика разамана по разным CI/CD , чуток в гите , чуток в консуле, чуток в файлах образа
почему в момент запроса, а не когда данные изменились в самом консуле?
потому что иначе придётся генерировать конфиг на каждую комбинацию (stage, location, instance_id)
Это не является проблемой
это как если б kind:Deployment материализовался в несколько в список kind:Pod на стороне CI, а куб про Deployment ничего б не знал. Хорошо б так жить было?
Учитывая, что депломйент убог - возможно и было бы норм
Обсуждают сегодня