VMware в мире контейнеров

Заглянем в прошлое?

Контейнеризация (виртуализация на уровне операционной системы) с каждым днем все глубже проникает в жизнь разработки и управления приложениями. Уже трудно встретить ИТ-специалиста, который не слышал бы о таких разработках, как Docker, Kubernetes или иных технологиях контейнерной виртуализации.

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

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

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

Вначале был chroot

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

Технология была представлена после трех лет разработки в 1982 году и не эволюционировала вплоть до 2000, пока в операционной системе FreeBsd не появился механизм Jail, отличающийся от chroot еще большей изоляцией окружения. На материнской системе создавались экземпляры FreeBsd, использующие общее ядро, но с обособленной сетью, набором приложений и файловой системой. При этом доступ к общей памяти тоже был ограничен, что сделало Jail действительно первой системой контейнеризации в околосовременном представлении.

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

Вслед за Jails достаточно быстро аналогичное решение появляется в сообществе Linux (vserver в 2001 году). Далее события развивались лавинообразно. 2004 год ознаменовался появлением Solaris Containers, 2005 — Open VZ, 2008 — LXC, 2011 — Warden, а в 2013 компания Google представила свое решение под названием LMCTFY (Let Me Contain That For You), прекратившее свое существование в 2015 году.

Но нас больше интересует событие, произошедшее в том же 2013-м и поднявшее технологию контейнеризации на новый уровень популярности. Мы говорим, конечно же, о появлении Docker. До этого момента контейнерная виртуализация использовалась преимущественно в решениях VPS из-за большой плотности и экономии ресурсов, позволяя провайдерам получить более 60% выгоды по сравнению с виртуальными машинами. Но Docker позволил нам взглянуть на эти технологи совершенно с другого ракурса.

Герой, которого мы заслуживаем

Если максимально упростить, то Docker делает следующее. К примеру, вы написали некое приложение и хотите передать его заказчику, или переносите его из dev в prod, или просто просите друга помочь его доработать. Для этого вам надо как-то передать это приложение. Вы можете скинуть его кодом, но тогда все накладные расходы по разрешению зависимостей для запуска приложения кладутся на принимающую сторону. Используя Docker, вы можете подготовить образ, в который будут уже заложены все необходимые компоненты и само приложение, и быть спокойным, что оно поведет себя именно так, как вы задумывали, когда из этого образа на второй площадке будет запущен контейнер.

Происходит это так. Вы скачиваете (или создаете) базовый образ из Docker HUB (эдакий магазин образов с различными дистрибутивами Linux и предустановленным набором утилит), пишете dockerfile (сценарий, описывающий, что мы хотим сделать в этом образе: установить дополнительный софт или добавить библиотеки, к примеру), подготавливаете образ с помощью dockerfile, а затем просто запускаете из него контейнер. При запуске контейнера из образа накладываются последние штрихи в виде hostname, сетевой части, ресурсов и прочего. Так называемый верхний слой, который отсутствует в исходном образе. Все. Приложение запущено, при этом мы экономим время на доставку и разработку, а со стороны инфраструктуры — ресурсы.

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

А как же VMware?

Так при чем тут VMware? Начнем с того, что компания VMware активно поддерживает и развивает Kubernetes и контейнерную виртуализацию совместно с остальным комьюнити, в которое также входят такие гиганты, как IBM, Google, Microsoft и Red Hat. Кроме этого, в рамках VMware Open Source Projects существуют собственные open source решения для работы с контейнерами. Примером может являться VMware VIC (vSphere Integrated Containers), который позволяет запустить контейнер в виде виртуальной машины vSphere со всеми вытекающими из этого преимуществами в виде управления ресурсами на уровне хоста vSphere, vMotion, HA, мониторинга, управления всей инфраструктурой из единой точки и прочих. Так как доступна работа с Docker API, можно работать с контейнерами прямо из Docker CLI с той лишь разницей, что контейнеры разворачиваются сразу в ВМ на хосте vSphere.

Каков сценарий использования VIC? Главный сценарий — предоставить собственную песочницу для разработки и управлять ею в рамках единой виртуальной инфраструктуры VMware. Либо получить фундамент для построения процессов CI\CD от провайдера как сервис — вместо построения собственной инфраструктуры контейнерной виртуализации.

В основе решения лежит VIC Engine, который, грубо говоря, реализует функционал запуска контейнеров в виде ВМ, но вынесен за пределы исполняемой среды в качестве отдельного модуля VCH (Virtual Container Host). VCH, кроме прочего, управляет виртуальной машиной Docker Endpoint, через API которой конечный пользователь и осуществляет управление контейнерами. На практике мы взаимодействуем с данной технологией точно так же, как с обычными docker-контейнерами. Virtual Container Host можно представить как Docker, но стоящий отдельно от своих контейнеров.

Следующим open source решением является Project Harbor, который по своей сути является форком Docker HUB для корпоративного использования. Docker Hub может не отвечать вашим стандартам безопасности, либо вам необходимо развернуть свой реестр по тем или иным причинам, поэтому Harbor позволяет создать собственный репозиторий образов и использовать его совместно с Docker или VIC. Harbor имеет достаточно широкий набор функций и умеет сканировать образы на предмет уязвимостей, позволяет аутентифицироваться с помощью LDAP и Active Directory, а также производить изоляцию контейнеров на уровне ролей (по проектам или административной роли). Нельзя забывать о возможности подписывать образы при операции push, что добавляет дополнительное очко в копилку безопасности всей инфраструктуры контейнеризации и делает Harbor полноценным реестром образов корпоративного класса.

Последний проект, который направлен на удобство построения контейнерной инфраструктуры, — VMware Admiral. Он позволяет управлять всей системой из единого портала. Вы можете создать кластер из Virtual Container Host или отдельных Docker-систем, интегрировать их с репозиториями Harbor или Docker HUB, использовать систему мониторинга или разворачивать приложения нажатием пары клавиш. Оно распространится по кластеру в том количестве, которое указано в политике.

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

Вместо заключения

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