Комментарии 16
Непонятно только, почему этим так называемым разработчикам приложений так «зашла» идея заворачивать приложения в изолированных ящиках.
Может потому, что они настолько криворукие разработчики, что не могут написать приложения, которые бы не мешали работе друг-друга?
В 2000-х была популярна шутка про начинающих разработчиков, которые пишут приложения, которые нигде больше не запускаются, кроме как на компе своего создателя. Такое ощущение, что весь тот докер про это.
Если же всё дело в изоляции, то чем системные механизмы изоляции не устраивают? И если все-таки не устраивают, с какого перепугу проблему изоляции прикладных программ решает другая прикладная программа, а не решается это на уровне ОС?
Видимо вы не разрабатывали под Linux. Попробуйте и скоро сами изобретëте свой докер)
Ошибаетесь. Разрабатывал, хоть и не так много, как под Windows.
Ну опишите открытым текстом, что вашим приложениям мешает жить на линукс-машины без завёртывания в контейнер?
И, каким бы ни был ответ, почему вместо допиливнаия линукса (что было бы идеологически верным) лепят нашлёпку поверх недопиленного линукса и ещё и радуются этому?
И как тогда по вашему существовал мир до создания докера? Как кромешный ад и ужас? Это мне напоминает «ощущение» у неофитов, что 100 лет назад мир в принципе был чёрно-белым.
"write once, run anywhere" слышали? Эта фраза еще даже постарше нулевых будет)
Очень сложно писать приложения, которые бы не мешали работе друг друга. Особенно сложные приложения. Особенно когда много приложений. Одному приложению нужно glibc одной версии, другому приложению нужно glibc другой версии, а третьему нужно, чтобы системная библиотека была musl и так далее. А у приложения может быть несколько десятков библиотек. И надо как-то потом все эти библиотеки обновить. И ещё так, чтобы другие приложения не зацепить. И при этом иметь возможно всё откатить если что-то не так пойдёт.
И ещё желательно максимально исключить человеческий фактор, который часто является причиной поломки (что-то забыл, упустил, мы люди, мы ошибаемся, это нормально). Особенно, когда надо обновить ОС и ещё с десяток библиотек.
А потом ещё начинаются различные хотелки, например, сетевой трафик не постоянный, а может сезонно увеличиваться, а затем уменьшаться. И хотелось бы оперативно горизонтально масштабировать приложение, и когда не надо, то отключать лишние экземпляры. И надо как-то следить за всеми проектами (допустим, в компании их около 100 штук), собирать метрики, собирать логи куда-нибудь. Дальше больше, наша реальность суровая и в ней может происходить всё что угодно. И в ней происходит что угодно, приложение может упасть, сломаться, жёсткий диск посыпаться, плата сгореть. Хотелось бы как-то восстановить работоспособность. Желательно быстро и с минимальными потерями.
И уже появляется оркестрация.
Контейнеры и всякие куберы (контейнеры ещё появились в 2005 году в Solaris) - всего лишь инструмент для решения определённых проблем. Решают ли они все проблемы и являются ли панацеей от всего? Нет. Где-то они не нужны и лишние, а где-то решают свои задачи. Хорошо ли они решают проблемы? Где-то да, где-то нет.
Одному приложению нужно glibc одной версии, другому приложению нужно glibc другой версии, а третьему нужно
Так и в чем проблема обеспечить зависимость одного приложения от версии одной библиотеки, а другого приложения от версий другой? Может реально если система не позволяет поставить н-цать версий в себя и подсунуть требуемую(или поддерживаемую) версию приложению - проблема в системе и её надо допиливать, а не делать "костыль" в виде очередной системы имеющей свои проблемы.
Опять же эта любовь линуксоидов ломать поддержку снизу вверх - концептуальная причина этих костылей
Допустим можно написать свой велосипед, чтобы твоё приложение зависело от определённых версий библиотек. Но есть же транзитивные зависимости, когда библиотека зависит от дрйгих библиотек. И надо там аналогичное реализовать, чтобы библиотека как-то умела зависеть от определённых версий своих зависимостей. И так далее. Сможете организовать, чтобы все-все-все разработчики отныне реализовали ваш механизм для версионирования? А этот ваш механизм сможет обеспечить все требования? С удовольствием послушаю как вы реализуете механизм версионирования и как вы убедите всех разработчиков следовать этому механизму. А потом ещё надо заставить все дистрибутивы Linux тоже следовать этому принципу. И не только дистрибутивы, а ещё и другие ОС, например OS X, чтобы разработчик на OS X смог написать приложение, которое сможет работать на CentOS-сервере, и другой разработчик на Arch Linux или MS Windows не имел бы проблем с его запуском и поддержкой.
И опять же, изоляция зависимостей - это одна из проблем, которую пытается решить контейнеры.
Может реально если система не позволяет поставить н-цать версий в себя и подсунуть требуемую(или поддерживаемую) версию приложению - проблема в системе и её надо допиливать
Жду от вас предложение как допилить систему, чтобы решить данную проблему.
Зачем при грузовых перевозках используют контейнеры? Неужели так сложно сделать грузы, которые не мешают друг другу?
Если проблема в изоляции, то почему проблема не решается на уровне корабля и поезда?
Ну это было бы справедливо для всего ПО, включая ОС. Если бы не было зоопарка железа, которое постоянно меняется.
Криворукие разработчики хотят чтобы на новой малинке тоже работало. И все равно ни ОС, ни докер, ни библиотеки не гарантируют до конца, что работать будет так же хорошо.
Вообще, виртуализация зашла и расползлась вовсе не для этого (не для заворачивания приложений). Деньги всегда что-то продвигают (все хотят тратить их рационально) или что-то уходит в Лету из-за их отсутствия (из-за бесполезности этого чего-то). Виртуализация сильно подняла эффективность использования железа (можно сказать, КПД железа). Самое дорогое железо - серверное. Именно серверная виртуализация прокатилась по миру и все обратились в эту веру. Средняя нагрузка серверов до того - где-то 15-20%, значит, 80+ процентов дорогого железа 24/7 молотили воздух. Но админы не могли поднять планку средней загрузки больше, ибо в моменты (минуты, часы) пиковых нагрузок серверА должны их держать. Серверная виртуализация позволила поднять среднюю (именно среднюю!) нагрузку (на гипервизорах) до примерно 80% (всё зависит от конкретных условий). То есть КПД в 4-5 раз! То есть получать ту же вычислительную мощность, скажем, не за 100 000 денег, а за 20-25 тысяч тех денег. Вот в чем главная причина перехода к виртуализации. А то, что можно поиграться в Linux на Windows-машине или наоборот - это побочные плюшки, которые зашли, потому что деньги уже были "уплочены" - почему бы не использовать технологию? А потом пришли контейнеры - еще бОльшая эффективность использования железа. И увидели люди, что в них удобно заворачивать приложения. И пришел Doker и т.п.
Можно еще весь код писать одной функцией, которая будет сразу делать всё что нужно под любым окружением и на любом железе с любыми драйверами (даже на том, которое будет выпущено в будущем). Вопрос изоляции в этом случае легко решается областью видимости и ИФами.
А еще можно версии хранить в папочках или в архивах. Проблема хранения файлов и кода ведь решается на уровне ОС, с какого перепугу эту проблему должен решать другой код.
А доставлять этот код заказчику можно просто зип-архивом через Скайп, всем известный файлообменник популярный в 2000-х.
200+ утащили в закладки. Купился, а смотреть не на что.
Введение в Docker и Kubernetes: основы контейнерных технологий