Назовите преимущества и недостатки контейнеров по сравнению с виртуальными машинами

Что такое контейнер и контейнерная виртуализация

В свое время контейнерная перевозка грузов стала настоящим прорывом в логистике товаров, что в дальнейшем повлияло на экономику всего мира. Такой способ позволил удобно и без потерь перевозить товар. В IT похожий способ комплектации переняли для работы с программами и приложениями в виртуальной среде. Теперь большое количество комплектующих приложения можно поместить в виртуальный контейнер.

В этой статье мы разберём, что такое контейнеризация и для чего её используют.

Прародителем контейнеризации была технология виртуализации. Это возможность запуска нескольких операционных систем на одном физическом устройстве. Виртуализация использует ресурсы устройства (память, процессор, устройство ввода и вывода), но при этом работает как отдельный компьютер со своей операционной системой. Чтобы создать на компьютере или сервере виртуальную среду, нужно установить программу — виртуальную машину. Примерами таких программ являются VirtualBox, Parallels Desktop, Microsoft Hyper-V.

Созданием виртуальной машины и её управлением занимается гипервизор. Он обеспечивает изоляцию операционных систем друг от друга и разделение ресурсов между ОС. Виртуализация может пригодиться, например, при тестировании новой программы. При создании новых продуктов сложно сразу продумать все возможные конфликты с архитектурой ОС компьютера. Для выявления всех проблем программы проводят множество тестов и доработок. Чтобы не повредить основную операционную систему, в виртуальной среде можно создать новую (дополнительную) и протестировать программу на ней. Так как обе системы изолированы друг от друга, в случае ошибки основная ОС не пострадает.

Подобную функцию выполняет контейнеризация. Это виртуализация, которая работает на уровне операционной системы, в ядре. Ядро — центральная часть ОС, которая координирует ресурсы компьютера (процессорное время, память, внешнее аппаратное обеспечение, внешнее устройство ввода и вывода информации) для приложений. Также ядро предоставляет файловую систему и сетевые протоколы. При контейнеризации ядро операционной системы поддерживает несколько изолированных экземпляров пространства вместо одного. Эти экземпляры пространств называют контейнерами.

Контейнер ― это помещенный на виртуальный диск файл, в который упаковывается приложение со всеми необходимыми для его работы зависимостями: кодом приложения, средой запуска, системными инструментами, библиотеками и настройками. Он запускается при помощи контейнерного движка (Docker, CRI-O, Railcar, RKT, LXC).

Контейнерный движок ― это программное обеспечение, которое принимает запросы пользователя, скачивает контейнеры и запускает их. Запуск контейнера происходит при помощи API-обращений.

Отличие виртуальной машины от контейнера

Главное отличие ― способ работы. При виртуализации создается полностью отдельная операционная система. При контейнеризации используется ядро операционной системы той машины, на которой открывается контейнер.

Ещё одно значимое отличие ― размер и скорость работы. Размер виртуальной машины может составлять несколько гигабайт. Также для загрузки операционной системы и запуска приложений, которые в них размещены, требуется много времени. Контейнеры более лёгкие — их размер измеряется в мегабайтах. По сравнению с виртуальными машинами, контейнеры могут запускаться намного быстрее.

Для чего используют контейнерные системы

Удобная работа с кодом при создании нового продукта. Некоторые разработчики работают удалённо на локальных компьютерах. Нередко им приходится пересылать код программы. Чтобы упростить процесс, весь код можно собрать в один контейнер. Далее из этого контейнера будет не только легко получить программу, но и протестировать её на компьютере без ущерба для основной ОС.

Быстрая передача продукта пользователям. Часто при работе со сложными программами приходится устанавливать дополнительные настройки, скачивать библиотеки и другие вспомогательные элементы. При использовании контейнера можно сэкономить время — всё, что нужно для установки, уже содержится в нём. Пользователю достаточно ввести только одну команду для запуска. Это удобно и для разработчиков, так как пользователи меньше обращаются в техническую поддержку.

Преимущества контейнерной виртуализации

Скорость работы. Как говорилось раньше, контейнеры «весят» меньше, чем виртуальные машины, что позволяет устанавливать и запускать их быстрее, чем машины.

Защита от ошибок. Так как контейнеры изолированы один от другого, ошибки, обновления и изменения в одном контейнере не влияют на другой.

