Nano Server vs Server Core для IIS: на 80% меньше памяти, но .NET Framework осталась за бортом

Пару недель назад мы разобрали перенос legacy IIS-приложения в Windows Container на базе Server Core - и сразу получили вопрос от коллег: «А почему не Nano Server? Там же образ маленький». Вопрос справедливый. Потратили несколько дней на параллельный стенд - сравниваем обе опции для IIS в практическом разрезе.

Что вообще сравниваем

В Windows Server 2016 у нас теперь три варианта установки: Full (с GUI), Server Core (без GUI, есть .NET Framework) и Nano Server (без GUI, без 32-бит подсистемы, без полного .NET). Для контейнеров интересны последние два - базовые образы microsoft/windowsservercore и microsoft/nanoserver.

Разница по размеру образов сразу бросается в глаза. Server Core после pull - около 4 ГБ. Nano Server - порядка 400-500 МБ. Почти на порядок. В памяти разрыв аналогичный: Server Core контейнер с IIS в простое кушает несколько сотен мегабайт, Nano Server - ощутимо меньше. Примерно в те самые 80%, о которых говорит Microsoft в документации, и которые мы в целом подтвердили на стенде.

На бумаге Nano Server выглядит идеальным базовым образом для IIS в контейнере. Реальность, как водится, сложнее.

Что именно работает через Nano Server

IIS на Nano Server - это не тот IIS что на Server Core. Это облегчённый набор ролей, который поддерживает:

• Статику и простые приложения - HTML, CSS, JS, PHP через FastCGI - без проблем.
• .NET Core приложения - ASP.NET Core через Kestrel или через IIS как reverse proxy - работает нормально.
• Базовые модули IIS - URL Rewrite, статическая компрессия, basic auth.

При этом Nano Server Dockerfile для IIS-контейнера выглядит минималистично:

New-NanoServerImage `
    -MediaPath D:\WS2016 `
    -BasePath C:\NanoBase `
    -TargetPath C:\NanoVMs\nano-iis.vhd `
    -ComputerName nano-iis `
    -Package Microsoft-NanoServer-IIS-Package `
    -GuestDrivers `
    -EnableRemoteManagementPort

Или как Docker образ через microsoft/nanoserver с добавлением IIS-пакета через dism при сборке.

Где Nano Server ломается

Вот тут начинается отрезвление. Полный .NET Framework (4.x) на Nano Server не поддерживается. Совсем. Есть только .NET Core и CoreCLR. Это означает, что ASP.NET WebForms, WCF, классический ASP.NET MVC на полном фреймворке - всё это на Nano Server не запустится.

Для нас это критично: большая часть IIS-приложений у клиентов - это именно legacy на .NET Framework 4.5-4.6. Переписывать их под .NET Core никто не собирается - они работают, приносят деньги. Nano Server для этого класса задач закрыт.

Второй момент - ограниченный набор модулей IIS. На Nano Server нет поддержки, например, Windows Authentication (Kerberos/NTLM), которая используется во внутренних корпоративных приложениях. Нет части ISAPI-расширений. Нет 32-битного режима AppPool.

Список «не работает» вполне конкретный и описан в документации WS2016, но узнаёшь об этом обычно в процессе, а не до.

Когда Nano Server всё-таки правильный выбор

Если стек позволяет - Nano Server действительно интересен. Три сценария где он имеет смысл:

• Новые .NET Core приложения - ASP.NET Core приложение в Nano Server контейнере весит суммарно 500-600 МБ против 5+ ГБ для аналогичного Server Core образа. На плотно упакованном хосте это ощутимая экономия.
• Reverse proxy / API Gateway роль - если IIS используется только как фронт для проксирования на backend, Nano Server справится и потребует минимум ресурсов.
• Cloud-нативная разработка - если команда строит сервисы на .NET Core с нуля, Nano Server как production target вполне разумен. Быстрее загружается, меньше поверхность атаки, обновления реже требуют перезагрузки.

Как это выглядит в контейнерном контексте

В паре с Windows Containers сценарий такой: на одном хосте WS2016 можно гонять и те и другие контейнеры. legacy приложение на Server Core образе, новый .NET Core сервис - на Nano Server. Docker не мешает им сосуществовать, образы никак не пересекаются.

Практически это означает что для managed-сопровождения на Windows-стеке выбор базового образа - это фактически выбор стека приложения. Первый вопрос при контейнеризации IIS-приложения: «Ты на полном .NET или на Core?» - и дальше ответ очевиден.

Где мы сейчас

Для клиентских задач с legacy IIS мы остаёмся на Server Core - совместимость важнее экономии на размере образа. Nano Server берём в работу для нескольких новых .NET Core проектов где нет груза обратной совместимости.

Интересная деталь: летом мы смотрели Nano Server в RC и тогда основным открытием была жизнь без RDP. Сейчас, после GA и нескольких месяцев реальной работы, основным ограничением оказалась не операционная модель, а именно совместимость с .NET Framework. Жить без RDP научились, жить без полного фреймворка - не получается. Не потому что не хотим, а потому что приложения у клиентов не переписаны.

Выбор базового образа в Windows-контейнерах в 2016 году - это не «что лучше», а «что совместимо с вашим кодом». Microsoft сделала правильную инженерную ставку на Nano Server для cloud-нативных workload, но переходный период для тех кто несёт legacy .NET - это реальная история, которую не ускорить выходом нового дистрибутива.