Pages Menu
Rss
Categories Menu

Опубликовано | Нет комментариев

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


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

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

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

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

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

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

На рисунке ниже показано, как выглядит макет двух, доступных в Windows Server 2016, технологий контейнера.

контейнеры_один_физический_бокс

Контейнеры Windows Server 2016 и контейнеры Hyper-V в одном и том же физическом боксе

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

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

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

Глядя на любой тип контейнеров, важно понимать жизненный цикл разработки. С точки зрения разработчика, привычные им инструменты, такие как Visual Studio, позволяют им создавать и развёртывать приложения непосредственно в контейнеры. Другие инструменты, дают им возможность описать, какие основные функции требуется в базовой ОС, какие библиотеки могут совместно использоваться между приложениями, или какие библиотеки должны быть выделены для контейнера. На следующем рисунке показаны зависимости и режим работы контейнеров.

контейнеры_зависимости

Контейнеры и зависимости

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

Управление контейнерами

В 2015 году Microsoft объявила о поддержке на Linux ВМ движка Docker. Это хорошая новость, но остаётся вопрос: как он работает на Windows? С появлением контейнеров Windows Server и контейнеров Hyper-V, Докер становится ещё более полезным, потому что вы можете использовать его для управления Docker контейнеров в Windows, а также традиционной среде Linux. Кроме того, теперь у нас есть доступ ко всем доступным через Docker образам, поэтому мы можем загрузить их и развернуть!

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

На рисунке ниже показано размещение движка Docker в отношении контейнеров Windows Server или контейнеров Hyper-V и сравнение с механизмом Docker, работающем на Linux.

Docker_Windows_Linux

Движок Docker на Windows и Linux

Механизм Docker работает на одном уровне в контейнере Windows Server и контейнере Linux, и может работать с Windows Server или Linux уровнем выше движка Docker. Докер клиент будет подключаться к любому двигателю Docker и обеспечивать согласованное управление для конечных пользователей.

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

контейнеры_развёртывание

В контейнеры можно писать один раз и развёртывать в любом месте

Контейнеры и сети

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

сетевое_подключение_контейнеров

Сетевое подключение контейнеров

Как показано на рисунке, каждый контейнер будет подключаться через vNIC (контейнер Windows Server) или vmNIC (контейнер Hyper-V) к настроенному на хосте vSwitch. Каждый vNIC изолирован от следующего и считается собственным отсеком. Эти vNIC подключаются к vSwitch по портам (как Hyper-V). vNIC физического хоста изолирован от контейнеров. Сетевое подключение к контейнерам Hyper-V прозрачно для VM через vmNIC.

Внешнее соединение обеспечивается несколькими способами. Каждый из них зависит от сценария, который вы используете для контейнеров. Например, если вы хотите предложить контейнерную среду для разработчиков, лучший вариант для контейнерной сети - Network Address Translation (NAT). Он предоставляет частное IP-пространство (выданные через DHCP IP-адреса), которое изолировано от внешнего мира. Хотя и ограничивает возможность подключения к нескольким контейнерам, но даёт возможность переноса в контейнерную среду, с которой вы работаете. Любой трафик, поступающий на публичный NAT IP(внешний IP адрес NIC хоста) будет сравниваться с таблицей, управляемой через WinNAT, и перенаправляется в контейнер.

Если разработчикам или бизнесменам большой необходимости в развёртывании нет, а требуется, чтобы контейнеры располагались в корпоративном IP пространстве, вы можете использовать для контейнеров прозрачную сеть. В этом случае, для присвоения запускаемым вами контейнерам IP-адресов, используется (через DHCP или Static Assignment) существующее пространство IP. Если вы не используете DHCP, вы не можете установить адрес Gateway IP. В прозрачной сети, контейнеры могут взаимодействовать друг с другом и внешними службами, такими как SQL и т. д.

И наконец, если вы рассматриваете развёртывание облачного масштаба, можете использовать туннелирование уровня 2 (L2) или мост L2. Оба способа по сути являются сетевой виртуализацией для контейнеров, что позволяет полностью изолировать трафик через многоузловое развёртывание контейнеров в центре обработки данных.

В режиме L2 моста, расширение виртуальной платформы фильтрации (VFP) на хосте контейнера vSwitch, будет действовать как мост и по мере необходимости выполнять переписывание адреса управления доступом к Media Access Control (MAC). Уровень 3 (L3) или 4 (L4) остаются неизменными.