Стандартность. Большинство контейнеров основаны на стандартах, что позволяет им работать в Linux, Microsoft и других системах.

Возможности транспортировки среды. Контейнер упаковывает абсолютно все необходимые данные (сведения о приложениях, операционной системе), которые нужны для запуска. Благодаря этому контейнеры можно легко переносить из одних рабочих сред в другие.

Недостатки контейнерной виртуализации​

Ограниченность архитектуры. Можно использовать только те контейнеры, которые созданы для конкретной архитектуры. Например, если контейнер создан для Linux, то его нельзя будет использовать для Windows. Также стоит отметить, что контейнеризация Linux более распространена среди разработчиков, поэтому найти контейнеры программ для других операционных систем сложнее.

Низкая безопасность. Контейнерная виртуализация распространяется в основном при помощи публичных репозиториев. Злоумышленники могут вставить свои библиотеки, которые позволят им заразить сервер пользователя. На уязвимость также влияет более низкая изоляция в отличие от виртуальных машин. Из-за этого зараженный контейнер может атаковать основную операционную систему компьютера и повредить её.

Новизна технологии. Этот вид виртуализации только начал свой путь, поэтому при работе с контейнерами могут возникать трудности. Для решения проблем можно задавать вопросы на форумах или обращаться к технической поддержке сервиса, который предоставляет услугу контейнеризации.

Мы рассмотрели, что такое технологии контейнеризации и виртуализации, для чего используются контейнеры и какие у них преимущества и недостатки. Надеемся, что статья помогла определиться, подойдет ли контейнеризация для ваших целей.

Источник

Сравнение контейнеров и виртуальных машин

Узнайте о различиях между контейнерами и виртуальными машинами (ВМ), их популярных поставщиках и способах их совместного применения.

Контейнеры и виртуальные машины — очень похожие между собой технологии виртуализации ресурсов. Виртуализация — это процесс, при котором единичный системный ресурс, такой как оперативная память, ЦП, диск или сеть, может быть «виртуализирован» и представлен в виде множества ресурсов. Основное отличие контейнеров и виртуальных машин заключается в том, что виртуальные машины виртуализируют весь компьютер вплоть до аппаратных уровней, а контейнеры — только программные уровни выше уровня операционной системы.

Что такое контейнер?

Контейнеры — это легкие программные пакеты, содержащие все зависимости, необходимые для запуска автономного программного приложения. К этим зависимостям относятся системные библиотеки, сторонние пакеты кода и другие приложения уровня операционной системы. Зависимости, входящие в контейнер, находятся на уровнях стека выше уровня операционной системы.

Плюсы

Минусы

Популярные поставщики контейнеров

Что такое виртуальная машина?

ВМ — это тяжелые программные пакеты, которые обеспечивают полную эмуляцию низкоуровневых аппаратных устройств, таких как ЦП, дисковые и сетевые устройства. ВМ также могут включать дополнительный программный стек для запуска на эмулируемых аппаратных средствах. Эти аппаратные и программные пакеты позволяют получить полнофункциональный снимок вычислительной системы.

Плюсы

Минусы

Популярные поставщики виртуальных машин

Какой вариант подходит для вас?

Если вы выставляете определенные требования к оборудованию для вашего проекта или ведете разработку на одной аппаратной платформе, но целевой является другая платформа, например Windows или macOS, используйте виртуальную машину. Большинство других требований, предъявляемых только к программному обеспечению, можно удовлетворить с помощью контейнеров.

Как использовать контейнеры в связке с виртуальными машинами?

Ничто не мешает использовать контейнеры и виртуальные машины вместе, хотя практические примеры такого использования могут быть ограничены. Можно создать виртуальную машину, которая эмулировала бы уникальную аппаратную конфигурацию. Затем на оборудовании этой виртуальной машины можно установить операционную систему. После того как виртуальная машина будет готова и способна загружать операционную систему, поверх нее можно установить контейнерную среду выполнения. В результате получится функциональная вычислительная система с эмулированным оборудованием, на котором можно устанавливать контейнеры.

Одним из практических примеров использования такой конфигурации являются эксперименты с развертыванием в системах на микросхеме. Популярные вычислительные устройства с системой на микросхеме, такие как Raspberry Pi или макетные платы BeagleBone, можно эмулировать как виртуальные машины, чтобы экспериментировать с запуском на них контейнеров до тестирования на реальном аппаратном обеспечении.

