Комментарии 22
Вижу список преимуществ, но не указаны недостатки использования контейнеризированного приложения в сравнении с обычным развертыванием на сервере приложений. Разве их нет?
Оверхед, конечно же. Если один контейнер притащит за собой все свои зависимости, и другой тоже притащит свои, и у них окажутся разные версии - все это будет занимать место.
В чём здесь оверхед? Ты ставишь два приложения со своими зависимотями не в докере и получаешь тот же самый размер своих зависимостей, да еще конфликтующих друг с другом, вот где будет тебе твой оверхед.
Ставишь не в докере - зависимости решает менеджер пакетов - обычно без конфликтов. Если одно приложение требует libssl, и другое тоже - если их установил пакетный менеджер - libssl будет та что в дистрибутиве, одна. И в память ее загрузят 1 раз.
Если одно приложение в одном контейнере живет с libssl1.1, а другое в другом с libssl3.0 (это же docker, так можно) - будут установлены обе, каждое в своем контейнере. Будут занимать место и на диске, и в памяти.
Если апп1 требует либссл1, а апп2 требует либссл3, то менеджер пакетов не сможет разрешить конфликт. В вашем кейсе не верно описаны минусы.
Ключевой минус контейнеризации повышение сложности и следовательно повышение требований к квалификации, а большая квалификация требует больших расход на поиск, найм и удержание, а так же ФОТ. Однако в 99% случаев выгоднее более квалифицированные кадры для повышения эффективности, но возможно такие кадры экономически оптимальней было бы делегировать на частичный аутстаф.
Если и app1 и app2 ставятся менеджером пакетов - они либо установятся без конфликтов, либо не установятся никак. Если каждое приложение в своем контейнере - может быть по всякому, в том числе и вот так.
А раньше было святое правило: Если ты обновил версию либссл1 до версии либссл3, то работа приложения с либссл1, должна поддерживаться и в либссл3. И никакие докеры не нужны.
Только приложение апп1 ты купил в рога и копыта, а они закрылись и у тебя нет исходников. Ну или не закрылись, а цену поставили х10 за обновление и уже экономически не выгодно обновлять. А предыдущая версия апп1 не поддерживает либссл3 потому что там ABI изменился.
А раньше было святое правило
Оно и сейчас есть. Только его не всегда придерживаются. И что тогда делать, если одно приложение перешло на ssl3, а другое остановилось на ssl1.1? docker позволяет просто запустить каждое приложение в его собственном окружении, без dll hell.
Конечно же есть. Кастомизация например
Например, тут же была статья о том, как контейнеры "подрались" за системный вызов ядра. Одна из библиотек, включенных в контейнеры давала большое количество обращений к системному вызову, который ядро не могло в таких количествах (когда много контейнеров сразу запустили) обработать. И поиск проблемы в таком случае был весьма нетривиален. Ибо нагрузки на CPU нет, а тормозит всё так, будто он под максимальной нагрузкой.
Upd: почему-то умудрился промахнуться мимо ветки с вопросом о недостатках
И поиск проблемы в таком случае был весьма нетривиален
O_o
top, iotop, etc. Процессы в контейнерах - самые обычные процессы. Только мониторить нужно не изнутри контейнера ;)
Нет, надо именно с хоста мониторить, а ещё нагрузка на цпу есть и можно увидеть если смотреть потоки ядра или косвенно через wait и\или steel.
И увидеть, что нагрузки нет, а тормоза есть. Если я правильно помню, то авторы выловили проблему, используя eBPF для сбора статистики использования системных вызовов с хоста, где проблема есть и где нет. Обычные инструменты показывали, что всё хорошо, что на хосте, что внутри контейнера.
Обновление версий софта весьма интересный процесс. Сложно/невозможно обновлять версии "на лету". Большее время простоя. Возможно запаздывание обновлений, устраняющих критические уязвимости. Некоторый софт и вовсе может не обновлять какие-то библиотеки и существовать с критическими уязвимостями годами.
виртуальным машинам, которые включают в себя гипервизор, операционную систему и само приложение
Это когда в виртуальной машине есть гипервизор? Кроме экзотических случаев вложенной виртуализации, которым обычно не место в проде.
Очень похоже на перевод.
Господи, статья выглядит также , как и оф.дока Докера - просто название и ничего информативного. Где хоть один пример? Вижу только описания того, что такое докер и какой он крутой и какое за ним будущее.
Публикации
Docker: как создавать образы контейнеров и развертывать приложения