Windows Server 2016 TP2 и Nano Server: минимальный образ без GUI, который всё ещё не для всех

Microsoft выпустила Technical Preview 2 Windows Server 2016 - и в этот раз интереснее всего не сами контейнеры (там прогресс есть, но умеренный), а Nano Server. Мы поставили TP2 в лабораторию сразу, как раздача открылась, и потратили несколько дней разбираясь что это и зачем.

Что такое Nano Server

В прошлом обзоре TP2 мы упоминали Nano Server вскользь - там был только первый взгляд на контейнеры. В этот раз мы сосредоточились на Nano Server отдельно - Microsoft добавила документацию и примеры, которых в первых Preview практически не было.

Три режима установки Windows Server:

Server with Full UI - то, что все знают: графический рабочий стол, весь GUI, полный набор. Это то, что большинство клиентов ставили на серверы последние десять лет.

Server Core - без графического рабочего стола, но с локальным PowerShell, с возможностью зайти через RDP в cmd/PowerShell, с netsh, sconfig и другими локальными инструментами управления. Довольно привычный режим для тех, кто умеет в командную строку.

Nano Server - принципиально другая история. Нет локального входа вообще. Нет Remote Desktop. Нет 32-bit подсистемы. Нет MMC-консолей. Образ заметно меньше, перезагружается быстрее, attack surface меньше. Управление - только удалённо через PowerShell Remoting, WMI, или REST API через модуль Server Management.

Вот это «нет локального входа вообще» - первое, что выбивает из привычной колеи.

Как мы его запустили

Nano Server в TP2 разворачивается немного нестандартно. В дистрибутиве TP2 есть папка NanoServer с готовым VHD. Берёте его, копируете, указываете нужные пакеты через DISM (IIS, Hyper-V, Clustering, DNS, DSC и несколько других), монтируете VHD в Hyper-V как диск новой VM.

После запуска VM в Hyper-V видишь... консоль с минимальным Emergency Management Console. Она показывает IP-адрес, имя компьютера и один экран с базовыми сетевыми настройками. Всё. Больше там делать нечего - только посмотреть адрес и идти управлять удалённо.

Подключаемся через PowerShell Remoting:

Enter-PSSession -ComputerName 192.168.1.50 -Credential Administrator

И попадаем в обычный PowerShell, только на минимальном сервере.

Server Core vs Nano Server - в чём разница на практике

Если взять типичный сценарий «поднять IIS, положить приложение, настроить логирование», то на Server Core это делается вполне привычно. Можно зайти через RDP, открыть PowerShell локально, запустить Install-WindowsFeature, поковыряться в C:\inetpub напрямую.

На Nano Server всё то же самое делается удалённо. Invoke-Command, Copy-Item с -ToSession, работа через PowerShell Remoting. Концептуально это правильно - так устроен Linux с openssh, так работает Ansible с Windows через WinRM. Но если вы привыкли заходить на сервер «ногами», первое время некомфортно.

Отдельная история - диагностика. На Server Core можно запустить netstat, tracert, посмотреть event log через eventvwr локально, дернуть perfmon. На Nano Server для части этого нужны либо PowerShell-командлеты (которые есть не для всего), либо удалённый доступ к event log, либо сторонние инструменты. Мы несколько раз поймали себя на инстинктивном желании «зайти и посмотреть» - и упёрлись в пустую EMC-консоль.

Про Rich Management и где пока дыры

Microsoft добавила в TP2 «Server Management» - веб-интерфейс на базе REST API для управления Nano Server через браузер. Штука симпатичная: показывает процессы, сетевые интерфейсы, event log, позволяет управлять сервисами. Для тех, кто боится PowerShell Remoting, это точка входа.

Проблема в том, что Server Management в TP2 - тоже preview. Часть функций работает нестабильно, часть просто не реализована. Мы пробовали просматривать event log через него - зависло. Управление файлами - не реализовано. Работа с IIS через интерфейс - отдельный модуль, который ещё сырее.

На Server Core в аналогичной ситуации ты просто заходишь и смотришь сам. Здесь нет такой опции.

Контейнеры и Nano Server

Для Windows Server Containers Nano Server интересен как base image. Размер образа на диске в разы меньше WindowsServerCore - это означает более быстрые пуши в реестр, более быстрый pull при деплое. Идея понятна и логична.

На практике запуск .NET-приложений в Nano Server-контейнере требует дополнительных танцев - не всё из System.Web и классического .NET Framework доступно в Nano, есть ограничения по API. Для простых HTTP-сервисов на .NET это может быть нормально, для приложений, которые активно используют WCF или устаревшие части Framework, нужно проверять совместимость.

Что с этим делать сейчас

Для большинства клиентской инфраструктуры, которую мы сопровождаем, Nano Server в текущем виде не подходит - слишком много завязано на локальный доступ и инструменты, которые там не работают. Но для новых облачных или контейнерных ролей, где изначально проектируешь под «только удалённое управление», направление выглядит разумно.

Server Core остаётся рабочим компромиссом: меньше attack surface чем Full UI, но управлять можно привычными методами. Nano Server - это следующий шаг, к которому нужно готовить и инструменты, и собственные привычки.

TP2 в целом даёт представление о направлении - и по Nano Server, и по контейнерам. Смотрим что будет в следующих TP.