Но в большинстве случаев для конкретной виртуализации достаточно использовать что-то одно: ВМ или контейнеры. Чтобы сделать правильный выбор, важно понимать потребности в ресурсах и то, на какие компромиссы вы готовы пойти.

Источник

Контейнеры и виртуализация: быстрее, эффективнее, надежнее

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

Как известно, виртуализация в привычном ее формате (то есть подразумевающая запуск полноценной операционной системы внутри другой операционной системы) не всегда была такой «бодрой» и эффективной, как сейчас. Первые версии гипервизоров отличались относительной медлительностью и действительно приводили к серьезному снижению производительности по сравнению с тем, как операционные системы и запущенные в них приложения работали на «реальном железе».

Именно поэтому, когда наша компания только начинала работать над продуктом, который называется сегодня Virtuozzo, мы выбрали направление, которое называют сегодня «Контейнерами ОС» или «Легкими ВМ». В чем разница? А разница в том, что наши легкие ВМ не требовали и не требуют запуска отдельного ядра для каждой «сущности», работающей на сервере. Вместо этого мы берем готовое ядро Linux и предлагаем ему разделить все ресурсы между разными пользователями. Речь, конечно, шла не совсем о стандартном дистрибутиве Linux, а о модифицированной версии, которая могла изолировать пользователей между собой, предоставляя им доступ, например, только к отдельным частям дерева процессов, к отдельным сетевым адаптерам и так далее. Все это было очень востребовано, так как работала в десятки раз быстрее, чем полная виртуализация.

Но а пользователь фактически получал свой изолированный дистрибутив Linux: при доступе через SSH он видит определенные ресурсы, разрешенные процессы и не может влиять на других пользователей. Именно так и сложилась модель предоставления виртуального хостинга на базе контейнеров ОС (или «Легких ВМ») – максимум эффективности при минимальной нагрузке на серверы.

Прогресс неизбежен

С тех пор, как первая версия Virtuozzo была представлена в далеком 1999 году, прошло много времени, за которое технологии виртуализации – как контейнерной, так и полной – претерпели серьезные изменения, и наметились основные вектора поиска «Святого Грааля» — оптимального по своим характеристикам решения для современных cloud-native задач.

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

Что же, за это время средства виртуализации, позволяющие запускать полные версии гостевых ОС, сильно шагнули вперед, что в частности, видно на продуктах VMware. Благодаря тому, что современные процессоры поддерживают ряд оптимизаций для работы с виртуальными средами, количество процессов, которые приходится эмулировать, намного уменьшилось. В результате гостевое ядро все чаще обращается напрямую к оборудованию и лишь по требованию запросы проходят через гипервизор.

Зачем эмулировать простейшие инструкции? Например, арифметика или перемещение байтов могут выполняться процессором непосредственно. То же самое можно сказать и про функцию ret (возврат результата выполнения процедуры). Благодаря тому, что за данными не нужно каждый раз обращаться к гипервизору, виртуальные среды стали работать быстрее. И сегодня производители процессоров продолжают добавлять виртуальный контекст в свои продукты, делая системы виртуализации еще эффективнее.

Контейнерные технологии тоже становились все совершеннее. Например, в нашей собственной версии Virtuozzo Linux была реализована технология ReadyKernel, которая позволяет устанавливать обновления безопасности без перезагрузки сервисов, а значит – делать это в любое время, в том числе, моментально после их анонса. Или другой пример – шифрование дисков контейнеров, чтобы избежать возможности кражи данных, когда «Легкая ВМ» находится в неактивном состоянии. Так что пока средства полной виртуализации становились быстрее, их альтернатива в виде контейнеров ОС становилась более защищенной.

Паравиртуализация

С другой стороны, сами производители операционных систем стали помогать в осуществлении виртуальных инициатив. Сегодня и Linux и Windows являются паравиртуализированными системами. Это значит, что, работая в гостевом режиме, ОС «осознанно» обращаются не к реальному оборудованию, а к гипервизору. Таким образом, они могут один раз заявить гипервизору о серии привилегированных операций и сэкономить массу времени, которое раньше уходило на эмуляцию. В частности, управление памятью и работа с системами ввода/вывода стали на порядок лучше и быстрее, ведь фактически из системы был исключен слой «виртуального железа».

