Если вы обитаете не в каком-нибудь захолустье, то, наверное, слышали, как ваши разработчики ПО толковали о Docker и вообще о технологиях контейнеризации. Однако у руководителей ранга CXO по этому поводу могут быть вопросы, и они могут недопонимать, что такое в реальности Docker и контейнеры и послужат ли они улучшению уже существующей виртуальной и облачной инфраструктуры. Чтобы лучше понять смысл этой технологии, стоит обратить взгляд в прошлое и поговорить о первичных формах реализации схожих идей.
На заре современных ИТ, когда еще не было клиент-серверной архитектуры и даже ПК и платформы Intel x86, у нас имелись просто физические вычислительные машины — мэйнфреймы и мини-ЭВМ с многопользовательскими функциями.
Для эффективного использования этих ресурсов и взаиморасчетов между пользователями, имеющими совместный доступ к системе, была изобретена концепция «разделения времени». Парадигма централизованных вычислений во многих отношениях была предком того, что мы сегодня, спустя полвека, называем облаком.
В начале
Со временем технология виртуализации также появилась в архитектуре Intel и на ПК. Первоначально ее использовали для решения проблем совместимости, как в случае подсистемы DOS/Windows, реализованной в 1992 г. в OS/2 2.0.
В 1999 г. свой первый продукт создала VMware. Это была версия 1.0 для Linux, предназначенная в первую очередь для запуска Windows и ее приложений, поскольку в то время настольная ОС Linux была весьма бедна собственными приложениями. Продукт VMware был адресован и разработчикам ПО, желавшим запускать свой код в изоляции от рабочей среды, поскольку аварийное падение ВМ с создаваемым кодом не затрагивает основную ОС.
Вместе с быстрым ростом клиент-серверных инфраструктур в
Гипервизоры и виртуальная инфраструктура — это то, что является драйверами нынешних ЦОД, а также IaaS-предложений (инфраструктура как сервис) в публичных облаках. Но несмотря на продолжающиеся усилия по консолидации дата-центров и рост мощи хост-систем виртуализации, ИТ-затраты предприятий на собственные частные ЦОДы или на управляемые провайдером облачные сервисы продолжают расти.
Сегодняшняя IaaS-инфраструктура, эксплуатируемая внутри публичных облаков, например AWS и Microsoft Azure, оплачивается на почасовой основе, причем счет времени запускается при включении ВМ. Обусловлено это тем, что вы платите за почасовое использование виртуальных процессоров (vCPU), которые являются некой частью физических процессорных ядер хост-системы виртуализации.
Сами ВМ несмотря на все их преимущества, скажем, возможность переноса систем и приложений из физической в виртуальную среду без ущерба для фундаментальной архитектуры среды предприятия, зачастую могут поглощать очень значительные ресурсы, особенно при рабочих нагрузках, интенсивно использующих ОЗУ и процессоры, таких как базы данных.
Следует четко понимать, что ВМ представляет собой цельный экземпляр ОС с ядром и драйверами устройств, которому приходится конкурировать за доступ к системным ресурсам с другими ВМ того же гипервизора. На уровне арендуемого частного облака и гипермасштабного публичного облака, где работают тысячи или сотни тысяч виртуальных машин, многие из которых имеют рабочие нагрузки, перенесенные из стен предприятий, вы начинаете сталкиваться с проблемами масштабируемости.
Так каково же стратегическое решение вопроса неконтролируемого роста числа ВМ? Этим решением является контейнеризация. Как и технология ВМ, она тоже берет начало из мира «большого железа». Хотя она еще раньше присутствовала в FreeBSD под названием «Jailing» (Изоляция), первая коммерческая реализация контейнеров появилась в виде функции «Zones» (Зоны) UNIX-ОС Solaris 10 компании Sun (ныне поглощенной Oracle).
По прошествии времени эта технология проложила себе путь в x86 Linux и Windows в виде продукта Parallels Virtuozzo (ныне бренд Parallels сменен на Odin). Реализация той же технологии в мире Open Source для Linux называется OpenVZ, и ее продолжает разрабатывать FOSS-сообщество, однако в центре внимания работы над свободной технологией контейнеризации сегодня находятся LXC (Linux Containers), которые используются в тандеме с Docker.
Контейнеры похожи на ВМ в том смысле, что они предоставляют отдельное изолированное и дискретное пространство для исполнения приложений в ОЗУ и их размещения в дисковой памяти и выглядят как индивидуальная система, так что каждый контейнер может иметь собственных сисадминов и пользователей. Однако в отличие от ВМ контейнеру не требуется цельный экземпляр или образ ОС с ядрами, драйверами и разделяемыми библиотеками. Вместо этого поверх единственного экземпляра хост-ОС может работать целый стек из десятков, сотен или даже тысяч контейнеров, занимающий малую долю тех ресурсов, которые потребовались бы ВМ, выполняющим те же прикладные задачи. Дополнительные контейнеры могут запускаться за микросекунды по сравнению со временем в минуты или более, необходимым для запуска ВМ. Контейнеры содержат только приложения, параметры их работы и необходимую для них дисковую память. Эту концепцию иногда называют JeOS или «Just enough OS» (ОС в строго необходимой мере).
Это открывает целый ряд возможностей, в частности потому, что контейнеры наследуют библиотеки и патчи от своего хоста контейнеризации. Это дает выгоды в плане управления системами, так как если на хост-системе контейнеризации были установлены исправления, все они будут унаследованы контейнерами, так как последние используют те же разделяемые библиотеки в виде клонированных копий в ОЗУ. К этому следует добавить, что все контейнеры или виртуальные среды, запущенные на хост-системе контейнеризации, используют одну и ту же версию ОС.
Если для запуска ВМ нужен гипервизор, то для работы контейнеров требуется хост-ОС или платформа контейнеризации, например LXC с Docker. Вот почему контейнеризацию также называют виртуализацией на уровне ОС. Если хост-системой контейнеризации служит Linux, в ней запускаются Linux-контейнеры, а если ею служит Windows, в ней будут запускаться Windows-контейнеры. Поскольку для работы множества контейнеров достаточно одного экземпляра ОС, вполне возможно, чтобы хост-системой контейнеров служила даже одна виртуальная машина. Недавно заявленная собственная стратегия контейнеризации VMware базируется на легковесных ВМ типа JeOS Linux.
Итак, мы наконец подобрались к Docker — технологии контейнеризации, которая сегодня привлекает всеобщее внимание. В ОС Linux реальным механизмом контейнеризации Docker является LXC. От других, описанных выше технологий контейнеризации Docker отличается тем, что предоставляет способ «упаковки» сложных приложений и их выгрузки в открытые репозитории, откуда их потом можно загружать в публичные или частные облака, где работают хост-системы Docker (ОС для запуска Docker Engine с платформой контейнеризации), примерно так же, как вы загружаете приложения из App Store на свой смартфон или планшет. И по аналогии с ВМ, которые можно переносить из одной хост-системы виртуализации в другую, контейнер можно легко (и гораздо быстрее) перенести с одного хоста контейнеризации на другой.
Docker при использовании инструментов Swarm также предоставляет собственные функции кластеризации, и хост-системы контейнеризации можно будет группировать.
В настоящий момент Docker главным образом является технологией упаковки контейнеров на основе Linux. Но ситуация быстро меняется. Партнерские отношения с Docker завязала Microsoft, приняв эту технологию в качестве стандарта контейнерной упаковки для Azure, так что приложения Linux Docker смогут беспрепятственно работать в ее публичном облаке.
Microsoft также намерена создать свою родную версию Docker Engine for Windows, родную версию Docker Client и будет разрабатывать родной формат совместимых с Docker контейнеров для Windows, официально именуемый как Windows Server Containers. Windows Server Containers смогут работать «на железе» или внутри ВМ Windows Server, работающих под Hyper-V. Хотя точные сроки появления таких контейнеров в Azure и Windows официально не объявлены, ожидается, что более подробная информация будет представлена на предстоящей конференции BUILD.
Что это означает для руководителей уровня CXO? Это значит, что использование ВМ у нас пойдет на убыль, и контейнеры смогут обеспечивать гораздо более высокую плотность вычислительных ресурсов, что приведет к общему снижению затрат на облачные вычисления, особенно на гипермасштабном уровне, подобно уже имевшему место снижению цен на облачную память.
И поскольку Docker и родственные технологии контейнеров продолжают набирать зрелость, вам следует подумать о перестройке или модернизации ваших бизнес-приложений для использования их в контейнерах, работающих в публичных и частных облаках.
