ну в том что тебе это точно не грозит

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

Это, это что ?

Какие приложухи, какая мясорубка

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

если у вас уже такой вариант рассматривается, значит у вас система не масштабируема

далее разговаривать не интересно

Почему ?

Как плейсмент компонент связан с масштабированием ?

Если у меня апп заехал к базе на хост, как это влияет на масштабирование что базы, что аппа ?

Этот же апп ещё в 5 копиях может крутится на других хостах

если у вас уже такой вариант рассматривается, значит у вас система не масштабируема

Всё ? Вы тока свои аргументы и вопросы рассматриваете ?

гугл в помощь

беда

Всё ? Вы тока свои аргументы и вопросы рассматриваете ?

Имхо, Петр высказал, что слышал где-то. Я сам такое много раз слышал. Но вот когда дело доходит до объяснения, вопрос закрывпется примерно так как Петр сейчас закрыл :) Люди лезут в гугол, но находят толь такие безосновательные утверждения. Так они плодятся и поддерживаются поисковиками, как актуальные. В итоге имеем то, что имеем. В общем, не обащйте внимание на мнения.

просто этот чат казался одним из пары-тройки адекватных чатов российского "около-devops" коммьюнити, и тут нате)

просто этот чат казался одним из пары-тройки адекватных чатов российского "около-devops" коммьюнити, и тут нате)

Пичалька. Ну может это разовая ошибка. Давайте не будем судить строго.

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

ptchol один из представителей неадекватных особей русского сообщества айти

ничоси) Вот это новости.

пишешь о адекватности? Вместо того чтобы нормально обсудить тему, пишешь 'ЧОЙТА' и дальше в этом духе

Если вы ранее говорили про масштабируемость и всё такое, какая вам разница про совместимость aufs/overlay в рамках хоста ? Обновили на новом хосте, и просто мувнулись туда.

Так не я сливаюсь с темы.

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

если ваша система выдерживает держать базу данных и само приложение в одной физ(виртуальной машине) Так как бд обычно самое узкое место в приложениях, каким бы оно ни было. Но если у вас там крутятся маленькие бложики, event calendar или новости, вы можете себе такое позволить.

нет, просто у меня был кейс, когда база была read intensive настолько, что порезанные на 2k iops облачные дисочки выжирала полностью, при этом cpu простаивал. И мы действительно плейсили на эти ноды ряд приложений.

других, не работающих с этой базой

я не понимаю что в этом такого кромольного. Честно.

странные вещи рассказываешь, что если оно выжирает диск полностью, то значит можно поднять еще приложение вне зависимости IO диска

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

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

то есть запуск приложения занимает менее 2-3 секунд?

эмс.

но нет же, у вас полностью диск забит read writaми

нет, доставить образ конечно занимало не 2-3 секунд.

я не понимаю что в этом такого кромольного. Честно.

Ничего, но Петру нужно как-то выбратся из тупика.

лол =)

ну время доставки и старта приложения, конечно не занимало 2-3 секунды, у меня вполне стандартный кейс когда приложение раскатывается на ноде секунд по 30

но как бы, это не критично нисколько

Ничего, но Петру нужно как-то выбратся из тупика.

наверху я уже все описал

никакого тупика не вижу

написал что плохая практика

Ничего, но Петру нужно как-то выбратся из тупика.

го в мой клуб неадекватных)

далее соглашаться с этим мнением или нет ваше решение

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

написал что плохая практика

я пропустил, процетируйте себя пожалуйста.

Довод в том что graphdriver plugin на лету сменить нельзя ?

еще раз повторяю, я вас не заставляю переходить обратно, если вас все устраивает =) сидите. Как говориться "Работает не трогай."

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

классический rolling update решает все задачи, в том числе системных изменений

далее соглашаться с этим мнением или нет ваше решение

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

вот в русском сообществе, еще раз повторяю вместо того чтобы обсудить проблему. У вас какие то разговоры про "тупики", вместо конструктивных доводов, что в каких то юзкейсах есть проблемы и они действительно есть. Говорить что в докере нет проблем - это как минимум глупо, не во всех ситуациях докер это панацея. Я не писал что категорично нельзя использовать ваш докер в бд. Я и сам им пользуюсь, но не в больших проектах. В вашем разговоре просто надо установить кто кого словестно победил - яркая черта русских терпил.

