Спасибо дай бог тебе здоровья

Да вот фиг знает. Если хош, можем в @sds_ru обсудить дальше, все-таки не про кубер это

Всем добрый день, подскажите а у кого нибудь в кубер кластере реализована развертывание окружения на бранч в гите? ну т.е разработчики создают ветки и  пайплайн запускает процесс развертывания там 3-4 приложений в кубере?

привет. Да

а можешь подсказать засчет чего у вас это реализовано? развертываемое приложение понимает о своих зависимостях через dependencies в helm chart'е или как то по другому?

у меня все просто, одна репа - одно приложение - один чарт. Зависимости не использую.
Если приложение имеет два сервиса или больше, то как правило это отдельные репы и отдельные чарты у каждого.  Тут работает правило что ветка А сервиса А идет в ветку А сервиса Б. Если надо для тестов соеденить разные ветки у сервисов, то используется спец задача в CI, где тестер выбирает ветки у сервисов и нажимает кнопочку деплой.
То есть по сути кто куда  должен конектится на уровне CI решается

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

в отдельном нэймспейсе конечно же

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

У нас если над фронтендом и бэком работают меньше 5 человек это одна репа - один чарт - тут все просто.
Если над фронтом и бэком отдельные команды, то разные репы и все происходит как я описал выше.
Каждая ветка в репе фронта выкатывается и каждая ветка бэка выкатывается, ветка А фронта, в качестве бэка использует ветку А (одноименную) бэкенда.
+ есть задача в CI, в которой ты можешь выкатить оба чарта из выбранных веток

интересный вариант, спасибо)

Народ скажите, нужна самая быстрая очередь, и pub-sub из имеющихся на рынке. Персистентность не нужна.
ZeroMQ написана на Си, она же быстрее Nats ?

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

0mq это про другое

как бы как сравнивать голвй tcp и http

ну и определился с гарантиями доставки и прочими плюшками, какие вам там нужны

в целом - любая технология может дать примерно одинаковый срюпут

что кафка, что ребит

другой вопрос, что на практике - там все зависит от скалируемости

та же кафка рулит, потому что партиции наращивать и масштабироваться очень сильно