Проксирование

Другая интересная технология, которая сегодня только набирает обороты и может дать большой толчок в развитии именно «Легких ВМ» — это проксирование. Первыми о данном решении заявили в компании Apporeto. Разработчики предложили следующую идею: они проанализировали базу данных уязвимостей и сделали вывод, что уязвимости в файловых системах и сетевом стеке находят всего 1-2 раза в год. Но в интерфейсной части это происходит намного чаще. В результате было предложено использовать всем клиентам один и тот же слой работы с сетью, файлами и другими «глубокими» сервисами ОС, но при этом вынести в гостевые системы все, что связано с интерфейсами. Таким образом, даже если злоумышленник сможет использовать свежую уязвимость, он не сможет пробраться дальше конкретной «Легкой ВМ». На данный момент для реализации подхода необходимо использовать специальный дистрибутив Linux, но учитывая перспективность подхода, в скором времени мы увидим реализацию этого принципа в большинстве стандартных дистрибутивов.

С прицелом на приложения

Впрочем, победоносное шествие Docker определило еще один очень интересный тренд: многим хочется запускать готовые микросервисы – отдельные приложения. И затевать для этого целую виртуальную машину, вроде бы, не имеет смысла. В этом случае можно предоставить владельцу возможность выбирать, какие функции доступны приложению. И этот подход стал весьма популярен за неимением иных готовых решений. Но он подходит только для тех приложений, которым не нужно много функций. В противном случае приходится чем-то жертвовать, а это – не интересно.

Вместо этого стали появляться возможности запустить приложение в гипервизоре без ядра, но снабдить его нужными библиотеками. Такие решения называются Unikernel. Они включают в себя модифицированные системные библиотеки, которые изначально знают, что работают в гипервизоре. Для гипервизора гостевая ОС представляет собой 1 процесс. Так какая разница? Почему не запустить в виде этого 1 процесса наше приложение?

Отличие состоит лишь в том, что приложение вместе с библиотеками формируется как «монолит», который включает в себя нужные модули. Впрочем, сегодня уже создано достаточно автоматизированных инструментов, которые помогают собирать такие комплекты и запускать их прямо в гипервизоре, обеспечивая одновременно и высокую степень изоляции процессов друг от друга, и высокую производительность.

Источник

Контейнеры или виртуальные машины – что выбрать?

Технологии виртуализации значительно изменили процесс вычислений. Благодаря этому удалось повысить эффективность систем и мобильность их использования. Если еще несколько лет назад для развертывания виртуальных серверов применялись гипервизоры и ВМ, то сегодня к ним добавились и контейнеры. Они стали достойной альтернативой классическим методикам и предоставили ряд новых возможностей для настройки инфраструктуры.

В результате многие компании, впервые столкнувшиеся с виртуализацией своей ИТ-инфраструктуры, встали перед трудным выбором – ВМ или контейнер. Различие между решениями заключается в способе применения ресурсов операционной системы и непосредственном расположении прослойки виртуализации. Но по сути обе технологии являются различными вариантами использования имеющихся ресурсов. Разберемся, какой подход стоит выбрать для корпоративных нагрузок и в чем заключается разница технологий.

Особенности и преимущества ВМ

Этот вариант технологии представляет собой специальный программный слой, который устанавливается поверх аппаратной части «железа». Различают гипервизоры 1-го типа, которые по сути представляют собой самостоятельные ОС (это, например, виртуализация на базе VMware vSphere). После установки гипервизора возможно создать необходимое количество виртуальных машин, а на каждую из них – установить собственную операционку и программное обеспечение.

Главная особенность ВМ в том, что они создаются независимо друг от друга, поэтому их ресурсы полностью изолированы. В результате этого любые сбои, вирусы, вредоносные программы влияют только на одну виртуальную машину, не затрагивая другую. Кроме этого, виртуальные машины не зависят от аппаратной части самого хостинга. За счет этого их можно переносить из одной инфраструктуры в другую без каких-либо трудностей и последствий.

Если говорить об основных свойствах и преимуществах решения, то стоит отметить следующее:

За 20 лет активного использования виртуальные машины стали практически неотъемлемым компонентом корпоративной виртуализации. Такую технологию используют для решения бизнес-задач различных масштабов.

