Тем более бэкапить там полтора байта.

А есть какоето готовое решение ты ему доступ к куберу а оно тебе бэкап всего что там найдет?))

бэкапь etcd, для пользовательских приложений операторы умеет бэкапить - см. https://github.com/operator-framework/awesome-operators

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

имелось ввиду сбэкапить содержимое volumes и конфигурацию а не контейнеры. Что бы потом на идентичном кластере быстро все развернуть

кто-то все еще использует volumes? ?

кто-то все еще использует volumes? ?

Это про терминологию? Или где базу хранить нынче?

кто-то все еще использует volumes? ?

А что вместо них в тренде?

volume - это такая штука, которую непонятно зачем придумали в докере и затем непонятно зачем начали использовать все

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

Это надо обдумать)) Вроде докер рекомендовал вольюмы а про маунт отмалчивались)

Почему бы базу не держать на отдельном сервере по классике? Я не понимаю этого тренда - сувать бд в докер

Вчера попробовал stolon, обернул как daemonset, бд хранятся на hostPath - не вижу причин не использовать

Почему бы базу не держать на отдельном сервере по классике? Я не понимаю этого тренда - сувать бд в докер

Когда полно девелоперов со своими стендами, это удобно :)

или просто когда много бд

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

nfrjt

такое

у нас хайлоад

несколько бд на одном сервере - это плохо

:))

Но, правда, мы в пром не пустили бд на докерах

только девелоперские стенды

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

в чем принципиальная разница? (кроме того, что в одном случае достаточно подчищать только внутри одного неймспейса, а в другом надо менеджить еще лайфсайкл БД внутри инстанса)

"У нас хайлоад поэтому базы в докере"?

А, ок

+))

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

решил поправить настройки базы = все подождут? И бэкапить кучу девелоперского шлака?

вертикально скалить не до бесконечности можно

У дев стенда отдельный стенд. Или кто-то серьезно хочет держать все бд на одном сервер?

решил поправить настройки базы = все подождут? И бэкапить кучу девелоперского шлака?

А у тебя сервис с отдельной бд на сколько интегрирован с другими?

А у тебя сервис с отдельной бд на сколько интегрирован с другими?

у меня никакого сервиса нет, просто интересны аргументы сторон таксказать

решил поправить настройки базы = все подождут? И бэкапить кучу девелоперского шлака?

Большинство настроек применяются без рестарта СУБД. В случае с БД, докер - лишняя потенциальная точка отказа

вертикально скалить не до бесконечности можно

А скейл тут причем? И да, интересно, на сколько легко скелить реляционку горизонтально? Разве контейнеры тут помогут?

Большинство настроек применяются без рестарта СУБД. В случае с БД, докер - лишняя потенциальная точка отказа

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

и cgroups бесплатные, ага

как будто процессы вне докера не под cgroups

несколько бд на одном сервере - это плохо

Конечно зависит от нагрузки. Да и ты сам пишешь, что на проде не используете в докере)

Таки потенциальная. А смысла БД держать в докере нет

Давайте докопаемся до мышей. Потенциальная что? Что именно произойдет?

Приложения в докере - самое то, собрал в ci дистрибутив и растиражировал

Таки потенциальная. А смысла БД держать в докере нет

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

Хз. У нас в планах поднятие отлельного кубер кластера под разработчиков

Имхо - для дева решение топовое

Я сейчас рассуждаю с т.з. эксплуатации: вот представьте, что у вас несколько бд живут на одном отдельном сервер (хоть на нескольких, но все равно не 1к1 по сервисам). И вам нужно это дело как-то обслуживать - репликация/кластеризация/бэкап

Давайте докопаемся до мышей. Потенциальная что? Что именно произойдет?

Подправил мелочь в конфиге постгреса и хочешь сделать ему релоад (не рестарт!)

И как докер этому мешает?

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

А скейл тут причем? И да, интересно, на сколько легко скелить реляционку горизонтально? Разве контейнеры тут помогут?

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

Я сейчас рассуждаю с т.з. эксплуатации: вот представьте, что у вас несколько бд живут на одном отдельном сервер (хоть на нескольких, но все равно не 1к1 по сервисам). И вам нужно это дело как-то обслуживать - репликация/кластеризация/бэкап

Вторая ситуация - на каждый сервис деплоит вся отдельная бд в докере (ещё и с маунтами/вольюмами). И как этим хозяйством управлять теперь?

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

Имхо - для дева решение топовое

