Kubernetes с разным набором env-переменных для каждого бранча - с помощью чего и как вы это делаете?
Когда деплой идёт по тэгам или из одной ветки (master) - тут все просто, можно положить файл .env нужный в репу и менять при необходимости, а секреты создать заранее. А вот когда хочется в разных ветках тестить интеграцию с другими API зависимыми и тоже переключать на версию из бранча - тут встаёт вопрос управления этим добром - как это лучше провернуть? Как вы указываете такие эндпоинты под каждый бранч отдельно?
Идейно надо бы создавать ConfigMap под бранч с предопределённым набором эндпоинтов. Но пока что-то Helm так легко не позволяет для 10 .env переменных каждый раз задавать новые значения в бранчах.
я из jenkins это делаю. Во время деплоя хожу по всем сервисам на гит, проверяю есть ли там одноименная ветка, если нет, то направляю этот сервис на ветку develop/master этих сервисов. Если хотим чтобы сервис А смотрел на определенную векту сервиса B, то создаем там одноименную ветку. Но лучше наверное метарпепу иметь, которая деплоет все эти сервисы, и знает куда кому надо смотреть
как в итоге решили вопрос? ps: всё обсуждение по этому вопросу прочитал, но вдруг удалось найти подходящий инструмент
В итоге сделал так: в Helm передаётся название бранча на CI/CD pipeline. Это название используется в нескольких местах: 1)ингресс-контроллере для указания имени хоста: аля abc-123.service или master.service. 2) для префиксования всех сущностей кубера для этой ветки (abc-123-service, abc-123-deployment) 3) для указания пути в Vaulte - проверяю в CD есть ли конфиг специфичный для ветки, если есть - подключается он, иначе конфиг для мастера
Готового ничего не находилось, если вдруг кто найдёт или знает что-то, будет интересно тоже почитать. Пока же решение есть на хелме+Vaulte рабочее
хмм... интересно спасибо!
Обсуждают сегодня