Docker и контейнеры (часть 5) — реализация контейнеров Hyper-V

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

Ранее в этой серии мы рассмотрели основы реализации виртуализации контейнеров в готовящейся к выпуску операционной системе Windows Server 2016. Как мы видели, в Windows Server 2016 появятся два «разновидности» технологии контейнеров, а именно:

• Контейнеры Windows Server
• Контейнеры Hyper-V

В предыдущей статье этой серии мы рассмотрели первый подход и увидели, как можно реализовать контейнеры Windows Server в предварительном выпуске Windows Server 2016 Technical Preview 4 (TP4). Мы продемонстрировали это, сначала создав узел контейнера виртуальной машины в облаке Microsoft Azure IaaS, используя Resource Manager в качестве метода развертывания. Затем мы создали контейнер и настроили его, добавив роль веб-сервера, чтобы мы могли запускать веб-приложения на нашем хосте контейнера. Затем мы захватили образ контейнера из нашего контейнера, а затем создали новый «рабочий» контейнер из захваченного образа. Затем этот новый контейнер можно использовать для запуска контейнерного веб-приложения на нашем узле контейнеров в Azure. Мы закончили предыдущую статью, указав, что нам потребуется использовать группу безопасности сети (NSG), чтобы разрешить доступ к нашим контейнерным веб-приложениям из внешнего мира, но мы собираемся отложить демонстрацию этого до тех пор, пока я не получу коллега из Microsoft, который работал со мной над электронной книгой System Center для Microsoft Press, и собирается написать для нас что-то о NSG, чтобы объяснить, что они собой представляют и как они работают.

Тем временем давайте продолжим обсуждение двух «разновидностей» технологии контейнеров, появившихся в Windows Server 2016, и рассмотрим, как можно реализовать тип контейнера раздела, а именно контейнеры Hyper-V. Я попросил Джона Маккейба показать нам, как реализовать контейнеры Hyper-V в Windows Server 2016 TP4. Джон является старшим полевым инженером уровня Premier (PFE), работающим в службе поддержки Microsoft Services в Ирландии, и его блог Parallel Universe можно найти по этой ссылке. Джон начинает ниже с выделения сходств и различий между контейнерами Windows Server и контейнерами Hyper-V, а затем демонстрирует, как начать работу с контейнерами с помощью Windows PowerShell. Наконец, Джон завершит свое пошаговое руководство кратким описанием того, почему можно вообще подумать об использовании контейнеров вместо виртуальных машин.

Контейнеры Hyper-V и контейнеры Windows Server

В Windows Server 2016 и Windows 10 будут доступны два типа контейнеров:

• Контейнеры Windows Server
• Контейнеры Hyper-V

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

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

На рис. 1 показано сочетание контейнеров Hyper-V и контейнеров Windows Server на одном хосте.

Рис. 1. Контейнеры Windows Server и контейнеры Hyper-V на одном физическом компьютере

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

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

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

Как начать работу с контейнерами

Итак, как начать работу с контейнерами в Windows Server? В следующем списке подробно описан процесс развертывания контейнеров:

1. Включить «контейнеры» функций Windows
2. Создание коммутатора виртуальной машины
3. [Необязательно] Настройте NAT, если требуется
4. Установите образ ОС контейнера
5. [Необязательно] Разверните Docker
6. [Необязательно] Включить Hyper-V
7. [Необязательно] Включить вложенную виртуализацию
8. [Необязательно] Настройте виртуальные машины для вложенных виртуальных машин.
9. [Необязательно] Отключить динамическую память для вложенных виртуальных машин
10. [Необязательно] Включена подмена MAC-адреса для вложенной виртуальной машины.

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

Для контейнеров Hyper-V нам необходимо сначала установить Hyper-V. Если вы планируете использовать комбинацию контейнеров Hyper-V и программных контейнеров вложенных виртуальных машин, нам необходимо запустить следующие командлеты для настройки вложенной виртуальной машины. Эти командлеты включают вложенную виртуализацию, обеспечивая минимальное количество ЦП, равное 2, для виртуальной машины узла контейнера Windows Server. Отключите динамическую память и включите спуфинг Mac для виртуальной машины-контейнера.

