Предлагаем вам ознакомиться мнением на этот счет известного американского эксперта Брайена Поузи, опубликованным на ресурсе SearchStorage.com.

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

Главные отличия программных контейнеров от виртуальных машин

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

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

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

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

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

Контейнеры начинают теснить виртуальные машины

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

Первая особенность — это «блуждающие ошибки». Это — наиболее коварная опасность, которая вызывает наибольшую озабоченность со стороны разработчиков. Речь идет о настройках и параметрах операционной среды, которая на стадии эксплуатации оказывается иной, чем на стадии разработки. Обеспечить перенос всех параметров со 100%-ной точностью удается не всегда. Иногда это невозможно осуществить даже чисто технически.

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

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

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

Еще одно достоинство контейнерного подхода — это дополнительные удобства в случае дизайна виртуализованного приложения в виде набора независимых микросервисов. Каждый из них выполняет в этом случае только определенную, узкую задачу. Например, когда веб-приложение «разложено» на веб-сервер, СУБД, службу поддержки очередей заданий, и каждая функция оформлена в виде отдельного микросервиса. Такой способ конструирования позволяет улучшить работу системы в целом и сделать ее гибкой в отношении бизнес-потребностей заказчика. Появляется возможность для упрощенного автоматического развертывания обновлений по каждому направлению, становится реальностью децентрализация контроля над кодом и данными.

Разложение на микросервисы позволяет раскрыть и другие достоинства контейнеризации. Например, готовность к масштабированию. Если речь идет о веб-приложении, то становится просто наращивать мощность СУБД, не затрагивая при этом работу веб-сервера и службы заданий. Заказчик может совершенствовать интерактивные возможности своего веб-приложения, которые могут потребовать дополнительные ресурсы, не обращая внимания на то, как ведет себя поток привлеченных клиентов — растет или остается неизменным.

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