Ivan
в композе прописываю новую версию тэга и перезапускаю
Sebor▂▅▇█▓▒░
Раз-раз прописал новый тег образа и перезапустил
Ivan
хотя нет, папка постгреса тоже вроде монтируется
Ivan
данные же не теряются после перезапуска
Sebor▂▅▇█▓▒░
Конечно монтируется
Sebor▂▅▇█▓▒░
Только бэкапить ее все равно неудобно
Владимир
поидее надо потсгрес в отдельном контейнере держать, встроенный же они могут обновить и твой волум не примет
Ivan
нет, там всё ок.
автоматом всё конвертится
Владимир
ну тогда volumes + контейнер - необходимо и достаточно что бы восстановиться?)
Sebor▂▅▇█▓▒░
Ох уж эти хипстеры, все подряд тянут в контейнеры
Владимир
А есть какоето готовое решение ты ему доступ к куберу а оно тебе бэкап всего что там найдет?))
Sebor▂▅▇█▓▒░
Контейнеры - это по большей части стейтлес. Если вам нужно что-то бэкапить там, то что-то вы делаете не то. Ну или вы просто извращенец)
Igor
я бы сказал, что то, что работает в контейнерах - не должно иметь необходимости бекапиться
Igor
иначе вы действительно что-то делаете не правильно =))
Mikhail [azalio]
а etcd при установке через кубеадм где поднимается? )
Mikhail [azalio]
что, не бекапить тогда?
Andrey
Тем более бэкапить там полтора байта.
Vadim
А есть какоето готовое решение ты ему доступ к куберу а оно тебе бэкап всего что там найдет?))
бэкапь etcd, для пользовательских приложений операторы умеет бэкапить - см. https://github.com/operator-framework/awesome-operators
Владимир
Контейнеры - это по большей части стейтлес. Если вам нужно что-то бэкапить там, то что-то вы делаете не то. Ну или вы просто извращенец)
имелось ввиду сбэкапить содержимое volumes и конфигурацию а не контейнеры. Что бы потом на идентичном кластере быстро все развернуть
Etki
кто-то все еще использует volumes? 😏
Etki
volume - это такая штука, которую непонятно зачем придумали в докере и затем непонятно зачем начали использовать все
Etki
потом внезапно оказывается, что диск заполнен этим говнищем до краев, а функционал ровно тот же, как просто смаунтить директорию
Владимир
Это надо обдумать)) Вроде докер рекомендовал вольюмы а про маунт отмалчивались)
Sebor▂▅▇█▓▒░
Почему бы базу не держать на отдельном сервере по классике?
Я не понимаю этого тренда - сувать бд в докер
𝚔𝚟𝚊𝚙𝚜
Вчера попробовал stolon, обернул как daemonset, бд хранятся на hostPath - не вижу причин не использовать
Igor
Почему бы базу не держать на отдельном сервере по классике?
Я не понимаю этого тренда - сувать бд в докер
Когда полно девелоперов со своими стендами, это удобно :)
𝚔𝚟𝚊𝚙𝚜
или просто когда много бд
Sebor▂▅▇█▓▒░
Несколько бд можно по прежнему на один инстанс вешать, а не плодить на каждый сервис новый
И потом сношаться с кучей сущностей...
Igor
nfrjt
Igor
такое
Igor
у нас хайлоад
Igor
несколько бд на одном сервере - это плохо
Igor
:))
Igor
Но, правда, мы в пром не пустили бд на докерах
Igor
только девелоперские стенды
Etki
Несколько бд можно по прежнему на один инстанс вешать, а не плодить на каждый сервис новый
И потом сношаться с кучей сущностей...
в чем принципиальная разница? (кроме того, что в одном случае достаточно подчищать только внутри одного неймспейса, а в другом надо менеджить еще лайфсайкл БД внутри инстанса)
Andor
"У нас хайлоад поэтому базы в докере"?
Andor
А, ок
Igor
+))
Vadim
Несколько бд можно по прежнему на один инстанс вешать, а не плодить на каждый сервис новый
И потом сношаться с кучей сущностей...
решил поправить настройки базы = все подождут? И бэкапить кучу девелоперского шлака?
𝚔𝚟𝚊𝚙𝚜
вертикально скалить не до бесконечности можно
Sebor▂▅▇█▓▒░
У дев стенда отдельный стенд. Или кто-то серьезно хочет держать все бд на одном сервер?
Sebor▂▅▇█▓▒░
решил поправить настройки базы = все подождут? И бэкапить кучу девелоперского шлака?
А у тебя сервис с отдельной бд на сколько интегрирован с другими?
Vadim
А у тебя сервис с отдельной бд на сколько интегрирован с другими?
у меня никакого сервиса нет, просто интересны аргументы сторон таксказать
Airat
решил поправить настройки базы = все подождут? И бэкапить кучу девелоперского шлака?
Большинство настроек применяются без рестарта СУБД.
В случае с БД, докер - лишняя потенциальная точка отказа
Sebor▂▅▇█▓▒░
вертикально скалить не до бесконечности можно
А скейл тут причем?
И да, интересно, на сколько легко скелить реляционку горизонтально? Разве контейнеры тут помогут?
Etki
Большинство настроек применяются без рестарта СУБД.
В случае с БД, докер - лишняя потенциальная точка отказа
вы же понимаете, что запущенный докером процесс ничем не отличается от других процессов в системе?
Andor
и cgroups бесплатные, ага
Etki
как будто процессы вне докера не под cgroups
Sebor▂▅▇█▓▒░
несколько бд на одном сервере - это плохо
Конечно зависит от нагрузки. Да и ты сам пишешь, что на проде не используете в докере)
Airat
Таки потенциальная. А смысла БД держать в докере нет
Etki
Давайте докопаемся до мышей. Потенциальная что? Что именно произойдет?
Airat
Приложения в докере - самое то, собрал в ci дистрибутив и растиражировал
Vadim
Таки потенциальная. А смысла БД держать в докере нет
да, если не считать нормального неймспейсинга, готовых операторов с мониторингов и бэкапами и полноценным разделением конфигов
Igor
Хз. У нас в планах поднятие отлельного кубер кластера под разработчиков
Igor
Имхо - для дева решение топовое
Sebor▂▅▇█▓▒░
Я сейчас рассуждаю с т.з. эксплуатации: вот представьте, что у вас несколько бд живут на одном отдельном сервер (хоть на нескольких, но все равно не 1к1 по сервисам). И вам нужно это дело как-то обслуживать - репликация/кластеризация/бэкап
Andor
Давайте докопаемся до мышей. Потенциальная что? Что именно произойдет?
Подправил мелочь в конфиге постгреса и хочешь сделать ему релоад (не рестарт!)
Etki
И как докер этому мешает?
Airat
Для дева, когда потеря или простой субд неважен, хорошо, можно быстро развернуть
𝚔𝚟𝚊𝚙𝚜
А скейл тут причем?
И да, интересно, на сколько легко скелить реляционку горизонтально? Разве контейнеры тут помогут?
вопрос в количестве баз данных, если их достаточно много, нет никаких проблем запускать их на одном сервере, но ресурсы сервера ограничены и со временем вам все равно придется деплоить новые сервера.
А как этого достичь это уже другой вопрос, мое мнение лучше когда оно все в одной экосистеме
Sebor▂▅▇█▓▒░
Я сейчас рассуждаю с т.з. эксплуатации: вот представьте, что у вас несколько бд живут на одном отдельном сервер (хоть на нескольких, но все равно не 1к1 по сервисам). И вам нужно это дело как-то обслуживать - репликация/кластеризация/бэкап
Вторая ситуация - на каждый сервис деплоит вся отдельная бд в докере (ещё и с маунтами/вольюмами). И как этим хозяйством управлять теперь?
𝚔𝚟𝚊𝚙𝚜
ну плюс когда у вас много серверов с маленькими бд любой outage будет гораздо менее затратным чем в случае одного большого
Etki
Имхо - для дева решение топовое
Мне больше всего нравится идея с тестингом и сравнением производительности версий. Поднять все приложение из кучи микросервисов и затем его прибить, поднять чуть-чуть отличающийся конфиг - никаких проблем. Ну и да, идеально если на каждую фича-ветку создается отдельный деплоймент, который каждый может трогать руками.
Airat
Про "потенциальные точки отказа". ПО может сбоить, жто бывает, Постгрес может дать осечку. А если слон в докере, появляется теоретическая вероятность сбоя в работе докер сервиса. А профита от бд в докере нет. Поэтому в проде этот подход неоправдан
Airat
+1 теоретическая точка отказа
Igor
Мне больше всего нравится идея с тестингом и сравнением производительности версий. Поднять все приложение из кучи микросервисов и затем его прибить, поднять чуть-чуть отличающийся конфиг - никаких проблем. Ну и да, идеально если на каждую фича-ветку создается отдельный деплоймент, который каждый может трогать руками.
Жаль, что у нас все это говнище на этапе внедрения.
Ска, слишком дохрена жопы возникает из-ха bare-metal :))
Airat
А бд - почти самое важное
Sebor▂▅▇█▓▒░
вопрос в количестве баз данных, если их достаточно много, нет никаких проблем запускать их на одном сервере, но ресурсы сервера ограничены и со временем вам все равно придется деплоить новые сервера.
А как этого достичь это уже другой вопрос, мое мнение лучше когда оно все в одной экосистеме
В одной экосистеме - в смысле все в докере? Повторюсь - масштабировать бд горизонтально не тривиальная задача (речь конечно же про реляционки в первую очередь)
Igor
Про "потенциальные точки отказа". ПО может сбоить, жто бывает, Постгрес может дать осечку. А если слон в докере, появляется теоретическая вероятность сбоя в работе докер сервиса. А профита от бд в докере нет. Поэтому в проде этот подход неоправдан
Не согласен, кстати.
Если есть нормальная сетевая хранилка, и слегка подтюненная бд, то все хорошо
Igor
В теории, по коайней мере.
На практике не работал с подобным решением, но хлчется
Sebor▂▅▇█▓▒░
Про "потенциальные точки отказа". ПО может сбоить, жто бывает, Постгрес может дать осечку. А если слон в докере, появляется теоретическая вероятность сбоя в работе докер сервиса. А профита от бд в докере нет. Поэтому в проде этот подход неоправдан
+ если слон в докере появляется дополнительный гемор с репликацией/бэкапом/кластеризацией
Vadim
+ если слон в докере появляется дополнительный гемор с репликацией/бэкапом/кластеризацией
операторы всё это давно умеют
Etki
Про "потенциальные точки отказа". ПО может сбоить, жто бывает, Постгрес может дать осечку. А если слон в докере, появляется теоретическая вероятность сбоя в работе докер сервиса. А профита от бд в докере нет. Поэтому в проде этот подход неоправдан
https://docs.docker.com/config/containers/live-restore/ давно же запилили уже
Etki
пусть падает сколько хочет
Vadim
В теории, по коайней мере.
На практике не работал с подобным решением, но хлчется
zalando делают свой патрони, у них это давно в проде. Правда, не могу похвастаться что кто-то из наших кастомеров такое делает - еще не слышал чтобы кто-то перешел