Hyper-V 2016 и Windows Containers: IIS в Server Core за секунды, но NAT-драйвер требует внимания

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

Два режима изоляции

Ключевое, что нужно понять про Windows Containers в 2016 - их два вида, и они принципиально разные по изоляции.

Windows Server Containers - это process-level изоляция, как Docker на Linux. Контейнеры делят ядро хоста. Быстрый старт, минимальные накладные расходы. Подходит для доверенных рабочих нагрузок.

Hyper-V Containers - каждый контейнер получает свою облегчённую VM с отдельным ядром. Изоляция полная: процессы на хосте не видят что происходит внутри. Оверхед выше, зато граница безопасности настоящая. Запускается той же командой Docker, только с флагом --isolation=hyperv.

С точки зрения команды разницы почти нет: один и тот же образ, один и тот же docker run. Разница в том что происходит под капотом - и в требованиях к хосту.

Вложенная виртуализация

Для Hyper-V Containers на виртуальной машине нужна вложенная виртуализация - nested virtualization. В Hyper-V 2016 она появилась как официальная функция. Включается через PowerShell на хосте:

Set-VMProcessor -VMName "ws2016-containers" -ExposeVirtualizationExtensions $true

После включения внутри VM видны Intel VT-x расширения, и Hyper-V Containers стартуют нормально. Мы проверяли на тестовом стенде с двумя уровнями Hyper-V - работает. Производительность на вложенной виртуализации, понятно, ниже чем на железе напрямую, но для тестовой и dev-среды это приемлемо.

IIS в Server Core контейнере

Первый реальный тест - поднять IIS внутри Windows Server Core контейнера. Базовый образ microsoft/windowsservercore весит несколько гигабайт (это не Alpine, тут другой мир), зато в нём можно ставить Windows-роли как на обычном сервере.

Dockerfile для IIS минимальный:

FROM microsoft/windowsservercore
RUN powershell -Command Add-WindowsFeature Web-Server
EXPOSE 80
CMD ["powershell", "Start-Service W3SVC; while ($true) { Start-Sleep 30 }"]

Сборка образа с установкой IIS занимает несколько минут - первый раз. Дальнейшие запуски контейнера из готового образа - секунды. Это ощущение непривычное когда ты привык что «поднять IIS» подразумевает несколько минут установки роли и перезагрузку. Здесь - docker run, и через несколько секунд IIS отвечает.

Статическую страницу положили через docker cp, убедились что 80-й порт отдаёт ответ. Работает без сюрпризов.

Где реально споткнулись - NAT и сеть

Вот тут началось интересное. Windows Containers в 2016 по умолчанию используют NAT-драйвер для сети. Это означает: контейнер получает адрес из внутренней сети (172.16.x.x по умолчанию), и с хоста к нему можно добраться через проброс портов.

Проблема первая: на одном хосте работает только одна NAT-подсеть. Если у вас несколько контейнеров с разными сетевыми требованиями - вы упираетесь в это ограничение сразу. В Docker на Linux привычная модель - создаёшь сколько нужно bridge-сетей. Здесь иначе.

Проблема вторая: при вложенной виртуализации маршрутизация между слоями периодически требует ручного вмешательства. Мы несколько раз получали ситуацию когда контейнер внутри вложенной VM стартовал, порт пробрасывался, но снаружи родительского Hyper-V хоста добраться до него не получалось. Чинилось добавлением явного маршрута или правила Windows Firewall - но именно это «чинилось руками» и требовало разбирательства каждый раз.

Третья история - DNS внутри контейнера. Резолюция работала не всегда предсказуемо: внешние имена резолвились, внутренние корпоративные - с перебоями. Обходили явным указанием DNS-серверов через --dns.

Что с transparent и l2bridge драйверами

Помимо NAT, в Windows Containers есть transparent и l2bridge сетевые драйверы - они позволяют подключить контейнер напрямую к физической сети и получить реальный IP из вашего VLAN. Выглядит привлекательно для сценария «контейнер как замена VM» в Windows-среде.

Мы попробовали transparent на тестовом стенде. Работает - контейнер получил IP от реального DHCP, был виден в сети наравне с хостами. Но конфигурация требует точности: нужно явно указывать сетевой адаптер хоста, и при вложенной виртуализации у виртуального адаптера должен быть включён MAC spoofing - без него пакеты от контейнера не проходят через Hyper-V.

Set-VMNetworkAdapter -VMName "ws2016-containers" -MacAddressSpoofing On

Без этой строки полчаса диагностики - и никаких очевидных ошибок в логах.

Как это выглядит с точки зрения сопровождения

Для managed-инфраструктуры на Windows-стеке Windows Containers открывают интересный сценарий: быстрый деплой IIS-приложений без полноценных VM, изоляция через Hyper-V Containers для задач где process-level границы недостаточны. Это реальная альтернатива схеме «одно приложение - одна VM», которая сейчас типична для большинства клиентов.

Практический вывод на текущий момент: базовый сценарий с IIS в Server Core контейнере работает и выглядит зрелым. Сетевая часть с NAT-драйвером требует понимания ограничений и аккуратной настройки - особенно на вложенной виртуализации. Для первого продакшн-сценария мы бы выбрали transparent или l2bridge на физических хостах, а не NAT на вложенном Hyper-V.

Тестовый стенд продолжаем гонять, следующий шаг - проверить как ведёт себя это всё с несколькими контейнерами и какие у Docker на Windows ограничения по Compose и оркестрации.