БД для docker

ы расскажи какой мне профит от докеризации/контейнеризации постгреса либо того же мускуля?

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

Что будешь делать?

Нормальную виртуалку поставлю. Ибо пихать БД в докер... ну выше было уже.

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

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

Нормальную виртуалку поставлю. Ибо пихать БД в докер... ну выше было уже.

Против религиозных тезисов возражений не имею.

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

Тем же, чем и докеризация всего остального, не?

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

Волюмы это не персистентность

А что?

они находятся за пределами контейнера

Это рекомендуемый способ хранения данных в Docker'е. А вы написали:

Никогда не клади БД в докер. Сколько раз уже говорено и писано об этом. В докере не должно быть данных. Точка.
Докер не умеет в персистентность. Более того, он и не планировал ее уметь никогда, это фича. Все, что ты засунул в докер, может подохнуть в любой момент

докеризация stateless говна помогает мне легко масштабировать это говно в случае проблем с производительностью этого говна. как мне поможет докеризация постгреса в случае проблем с производительностью постгреса?

А что?

Это внешнее хранилище.

Это рекомендуемый способ хранения данных в Docker'е. А вы написали:

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

Не уверен, что он такие слова умные знает. Ему просто лень/не умеет поднять сервер БД, потому проще дернуть докер.

Не в докере, а для докера.

Как вы определяете, что «в», а что «для»?

Смысла гонять на девелоперской машине окружение, которое никогда не попадет в продакшен - нет.

Т.е. если мне нужно проверить как libfoo-x.y.z работает с сервером бд blah-k.l.m, мне нужно закупать десяток серверов и СХД, раз в продакшене оно будет развёртываться именно на таком оборудовании?

Вот облом.

Потому что тогда софт будет написан не для того, чтобы он работал в продакшене, а для того, чтобы он работал у погромистов.

Ты просто гуру тестирования.

А. Я понял. Ты просто путаешь докер-контейнеры и микросервисную архитектуру. Они действительно часто используются вместе, но это далеко не синонимы.

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

В лоб - никак

А вот если сначала наделить его свойством stateless, то он станет stateless говном, а к этому уже можно применит докеризацию, что избавит от проблем с производительностью

Ну както так…

а теперь найди, где я говорил о том, что это синонимы.

Нигде. Но твои тексты станут верными, если все вхождения слова «докер» заменить на «микросервисная архитектура».

как оно поможет мне с постгресом, мне ответит кто-нибудь?

Как я уже и говорил ранее, точно так же, как поможет со всем остальным. Как оно это делает, ты сможешь узнать, зайдя на hub.docker.com и проверив как люди используют докер/

кто мне конфиги поправит, репликацию настроит. или докер мне как-то поможет в ситуации, когда вдруг понадобился шардинг?

тебе никто его не «настроит» - ты должен написать софт (какой-то гипервизор), который сам будет инспектить текущее состояние кластера и настраивать его автоматически.

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

докер - один из многих кирпичиков на большом пути

погугли, что такое hyperconvergence и как работает современный девопс (гугл даже сделал про это бесплатную книжку: https://landing.google.com/sre/book.html)

Нигде. Но твои тексты станут верными, если все вхождения слова «докер» заменить на «микросервисная архитектура».

анус себе замени, пёс. меня мои тексты устраивают именно в том виде, в котором я их написал

Как я уже и говорил ранее, точно так же, как поможет со всем остальным. Как оно это делает, ты сможешь узнать, зайдя на hub.docker.com и проверив как люди используют докер/

то есть ответа не будет, только бла-бла-бла? зачем ты тогда в принципе в тред влазил?

докер - один из многих кирпичиков на большом пути

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

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

Но ведь тогда получается глупость.

то есть ответа не будет,

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

1. Ты смотришь на вещи не под тем углом.

2. Если сотни тысяч инженеров используют метод а, чтобы решить задачу А, значит метод а небесполезен и, возможно, пригодится и тебе.

Дальше сам.

потому что докер решает кусок этого пути. Это очень, очень технически сложный кусок, чтобы простой быдлокодер сам мог за месяц времени и бочку смузи написать свой аналог Докера. Обычным людям (не гуглам с майкрософтами) приходится жрать что есть и обмазывать его клеем и костылями. Плюс вокруг докера уже есть огромное количество утилит (типа кубернетиса), которые тоже самому писать долго, а для докера уже всё готово, достаточно обмазать костылями и смузи.

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

так какую задачу А решают сотни тысяч инженеров, расскажешь?

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

Вот, например, прямо сейчас я планирую провести пару экспериментов с elasticsearch. И всё, что мне нужно, это сделать.

$ docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:5.6.0

И никакого секса с установкой 100-500 библиотек, разрешения конфликтов версий и корректным удалением этого барахла через час, когда я закончу. Это ли не счастье?

это твое счастье имеет два небольших недостатка: оно не имеет отношения к

а) хранению данных

