Начало работы с контейнерами (часть 2)

• Начало работы с контейнерами (часть 6)

Введение

В моей предыдущей статье я потратил некоторое время, чтобы объяснить, что такое контейнеры, а что нет. Проще говоря, контейнер — это объект, который позволяет использовать код для нескольких рабочих нагрузок, обеспечивая при этом границу изоляции (более подробное объяснение см. в моей предыдущей статье). До сих пор я говорил о контейнерах в общем, почти теоретическом контексте.

Прежде чем я начну

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

Основы контейнера Windows Server

Одна из вещей, о которых я упомянул в своей предыдущей статье, заключалась в том, что, основываясь на том, что я прочитал на некоторых досках объявлений в Интернете, контейнеры, кажется, вызывают некоторое замешательство у некоторых администраторов. Основываясь на том, что я прочитал, я думаю, что основная причина этой путаницы заключается в том, что Windows Server 2016 предлагает два разных типа контейнеров. Один тип контейнера основан на Windows Server, а другой — на Hyper-V. Эти два типа контейнеров имеют свои различия, и все же они оба называются контейнерами. Таким образом, я читал сообщения в блогах, которые прямо противоречат друг другу, и все же оба сообщения верны, потому что сообщения относятся к двум разным типам контейнеров. Таким образом, ключом к пониманию контейнеров является сначала изучение основных типов контейнеров и того, как они функционируют. Это то, о чем эта статья.

Хосты и образы

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

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

Следующая концепция, которую вы должны понять, — это образ контейнера. И контейнеры Windows Server, и контейнеры Hyper-V развертываются из образов. Эти образы обычно называются образами-контейнерами.

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

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

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

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

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

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

Любой, кто когда-либо развертывал коллекцию серверов Exchange, знает, насколько трудоемким может быть этот процесс. Недавно мне пришлось развернуть несколько виртуализированных серверов почтовых ящиков Exchange для проекта, над которым я работал. Мой подход заключался в создании образа виртуальной машины (не образа контейнера), содержащего операционную систему Windows Server, необходимые компоненты Exchange Server и копию двоичных файлов Exchange Server. Затем я использовал этот образ для создания своих серверов Exchange. Процесс работал, но было много отходов, потому что каждая полученная виртуальная машина имела свою собственную ОС и свои собственные двоичные файлы Exchange.

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

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

Итак, давайте представим, что вы создаете образ ОС, а затем используете его для создания нового контейнера. Этот новый контейнер выглядит и ощущается как чистая виртуальная машина Windows Server. Поскольку целью в этом случае является развертывание ряда серверов Exchange, вы можете установить двоичные файлы и необходимые компоненты Exchange Server в этот контейнер. Оттуда вы можете сохранить контейнер как изображение. Этот образ не является полноценным сервером Exchange. Он просто содержит компоненты Exchange и указатель на контейнер образа ОС. У него нет собственной операционной системы. После создания контейнера образа Exchange вы можете использовать его для создания серии контейнеров Exchange Server, которые в конечном итоге будут функционировать как серверы Exchange. Эти контейнеры будут содержать очень мало собственного кода, поскольку операционная система и компоненты Exchange находятся в родительских образах.

Вывод

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

• Начало работы с контейнерами (часть 6)