Если говорить о недостатках решения, то к их числу можно отнести размер используемых ресурсов. Часто экземпляры ВМ могут занимать большой объем памяти. Кроме этого, в некоторых случаях создание и развертывание одного элемента может занимать длительное время.

Особенности и преимущества контейнеров

Если говорить о виртуализированной контейнерной среде, то она устроена по-другому. Такая технология подразумевает изначальную установку операционный системы на хост. После этого поверх инсталлируются контейнеры. Как правило, это происходит за счет использования специального менеджера, который выполняет функционал гипервизора.

После создания слоя для контейнеров удастся развернуть нужные экземпляры с учетом доступных ресурсов. Но при этом каждый контейнер будет использовать только одну и ту же базовую операционную систему – ту, которая изначально установлена на хосте. Слой контейнеров позволяет добиться лишь логической изоляции между элементами.

Если говорить об основных свойствах и преимуществах контейнерной среды, то стоит выделить:

Если говорить о недостатках, то такая технология имеет меньшую производительность. Связано это с тем, что контейнеры используют общую операционку, поэтому между ними возможны конфликты из-за доступа к аппаратным ресурсам и сети. Также виртуальные контейнеры отличаются низкой совместимостью. Элементы и инструменты, развернутые для одной площадки, напросто могут не работать с другими.

Сравнение решений

Теперь разберемся, какая технология лучше – виртуальные машины или контейнеры. При выборе стоит обратить внимание на следующие критерии:

Выводы

В целом же можно говорить, что обе технологии являются достаточно эффективными и безопасными в использовании. Виртуальные машины лучше подходят для создания устойчивой платформы с большими постоянными нагрузками. Контейнеры – более гибкие и быстрые, однако работают на общей операционной системе. По этой причине их лучше применять для краткосрочных проектов, в которых важна скорость развертывания и масштабируемость. При выборе решения советуем, в первую очередь, руководствоваться целями проекта, а также требуемыми параметрами ресурсов.

Если вы не знаете, что выбрать для своей инфраструктуры, то специалисты нашей компании Xelent готовы помочь в этом вопросе. Вы можете оставить заявку на нашем сайте или позвонить по указанным номерам!

Источник

Контейнеры или виртуальные машины — что лучше выбрать для своей компании?

Вопрос несколько сложнее, чем «куда поместится больше приложений»

Назовите любую технологичную компанию, и можно будет с уверенностью сказать, что она тоже инвестирует в контейнеры. Google — конечно. IBM — да. Microsoft — безусловно. Но тот факт, что контейнеры сейчас невероятно популярны, еще не делает виртуальные машины устаревшими. Ведь это вовсе не так.

Да, контейнеры позволяют уместить гораздо больше приложений на одном физическом сервере, чем любая виртуальная машина. Технологии контейнеризации вроде Docker в этом плане легко кладут на лопатки VM.

Виртуальные машины занимают много системных ресурсов. Каждая из них содержит не только операционную систему, но и необходимое для работы виртуальное оборудование. А это сразу отнимает довольно много оперативной памяти и процессорных циклов. С контейнером ситуация совсем другая — в нем можно разместить только приложение и необходимый минимум системных библиотек для исполнения; на это уйдет минимум ресурсов.

На практике это означает, что при использовании контейнеров вы сможете разместить в два-три раза больше приложений на одном сервере. Кроме того, контейнеризация позволяет создавать портативное и целостное окружение для разработки, тестирования и последующего развертывания.

Если бы наше сравнение на этом заканчивалось, впору было бы писать некролог для классической виртуализации. Но вопрос все же несколько сложнее и шире, чем «куда поместится больше приложений».

Проблема контейнеров № 1: безопасность

Это самая серьезная проблема, которая, однако, часто упускается из виду. Дэниэл Уолш, инженер по безопасности из Red Hat, опубликовал статью «Пустые контейнеры». Там рассматривается Docker, который использует libcontainers в качестве основы. Libcontainers взаимодействует с пятью пространствами — Process, Network, Mount, Hostname, Shared Memory — при работе с Linux. При этом есть множество важных подсистем ядра Linux вне контейнера.

