Здравствуйте, Privalov, Вы писали:
S>>А серебряной пули не бывает. Подобный человек — не панацея для всех бед. К тому же и у тебя изначально нужных знаний не было. Понятное дело что в чём-то он будет опираться на ваше мнение, гдето на своём настаивать и так далее. Но он избавит вас от проблем "аааа дллхэллл нада три версии одной либы линупсгавно".
P>Серебряная пуля — это немного о другом. Да, изначально у меня не было нужных знаний. Но во время работы над проектом они появились. Разработчик же читает литературу, ставит эксперименты. Это исттчник нужных знаний, нет? А вот админу этого ничего не нужно. У него другие задачи.
Ты путаешь админов вашей инфраструктуры с админом/девапсом, цель которого чтобы ваш софт безболезненно устанавливался и работал у заказчика. И вот ему уже просто необходимо будет погрузиться в проблематику и ваших диб, может даже в код посмотреть и так далее.
Здравствуйте, Sheridan, Вы писали:
S>Зачем устанавливать томкат? Надо добавлять его в зависимости пакета. Вместе с бинарниками устанавливать также кусок конфига, в мануале описать как инклудить его в конфиг томката. S>Так-же и для nginx и так далее. S>Опять же, мне может быть и не надо "на стандартном порту". Поэтому не стоит хардкодить.
Затем, что приложение протестировано именно на томкате. Причем именно на томкате определенной версии и поставляется она с томкатом. И на машине может быть уже установлено другое приложение, которое требует томкат другой версии. При этом приложение еще требует Java, при этом снова определенной версии, и это приложение использует deprecated api, которое в новых версиях почикали. Docker как раз и занимается тем, что решает проблему конфликта зависимостей.
Просто для разработки, когда ты разработчик, ты можешь с версиями работать допустим через sdk man, легко меняя на лету конкретную версию какой тулзы, это оказывается достаточно комфортно. Ибо в один момент времени ты работаешь с одной версией, переключаешь и все. Вот только на сервере крутится одновременно до черта версий, и тебе необходимо чтобы они друг на друга не влияли. До докера приходилось приложения под полноценными виртуалками поставлять. А виртуалки мало того, что ресурсы тратят впустую, так еще и рестарт занимает черти какое количество времени — нужно чтоб не только приложение поднялось, но и чтоб внутри виртуалки ОС загрузилось, драйверы и тому подобное. И это было до докера самая разумная альтернатива, без виртуалок геморроя оказывалось еще больше.
Нужно разделять понятие софта и ОС. Внутри ОС — ок, все должно быть одной версии, максимально должно быть унифицировано. Но сторонний софт должен запускаться где угодно, причем должна быть возможность одновременно запустить разные версии и не иметь геморроя.
Здравствуйте, elmal, Вы писали:
S>>Зачем устанавливать томкат? Надо добавлять его в зависимости пакета. Вместе с бинарниками устанавливать также кусок конфига, в мануале описать как инклудить его в конфиг томката. S>>Так-же и для nginx и так далее. S>>Опять же, мне может быть и не надо "на стандартном порту". Поэтому не стоит хардкодить. E>Затем, что приложение протестировано именно на томкате. Причем именно на томкате определенной версии и поставляется она с томкатом. И на машине может быть уже установлено другое приложение, которое требует томкат другой версии. При этом приложение еще требует Java, при этом снова определенной версии, и это приложение использует deprecated api, которое в новых версиях почикали. Docker как раз и занимается тем, что решает проблему конфликта зависимостей.
С окаменелостями всегда так. Приходится приседать чтобы заработало. И проблема тут не в том что в дистрибутивах новое, а в том что вы используете в своём коде старое.
E>Просто для разработки, когда ты разработчик, ты можешь с версиями работать допустим через sdk man, легко меняя на лету конкретную версию какой тулзы, это оказывается достаточно комфортно. Ибо в один момент времени ты работаешь с одной версией, переключаешь и все. Вот только на сервере крутится одновременно до черта версий, и тебе необходимо чтобы они друг на друга не влияли. До докера приходилось приложения под полноценными виртуалками поставлять. А виртуалки мало того, что ресурсы тратят впустую, так еще и рестарт занимает черти какое количество времени — нужно чтоб не только приложение поднялось, но и чтоб внутри виртуалки ОС загрузилось, драйверы и тому подобное. И это было до докера самая разумная альтернатива, без виртуалок геморроя оказывалось еще больше. E>Нужно разделять понятие софта и ОС. Внутри ОС — ок, все должно быть одной версии, максимально должно быть унифицировано. Но сторонний софт должен запускаться где угодно, причем должна быть возможность одновременно запустить разные версии и не иметь геморроя.
Ты читал с чего всё это началось
Здравствуйте, Sheridan, Вы писали:
S>С окаменелостями всегда так. Приходится приседать чтобы заработало. И проблема тут не в том что в дистрибутивах новое, а в том что вы используете в своём коде старое.
Ну вот допустим 3 года назад мы делали проект. На самых последних суперпупер библиотеках. Сделали, он вполне нормально работает и крутится до сих пор. Новых фич не нужно, все устраивает. За каким хреном нам обновлять этот проект чтобы он запускался на последних библиотеках, которые с тех пор поменялись 10 раз? В случае когда фичи новые требуются — да, иногда если позволяет время переходим на новые версии. Но если не требуется и все работает как надо — ну на хрена туда лезть? Заняться больше нечем?
Здравствуйте, elmal, Вы писали:
S>>С окаменелостями всегда так. Приходится приседать чтобы заработало. И проблема тут не в том что в дистрибутивах новое, а в том что вы используете в своём коде старое. E>Ну вот допустим 3 года назад мы делали проект. На самых последних суперпупер библиотеках. Сделали, он вполне нормально работает и крутится до сих пор. Новых фич не нужно, все устраивает. За каким хреном нам обновлять этот проект чтобы он запускался на последних библиотеках, которые с тех пор поменялись 10 раз? В случае когда фичи новые требуются — да, иногда если позволяет время переходим на новые версии. Но если не требуется и все работает как надо — ну на хрена туда лезть? Заняться больше нечем?
Например для того чтобы клиентам/заказчикам не приходилось приседать чтобы заставить ваши окаменелости хоть как то работать.
Да, знаю, "работает — не трогай". Но не нужно к этому правилу подходить с фанатизмом. Фанатизм плох всегда и в любом деле.
Здравствуйте, Sheridan, Вы писали:
S>Например для того чтобы клиентам/заказчикам не приходилось приседать чтобы заставить ваши окаменелости хоть как то работать. S>Да, знаю, "работает — не трогай". Но не нужно к этому правилу подходить с фанатизмом. Фанатизм плох всегда и в любом деле.
На деле, благодаря докеру окаменелостей становится наоборот меньше. Ибо ничего не мешает на момент разработки использовать последние на данный момент библиотеки. Без докера приходится подстраиваться на инфраструктуру, а инфраструктура бывает ОЧЕНЬ древняя, и обновить ее проблематично и она не от тебя зависит. В результате устаревает все наоборот медленнее через 3 года у тебя будет устаревание на 3 года по библиотекам, а не на 6 и более лет, как было до докер эпохи.
И кстати. Именно для локальной разработки докер как раз и не нужен. При разработке вообще не пользуюсь, у меня для версионирования при разработке есть другие инструменты более удобные. Докер нужен для конечной эксплуатации в проде (причем докера сейчас мало). И также для сборки проектов на CI сервере.
Здравствуйте, elmal, Вы писали:
E>И кстати. Именно для локальной разработки докер как раз и не нужен. При разработке вообще не пользуюсь, у меня для версионирования при разработке есть другие инструменты более удобные. Докер нужен для конечной эксплуатации в проде (причем докера сейчас мало). И также для сборки проектов на CI сервере.
А мне удобно некоторые сервисы в контейнерах поднимать. редис, рэббит, вот это вот все. да чего там, даже mssql там кручу .
Здравствуйте, Reset, Вы писали:
R>Кстати, вопрос про масштабирование микросервисов. Как оно происходит на практике? Ну, т.е. понятно, что в настройках Deployment кубера указано, что сервис можно масштабировать до 10X от обычного количества (и он это сделает), но... Для этого же реальное железо нужно (про абстрактные облака только трепать языком можно, как все хорошо, а когда теория сталкивается с реальной реальностью, то все оказывается сильно другим).
Во первых, Deployment это простейший случай. В более сложных случаях можно написать свой сервис, который через апи кубура будет заниматься стопанием и поднятием под, что собственно у нас сделано. Да, нужно реальное железо. Если железа не хватает — никакого чуда не произовдет, кубер будет ругаться что нет нод удовлетворяющих заданным критериям. Если купят новый сервак к датацентр или просто подрубят рядом и включат в кубер кластер, поды автоматом туда задеплоятся. Или если кто другие сервисы потушит, которые занимали ресурсы — снова кубер туда автоматом задеплоит.
R>Хочу узнать, какова реальная реальность масштабирования микросервисов у тех, кто этим пользуется?
Абсолютно реально. В случае своего датацентра упирается в бюрократию согласования закупки новых нод. Пока не закупили приходится, приходится перебрасывать сервисы на свободные ресурсы с других проектов. В принципе даже компы разработчиков бывает в кластер объединять приходится.
R>И другой вопрос про Postgres. Как я понял, в облаках принято использовать эфемерные контейнеры (StateLess) и объектные хранилища, которые отлично мастштабируются за счет автошардирования. Но если хочется из контейнера использовать Postgres, причем масштабировать его до производительности железа машины. Какие есть варианты. Как я понял, в докер пихать production Postgres не вариант. Разве что использовать stolon (тогда все будет в кубере). Можно накатить Postgres как обычно на отдельную машину (вообще без использования кубера, т.е. по старинке), но после этого придется всерьез запариться защитой от расщепления сети, и это не просто. Какие еще надежные варианты используют? Было бы круто, если бы Postgres был на одной ноде с контейнером, который его использует, чтобы исключить сетевые задержки (терять 0.5ms на запрос как-то расточительно, хотя я уже понял, что кубер это не ради производительности) и чтобы этот postgres был единственным на ноде на все контейнеры, которым он нужен...
Собственно самый рабочий способ который знаю и которым сам пользуюсь — база сохраняет свои данные не в докер, а на диск ноды. Настроена репликация. Когда поднимается пода на новой ноде, на которой данных еще нет — данные сначала реплицируются и пода становится в состоянии ready только тогда, когда данные зареплицированы. Вариантов репликации может быть много, можно допустим проигрывать события из kafka с самого начала и вставлять в базу. В моем случае это допустимо, хотя поднятие на новом железе занимает часа 4, но далее уже рестарт быстрый. Можно в принципе настроить распределенную файловую систему, она уже настроена в облаках по умолчанию, сам не юзал, но что то мне подсказывает что с производительностью будет фигня. Конкретно у нас основные базы гоняются на голом железе и администрируются отдельно, но то, что можно позволить поместить внутрь контейнеров туда помещаем.
Здравствуйте, Sheridan, Вы писали:
S>Ты путаешь админов вашей инфраструктуры с админом/девапсом, цель которого чтобы ваш софт безболезненно устанавливался и работал у заказчика. И вот ему уже просто необходимо будет погрузиться в проблематику и ваших диб, может даже в код посмотреть и так далее.
О какой проблематике идет речь? Вот чего я ни разу не видел, так это админов, изучающих исходники всяких библиотек. Начиная, для определенности, с Графора.
Здравствуйте, Reset, Вы писали:
R>Если же используется "облачный провайдер", то там ценник такой, что дешевле на те же деньги закупить арендованных машин у обычных хостеров раз в 10 больше
Здравствуйте, Sheridan, Вы писали: S>Например для того чтобы клиентам/заказчикам не приходилось приседать чтобы заставить ваши окаменелости хоть как то работать.
Вот ты смешной.
Эти фантазии хороши тогда, когда у тебя один клиент/заказчик.
А когда их больше пальцев на руке, начинается развлекалово — одни кричат "нам нужно самое новьё, вчера новый релиз платформы вышел, вы почему ещё его не поддерживаете", а другие — "не-не-не, у нас RHEL6, и мы с него никуда в ближайший год не переедем. Потому что на нём работает не только ваш софт, а софт ещё других пацанов. Их версия 4 работает только с RHEL6, а начиная с версии 6 у них новый формат данных, поэтому мы не можем просто проапгрейдить их софт на актуальную версию. Мы уже три квартала ведём переговоры о миграции, пытаясь выяснить, кто, в какие сроки, и за чей счёт будет её проводить".
В итоге — на сотню клиентов две сотни версий окружения, в котором надо работать.
Докер даёт нормальную возможность удовлетворить сразу всех — и клиенту не надо париться с тем, что софт "тех пацанов" не бегает на новом рхеле, и нам не надо париться с тестированием своего софта в сотнях разных окружений.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Zhendos, Вы писали:
Z>Э... Вы же сами писали что специалистов по k8s очень сложно найти,
Специалист по куберу-это тот, кто однажды прошёл через немоверное количество его багов и граблей, количество которых просто зашкаливает. Это не система, которая просто работает, это такая система, которая очень часто просто не работает. Логично что желющих вляпываться маловато.
S>Эти фантазии хороши тогда, когда у тебя один клиент/заказчик. S>А когда их больше пальцев на руке, начинается развлекалово — одни кричат "нам нужно самое новьё, вчера новый релиз платформы вышел, вы почему ещё его не поддерживаете", а другие — "не-не-не, у нас RHEL6, и мы с него никуда в ближайший год не переедем"
Да даже если заказчик один, внутренний, сама компания, то при определенном размере компании все равно натыкаешься на все вот это. Просто потому что невозможно заставить не то что несколько сотен, но даже несколько десятков программистов одновременно перевести все продукты и сервисы на те версии библиотек, которые понравились какому-то неу(ё)мному сисадмину.
Здравствуйте, Ночной Смотрящий, Вы писали:
С>>Извольте соответствовать этой культуре. НС>Простой вопрос — зачем?
Когда-то я участвовал в дискуссии о поведении игроков в онлайн-РПГ (для попёрдывающих и знать не желающих, что это такое, напомню, что Ultima Online появилась ещё в те годы, когда у вас интернета не было, в 1997 году). Меня тогда поразило заявление, что дескать в РПГ один игрок может убить другого просто по приколу, и ничего ему за это не будет, а вот в реальной жизни этот же самый человек не убивает бабку, торгующую семечками, только потому, что иначе его милиция поймает и посадит.
Итак, есть два мнения:
1) Люди не срут там где живут, потому что это не соответствует их культуре, морали, этике и так далее
2) Люди не срут там где живут только потому, что иначе их палкой по голове бить будут, а без палки они не понимают.
Здравствуйте, elmal, Вы писали:
E>И кстати. Именно для локальной разработки докер как раз и не нужен.
Это зависит от количества сервисов и наличия shared infrastructure. Вот на текущем проект даже простой сервис почти наверняка захочет сиквел, постгри, редис, реббит, минио 2-3 инстанса в разных режимах. А если какую нибудь посложнее цепочку прогнать — появляются всякие OPA, flowable, identity server и т.п. Нафига мне весь этот зоопарк устанавливать на рабочую машину?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это зависит от количества сервисов и наличия shared infrastructure. Вот на текущем проект даже простой сервис почти наверняка захочет сиквел, постгри, редис, реббит, минио 2-3 инстанса в разных режимах. А если какую нибудь посложнее цепочку прогнать — появляются всякие OPA, flowable, identity server и т.п. Нафига мне весь этот зоопарк устанавливать на рабочую машину?
а почему это все происходит? потому что докер поощряет overengeneering! не было бы докера — сделали бы монолит, который бы ставился одной rpm-кой сразу на весь кластер, только кластера бы тоже не было, потому что это тоже overengeeniring
.
