GG
Насчёт создания БД - я видел очень красивое решение от коллег с конференции Мейла, где они создали кастомный контроллер для объекта databaseclaim )))
Size: a a a
2021 January 04
S
а если подлиннее), можешь пнуть на пример?
External Service в кубере
GG
Пихаешь все объекты в один неймспейс для конкретного «инстанса» - и все ок
GG
External Service в кубере
+
R
Насчёт нескольких деплойментов - можно через тот же консул исхитриться ) т.е. есть некая матрица конфигов и приложение само с собой договаривается и определяет какой подтягивать, но сложно в реализации. Наверное, проще действительно разные деплоймент тащить
Звучит сложнее, чем несколько деплойментов сделать. Опять же не хочется эту логику с маршрутизацией и менеджментом БД коннекшенов в приложения тащить, в моем случае это чисто инфраструктурная часть.
В общем, пойду писать CRD и контроллеры под них, спасибо
В общем, пойду писать CRD и контроллеры под них, спасибо
GG
Но не обязательно. Можно в ингресса вообще кастомный апстрим задать
S
Но не обязательно. Можно в ингресса вообще кастомный апстрим задать
+)
S
Но так обсервабилити будет лучше
ВМ
External Service в кубере
спасибо), теперь хоть есть что погуглить)
R
Сделаю свой кастомный "деплоймент темплейт", и при апдейте имейджа в нем все "дочерние" деплойменты будут апдйетиться тоже. И маппинг деплойментов к БД тоже отдельным CRD можно сделать.
S
Ох и адовые задачки вы решаете, коллега
ВМ
Ох и адовые задачки вы решаете, коллега
если Вы мне, то у меня это как временное решение, там выносится на поддомен сервис и пока его не вынесли я буду его через ингресс прокидывать.
S
если Вы мне, то у меня это как временное решение, там выносится на поддомен сервис и пока его не вынесли я буду его через ингресс прокидывать.
Не. У вас все просто на самом деле и кейс для решения стандартный. Обычно тяжело за всем следить когда точек отказа в разных местах много. Когда все или почти все в кубере всегда проще потому и проще объект с которым вы собрались работать поселить в кубер
S
Я про Роберта :)
R
В моем случае пилим SaaS, и хочется одно и то же приложение давать разным клиентам, но на dedicated инфраструктуре (отдельная БД каждому, и в зависимости от плана отдельные воркер ноды). При этом цикл разработки иметь продуктовый, т.к. приложение по факту одно (ок, несколько, но со схожими циклами жизни), и когда релизим для одного, релизим для всех в общем случае
R
Много ручной работы выходит, если не автоматизировать как-то
GG
В моем случае пилим SaaS, и хочется одно и то же приложение давать разным клиентам, но на dedicated инфраструктуре (отдельная БД каждому, и в зависимости от плана отдельные воркер ноды). При этом цикл разработки иметь продуктовый, т.к. приложение по факту одно (ок, несколько, но со схожими циклами жизни), и когда релизим для одного, релизим для всех в общем случае
Тогда похоже вам оператор нужен )
R
Да, мне тоже так показалось, хорошо мапится на CRD, осталось формат удобный придумать
GG
Очевидно же - джисон сосисон )
Там основной затык будет в описании лайфсайкл приложения ₽ а потом поддержке обратной совместимости между разными итерациями разработки оператора
Там основной затык будет в описании лайфсайкл приложения ₽ а потом поддержке обратной совместимости между разными итерациями разработки оператора