К ним относятся все устройства, SELinux, Cgroups и вся файловая система внутри /sys. Это значит, что при наличии у пользователя или приложения прав суперпользователя в контейнере операционная система может быть взломана. И это плохо.

Есть много способов обезопасить Docker и другие технологии контейнеризации. Например, можно смонтировать /sys только для чтения, заставить процессы контейнеров работать с определенными разделами файловой системы и настроить сеть так, чтобы можно было подключаться лишь к определенным внутренним сегментам. Но ничего из этого по умолчанию не сделано, и вам придется дополнительно озаботиться этими вопросами.

В качестве базового правила можно порекомендовать относиться к контейнерам так же, как вы относитесь к любому серверному приложению. Вот что советует Уолш:

Другая проблема состоит в том, что контейнеризованные приложения выпускает кто угодно. И среди разработчиков всегда найдутся «плохие парни». Если, к примеру, вы или ваши сотрудники достаточно ленивы, чтобы запустить на сервере первый попавшийся контейнер, то вполне можете получить трояна. Важно донести до сотрудников мысль, что нельзя просто скачивать любые приложения из Интернета так же, как они это делают на своих смартфонах.

Вообще, на смартфоны тоже не стоит ставить что попало, но это уже совсем другая история.

Прочие проблемы контейнеров

Получается, если решить вопросы безопасности, то контейнеры будут отличным выбором? Не совсем. Стоит задуматься и о других аспектах.

Роб Хиршфельд, генеральный директор RackN, отметил следующее: «Идея «изолированной коробки» помогает решить часть проблем с нижестоящими системами (вы знаете, что у вас там есть), но никак не с вышестоящими (вы не знаете, от чего зависите)».

Разделение системы на множество более мелких отдельных частей — хорошая идея. Но это означает и то, что управлять придется ЕЩЕ БОЛЬШИМ числом элементов. Всегда существует некая переломная точка между декомпозицией и неконтролируемым разрастанием.

Роб Хиршфельд, генеральный директор RackN

Тут я хотел бы добавить, что это не только проблема безопасности, но и проблема обеспечения качества. Можно сказать, что X контейнеров в состоянии поддерживать веб-сервер NGINX, но достаточно ли вам этого? Включен ли в такое решение заодно и обновленный балансировщик TCP? Развернуть приложение в контейнере довольно легко, но если ошибиться с выбором компонентов, то вы просто потратите время впустую.

Хиршфельд также указывает на серьезность проблемы разрастания числа контейнеров. Стоит помнить о том, что «Разделение системы на множество более мелких отдельных частей — хорошая идея. Но это означает и то, что управлять придется ЕЩЕ БОЛЬШИМ числом элементов. Всегда существует некая переломная точка между декомпозицией и неконтролируемым разрастанием».

Помните: вся суть контейнера заключается в запуске одного изолированного приложения. Чем больше задач вы назначаете на контейнер, тем выше вероятность того, что их стоило решать с помощью виртуальных машин.

Верно, некоторые технологии контейнеризации вроде Linux Containers (LXC) могут использоваться вместо VM. К примеру, LXC можно использовать для запуска определенных приложений Red Hat Enterprise Linux (RHEL) 6 на экземпляре RHEL 7. Но если говорить в общем, то для запуска одного приложения подходят контейнеры, а для нескольких лучше использовать виртуальные машины.

Непростой выбор

Так что же выбрать — VM или контейнеры? Если требуется запустить несколько копий одного приложения, скажем MySQL, то используйте контейнер. Если нужна большая гибкость при работе нескольких программ — задействуйте виртуальную машину.

Кроме того, контейнеры обычно привязывают к определенной версии операционной системы. Это бывает полезно: нет необходимости беспокоиться о зависимостях, если приложение корректно работает в контейнере. Но взамен вы получаете дополнительные ограничения. С виртуальными машинами не важно, какой гипервизор используется (KVM, Hyper-V, vSphere, Xen), — скорее всего, вы сможете запустить там любую ОС. Нет проблемы запустить в VM специфичное приложение, работающее только на QNX. Но реализовать это с нынешним поколением контейнеров становится не просто.

Итак, подытожим:

По мере «взросления» технологии контейнеризации нас ждет такое будущее, где контейнеры и виртуальные машины совместно будут составлять гибкую и портативную облачную среду. До этого еще далеко, но свет в конце тоннеля уже виднеется.

Источник