Комментарии 26
Не могли бы вы рассказать поподробнее для каких сценариев предназначается Nano Server?
В ссылке на официальную документацию в начале статьи говорится об использовании в качестве хоста для Hyper-V, однако в примерах наоборот, сам Nano Server это виртуальная машина.
В чём по вашему мнению преимущества .NET Core + Nano перед классическим ASP.NET MVC (OWIN) на полновесной ОС, тем более что вы всё равно используете IIS? Какие реальные проблемы решает связка c Nano?
Некоторые недостатки у Core есть, например пока отсутствует System.Drawing, которой мы используем для масштабирования JPEG-ов. Что оправдывает цену перехода на новую технологию? Может Deployment? Но, как я понимаю, даже облегчённая версия Windows слишком велика чтоб сделать весь образ артефактом который поставляют разработчики — копирование образа займёт слишком много времен.
Одним словом, чем по вашему мнению интересен Nano Server? Грубо говоря, чем он лучше полновесной Windows с одной стороны и Docker-а с другой?
/* Сухой маркетинговый язык страниц MSDN уже читал, хочется знать мнение реально работающих с этой технологией */
В ссылке на официальную документацию в начале статьи говорится об использовании в качестве хоста для Hyper-V, однако в примерах наоборот, сам Nano Server это виртуальная машина.
В чём по вашему мнению преимущества .NET Core + Nano перед классическим ASP.NET MVC (OWIN) на полновесной ОС, тем более что вы всё равно используете IIS? Какие реальные проблемы решает связка c Nano?
Некоторые недостатки у Core есть, например пока отсутствует System.Drawing, которой мы используем для масштабирования JPEG-ов. Что оправдывает цену перехода на новую технологию? Может Deployment? Но, как я понимаю, даже облегчённая версия Windows слишком велика чтоб сделать весь образ артефактом который поставляют разработчики — копирование образа займёт слишком много времен.
Одним словом, чем по вашему мнению интересен Nano Server? Грубо говоря, чем он лучше полновесной Windows с одной стороны и Docker-а с другой?
/* Сухой маркетинговый язык страниц MSDN уже читал, хочется знать мнение реально работающих с этой технологией */
Я не автор заметки, но попробую ответить. Основное преимущество Nano Server это его требования к ресурсам. MS вырезал из этой версии ОС практически всё. На конференции показывали, что в «голом» виде там крутится в памяти что-то около 12-15 процессов :) Процесс установки и управления сервером тоже существенно упростился. Также сменили политику установки обновлений.
Применять Nano Server стоит ИМХО в связке с Docker или с Win Server Containers (тот же Docker, только в профиль). Применение в качестве хоста Hyper-V имеет смысл, потому что ОС не отъедает полтора ГБ оперативки за «красивые глазки»
Применять Nano Server стоит ИМХО в связке с Docker или с Win Server Containers (тот же Docker, только в профиль). Применение в качестве хоста Hyper-V имеет смысл, потому что ОС не отъедает полтора ГБ оперативки за «красивые глазки»
Надо только учитывать, что при применении ASP.NET Core в докер-контейнере IIS в этом самом контейнере нафиг не нужен.
То-есть область применения можно сформулировать следующим образом:
Если нужна кросс-платформенность, то надо брать Core. Главная цель — докер, который нам люб за то, что когда программист говорит «готово», то результатом является контейнер, который однозначно описывает систему во всех видах установки, от DEV до Production. Тем самым на корню устраняются проблемы вида «а у меня на компьютере всё работает». Ценой является отказ от бесплатных плюшек IIS вроде gzip-упаковки или Windows-аутентификации.
Если контейнеры нам пока не светят, например по организационным причинам, то полезность Core в нынешнем его состоянии не очевидна. Да, сегодня разработчики выдают при релизе 20 Мб DLL-ек, которые отдельная Infrastructure-команда устанавливает на заботливо оберегаемом ими Windows Server 2012, а завтра программисты будут выдавать лишь 2 Мб, а остальные 18 Мб сервер сам скачает из NuGet, но правил игры это не меняет. Сервер остаётся «pet, not cattle».
Замена тяжеловесного сервера на Nano порадует сисадминов, которым мучительно больно смотреть на расходуемые зря гигабайты, но мало что изменит для программистов.
Или я где-то ошибаюсь?
Если нужна кросс-платформенность, то надо брать Core. Главная цель — докер, который нам люб за то, что когда программист говорит «готово», то результатом является контейнер, который однозначно описывает систему во всех видах установки, от DEV до Production. Тем самым на корню устраняются проблемы вида «а у меня на компьютере всё работает». Ценой является отказ от бесплатных плюшек IIS вроде gzip-упаковки или Windows-аутентификации.
Если контейнеры нам пока не светят, например по организационным причинам, то полезность Core в нынешнем его состоянии не очевидна. Да, сегодня разработчики выдают при релизе 20 Мб DLL-ек, которые отдельная Infrastructure-команда устанавливает на заботливо оберегаемом ими Windows Server 2012, а завтра программисты будут выдавать лишь 2 Мб, а остальные 18 Мб сервер сам скачает из NuGet, но правил игры это не меняет. Сервер остаётся «pet, not cattle».
Замена тяжеловесного сервера на Nano порадует сисадминов, которым мучительно больно смотреть на расходуемые зря гигабайты, но мало что изменит для программистов.
Или я где-то ошибаюсь?
Замена тяжеловесного сервера на Nano порадует сисадминов, которым мучительно больно смотреть на расходуемые зря гигабайты, но мало что изменит для программистов.
Для админов оно тоже не всегда лучше.
Спасибо за ссылку, очень интересно.
Получается, что с точки зрения программиста (которому всё равно нельзя лазить на Production серверы) Nano Server не отличается от полновесного Windows Server — в обоих есть полноценный IIS.
А у админов теперь выбор — выучить новые cmdlet-ы и радоваться легковесным виртуальным машинам, или и дальше пользоваться Windows Server, платя, тем самым, «налог на незнание PowerShell».
Учитывая тенденцию нарезать бизнес-логику маленькими независимыми кусочками микросервисов, перспектива хостить на одном Hyper-V несколько десятков лёгких VM с Nano Server весьма заманчива.
Получается, что с точки зрения программиста (которому всё равно нельзя лазить на Production серверы) Nano Server не отличается от полновесного Windows Server — в обоих есть полноценный IIS.
А у админов теперь выбор — выучить новые cmdlet-ы и радоваться легковесным виртуальным машинам, или и дальше пользоваться Windows Server, платя, тем самым, «налог на незнание PowerShell».
Учитывая тенденцию нарезать бизнес-логику маленькими независимыми кусочками микросервисов, перспектива хостить на одном Hyper-V несколько десятков лёгких VM с Nano Server весьма заманчива.
Да, в общем верно. ASP.NET Core для того и создавали, чтобы быть кросплатформенными.
Ну а Docker не панацея от «а у меня на компьютере всё работает», просто проще это все задеплоить (хотя тут тоже спорный момент).
Подозреваю, это будут те же 20 Мб, только заботливо упакованы в контейнер :D
Ну а Docker не панацея от «а у меня на компьютере всё работает», просто проще это все задеплоить (хотя тут тоже спорный момент).
а завтра программисты будут выдавать лишь 2 Мб, а остальные 18 Мб сервер сам скачает из NuGet
Подозреваю, это будут те же 20 Мб, только заботливо упакованы в контейнер :D
завтра программисты будут выдавать лишь 2 Мб, а остальные 18 Мб сервер сам скачает из NuGНа самом деле они выкачиваются на этапе сборки, полный бандл достаточно тяжёлый, мегабайт 40. И поддержка IIS там никуда не делась, нужно просто к нему модуль специальный доустановить.
Так же надо понимать, что переезд со Standard на Nano живёт своей жизнью и туда отлично деплоится обычный ASP.NET. Надо только ввести одно короткое, простое и легко гуглящееся заклинание в консольку:
Скрытый текст
Я летом на дотнексте показывал процесс упаковки классического аспнета в контейнер, там нет ничего сложного.DISM.EXE /online /enable-feature /featureName:IIS-WebServerRole /featureName:IIS-WebServer /featureName:IIS-CommonHttpFeatures /featureName:IIS-StaticContent /featureName:IIS-DefaultDocument /featureName:IIS-DirectoryBrowsing /featureName:IIS-HttpErrors /featureName:IIS-HttpRedirect /featureName:IIS-ApplicationDevelopment /featureName:IIS-ASPNET45 /featureName:IIS-NetFxExtensibility45 /featureName:IIS-ASP /featureName:IIS-CGI /featureName:IIS-ISAPIExtensions /featureName:IIS-ISAPIFilter /featureName:IIS-ServerSideIncludes /featureName:IIS-HealthAndDiagnostics /featureName:IIS-HttpLogging /featureName:IIS-LoggingLibraries /featureName:IIS-RequestMonitor /featureName:IIS-HttpTracing /featureName:IIS-CustomLogging /featureName:IIS-ODBCLogging /featureName:IIS-Security /featureName:IIS-BasicAuthentication /featureName:IIS-WindowsAuthentication /featureName:IIS-DigestAuthentication /featureName:IIS-ClientCertificateMappingAuthentication /featureName:IIS-IISCertificateMappingAuthentication /featureName:IIS-URLAuthorization /featureName:IIS-RequestFiltering /featureName:IIS-IPSecurity /featureName:IIS-Performance /featureName:IIS-HttpCompressionStatic /featureName:IIS-HttpCompressionDynamic /featureName:IIS-WebDAV /featureName:IIS-WebServerManagementTools /featureName:IIS-ManagementScriptingTools /featureName:IIS-ManagementService /featureName:IIS-IIS6ManagementCompatibility /featureName:IIS-Metabase /featureName:IIS-WMICompatibility /featureName:IIS-LegacyScripts /featureName:IIS-FTPServer /featureName:IIS-FTPSvc /featureName:IIS-FTPExtensibility /featureName:NetFx4Extended-ASPNET45 /featureName:IIS-ApplicationInit /featureName:IIS-WebSockets /featureName:IIS-CertProvider
На самом деле не совсем так. Да, в 80% случаев надо смотреть на связку ASP.NET Core + Kestrel, но IIS все еще далеко впереди по «фичам» (вот тут небольшое сравнение).
IIS прожорлив, но потолок быстродействия у него довольно высокий для большинства проектов. Половина сайтов умирают сами по себе еще на половине пути к этому «потолку» :)
IIS прожорлив, но потолок быстродействия у него довольно высокий для большинства проектов. Половина сайтов умирают сами по себе еще на половине пути к этому «потолку» :)
По вашей ссылке сравнивают Kestrel и WebListener. Первый работает на libuv и имеет свою реализацию HTTP протокола, второй использует драйвер http.sys. В обоих случаях IIS выступает в качестве проксирующей запросы прокладки, то есть, не нужен. Во втором он вдвойне не нужен, так как WebListener может жить с IIS на одном порту за счёт этого самого http.sys.
Сорри за невнимательность, не тот линк вставил. Вот тут полное сравнение.
Кроме того в IIS еще есть куча фич как dynamic compression, logging, access management, балансировка запросов между процессами и т.д. Поэтому, «проксирующая прокладка» это уж слишком сильное приуменьшение ;)
Да, все эти фичи сильно снижают мифический показатель RPS, но, как я уже писал, большинство проектов никогда не увидят этот «потолок».
UPDATE: похоже, это одна и та же таблица, просто на docs.asp.net убрали колонку IIS, так как она почти полностью дублирует WebListener.
Кроме того в IIS еще есть куча фич как dynamic compression, logging, access management, балансировка запросов между процессами и т.д. Поэтому, «проксирующая прокладка» это уж слишком сильное приуменьшение ;)
Да, все эти фичи сильно снижают мифический показатель RPS, но, как я уже писал, большинство проектов никогда не увидят этот «потолок».
UPDATE: похоже, это одна и та же таблица, просто на docs.asp.net убрали колонку IIS, так как она почти полностью дублирует WebListener.
Тут тогда еще бы добавить Nginx и Apache ;) И я бы посмотрел, например, на wildcard subdomains… ;)
Плюс по фичам — часть из них реализована в виде Middleware:
Buffering — https://github.com/aspnet/BasicMiddleware/tree/dev/src/Microsoft.AspNetCore.Buffering
Compression — https://github.com/aspnet/BasicMiddleware/tree/dev/src/Microsoft.AspNetCore.ResponseCompression
Последний линк кстати чутка устарел:) Часть фич уже сделали. Например Connection, RequestLifetime.
Плюс по фичам — часть из них реализована в виде Middleware:
Buffering — https://github.com/aspnet/BasicMiddleware/tree/dev/src/Microsoft.AspNetCore.Buffering
Compression — https://github.com/aspnet/BasicMiddleware/tree/dev/src/Microsoft.AspNetCore.ResponseCompression
Последний линк кстати чутка устарел:) Часть фич уже сделали. Например Connection, RequestLifetime.
Но как бы Kestrel не предназначен для работы в одиночку. Подразумевается его использовать(в продакшене) только за Nginx-ом или IIS-ом. О чем и пишется в документации.
Забавно, MS сами [пока] не используют Docker, а установщик даже не включен в дистрибутив Windows Server.
Так мне на докладе о Nano Server & Containers рассказал докладчик. Конкретно: пилят свои контейнеры, но поддержке докера «из коробки» быть (но только в новом сервере, о старых никто не говорил). Рассказывали мне в апреле, с того времени планы могли немного измениться.
Я лично не совсем понимаю зачем сейчас пилить свой контейнер, лучше бы хорошо интегрировали Docker. Но может там какие-то супер-пупер инновации, о которых нам пока ничего не рассказали :)
Я лично не совсем понимаю зачем сейчас пилить свой контейнер, лучше бы хорошо интегрировали Docker. Но может там какие-то супер-пупер инновации, о которых нам пока ничего не рассказали :)
Ну MVC(OWIN) vs Core отдельная тема. Drawing, DirectoryServices отсутствуют пока что. Но если нет таких либ в зависимостях, то MVC(OWIN) в принципе теряет смысл сейчас для новых проектов.
PS. Ну и можно зареференсить их если таргет нужный поставить. И использовать Nginx + Core на WinServer.
PS. Ну и можно зареференсить их если таргет нужный поставить. И использовать Nginx + Core на WinServer.
ASP.NET Core умеет работать поверх обычного .NET Framework/Mono. Соответственно, с зависимостями проблем нет.
Как раз OWIN мы уж 2 года используем со старым-добрым .NET 4.5-4.6, вместе с классическим IIS.
Началось всё с тестирования микросервисов на WEB API 2, приятно когда в две строчки можно поднять в памяти весь сервис и проверять правильность на уровне HTTP Request/Response, в том числе и правильную обработку HTTP-Headers и кодов возврата. А потом как-то незаметно переползло и в обычные веб-приложения. OWIN там не даёт особых преимуществ, но просто приятно убрать всё лишнее из global.asax, в котором отовсюду торчат уши HttpHandler (каковым и являлся ASP.NET в 2002 году).
Началось всё с тестирования микросервисов на WEB API 2, приятно когда в две строчки можно поднять в памяти весь сервис и проверять правильность на уровне HTTP Request/Response, в том числе и правильную обработку HTTP-Headers и кодов возврата. А потом как-то незаметно переползло и в обычные веб-приложения. OWIN там не даёт особых преимуществ, но просто приятно убрать всё лишнее из global.asax, в котором отовсюду торчат уши HttpHandler (каковым и являлся ASP.NET в 2002 году).
OWIN позволяет нормально обрабатывать веб реквест выстраивая цепочки Middlware с прогнозируемым порядком выполнения. До сих пор вспомниаю ахтунг с SessionHttpModule + WSFederationAuthenticationModule.
Новые проекты уже на Core. ИМХО это большой шаг вперед относительно OWIN(как минимум нет переключений в ASP.NET для того же MVC) и его логическое развитие. Как минимум кастомизируемый роутинг на уровне Middleware и механизм IOptions/IConfiguration. Ну и производительность совершенно другого порядка. Старые проекты уже активно готовятся к переезду.
Новые проекты уже на Core. ИМХО это большой шаг вперед относительно OWIN(как минимум нет переключений в ASP.NET для того же MVC) и его логическое развитие. Как минимум кастомизируемый роутинг на уровне Middleware и механизм IOptions/IConfiguration. Ну и производительность совершенно другого порядка. Старые проекты уже активно готовятся к переезду.
пока отсутствует System.Drawing, которой мы используем для масштабирования JPEG-ов
Возможно это вам поможет:
https://github.com/antiufo/Shaman.System.Drawing
для масштабирования JPEG-ов.
Вот ещё обёртка для ImageMagick. Отлично работает под Asp.Net Core — проверено.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ASP.NET Core на Nano Server