Если в сценарии развёртывания облака это требуется сетевой политикой, вы можете использовать туннельный режим L3. Внешний vSwitch предоставляет для контейнера все параметры подключения. Весь контейнерный трафик пересылается через физический узел, и перед входом в сетевую структуру переписывается MAC-адрес.

По умолчанию Docker будет пытаться связаться с NAT-сетью, и если он её не найдёт, то попытается создать. Любые контейнеры, созданные после этого, будут подключаться к сети NAT. Можно переопределить это поведение по умолчанию, выполнив следующие действия, например:

Docker -b "none"

Ни один из них не представляет собой имя сети; -b -- это мост. В этом случае мы ни к чему не присоединяемся.

Чтобы создать прозрачную сеть, вы можете использовать следующее:

Docker network create -d transparent -gateway 192.168.0.254 "TransparentNET"

Мультисетивые контейнеры

В случае, если вам на контейнере хоста необходимо иметь несколько сетей, применяются следующие правила:

  • Для каждого контейнера хоста может быть создана только одна NAT сеть.
  • Несколько сетей, которые используют для подключения внешний vSwitch (например, прозрачный, мост L2 и прозрачный L2), должны использовать свой собственный сетевой адаптер.
  • Разные сети должны использовать разные vSwitches.

Контейнеры и брандмауэры

У каждого хоста контейнера, по умолчанию, включён набор правил брандмауэра. Эти правила установлены со стандартными настройками. Если вы хотите, чтобы контейнеры пинговались (ICMP) или получили IP-адрес от DHCP, необходимо убедиться, что на хосте контейнера эти правила включены. Чтобы разрешить использование в контейнерах разных типов трафика, вам потребуется настроить дополнительные правила.

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

Исправление проблем

Docker больше не хранит отдельный файл журнала; он регистрирует все события в журнале приложений Event Viewer.

Вы можете фильтровать основной источник, равный Docker, и используя для просмотра журнала Windows PowerShell или следующий код, извлекать все его события:

Get-EventLog -LogName Application -Source Docker

А также, вы можете запустить Docker в режиме отладки:

Dockerd.exe -D

Или использовать файл конфигурации докера (вы можете найти этот файл или поместить его, если он не существует в C:\ProgramData\docker\config\daemon.json), чтобы запустить режим отладки следующим образом:

{
"debug": true
}

Установка контейнеров

Чтобы использовать контейнеры Windows Server, сначала вы должны установить функцию «Containers». Кроме того, если вы хотите использовать контейнеры Hyper-V, вам также будет необходимо установить функцию Hyper-V.

Затем, вам нужно будет установить и настроить Docker, который не поставляется с Windows Server 2016.

Дополнительная информация. Чтобы узнать, как настроить эту функцию и как установить и настроить Docker, перейдите на https://aka.ms/windowscontainers и прочитайте руководства по быстрому запуску.

Правила для контейнеров

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

Таблица: Поддерживаемые на хостах образы контейнеров

Среда выполнения контейнера
Server Core Nano Server (AB1)
Развёртывание операционной системы контейнера Сервер с UI (LTSB) Контейнеры Windows Server и/или контейнеры Hyper-V Контейнеры Windows Server и/или контейнеры Hyper-V
Server Core (LTSB) Контейнеры Windows Server и/или контейнеры Hyper-V Контейнеры Windows Server и/или контейнеры Hyper-V
Nano Server (AB1) Контейнеры Hyper-V Контейнеры Windows Server или контейнеры Hyper-V

Для исправления хоста контейнера потребуется патч образа контейнера и для обеспечения нормальной работы - фиксация.

Microsoft будет предоставлять обновлённый образ Windows Docker на ежемесячной основе. Его вы можете использовать для восстановления образа контейнера.

Если вы планируете использовать контейнеры Hyper-V внутри гостевой виртуальной машины, необходимо обеспечить следующее:

  • Для хоста контейнера включена вложенная виртуализация
  • На хосте имеется не менее 4 ГБ ОЗУ
  • Для операционной системы хоста вы используете Windows Server 2016 или Windows 10
  • В гостевой виртуальной машине хоста требуется, по меньшей мере, два виртуальных процессора

В репозитории Docker есть дополнительные образы, которые соответствуют тем же правилам.

Подробнее. Для получения большей информации о развёртывании контейнеров Windows Server перейдите на https://msdn.microsoft.com/virtualization/windowscontainers/ quick_start/manage_docker.

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.


↓