Проблема никогда не бывает линейной

пошла какая то русофобия

Ну я не совсем русский :)

Вы привели один кейс, с проблемой по смене граф драйвера. Я спрашиваю, в случае если вы умеете переключать бд на резерв быстро и без простоя, в чём же суть проблемы ? вайпнули ноду\vps, накатили заново, накатили инстанс базки.

Ну я не совсем русский :)

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

или вы рассматриваете ситуацию "бд в одной копии \ мы не можем без простоя свичнуть мастер и резерв \ у нас приложения не могут быстро переключаться при смене мастера" ?

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

Ну это уже ближе, но вопрос с БД остается открытым.

остальное в гугл иди =) еще раз пишу что если тебе не важно, простаивание процесса в случае kernel panic. Конечно можно бд поднять заново и все слейвы тоже обнулить с корупшион дата. Но пока все очнется будет простаивание, если это не так важно, как и не важно обновление докера или обновление ядра системы изза каких то киллер фитч в пакетах, используй ради бога. Никто тебе ничего не запрещает

не будет "простаивания", и тут дело не в докере.

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

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

еще раз пишу, плохая практика не означает категоричный отказ, пишу в последний раз для одаренных. Для вас разжевывать весь материал, мне может еще бесплатный вебинар для тебя специально устроить? Остальное прочитаешь в гугле, человек пишущий что рядом с бд когда io диска фулл забито, он поднимает рядом приложение ок =) Еще доводы ждет

Ну простой БД на время обновления докера - это аргумент. Но думаю, большинство пойдут на это ради преимуществ.

Вы так и не ответили на мои доводы и вопросы, и опять углубились в "ты ничего не понимаешь, чо те объяснять"

ERROR: S client not available

Да какой простой ?

вот у меня монга, что с докером что без докера master свитчиться сам и я ничего не замечаю.

Да какой простой ?

На время апгрейдо докера

что я делаю не так ?

вопрос тут не в докере, а в том приложение у вас может понять что одна из БД нод стала недоступной и перестать работь с ней и всё.

и в том что если эта нода мастер, то в случае её gracefull shutdown она передаст свои обязанности кому то и всех клиентов тоже

вот у меня монга, что с докером что без докера master свитчиться сам и я ничего не замечаю.

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

если вы к 2018 не научились делать так, ну что, печалька.

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

Если у вас все так стабильно, ни одного data corruption, ни одного kernel panic

вот у меня монга, что с докером что без докера master свитчиться сам и я ничего не замечаю.

как ты данные синхронизируешь?

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

как ты данные синхронизируешь?

это делает механизм репликации.

а дальше политики acknowledgement уже настраиваются и конфугирурются в зависимости от БД. Это стандартный подход, что в монге, что в ПГ, что в кассандре

Если у вас все так стабильно, ни одного data corruption, ни одного kernel panic

Суть в том, что докер не добавляет вероятности ни паник, ни корраптов. Или ошибаюсь?

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

Суть в том, что докер не добавляет вероятности ни паник, ни корраптов. Или ошибаюсь?

чисто теоретически, в случае завершения работы базки, в стандартном поведении докера, если приложение не завершилось за 30сек ему в лицо прилетит sigkill что может негативно повлиять на данные ряда БД

это кстати стандартное же поведение и для systemd )

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

о том что не стоит юзать ПГ ? )

лол видишь ты опять за свое

эмс, ну ладно вам, разок трольнул, за 5 страниц текста.

я не пишу категорично не юзай, еще раз, я не писал категорически не юзай, повторяю еще раз я не писал категорически не юзай

сколько раз повторить?

эмс, ну ладно вам, разок трольнул, за 5 страниц текста.

вот еще одно поведение совка

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

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

вот еще одно поведение совка

лол) у меня тут у коллеги отец умер и они шутили в общем чатике про "Добро пожаловать в dead dad club") и ничо )

если вы такой крутой напишите статью где нибудь, в том же habrahabr о своем сетапе, посмотрим сколько вы плюсов наберете

американцы )

есть инфа по вашему сетапу

если вы такой крутой напишите статью где нибудь, в том же habrahabr о своем сетапе, посмотрим сколько вы плюсов наберете

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

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

ну в последнее время так и есть. Но хоть какой то будет сабж