Ну а как правильно тогда?

Правильно шаблонизировать values - helmfile к примеру - но это спорно

нету правильно, если это что-то универсальное, то оно должно быть идемпотентно.. или дайте больше контекста, что вы пытаетесь оптимизнуть

Сейчас, я договорю по тел опишу подробнее что есть и какую проблему решаю...

Хочу шаблонизировать values - расскажи как правильно контекст: 1. Приложуха 2. Деплоится в разные ns 3. Переменные зависят от среды

никак, ладно как

не совсем так)

не деплоить в разные нс, или описывать каждый комонент отдельно и юзать хелмфайл,хелмвайв, аргосд/ flux... etc

Вернемся к нашим баранам) Итак, есть приложуха, она состоит из микросервисов (неожиданно). Есть Кластера (дев, тест, стейдж и тп). Есть Головной хельмчарт для всего. Каждый микросервис описан отдельным сабчартом со своими вэльюс и конфиг.ямл и прочими приблудами. На данный момент получается, что каждый микросервис должен деплоиться во все неймспейсы во все кластера со своими значениями (пути к базам, настройки ингреса, кол-во реплик и пр). Сейчас это все сделано так, что для каждого неймспейса создан отдельный конфиг.ямл И при деплое хельму просто подкладывается нужный конфиг. А теперь момент: в имени конфига зашито имя кластера и имя неймспейса и сиайка при деплое выбирает конфиг по маске. Поддерживать такую струтуру оч сложно, особенно когда у тебя кластеров не один и не два и в каждом неймспейсов не5 и не 10... Вот и идея такая, чтоб был один конфиг и он уже дофаршировывался значениями из файла с переменными вида: namespace1: name: value Namespace2: name: value Готов с радостью выслушать альтернативные идеи решения вопроса)

Вот моя боль)

вот проблема

иерархию переменных и отличия от базовых поясни

Ну вот например в ингресе. Есть там дериктива path. Для одного на она будет path: /app/namespace1/ для ругого /app/namespace2/

там неймспейс вшит? и что ?

Обстрагируйся от того что это нс. Там можно релизнеймспес вкорячить. Просто разные значения в зависимости от нс. Типа разный хост и порт для базы каждому нс

Разные valeus или разные структуры в одном vaules. Делай как удобно. Вот например в одном values stages: prod: &PROD param1: val1 param2: val10 dev: &DEV param1: val2 param2: val30 deploy_app: app1 env: prod apps: app1: prod: <<: *PROD param1: val3 ns: namespace1 dev: <<: *DEV ns: namespace999 app2: prod: <<: *PROD param1: val3 ns: namespace222 dev: <<: *DEV ns: namespace333 При деплое просто указываешь какой апп хочешь зарелизить и c каким енвом helm upgrade -i --set deploy_app=app2,env=dev app ./appChart То что оно у тебя будет в одном values, кучу переменных никуда не пропадут, просто запихнешь их в один values.yaml

Ну вот я так примерно и хотел)

так это тоже самое что несколько vaules. Вместо кучи values, будет куча апов в apps в одном values

Ну это все вынос в сиайку опять таки, а задача именно хельмом обыграть...

какую сиайку?

Ни разу не видел якоря в вальюс) видимо я еще не дорос до такого

Что вам мешает деплоить каждый микросервис отдельно? Зачем тут такой комбайн из кучи ямла и шаблонов

Вот меня тоже это смутило)

@ilya_it C такой структуров тебе придется во всех шаблонах делать в начале что-то типо {{ $env := index (index .Values.apps .Values.deploy_app) .Values.env }} И тогда в шаблоне можно будет к param1 обратится например так: $env.param1

Ну если под каждый микросервис отжельно все делать это еще монструознее выйдет...

нет, ты просто в отличии от меня нормальный чувак, и юзаешь несколько values файлов

Ну вот это я и планировал)

Как красиво указывать вальюс для амбрелла чарт

не знаю

У меня это не микросервис например. А просто различные вариации одного и того же приложения. То есть в чарте не куча разных приложений, а одно, но на проде его вариаций может быть несколько. Разные секреты у них, базы данных, домены, переменные среды и т.д. Но образ один

ну у меня тоже есть универсальный чарт, туда вообще что угодно можно засунуть, я к тому, зачем этим управлять из одно места

не, это не универсальный чарт. Это фактически одно приложение, один код, один образ и один чарт helm, без особых вариаций. Но инсталяций в проде, может быть его несколько, с разными базами, разными доменами и тому подобное

это странно выглядит

Да нет вполне нормально. Например у меня конкретно это бэки для приложений для google, ios, facebook, vkontakte, wechat, mixi, hangame и так далее. Для каждой такой платформы могут быть разные версии такого бэка, они могут деплоятся в разные кластера, и имеют разные базы данных, домены и т.д.

да но как тут ролбэки делать например, релиз то один, просто как по мне таким комбайнов не очнень удобно управлять, мое мнение, если это распилить, описать в том же арго или флюкс, будет куда удобной, да и межкластерные деплои пулл модель намного лучше решает как по мне

релиз не один, каждая вариация отдельный релиз, версии могут отличаться. Роллбек делается просто, указываешь предыдущий тег и делаешь upgrade

можно и с арго, принципиальных отличий не вижу. пуш на пулл только поменяем

+

но это может сломаться, если придется откатится не на предыдущий, комбинаторика говорит, что это возможно и с ростом числа зависимостей вероятность повышается

+

Часто за последние полгода откатывался? А не на предыдущий?

там нет роста числа зависимостей. Выбираешь любой тег, хоть месячной давности, не понял в чем проблема о которой ты говоришь

я имею ввиду ролбэк самого хелм релиза, когда values меняется например

Все равно не понял =). Ну берешь указываешь старый тег, вместо текущего, вот и весь роллбэк

ты в целом говоришь про решение несколько values.yaml vs один values.yaml? Я не топлю ни за какой вариант, если что. Что удобно то и юзать

вот тут под распилить ты что имеешь в виду? На разные values.yaml? Можно и так конечно, я не против

мой посыл в том, чтобы у каждого апа был свой хелмрелиз, когда несколько аппов в одном релизе, при откате ты можешь получить не консистент в одном из них

не понял как это противоречит. Я же не говорил лить в один релиз всё. Я же писал, что такой бэк может вообще в отдельный кластер лится, или в отдельный namespace. Вот например google льется в кластер в европе, wechat в китае. Почему один релиз то?