Здравствуйте, Michael7, Вы писали:
M> V_>Чудовищно, это сколько? В процентах, с примерами, если не брать образы от новичков, где в базовый полный Ubuntu запихан
M> Я о том, что если войдет в моду каждую программу оборачивать в контейнер. Хотя может и переборщил с эпитетом.
iOS давно уже (почти) не пускает прилощения за рамки своей песочницы
. S>Надо ложить на актуализацию используемых в проекте либ -> глупость. Либы в проекта должны быть свежими. Их актуализацию надо планировать. Даже в проектах, ушедших с разработки в саппорт. S>Изоляция строго необходима -> глупость. Изоляция нужна при запуске опасных процессов, способных развалить систему. Например, при экспериментах с вирусами. Либо для ещё одного слоя усложнения доступа к важным данным из соседних процессов. Например, к персональным данным. В остальных случаях можно обойтись.
При разработке ПО также есть дилемма — складывать библиотеки на компьютере централизованно, либо поставлять с каждым приложением. Используются оба подхода, с перевесом в сторону упаковки библиотек с приложением. В микросервисе например уже интегрирован веб-сервер.
В snap и flatpak также используется механизм изоляции.
Вобщем, контейнеризация, изоляция, поставка библиотек с приложением — это объективная тенденция.
docker дошел до того, что поставляет приложение с куском операционки. Почему нет? Логичное развитие.
Инструмент сам по себе ничего плохого не несет, главное чтобы решаемая задача соответствовала.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>Когда твой конечный пользователь не имеет рутового доступа к системе, когда ты не знаешь, в каком окружении будет крутиться твоё приложение об актуализации либ можно забыть.
SVZ>>Ну т.е. либо для твоего софта выделять отдельную машину ("фигвам, а не отдельная машина", скажет сисадмин), либо поднимать виртуалку, либо докер. SVZ>>Либо выкручиваться так, чтобы ни одной dll/so в проекте не использовалось.
S>Это всё как раз не про несчастный глючный докер. Если у тебя софт -не маленькая программулька aka сайтик на lamp, а целый кластер, то, чтоб энтот кластер в виде кубернетиса на машину вкорячить нужно: S>1) отдельная мощная машина, иначе этот глючный хипстерский кубернетис просто не развернётся, будет плеваться кучей ошибок абсолютно непонятного содержания. Ему, например, диски быстрые нужно, видите ли, иначе он обидится и не развернётся.
ты хотел целый кластер а "не маленькая программулька aka сайтик" на нетбуке запускать?
Здравствуйте, Sheridan, Вы писали:
S>Если софт — коробка, то это просто обязан быть пакет. (deb, rpm итд), который должен ставиться штатными средствами.
и в нем как раз таки проблема версий будет стоять жестко. ты не контролируешь когда и как пользователи проапгрейдятся
К тому же коробка — не всегда чтото "десктопное". просто что-то тиражируемое. И...сюрприз... сами заказчики все чаще просят запаковать им продукт в докер.
Здравствуйте, Явь-Истъ, Вы писали:
ЯИ>Здравствуйте, Sheridan, Вы писали:
ЯИ>В snap и flatpak также используется механизм изоляции. ЯИ>Вобщем, контейнеризация, изоляция, поставка библиотек с приложением — это объективная тенденция. ЯИ>docker дошел до того, что поставляет приложение с куском операционки. Почему нет? Логичное развитие. ЯИ>Инструмент сам по себе ничего плохого не несет, главное чтобы решаемая задача соответствовала.
Инструмент конечно не может быть плохим или хорошим. Но очевидно что у каждого использования
инструмента для решения задачи есть преимущества и недостатки. И недостатки контейнеров очевидны:
1. повышенное потребление памяти, эти ведь разные версии библиотек/интерпретаторов/виртуальных машин не святым
воздухом питаются и тратят и кэш на самом диске и ОЗУ которую использует ОС для кэширования I/O и
кэши инструкций процессора и т.п.. У snap вообще все печально, насколько я знаю,
там даже одинаковые версии библиотек не разделяются, потому что нет фичи аналогичной "послойной" ФС в
docker. Иначе сложно объяснить почему калькулятор так долго стартует (одно из первых snapd приложений в Ubuntu)
2. сложность внесения критичных исправлений, например исправление уязвимостей.
И то что "контейниризация" это тенденция усиливает эти минусы, так как
их начинают пихать туда где они не очень или вообще не нужны.
Ну а с другой стороны похоже количество программ достигло критического
числа и разработчики Linux дистрибутивов тупо не справляются с работой по
интеграции всего. Например в Ubuntu LTS начиная чуть ли не с версии 14
одна программа тупо не запускается, каждый раз новый релиз LTS
разработчики упаковывают новую версию, новые зависимости,
но даже протестировать что программ запускается у них не доходят руки.
Сначала не хватало зависимости X, потом Y и т.д.
У каждого языка python/ruby/javascript/java/go... свой пакетный менеджер,
и так как зависимостями стало так легко управлять они очень часто меняются,
а никакой интеграции между разноязычнми пакетными менеджерами конечно нет,
проще уж дать контейрен и сказать делайте с ним что хотите: make install/npm install/pip install
Здравствуйте, Zhendos, Вы писали:
Z>Инструмент конечно не может быть плохим или хорошим. Но очевидно что у каждого использования Z>инструмента для решения задачи есть преимущества и недостатки. И недостатки контейнеров очевидны:
Z>1. повышенное потребление памяти, эти ведь разные версии библиотек/интерпретаторов/виртуальных машин не святым Z> воздухом питаются и тратят и кэш на самом диске и ОЗУ которую использует ОС для кэширования I/O и Z> кэши инструкций процессора и т.п.. У snap вообще все печально, насколько я знаю, Z> там даже одинаковые версии библиотек не разделяются, потому что нет фичи аналогичной "послойной" ФС в Z> docker. Иначе сложно объяснить почему калькулятор так долго стартует (одно из первых snapd приложений в Ubuntu) Z>2. сложность внесения критичных исправлений, например исправление уязвимостей.
Ну да, у snap все "печально", но chromium теперь доступен только в виде snap-пакета https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition
И в остальных snap пакетах обычно программы более свежие.
Или вот игры часто поставляются на windows и с DirectX, и с microsoft SDK, это решение лучше — требовать установки системных библиотек вместо того, чтобы их взять все с собой? Java вот тоже, потребляет ресурсов больше, чем С++, но ведь множество проектов все таки выбрали именно Java? Дополнительный уровень абстракции всегда появляется в ответ на увеличение сложности нижележащих уровней.
Серебряной пули, как говорится, нет, все новое не обязательно по всем параметрам лучше, но и полностью отвергать нововведения будет неверным.
M>>Почему он против докера, который: M>>— [1] снижает трудозатраты и программистов и девопсов
M>Он хочет сохранить работу, а с докером он просто не нужен больше
Да, эта мысль у меня тоже промелькнула. Job security, вот это всё.
То есть на самом деле грамотный девопс, который все это настроит, а потом уйдет и будет получать деньги за нулевые усилия все же нужен. Но это не про Шеридана.
Здравствуйте, mogadanez, Вы писали:
M> ты хотел целый кластер а "не маленькая программулька aka сайтик" на нетбуке запускать?
Прикол тут знаешь в чём? В том, что этот же весь кластер на той же машине (а она сильно мощная, это не нетбук, бро), без проблем и с полпинка ставится, например в OS solaris, развёртываясь в solaris zone c штатными средствами кластеризации этой OS. Всё ставибся влёт и работает как часы. Также этот же кластер развёртывается и работает без проблем в OS linux, если его запускать в виртуалках kvm или openVZ. Никаких оптимизаций, бубнов, всё делается соответствущим штатным набором команд. Оно глючит и зависает только если ентот кластер начать разворачивать и запускать в волшебной связке docker+кубернетис.
ЗЫ но местная публика ничего кроме маленьких сайтиков и хеллоуворлдов в докере и кубернетисе не запускала, вот и мнит себя крутыми, "осилившими" докеры и кубернетисами. Технологию обычно не надо "осиливать", она или работает как часы, как зоны и кластеризация в solaris, или глючит и зависает, дай ей чуть большую нагрузку, как в случае с докер и кубернетис.
Здравствуйте, smeeld, Вы писали:
S>Прикол тут знаешь в чём? В том, что этот же весь кластер на той же машине (а она сильно мощная, это не нетбук, бро), без проблем и с полпинка ставится, например в OS solaris, развёртываясь в solaris zone c штатными средствами кластеризации этой OS. Всё ставибся влёт и работает как часы. Также этот же кластер развёртывается и работает без проблем в OS linux, если его запускать в виртуалках kvm или openVZ.
Мальчик, ты опять жидко обгадился.
Docker работает через namespace'ы в Линуксе, с использованием cgroups для контроля ресурсов. Эта функциональность — строгое надмножество функциональности Solaris Zones. Namespace/cgroups штатно присутствуют во всех основных дистрибутивах уже как 10 лет.
Всё что делает Docker — это предоставляет удобный интерфейс к ним, и потому занимает минимум ресурсов. Это достаточно небольшая утилита, которая занимается записью в /sys/fs/cgroup и запуском процессов. Можно даже без демона обойтись — https://blog.alexellis.io/runc-in-30-seconds/
C>Docker работает через namespace'ы в Линуксе, с использованием cgroups для контроля ресурсов
Бро, не надо мне этих откровений, о которых в любом детском саду в курсе. А вот тебе следует знать, что в докере поверх cgroups такой очень жирный пласт очень глючного говнокода, которыей ваяли хепстеры, и который толком никто не продумывал, и который толком никто не тестировал. Загляни. Вот он и глючит. Oдин overlay, коего успели наваять уже несколько вурсий одна глучнее другой, чего стоит.
PS сами cgroups работают как часы, если их настраивать напряую, без этих говнопрослоек вроде докера.
Вобщем, контейнер — это наиболее универсальный способ распространения приложений, пусть и с определенным оверхедом, который все равно меньше, чем у образов виртуальных машин. Это снимает головную боль с разработчика, которому не надо заморачиваться, что там происходит на серверах. А админ не заморачивается с тем, какое окружение у разработчика. Это определенный компромис.
В Линуксе множество сборок, но ядро стандартизировано, что позволило контейнерам стать переносимыми.
snap и flatpak собственно тоже используют механизмы изоляции.
Это я считаю определенный прорыв, достигнутый в сообществе Линукса благодаря открытости и стандартизации.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Cyberax, Вы писали:
C>>Docker работает через namespace'ы в Линуксе, с использованием cgroups для контроля ресурсов
S>Бро, не надо мне этих откровений, о которых в любом детском саду в курсе. А вот тебе следует знать, что в докере поверх cgroups такой очень жирный пласт очень глючного говнокода, которыей ваяли хепстеры, и который толком никто не продумывал, и который толком никто не тестировал. Загляни. Вот он и глючит. Oдин overlay, коего успели наваять уже несколько вурсий одна глучнее другой, чего стоит.
S>PS сами cgroups работают как часы, если их настраивать напряую, без этих говнопрослоек вроде докера.
Кому ты здесь пишешь? Этой публике? Ты сразу баги репорть.
В Google напиши там, в Mайкрософт. "Так мол и так, неправильными путями идете товарищи. Я, некий smeeld (пацаны из отдела внедрения и Шеридан, для массовости) думаем, что вы все ошибаетесь и идете к явной катастрофе." Ну и так далее, напоржать кому нибудь хватит
Здравствуйте, Zhendos, Вы писали:
Z>Здравствуйте, Явь-Истъ, Вы писали:
Z>Инструмент конечно не может быть плохим или хорошим. Но очевидно что у каждого использования Z>инструмента для решения задачи есть преимущества и недостатки. И недостатки контейнеров очевидны:
Z>1. повышенное потребление памяти, эти ведь разные версии библиотек/интерпретаторов/виртуальных машин не святым Z> воздухом питаются и тратят и кэш на самом диске и ОЗУ которую использует ОС для кэширования I/O и Z> кэши инструкций процессора и т.п.. У snap вообще все печально, насколько я знаю, Z> там даже одинаковые версии библиотек не разделяются, потому что нет фичи аналогичной "послойной" ФС в Z> docker. Иначе сложно объяснить почему калькулятор так долго стартует (одно из первых snapd приложений в Ubuntu) Z>2. сложность внесения критичных исправлений, например исправление уязвимостей.
Z>И то что "контейниризация" это тенденция усиливает эти минусы, так как Z>их начинают пихать туда где они не очень или вообще не нужны.
Конкретно по нему, надо отключать мониторинг и прочие программы из кластера.
Самая же большая часть расходов и непредвиденностей — люди.
Только по сравнению с этим дополнительные (очень небольшие) расходы — копейки. Или они святым воздухом питаются?
Дальше (сверху) идут огромные business values, типа переносимости, прозрачности и структуризации.
Пусть будет супер-документация, до последней буквы соответствующая реальному положению дел. Это не заменит "в одну строчку", "деплой" или "покажи все что у нас есть, только точно". Безо всяких там Cron jobs на стороне или патчей наложенных 7 месяцев назад, в спешке.
Самая главная проблема докера и Кубернетес это отсутствие квалифицированных специалистов. Квалифицированных ы контейнерах, кластерах или просто, готовых учиться с интересом.
Здравствуйте, Vetal_ca, Вы писали:
V_>Здравствуйте, Zhendos, Вы писали:
Z>>И то что "контейниризация" это тенденция усиливает эти минусы, так как Z>>их начинают пихать туда где они не очень или вообще не нужны.
V_>Конкретно по нему, надо отключать мониторинг и прочие программы из кластера.
V_>Самая же большая часть расходов и непредвиденностей — люди.
V_>Самая главная проблема докера и Кубернетес это отсутствие квалифицированных специалистов. Квалифицированных ы контейнерах, кластерах или просто, готовых учиться с интересом.
Ну проблема "технологии" является часть проблемы "люди".
Ведь от того насколько сложна технология зависит сколько тебе нужно
найти специалистов, какого уровня, сколько им платить и т.д.
Поэтому отсутствие "специалистов" это естественно, сколько уровней абстракции
добавилось? Во скольких еще вещах нужно разбираться чтобы отладить почему
при незагруженном физическом CPU программы в контейнерах тормозят
или почему все контейнеры стали запускаться на одной физической машине из кластера, когда все другие
простаивают?
А начнут внутри контейнеров внутри k8s запускать
"мили-контейрены" внутри "микро-контейренов" и специалистов вообще не найдется.
Z>Ну проблема "технологии" является часть проблемы "люди". Z>Ведь от того насколько сложна технология зависит сколько тебе нужно Z>найти специалистов, какого уровня, сколько им платить и т.д.
Z>Поэтому отсутствие "специалистов" это естественно, сколько уровней абстракции Z>добавилось? Во скольких еще вещах нужно разбираться чтобы отладить почему Z>при незагруженном физическом CPU программы в контейнерах тормозят Z>или почему все контейнеры стали запускаться на одной физической машине из кластера, когда все другие Z>простаивают?
Z>А начнут внутри контейнеров внутри k8s запускать Z>"мили-контейрены" внутри "микро-контейренов" и специалистов вообще не найдется.
Пресловутое, "Если/когда".
Одни идут за теми, у кого получилось. Другие ищут повода, чтобы не начинать.
Как говорится "Слабый всегда ищет оправдания, сильный — возможности."
Для конструктива нужно "не почему у нас не получилось". А как у них получилось, интересные подходы и идеи.
Или, если не взлетело, "Как у известной компании XYZ не получилось с докером и/или кубернетес, что пошло не так и почему". Если ссылаться на "Некто с ником XYZ — у него не пошло". Здесь, или на собеседовании, то у собеседника возникает картинка "Лузер против облако-с-логотипами": "Госпади, откуда они берутся, пора закругляться и звать более перспективного"
Для вышеприведенных проблем,
1. Нужно знать пару базовых команд, docker exec / kubectl exec. Базовые знания Линукса и уметь пользоваться поиском. "Linux check IO load" или "Linux check network load". Если точно приложение "работает на моей машине"
2. Сразу, без поиска, вспомнилось когда читал хорошую книгу, Mario Luksa — Kubernetes in Action. "Part 3, Beyond the basics -> 11. Understanding Kubernetes internals, -> 11.1.5 Understanding the Scheduler
Предыдущее прочтение оставило в памяти, что эти компоненты взаимозаменяемы, включая планировщик. Направление поиска в зоне прямой видимости грамотного разработчика. И уж точно не причина для поиска повода для остановки в развитии.
Сегодня остановился, завтра через тебя переступили
Здравствуйте, Vetal_ca, Вы писали:
V_>Здравствуйте, Zhendos, Вы писали:
Z>>А начнут внутри контейнеров внутри k8s запускать Z>>"мили-контейрены" внутри "микро-контейренов" и специалистов вообще не найдется.
V_>Пресловутое, "Если/когда".
Э... Вы же сами писали что специалистов по k8s очень сложно найти,
я предположил что усложнив технологию еще получим совсем куцое количество специалистов.
Неужели вы не согласны что чем сложнее какой-то предмет тем меньше количество людей
в нем разбираются до конца?
V_>Для вышеприведенных проблем, V_>1. Нужно знать пару базовых команд, docker exec / kubectl exec. Базовые знания Линукса и уметь пользоваться поиском. "Linux check IO load" или "Linux check network load". Если точно приложение "работает на моей машине"
Совершенно бы не помогло. Дело было в баге в ядре Linux, из которого лимиты по CPU применялись неправильно,
и контейнерам время от времени не давали кванты времени хотя оно было в избытке.
V_>2. Сразу, без поиска, вспомнилось когда читал хорошую книгу, Mario Luksa — Kubernetes in Action. "Part 3, Beyond the basics -> 11. Understanding Kubernetes internals, -> 11.1.5 Understanding the Scheduler
Совершенно бы не помогло. Дело было в побитых данных в etcd, из-за которых неправильно распределялись
задачи по кластеру.
То есть общая информацию знать конечно хорошо, можно быстрее понять куда копать,
но пары книжек явно не хватит при отладке всей это хрени из сотен разных программ
размазанных на куче физических машин. Есть подходы и инструменты чтобы бороться
со сложностью, но довести до простоты: одна машина — одна ОС без всякой виртуализации и одна программа
никогда не получится, и намного больше случаев когда вся это сложность не нужна,
чем наоборот.
Здравствуйте, Zhendos, Вы писали:
Z>но пары книжек явно не хватит при отладке всей это хрени из сотен разных программ Z>размазанных на куче физических машин.
разбираться с сотней разных программ на куче физических машин если они установлены "штатно" не чуть не легче
Здравствуйте, smeeld, Вы писали:
C>>Docker работает через namespace'ы в Линуксе, с использованием cgroups для контроля ресурсов S>Бро, не надо мне этих откровений, о которых в любом детском саду в курсе. А вот тебе следует знать, что в докере поверх cgroups такой очень жирный пласт очень глючного говнокода, которыей ваяли хепстеры, и который толком никто не продумывал, и который толком никто не тестировал. Загляни. Вот он и глючит. Oдин overlay, коего успели наваять уже несколько вурсий одна глучнее другой, чего стоит.
Нету там говнокода. Я заглядывал в runc и посылал туда патчи. Можно пример строчек, пономерно?
Z>Э... Вы же сами писали что специалистов по k8s очень сложно найти, Z>я предположил что усложнив технологию еще получим совсем куцое количество специалистов. Z>Неужели вы не согласны что чем сложнее какой-то предмет тем меньше количество людей Z>в нем разбираются до конца?
До совершенства в любой теме доходят единицы. Да и не всегда это нужно, если тема уходит со сцены
Пока сложно найти, но будет тесно и на этой поляне в свое время. Главное, быть впереди прогресса а не на перенаселенном месте.
V_>>Для вышеприведенных проблем, V_>>1. Нужно знать пару базовых команд, docker exec / kubectl exec. Базовые знания Линукса и уметь пользоваться поиском. "Linux check IO load" или "Linux check network load". Если точно приложение "работает на моей машине"
Z>Совершенно бы не помогло. Дело было в баге в ядре Linux, из которого лимиты по CPU применялись неправильно, Z>и контейнерам время от времени не давали кванты времени хотя оно было в избытке.
Вот это уже тема знакомая. У меня тоже так было, в разговор с Ops-ами. У нас есть заапрувленная CentOS с ядром 3.x.x. Я им в ответ, даже не сметь заикаться со старым ядром. В release notes указано по ядру. да и просматривать баги и решения полезно, вместо "указано и заапрулвено" ... 5 лет назад людьми не в теме, которым лень разбираться с вещами, которые они должны продолжать копать.
Да и, вообще, вопрос не в том как у кого не получилось на этапе, который у других получился. Вот подняли бы вопрос, например, "Kubernetes — гуано, потому что Mesos делает XYZ лучше, чем подход Кубернетес ABC". Это была бы правильная тема для преамбулы "Кубернетес гуано"
Z>Совершенно бы не помогло. Дело было в побитых данных в etcd, из-за которых неправильно распределялись Z>задачи по кластеру.
Попробовать на другом кластере?
Z>То есть общая информацию знать конечно хорошо, можно быстрее понять куда копать, Z>но пары книжек явно не хватит при отладке всей это хрени из сотен разных программ Z>размазанных на куче физических машин. Есть подходы и инструменты чтобы бороться Z>со сложностью, но довести до простоты: одна машина — одна ОС без всякой виртуализации и одна программа Z>никогда не получится, и намного больше случаев когда вся это сложность не нужна, Z>чем наоборот.
Я поэтапно проходил все это. И вручную, и "а-ля ансибл" и docker и Kubernetes
Даже для такого, личного и мелкого односерверного, случая точно окупается. По отсутствию головной боли и легкости переноса/обновлению ОС