б) продакшну

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

P.S. И со стороны разработчиков тоже хорошо. Они собирают один образ один раз. А не овер 9к пакетов под все используемые версии (т.е. лет на 5 в прошлое) всех популярных дистрибутивов. После чего всё равно остаются всякие отщепенцы которые ноют на весь интернет, что для их школолинукса не собрали пакетика.

Ну, ты спрашивал зачем нужен докер. Я ответил.

чукча не читатель, ясно. да и писатель тоже так себе

я пытался :-(

Никогда не клади БД в докер

Нафиг тогда Докер, с таким подходом.

Какая из них будет предпочтительней в использовании?

PostgreSQL конечно. Про не завершение, это скорее всего кто-то криворукий.

Нафиг тогда Докер, с таким подходом.

«для всякого stateless-говна»

Ваш юзкейс stateless , а его statefull.

Чтобы ему было такое же счастье как вам (ну почти такое же), ему надо что-то типа архитектуры ceph , только вместо OSD - PostgreSQLDBSD :)

Ваш юзкейс stateless

Стоит добавить '-v /path/to/local/dir:/usr/share/elasticsearch/data' и внезапно stateless превращается в statefull.

Но это не важно. Вопрос не в том, что можно ли использовать docker для statefull приложений, а в том, когда и зачем использовать (а когда не использовать) контейнерную виртуализацию.

Стоит добавить '-v /path/to/local/dir:/usr/share/elasticsearch/data' и внезапно stateless превращается в statefull

нет, не превращается, вы получили stateless контейнер и прицепили к нему внешний state.

Вопрос не в том, что можно ли использовать docker для statefull приложений

вопрос анонима как раз в этом

нет, не превращается, вы получили stateless контейнер и прицепили к нему внешний state.

Поясни пожалуйста, в чём разница?

У вас какой-то сумасшедший контейнеры рандомно кладёт

Есть такая практика в нетфликсе - chaos monkey, оно как-раз этим и занимается для тестирования факапоустойчивости инфраструктуры. Ответственные за разработку сервиса, приведшего к падению остальных, огребают знатных люлей и после этого начинают писать идеальный код и продумывать архитектуру более тщательно тут должна была быть шутка про каскадные падения, но её удалят модераторы stevejobs, но даже хороший кот не спасает от рандомных падений(не по причине chaos monkey) в большой инфраструктуре и к этому надо быть готовым.

Можно и яйца дверью прищемить, но как это относится к sigterm/sigkill?

Hyperconvergence является предметной областью и задачей, жизненно необходимой.

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

Вопрос в том, что для этого есть лучше Docker.

В том-то и дело, что у докера нет никаких преимущества перед оркестраторами баз данных.

То есть, базы данных и их файловые хранилища так или иначе будут виртуализованы, это не вопрос.

кококо, докероблака.

докер - один из многих кирпичиков на большом пути

вот именно, что один из многих вариантов. во многих органихациях есть ci/cd, hypercorvergence и прочие базворды, но нет докера. и не придвидится, потому что уже давно без него процессы отлажены.

и как работает современный девопс (гугл даже сделал про это бесплатную книжку

и где в этой книге про hyperconvergence?

погугли, что такое hyperconvergence

вот ты бы сам и погуглил что это такое, а то смешно читать горе-архитектора.

у докера нет никаких преимущества перед оркестраторами баз данных.

А у руля нет никаких преимущест перед подушкой безопасности.

stateless - функция, statefull - объект. Понятна разница?

так что пекмоп — клоун?

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

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

точно-точно, а потом, чтобы закрыть критическую уязвимость, вместо обновления хоста, пересобираем все контейнеры, это я ещё молчу про дублирование 100500 версий mycoollib.so.{0..9}.{0..9} и «всё, что нужно для своей работы.». приходи когда у тебя будет овер9к контейнеров в проде.

stateless - функция, statefull - объект. Понятна разница?

Всё ещё нет. Телепат из меня так себе. Не могли бы вы изъясняться менее лаконично?

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

Для твоей задачи подходит не докер, а snap или flatpak

Да, это другой (тоже хороший) подход для решения тех же проблем. У него есть как преимущества (легковесность, скорость), так и недостатки (отстутсвие полноценной изоляции).

Гражданин, вы не на митинге.

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

да. Это проблема?

я ещё молчу про дублирование 100500 версий mycoollib.so.{0..9}.

и правильно молчите. Продолжайте в том же духе.