Здравствуйте, smeeld, Вы писали:
S>Есть ещё третий вариант, и именно он обеспечил массовость популярность контейнеров и докера в частности. Это когда сидит макака, ваяет у себя на локалхосте на последней убунту приложение, тащит для этого кучу всякого разношерстного и разноверсионного хлама из самых разных реп, самыми разными пакетными менеджерами, отличными от штатного (pip-ы, npm-ы). Поучается нагроможение и мессиво. Работать будет только у него на локалхосте. А нужно чтоб работало где-то на любом сервере, в закрытом или публичном облаке. Что делать? Завернуть всю эту кучу вместе с загаженным обазом ОС в контейнер, и этот контейнер можно уже запускать где угодно. А то, что вместе с жалкими 10KB творения макаки на каждый сервер тащится ещё 500MB образа ОС, то это макаку не волнует, а провайдеры только за-повышенное потребление ресурсов клиентами для них прибыль.
Падажжите. Разве там не будет слой незагаженного образа ОС, поверх которого накачены какие-то жалкие пара сотен мегабайт "кучи разношёрстного и разноверсионного хлама", вместе с 10кб собственно пользовательского кода?
При этом незагаженный образ разделяется между всеми контейнерами на конкретном хосте?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Падажжите. Разве там не будет слой незагаженного образа ОС, поверх которого накачены какие-то жалкие пара сотен мегабайт "кучи разношёрстного и разноверсионного хлама", вместе с 10кб собственно пользовательского кода? S>При этом незагаженный образ разделяется между всеми контейнерами на конкретном хосте?
Вот на экономию этих мегабайт Шеридан их хочет оправдать свой подход, идущий в разрез с реальностью бытия.
Да, на этот выхлоп нужно еще розги покупать и лояльность программистов, согласных терпеть эту Салтычиху
И, понятное дело, экономия на один Image/VM, а не инстанс каждого контейнера. Тут только на одну розгу и хватит
Здравствуйте, Sinclair, Вы писали:
S>Падажжите. Разве там не будет слой незагаженного образа ОС...
Макака одно приложение сваяет на образе одно версии убунту, второе на образе другой версии, третье на образе какой-нибудь sles11 (ибо нужные компоненты только под неё есть). И пропали твои слои
Здравствуйте, Sinclair, Вы писали:
S>Да ну откуда? Контейнеры же из слоёв; как я понял — слои повторно используются. S>Поэтому если у тебя на железке 30 контейнеров с аппликухами построены на одном и том же дистрибутиве, и в 20 используется питон, а в 10 — go, то физически на диске будет лежать 1 питон и 1 го. S>Если кому-то потребовался питон 2.7, а не 3.1, то появится 1 экземпляр питона 2.7, при этом он никак не помешает тем 20 аппликухам, которым нужен питон 3.1.
Ты сам это тестил, проверял, что так оно и есть? Учитывая, что докер-это жуткое глюкалово, не удивлюсь, если это только заявлено, но так это не работает должным образом. Вот у меня на локалхосте это не работает: собираемые локально, подтягиваемые извне контейнеры, все из которых создаются на основе одного и того же базового образа из центрального registry, в течении недели-двух отжирают несколько десятков GB. Регулярно приходится делать rm -fr /var/lib/docker
Здравствуйте, Vetal_ca, Вы писали:
V_>Вот на экономию этих мегабайт Шеридан их хочет оправдать свой подход, идущий в разрез с реальностью бытия.
Нет. Никакой экономии не будет. Потому как у вас программисты все пишут вразнобой и в проекте может быть несколько версий одной и той же либы. А тут недалеко уже и от нескольких версий дистрибутива.
Но если у вас не так, и всё чётко: либы идентичные, дистрибутив тот же (у вас же ровно один слайс плюс несколько сервисов, верно?), то и контейнеры тут не нужны.
Здравствуйте, Vetal_ca, Вы писали:
S>>Кто будет инфраструктуру настраивать? V_>Амазон, Гугл, Azure, ...
У ваших заказчиков всегда есть доступ к интернетам с достаточно широкой полосой? Открою тебе тайну: далеко не у всех так.
V_>На крайняк подгонят собрата Шеридана, один раз на Ansible кластер onprem накатить.
Это было бы правдой, если бы после релиза вся команда заседа бы на другой проект и к этому никогда бы больше не возвращалась.
Практика же показывает что деплой нужно развивать вместе с проектом исходя из изменяющихся требований.
Лично я, например, одному заказчику переделывал хранилище с aws на seaweedfs для вполне успешного проекта, который в проде был к тому времени уже несколько лет.
Здравствуйте, Reset, Вы писали:
Pzz>>Нет, уменьшилась. Если представить себе проект в виде графа зависемостей, сложность определяется не столько количеством вершин этого графа, сколько количеством связей между ними.
R>Что тебе мешает в монолите поддерживать минимум связей? Более того, разделение на модули придумали еще когда термин микросервисы не существовал (да и сетей почти не было).
R>Микросервисы решают 2 задачи: делают возможным реализацию приложения, которому не хватает ресурсов одной машины (гугл/фейскнига) и делают возможным разработку приложения, которым занимаются разные команды с разными дедлайнами, задачам и приоритетами (тут достаточно договориться о протоколе обмена данными и времени реализации изменений, а также поддержки легаси — остальное в каждой команде решают независимо, а вот запихать это в один монолит — возникнет неразруливаемый срач с выяснением у кого длиннее).
Самое главное, что решают микросервисы — позволяют писать код на чём угодно. В теории, конечно, можно и в монолите всё распилить на отдельные компоненты, изолированные через C-style ABI (ну или там, скажем, построить всё на основе COM, и писать часть кода на VC++, а часть — на Delphi), но на практике вызвать какую-нибудь питоновую либу из Java приложения — недостижимая фантастика.
Не менее весёлой становится задача, скажем, перевести монолит с одной версии платформы на другую. Вот у нас пара миллионов строк кода, которую нам нужно перевести с Java 1.3 на 1.8.
Там в принципе несложно — тут имя пакета подправить, там класс заменить. И таких мест — несколько тысяч. После этого оно начинает хотя бы собираться, но не факт, что работать. Надо тестировать: часть косяков вылезет в продакшн — например потому, что где-то там что-то подгружается динамически, и в новой java оно работает не так.
А переехать мы хотим потому, что есть какой-то новый компонент, и в нём очень бы кстати пришлась новая либа, которая не работает с жавой ниже 1.8.
И вот либо мы тратим N+1 месяцев на тщательное портирование всего монолита на новую версию (причём скорее всего замораживая весь feature development до его окончания), либо пилим новый компонент за 3x времени из-за отсутствия нужной либы.
А всё потому, что запустить в рамках одного процесса две версии джавы мы не в силах.
То же самое — с версиями питона. То же самое — с версиями дотнета.
Более того, у нас там может стрельнуть какая-нибудь наркомания вроде того, что у нас ядро на С++, хочет вызывать плагины через COM, и вот у нас два плагина, один на дотнете 3.5, второй — на 4.5. Каждый думает "ачотакова, ща я загружу CLR inproc, и мы поедем".
Микросервисы позволяют перетаскивать монолит на новую версию по частям.
Ну, а в совсем больших и запущенных случаях мы можем совмещать код на совершенно разных языках. В итоге, нам не нужно искать "специалиста по датамайнингу на дотнете" или "специалиста по видеокодекам на java".
Достаточно искать специалистов по датамайнингу и видеокодекам, а технологический стек пусть тащат какой хотят. Питон — пусть будет питон. Плюсы — пусть будут плюсы. Вам на гошечке комфортнее писать? Ну, давайте на гошечке напишем.
Вот так выглядит современная вавилонская башня, а вовсе не как дружная семья CLR-совместимых языков, которые все компилируются в .Net (как это себе представляла Редмондская молодёжь 22 года тому).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>Если бизнес скажет тебе вставить затычку в пятую точку — так и сделаешь? S>Бизнес нанимает профессионала чтобы решать задачи бизнеса но потом не слушает профессионала и требует вырастить руки на жопе. Это так работает?
Это значит, что неопытный рекрутер нанял бесконечно отсталого, бывшего профессионала (?), который даже не понимает, что от него хотят.
Что-то бормочет про руки на жопе, загоняет сам себе затычку в зад и показывает фиги.
Это опыт для рекрутера. Учится отсеивать, чтобы не тратить на таких самоназванных "селюков-профессионалов" времени.
S>У ваших заказчиков всегда есть доступ к интернетам с достаточно широкой полосой? Открою тебе тайну: далеко не у всех так.
Ну нет, так on-prem. Обычная работенка для админа средней руки
V_>>На крайняк подгонят собрата Шеридана, один раз на Ansible кластер onprem накатить. S>Это было бы правдой, если бы после релиза вся команда заседа бы на другой проект и к этому никогда бы больше не возвращалась. S>Практика же показывает что деплой нужно развивать вместе с проектом исходя из изменяющихся требований. S>Лично я, например, одному заказчику переделывал хранилище с aws на seaweedfs для вполне успешного проекта, который в проде был к тому времени уже несколько лет.
Тоже работа. Если самоокупается, то имеет право на жизнь
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Sinclair, Вы писали:
S>>Да ну откуда? Контейнеры же из слоёв; как я понял — слои повторно используются. S>>Поэтому если у тебя на железке 30 контейнеров с аппликухами построены на одном и том же дистрибутиве, и в 20 используется питон, а в 10 — go, то физически на диске будет лежать 1 питон и 1 го. S>>Если кому-то потребовался питон 2.7, а не 3.1, то появится 1 экземпляр питона 2.7, при этом он никак не помешает тем 20 аппликухам, которым нужен питон 3.1.
S>Ты сам это тестил, проверял, что так оно и есть? Учитывая, что докер-это жуткое глюкалово, не удивлюсь, если это только заявлено, но так это не работает должным образом. Вот у меня на локалхосте это не работает: собираемые локально, подтягиваемые извне контейнеры, все из которых создаются на основе одного и того же базового образа из центрального registry, в течении недели-двух отжирают несколько десятков GB. Регулярно приходится делать rm -fr /var/lib/docker
Ни разу такого не видел. Хотя опыт уже значительный
Может у тебя unnamed orphaned volumes ?
docker system prune --all
Или админы у тебя там каким-то боком по докеру касперского выпускают. Тогда, да, на такой цирк никто никаких гарантий давать не будет
Здравствуйте, Sheridan, Вы писали:
S>Нет. Никакой экономии не будет. Потому как у вас программисты все пишут вразнобой и в проекте может быть несколько версий одной и той же либы. А тут недалеко уже и от нескольких версий дистрибутива. S>Но если у вас не так, и всё чётко: либы идентичные, дистрибутив тот же (у вас же ровно один слайс плюс несколько сервисов, верно?), то и контейнеры тут не нужны.
Я за этим не слежу, у всех разные требования к либам. Чтобы все оптимизировать до одного слайса, у нас есть много других, более актуальных дел. Префекционизм любой ценой — зло
S>Макака одно приложение сваяет на образе одно версии убунту, второе на образе другой версии, третье на образе какой-нибудь sles11 (ибо нужные компоненты только под неё есть). И пропали твои слои
Что, у вас нет человека, который Docker image не может написать, сохранив путь макаки на требуемом образе?
Переделать под общий корпоративный стиль, какой нибудь Alpine, scratch или distroless ?
Это не та проблема, о которой-то и упоминают, вообще. Делают, и работает.
Тем более, что, собралось раз и, порядок.
V_>Что, у вас нет человека, который Docker image не может написать, сохранив путь макаки на требуемом образе?
У "нас" то есть, но у "нас" и докер юзается только для разработки и тестирования, в проде это исполняется нативно, ибо нефиг лишним мусором систему захламлять. А вот у основной массы потребителей облаков, таких человеков как правло нет.
Здравствуйте, Vetal_ca, Вы писали:
S>>Если бизнес скажет тебе вставить затычку в пятую точку — так и сделаешь? S>>Бизнес нанимает профессионала чтобы решать задачи бизнеса но потом не слушает профессионала и требует вырастить руки на жопе. Это так работает? V_>Это значит, что неопытный рекрутер нанял бесконечно отсталого, бывшего профессионала (?), который даже не понимает, что от него хотят.
А опытный рекрутер наймёт сразу того у кого руки из жопы и кто готов мужеложествовать если БИЗНЕСУ НАДО?
Здравствуйте, Vetal_ca, Вы писали:
S>>Нет. Никакой экономии не будет. Потому как у вас программисты все пишут вразнобой и в проекте может быть несколько версий одной и той же либы. А тут недалеко уже и от нескольких версий дистрибутива. S>>Но если у вас не так, и всё чётко: либы идентичные, дистрибутив тот же (у вас же ровно один слайс плюс несколько сервисов, верно?), то и контейнеры тут не нужны. V_>Я за этим не слежу, у всех разные требования к либам. Чтобы все оптимизировать до одного слайса, у нас есть много других, более актуальных дел. Префекционизм любой ценой — зло
Да никто перфекционизма то и не просит. Просто планируйте обновления либ и работайте по плану. Это сложно? Ну серьёзно то. Сложно? Невыполнимо?
Здравствуйте, Vetal_ca, Вы писали:
S>>Макака одно приложение сваяет на образе одно версии убунту, второе на образе другой версии, третье на образе какой-нибудь sles11 (ибо нужные компоненты только под неё есть). И пропали твои слои V_>Что, у вас нет человека, который Docker image не может написать, сохранив путь макаки на требуемом образе? V_>Переделать под общий корпоративный стиль, какой нибудь Alpine, scratch или distroless ? V_>Это не та проблема, о которой-то и упоминают, вообще. Делают, и работает. V_>Тем более, что, собралось раз и, порядок.
А что мешает то сделать второй шаг и поддерживать свежие версии либ для проектов? Тогда и докер не нужен то будет.
Здравствуйте, Pzz, Вы писали:
R>>Я так и не понял, как статическая линковка библиотек спасает от сложностей с обновлениями библиотек по сравнению с динамической линковкой. В обоих случаях: обновляешь библиотеки — получаешь сложности, не обновляешь — все хорошо. Pzz>При динамической линковке у тебя либы (или часть либ) могут вместе с дистрибутивом обновиться. И ты этим не очень-то управляешь.
Ну так наверное надо отслеживать версии используемых либ и обновлять у себя?
Да ну, не может быть!
Здравствуйте, Vetal_ca, Вы писали:
S>>У ваших заказчиков всегда есть доступ к интернетам с достаточно широкой полосой? Открою тебе тайну: далеко не у всех так. V_>Ну нет, так on-prem. Обычная работенка для админа средней руки
Ты наверное не поверишь, но далеко не везде есть даже средней руки. Чтото чуть сложнее чем "скопировать вот этот каталог в home, написать в текстовом конфиг-файле настройки деплоя и запустить make deploy" и всё, лапки.
Здравствуйте, Sheridan, Вы писали:
S>А опытный рекрутер наймёт сразу того у кого руки из жопы и кто готов мужеложествовать если БИЗНЕСУ НАДО?
Ты думаешь, что если подкрепить несостоятельное мнение оскорбительными выражениями, и переведя верхний регистр, то твое мнение обретет хоть какой-то вес? "Кто не думает как Шеридан — тот п****ас."? "Ну согласись, что Шеридан прав, и твоя ориентация будет этим же Шериданом подтверждена"? Это твои аргументы, это твой уровень?
Знаешь, в контексте обсуждения твоя ориентация и страхи с ней связанные тут не интересны. Хотя, уши проглядываются, уж слишком часто ты апеллируешь к этому делу.
