Здравствуйте, Zhendos, Вы писали:

Z>Здравствуйте, Явь-Истъ, Вы писали:


Z>Инструмент конечно не может быть плохим или хорошим. Но очевидно что у каждого использования
Z>инструмента для решения задачи есть преимущества и недостатки. И недостатки контейнеров очевидны:

Z>1. повышенное потребление памяти, эти ведь разные версии библиотек/интерпретаторов/виртуальных машин не святым
Z> воздухом питаются и тратят и кэш на самом диске и ОЗУ которую использует ОС для кэширования I/O и
Z> кэши инструкций процессора и т.п.. У snap вообще все печально, насколько я знаю,
Z> там даже одинаковые версии библиотек не разделяются, потому что нет фичи аналогичной "послойной" ФС в
Z> docker. Иначе сложно объяснить почему калькулятор так долго стартует (одно из первых snapd приложений в Ubuntu)
Z>2. сложность внесения критичных исправлений, например исправление уязвимостей.

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


По памяти я уже приводил пример

Автор: Vetal_ca
Дата: 20.05.20

Конкретно по нему, надо отключать мониторинг и прочие программы из кластера.

Самая же большая часть расходов и непредвиденностей — люди.

Только по сравнению с этим дополнительные (очень небольшие) расходы — копейки. Или они святым воздухом питаются?

Дальше (сверху) идут огромные business values, типа переносимости, прозрачности и структуризации.

Пусть будет супер-документация, до последней буквы соответствующая реальному положению дел. Это не заменит "в одну строчку", "деплой" или "покажи все что у нас есть, только точно". Безо всяких там Cron jobs на стороне или патчей наложенных 7 месяцев назад, в спешке

Здравствуйте, Zhendos, Вы писали:

Z>Здравствуйте, Явь-Истъ, Вы писали:


Z>Инструмент конечно не может быть плохим или хорошим. Но очевидно что у каждого использования
Z>инструмента для решения задачи есть преимущества и недостатки. И недостатки контейнеров очевидны:

Z>1. повышенное потребление памяти, эти ведь разные версии библиотек/интерпретаторов/виртуальных машин не святым
Z> воздухом питаются и тратят и кэш на самом диске и ОЗУ которую использует ОС для кэширования I/O и
Z> кэши инструкций процессора и т.п.. У snap вообще все печально, насколько я знаю,
Z> там даже одинаковые версии библиотек не разделяются, потому что нет фичи аналогичной "послойной" ФС в
Z> docker. Иначе сложно объяснить почему калькулятор так долго стартует (одно из первых snapd приложений в Ubuntu)
Z>2. сложность внесения критичных исправлений, например исправление уязвимостей.

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


По памяти я уже приводил пример

Автор: Vetal_ca
Дата: 20.05.20

Конкретно по нему, надо отключать мониторинг и прочие программы из кластера.

Самая же большая часть расходов и непредвиденностей — люди.

Только по сравнению с этим дополнительные (очень небольшие) расходы — копейки. Или они святым воздухом питаются?

Дальше (сверху) идут огромные business values, типа переносимости, прозрачности и структуризации.

Пусть будет супер-документация, до последней буквы соответствующая реальному положению дел. Это не заменит "в одну строчку", "деплой" или "покажи все что у нас есть, только точно". Безо всяких там Cron jobs на стороне или патчей наложенных 7 месяцев назад, в спешке.


Самая главная проблема докера и Кубернетес это отсутствие квалифицированных специалистов. Квалифицированных ы контейнерах, кластерах или просто, готовых учиться с интересом.