Windows Server 2016 TP2: контейнеры на Windows - смотрим, щупаем, записываем наблюдения

Microsoft в конце апреля выпустила Technical Preview 2 Windows Server 2016 - и там наконец появились Windows Server Containers. Мы их давно ждали как минимум из любопытства: Docker на Windows выглядел как оксюморон, а тут официально, с документацией и даже с интеграцией в PowerShell. Поставили TP2 в лабораторию, потыкали несколько дней. Рассказываем что нашли.

Контекст: зачем нам это смотреть

У нас значительная часть клиентской инфраструктуры сидит на Windows - IIS, MSSQL, .NET-приложения. Docker мы активно используем в Linux-части, и вопрос «а когда Windows» периодически возникает. Плюс в рамках итогов 2014 года мы отметили контейнеры как технологию, за которой надо следить. TP2 - первая возможность потрогать это не в теории.

Как устроены Windows Server Containers

Два режима изоляции, и это важный момент, который сразу надо понять:

Windows Server Containers - изоляция на уровне namespace'ов и Job Objects. Контейнеры разделяют ядро хоста, похоже на то как работает Docker/LXC на Linux. Быстрый старт, маленький overhead, но все контейнеры используют одно ядро хост-системы.

Hyper-V Containers - каждый контейнер запускается внутри легковесной Hyper-V VM с собственным экземпляром ядра Windows. Более тяжёлый вариант, зато изоляция полная: уязвимость в одном контейнере не даст выбраться на хост через общее ядро. Microsoft явно ориентирует этот режим на мультитенантные сценарии.

Синтаксис управления - PowerShell-модуль Containers и обёртка совместимая с Docker Remote API. На бумаге это должно означать что Docker-клиент с Linux или Windows будет работать с Windows Server Containers прозрачно.

Что реально работает

Базовый сценарий - создать контейнер из образа, запустить внутри что-то простое - работает. Команды типа New-Container, Start-Container, Invoke-Command функционируют. Мы запустили простой IIS-контейнер, он поднялся, ответил на HTTP. С точки зрения «работает/не работает» - работает.

Docker Remote API тоже подключается. Мы попробовали Docker Machine направить на Windows-хост - установка Docker-клиента на TP2 работает через скрипт Microsoft, после чего docker ps и docker run дают ожидаемый результат.

Где всё сыро

Образы. Базовые образы от Microsoft весят много. WindowsServerCore - это несколько гигабайт. Nano Server как образ заявлен и выглядит интереснее для минималистичных сервисов, но в TP2 поддержка Nano Server в контейнерах очень ограничена. В сравнении с Ubuntu:14.04 в 200 МБ это ощутимая разница в философии.

Hyper-V Containers в TP2. Здесь нас ждало разочарование. Hyper-V Container в TP2 практически не задокументирован на практике - флаг --isolation=hyperv принимается, но поведение нестабильное. На нашей тестовой машине (Hyper-V Server 2012 R2 в роли хоста) запуск Hyper-V Container стабильно падал с невнятной ошибкой. Судя по форумам Microsoft, это ожидаемо - фича заявлена, но до производственного качества в TP2 не доведена.

Сеть. Сетевая модель в Windows Containers - NAT через виртуальный коммутатор Hyper-V. Один NAT на хост, пул адресов 172.16.0.0/12 по умолчанию. Overlay-сетей для Linux здесь нет. При большом числе контейнеров на хосте NAT может стать узким местом - но это скорее TP-ограничение, чем фундаментальная проблема.

PowerShell как основной интерфейс. Microsoft добавила Docker-совместимый API, но ощущение что это второй слой поверх нативного PowerShell-управления. Некоторые вещи работают только через PowerShell, некоторые только через Docker-клиент, некоторые через оба но с разным поведением. Для команды, которая привыкла к чистому Docker API, это добавляет путаницы.

Watch list для следующих TP

Мы сформировали для себя список того, что хотим проверить в следующих Technical Preview:

Hyper-V Containers в реальной работе. Это ключевой differentiator - полная изоляция с удобством контейнеров. Если заработает стабильно, это интересно для мультитенантных Windows-окружений.

Образ Nano Server как base image. Если удастся запускать .NET-приложения в Nano Server контейнере, размер образов должен упасть в разы. Надо смотреть когда Microsoft доведёт это до рабочего состояния.

Интеграция с оркестраторами. Docker Swarm в 1.6 работает с Linux-хостами. Смешанный кластер Windows + Linux - это вопрос, который прямо сейчас без ответа.

Networking без NAT. Один NAT на хост - это не production-архитектура для серьёзной нагрузки. Когда Microsoft добавит нормальную overlay-сеть или хотя бы host-networking - станет понятнее.

Вывод, который не вывод

Windows Server Containers в TP2 - это честный preview в смысле «смотрите, примерно так оно будет выглядеть». Базовые вещи работают, архитектурные решения понятны, Hyper-V Containers как идея выглядит интересно для изоляции. Но брать это в работу сейчас не имеет смысла: нестабильность Hyper-V Containers, большие образы, сырая сеть.

Слой совместимости с Docker - приятный сигнал, что Microsoft смотрит в сторону существующей экосистемы, а не пытается построить параллельный мир. Это важно для тех из нас, кто хочет единообразный toolchain для Linux и Windows.

Продолжим смотреть следующие TP. Если Hyper-V Containers заработают нормально - появится о чём написать детально.