ADG Оставить заявку
Блог Инфраструктура 5 мин чтения

Nano Server уходит в контейнеры: Microsoft меняет стратегию и что это значит для заказчиков на VM

Microsoft подтверждает: с релиза 1709 Nano Server - только контейнерный образ. Для VM-нагрузок остаётся Server Core. Разбираемся что менять в роадмапе.

Контекст момента

Microsoft официально подтверждает: начиная с Windows Server 1709 Nano Server доступен исключительно как базовый образ для Windows-контейнеров, установка на bare metal и в VM исключена

На этой неделе блог команды Windows Server зафиксировал то, о чём ходили слухи ещё с объявления SAC-канала в июле: Nano Server в релизе 1709 - это исключительно контейнерный базовый образ. Установить его на железо или в виртуальную машину больше не получится. Для VM-сценариев Microsoft оставляет Server Core.

Мы смотрели на этот вопрос ещё когда анонсировали Semi-Annual Channel и тогда написали, что Nano Server в 1709 станет «ещё более stripped-down». Оказалось, stripped-down до предела - просто убрали возможность загрузки вне контейнерной среды.

Что именно изменилось

В Windows Server 2016 (LTSC) Nano Server был полноценным вариантом установки наравне с Desktop Experience и Server Core. Можно было поднять VM с Nano Server, поставить роли IIS, DNS, файловый сервер через пакеты. Процесс был не самый удобный - управление только удалённо, пакетная база отличалась от стандартной - но технически это работало.

С 1709 этой опции нет. Nano Server существует только как образ контейнера microsoft/nanoserver в Docker Hub. Запустить его как операционную систему VM невозможно - это не режим установки, это образ.

Для VM-нагрузок Microsoft однозначно указывает на Server Core. Он тоже без GUI, управляется удалённо через PowerShell и Project Honolulu (будущий Windows Admin Center), поддерживает полный набор серверных ролей. По сути Server Core - это то, чем Nano Server пытался быть, но с сохранённой совместимостью.

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

Почему Microsoft пошла на это

Объяснение от команды достаточно прямое. Поддерживать два stripped-down варианта - Nano Server как вариант установки и Server Core - при этом обеспечивая совместимость ролей, пакетов, PowerShell-модулей в обоих - это дорого. Экосистема пакетов для Nano Server так и не дотянулась до Server Core по охвату, и многие заказчики которые попробовали Nano Server в 2016 году вернулись на Server Core именно по этой причине: не нашли нужный пакет или роль.

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

Кого это касается прямо сейчас

У нас на managed есть несколько заказчиков, которые смотрели на Nano Server для VM-нагрузок - в первую очередь для IIS-хостинга лёгких .NET-приложений и для DNS/DHCP-серверов с минимальным attack surface. Для этих сценариев Nano Server выглядел привлекательно именно потому что меньше поверхность атаки, меньше компонентов требующих патчинга.

Теперь для них правильный путь - Server Core. Это не трагедия: Server Core в Windows Server 2016 значительно удобнее чем был в 2008 R2, PowerShell 5.1 покрывает большинство задач администрирования, а удалённое управление через RSAT работает нормально. Но тем кто строил роадмап с расчётом на Nano Server - нужно пересмотреть.

Конкретные последствия для тех кто планировал Nano Server на VM:

  • Шаблоны виртуальных машин - если в vSphere или Hyper-V были подготовлены шаблоны Nano Server для разворачивания новых VM, их нужно пересоздавать на Server Core. Это не быстро если шаблоны кастомизированы.
  • Ansible/DSC-скрипты - конфигурация Nano Server отличалась от Server Core в нескольких местах, особенно в части пакетного менеджмента. Скрипты которые работали с OneGet на Nano Server могут потребовать правки под Server Core.
  • Документация и runbooks - мелочь, но если у заказчика написаны процедуры под Nano Server, их нужно обновить прежде чем они потребуются в нештатной ситуации.

Что с теми кто уже на Nano Server в 2016

Windows Server 2016 LTSC никуда не делся. Nano Server как вариант установки в нём остаётся - и поддержка этого LTSC-релиза идёт по стандартному графику. Никто не говорит что нужно немедленно всё мигрировать.

Но при планировании следующего разворачивания или при обновлении инфраструктуры - учитывать что Nano Server-VM это тупиковая ветка: в следующем LTSC-релизе (Windows Server 2019, когда бы он ни вышел) этого варианта установки скорее всего уже не будет.

Контейнерный Nano Server - отдельная история

Для тех кто строит Windows-контейнеры изменение, напротив, позитивное: образ станет меньше, чище, более предсказуемым. Базовый образ microsoft/windowsservercore в Docker Hub весит немало, и альтернатива в виде облегчённого nanoserver-образа - это реальная польза для тех кто деплоит много контейнеров.

Правда, с multi-stage builds которые стали stable в Docker 17.06 появилась возможность использовать windowsservercore только как build-образ, а финальный деплоить на nanoserver. Это как раз та схема для которой маленький базовый образ критически важен.

Ждём 1709 в октябре и посмотрим насколько реально похудел образ контейнера и что стало с Process Isolation vs Hyper-V Isolation в новом релизе.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.