В следующем разделе обсуждается общий подход к развертыванию и настройке контейнеров независимо от того, являются ли они контейнерами Hyper-V или контейнерами Windows Server.

В интерфейсе командной строки PowerShell используйте следующую команду для установки компонента «Контейнеры»:

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

В интерфейсе командной строки PowerShell проверьте установку после перезагрузки с помощью командлета Get-ContainerHost:

Контейнерам потребуется некоторое сетевое подключение, чтобы клиенты могли подключаться к приложениям внутри контейнера. Это означает, что нам нужно создать переключатель для использования контейнерами. Командлет New-VMSwitch можно использовать для создания коммутатора виртуальной машины, который можно использовать для подключения образов контейнеров к сети! Коммутатор виртуальной машины для использования в контейнере можно настроить для преобразования сетевых адресов (NAT) или внешнего. Тип внешнего коммутатора позволит вам настроить образ контейнера так, чтобы ему был назначен IP-адрес от корпоративного DHCP-сервера, или статически настроить его. Если вы хотите обеспечить уровень сетевой изоляции для контейнеров, можно настроить NAT, а затем предоставить конечные точки для образов контейнеров.

Используя интерфейс командной строки PowerShell, создайте внешний коммутатор с помощью командлета New-VMSwitch (обратите внимание, что вам нужно будет знать имя адаптера, к которому вы хотите привязать внешний коммутатор виртуальной машины):

Используя PowerShell CLI, мы можем создать коммутатор с поддержкой NAT с помощью командлета New-VMSwitch следующим образом:

В сценарии NAT VM Switch необходимо будет создать объект, который позволит выполнить преобразование. Это называется объектом NAT, и мы можем использовать командлет New-NetNat для достижения этого следующим образом:

Основы настроены, но для начала нам нужны изображения. У Microsoft есть 2 образа, доступных в исходном репозитории для Nano Server и Windows Server Core. Чтобы получить доступ к этим изображениям, нам нужно установить провайдера.

Используя CLI PowerShell, мы можем использовать командлет Install-PackageProvider для установки поставщика контейнеров следующим образом:

Далее нам нужно просмотреть исходный репозиторий для образов контейнеров. Используя CLI PowerShell, мы используем командлет Find-ContainerImage для достижения этого следующим образом:

Примечание:
Командлет Find-ContainerImage использует диспетчер пакетов PowerShell OneGet в фоновом режиме для получения списков. Чтобы избежать путаницы, убедитесь, что вы выбираете образ контейнера только для типа хоста, на котором вы его развертываете. Например, не загружайте и не устанавливайте образ Nano Server на хост Windows Server Hyper-V, но вы можете иметь вложенный Nano Server и загрузить образ Nano Server на этот вложенный хост-контейнер.

После того, как вы определили нужный образ, его необходимо установить на узел контейнера с помощью командлета Install-ContainerImage следующим образом:

Образ будет загружен из репозитория и установлен, чтобы убедиться, что он на месте, вы можете использовать командлет Get-ContainerImage следующим образом:

Чтобы развернуть образ контейнера, используйте командлет New-Container, как показано в следующем примере, для создания контейнера:

Когда вы развертываете контейнер, у него не будет сетевого подключения, нам нужно использовать Add-ContainerNetworkAdapter, чтобы мы могли создать сетевую карту в контейнере:

Используйте командлет Connect-ContainerNetworkAdapter, чтобы подключить сетевую карту к коммутатору:

Сохраните новый контейнер в переменной, а затем запустите наш контейнер с помощью командлета Start-Container:

Вы также можете использовать командлет Stop-Container для остановки контейнера.

Теперь контейнер запущен и работает, мы можем удаленно управлять им с помощью Enter-PSSession с новым параметром ContainerName, который позволит нам запустить удаленную PSSession для контейнера:

Затем сеанс запускается с запущенным контейнером, например, вы можете запустить IPConfig и убедиться, что вы действительно находитесь в контейнере и работаете в правильном пространстве IP-адресов. Теперь вы можете установить и настроить приложение внутри контейнера по мере необходимости. Затем вы можете использовать командлет Save-ContainerImage для сохранения изменений для быстрого развертывания в будущем:

Вывод

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

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

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

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

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

• Докер и контейнеры (Часть 6)