Мне больше всего нравится идея с тестингом и сравнением производительности версий. Поднять все приложение из кучи микросервисов и затем его прибить, поднять чуть-чуть отличающийся конфиг - никаких проблем. Ну и да, идеально если на каждую фича-ветку создается отдельный деплоймент, который каждый может трогать руками.

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

+1 теоретическая точка отказа

Мне больше всего нравится идея с тестингом и сравнением производительности версий. Поднять все приложение из кучи микросервисов и затем его прибить, поднять чуть-чуть отличающийся конфиг - никаких проблем. Ну и да, идеально если на каждую фича-ветку создается отдельный деплоймент, который каждый может трогать руками.

Жаль, что у нас все это говнище на этапе внедрения. Ска, слишком дохрена жопы возникает из-ха bare-metal :))

А бд - почти самое важное

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

В одной экосистеме - в смысле все в докере? Повторюсь - масштабировать бд горизонтально не тривиальная задача (речь конечно же про реляционки в первую очередь)

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

Не согласен, кстати. Если есть нормальная сетевая хранилка, и слегка подтюненная бд, то все хорошо

В теории, по коайней мере. На практике не работал с подобным решением, но хлчется

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

+ если слон в докере появляется дополнительный гемор с репликацией/бэкапом/кластеризацией

+ если слон в докере появляется дополнительный гемор с репликацией/бэкапом/кластеризацией

операторы всё это давно умеют

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

https://docs.docker.com/config/containers/live-restore/ давно же запилили уже

пусть падает сколько хочет

В теории, по коайней мере. На практике не работал с подобным решением, но хлчется

zalando делают свой патрони, у них это давно в проде. Правда, не могу похвастаться что кто-то из наших кастомеров такое делает - еще не слышал чтобы кто-то перешел

операторы всё это давно умеют

Что есть операторы?

В одной экосистеме - в смысле все в докере? Повторюсь - масштабировать бд горизонтально не тривиальная задача (речь конечно же про реляционки в первую очередь)

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

оператор это такая хреновина чтобы удобно управлять стейтфул-сервисами

ERROR: S client not available

Что есть операторы?

https://coreos.com/operators/

Что есть операторы?

Балансер для бд, если мне не идменяет память

единая экосистема - кубер имел ввиду

Балансер для бд, если мне не идменяет память

Не то, чтобы совсем не попал :))

не, оператор эт что бы можно было оперировать сервисами с такой-же легкостью как и деплойментами: kubectl create mysql --replicas=3 --username=asd ...и у тебя готовый кластер с бд на три реплики

https://docs.docker.com/config/containers/live-restore/ давно же запилили уже

Это замечательно. Но не думаете же вы, что теперь докер совсем не ломается. Я верю, что докер надежен, но раз в год и палка стреляет

докер никогда не был надёжен

компьютер никогда не был надёжен

не, оператор эт что бы можно было оперировать сервисами с такой-же легкостью как и деплойментами: kubectl create mysql --replicas=3 --username=asd ...и у тебя готовый кластер с бд на три реплики

По-моему ты helm описал :))

докер никогда не был надёжен

Ща тебе влетит)

за что?

докер вообще говно

Полностью поддерживаю

По-моему ты helm описал :))

ну по сути это как helm только с crd и встроенный в кубернетес

Хипстерская игрушка!

По-моему ты helm описал :))

не, там процесс внутри кубера (и работающий через кубе-апи) поддерживает три реплики например

докер вообще говно

+1

не, там процесс внутри кубера (и работающий через кубе-апи) поддерживает три реплики например

Да, понимаю. Просто именно того описания - хватает на хелм, но не на оператора х)

https://coreos.com/operators/

Хм, и как оно? В проде на хайлоаде кто-нибудь использует?)

Это замечательно. Но не думаете же вы, что теперь докер совсем не ломается. Я верю, что докер надежен, но раз в год и палка стреляет

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

Хм, и как оно? В проде на хайлоаде кто-нибудь использует?)

странный вопрос, операторы - это паттерн

они уже мейнстрим

Я видимо уже стар для мейнстрима)

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

Это не единственный вариант сбоя

Пихать докер во все места только потому что могу - порочная практика

Пихать докер во все места только потому что могу - порочная практика

Правильно, надо не докер пихать, а В докер пихать) тогда норм будет)

Это не единственный вариант сбоя

какой еще?

пихать надо в кубернетес, а там пусть в cri-o хоть в clear containers запускает

надо просто набор практик сделать на тему "куда чо пихать", и назвать Lubernetes

интересно, почему в stolon решили не юзать pgbouncer и вообще пулинг

Забавно, ровно раз в две недели здесь поднимается тема по DB в контейнерах.