Docker и контейнеры (часть 1) — понимание контейнеров

• Docker и контейнеры (часть 4) — реализация контейнеров Windows Server
• Докер и контейнеры (Часть 6)

Введение

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

В этой серии статей мы рассмотрим основные концепции контейнеров и платформы Docker; как контейнеры реализованы в Windows Server, Hyper-V и Microsoft Azure; новая служба контейнеров Azure; и различные инструменты, доступные для оркестровки решений на основе контейнеров.

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

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

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

Виртуализация впервые появилась на платформе Microsoft Windows в Windows 3.1 с диспетчером виртуальной памяти (VMM), который управлял тем, как информация в физической памяти (ОЗУ) может быть выгружена на диск. Это создавало иллюзию того, что у компьютера больше оперативной памяти, чем на самом деле, и позволяло одновременно запускать на компьютере больше приложений. Но виртуализация действительно проявила себя на платформе Windows с включением аппаратной виртуализации на основе гипервизора через новую роль Hyper-V, представленную в Windows Server 2008. До этого организациям, которые хотели запускать виртуальные машины на базе Windows, приходилось использовать сторонний продукт, такой как VMware ESX. Однако, начиная с Windows Server 2008, теперь они могли запускать несколько виртуальных машин на базе Windows (а позже и на базе Linux) на одном физическом хост-компьютере с Windows Server 2008 без необходимости использования стороннего гипервизора.

Хотя аппаратная виртуализация по-прежнему широко используется в корпоративных средах любого размера, существует еще один тип виртуализации, который еще старше, но до недавнего времени был доступен только на платформе UNIX/Linux. Этот другой вид виртуализации обычно называют виртуализацией операционной системы (ОС), но он также имеет другое название, а именно контейнеры. Чтобы понять, что такое контейнеры, полезно сравнить их с гораздо более известной (по крайней мере, админам Windows) технологией виртуальных машин.

Чем контейнеры отличаются от виртуальных машин?

На рис. 1 ниже показан пример аппаратной виртуализации, когда две виртуальные машины работают на физическом хост-компьютере с использованием технологии гипервизора, реализованной в роли Hyper-V на платформе Windows Server:

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

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

Теперь давайте сравним это с примером виртуализации ОС, как показано на рисунке 2, где у нас есть два контейнера, работающих на хост-компьютере, поддерживающем виртуализацию ОС:

Рис. 2. Иллюстрация виртуализации ОС, которая позволяет запускать несколько контейнеров на одном физическом или виртуальном хост-компьютере.

Вы должны легко увидеть различия между этой диаграммой и предыдущей. Эти различия заключаются в следующем:

• Уровень гипервизора отсутствует. В аппаратной виртуализации (как реализовано в Hyper-V) гипервизор — это уровень программного обеспечения, который создает несколько изолированных виртуальных машин, которые совместно используют одни и те же базовые аппаратные ресурсы (ЦП, ОЗУ, диск, сеть) базовой физической хост-машины. Однако виртуализация ОС не использует технологию гипервизора, а использует другой подход, который мы вскоре рассмотрим.
• Каждый контейнер содержит только код приложения (здесь только одно приложение на контейнер, хотя у вас может быть больше). Контейнеры не содержат установленных экземпляров гостевой ОС; вместо этого каждый контейнер совместно использует файлы ОС (ядро и библиотеки) базовой ОС хоста. Из-за этого контейнеры используют гораздо меньше виртуальных ресурсов (например, памяти и диска), чем виртуальные машины; поэтому прямоугольники, представляющие контейнеры, показаны тоньше, чем прямоугольники для виртуальных машин на предыдущей диаграмме.
• Базовый хост-компьютер, на котором размещаются контейнеры, может быть физическим или виртуальным компьютером. Это обеспечивает гибкость реализации технологии контейнеров как в частных центрах обработки данных, так и поставщиками облачных услуг.

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

Так как же все это работает? Технология гипервизора хорошо изучена; см. статью Введение в Hyper-V в Windows Server 2008 из журнала TechNet, если вам нужно быстро освежить в памяти. Однако технология контейнеров является новой для многих из нас, кто работает с платформой Windows Server, поэтому давайте кратко объясним, как она работает.

Как работают контейнеры?

Реальная реализация контейнерной технологии для платформы операционной системы зависит от базовой архитектуры этой платформы. Другими словами, виртуализация ОС работает одним способом в Linux (на самом деле она была реализована различными способами на этой платформе) и другим способом на платформе Windows Server (это будет в следующей версии). Но пока мы оставим детали реализации контейнеров в грядущей операционной системе Windows Server 2016 и вместо этого просто опишем в общих чертах, как работают контейнеры.

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

Изоляция

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

Контроль ресурсов

Однако для того, чтобы это работало, также должен существовать механизм управления ресурсами, то есть для управления тем, какая часть физических ресурсов каждой хост-машины должна быть выделена каждому контейнеру, размещенному на машине. Например, вы можете ограничить контейнер № 1 возможностью использовать максимум 5 % циклов ЦП хост-компьютера и 10 % пропускной способности сети, в то время как контейнер № 2 будет иметь 15 % ресурсов ЦП и 20 % пропускной способности сети. доступная пропускная способность.

Вывод

Эта первая статья в этой серии помогла нам понять, что такое контейнеры и как они работают. Позже в этой серии мы подробно рассмотрим, как технология контейнеров будет реализована в грядущей операционной системе Windows Server 2016, но сначала нам нужно узнать о Docker и о том, почему он вызвал огромную волну интереса к контейнерам за последние пару годы.

• Docker и контейнеры (часть 4) — реализация контейнеров Windows Server
• Докер и контейнеры (Часть 6)