Сервер и публикация приложения

Сервер

Традиционно приложения ASP.NET развертывались на веб-сервере IIS. Однако поскольку ASP.NET Core имеет кроссплатформенную природу, потребовалось отвязать ASP.NET Core от IIS и в целом от Windows. И на данный момент для развертывания приложения ASP.NET Core поддерживает развертывание приложения на следующих веб-серверах:

IIS и IIS Express, а также предоставляет возможность запускать приложение без IIS в рамках собственного процесса с помощью двух дополнительных http-серверов, которые идут вместе с ASP.NET Core:

IIS HTTP Server

Microsoft.AspNetCore.Server.HttpSys (или просто WebListener) (в предыдущих версиях ASP.NET Core назывался WebListener)

Microsoft.AspNetCore.Server.Kestrel (или просто Kestrel)

HTTP.sys и Kestrel представляют два дополнительных http-серверов, которые идут вместе с ASP.NET Core. HTTP.sys работает только на платформе Windows, а Kestrel является кроссплатформенным.

Кроме того, если приложение использует Kestrel, то в качестве прокси-сервера оно может использовать также IIS, Apache и Nginx. То есть Apache, Nginx или IIS будут получать запросы и перенаправлять их приложению, которое работает на Kestrel. Такая схема, когда запросы идут не напрямую на Kestrel, проходят черех IIS/Apache/Nginx, позволяет нам задействовать возможности, которые есть у этих веб-серверов, но отсутствуют у Kestrel.

IIS и IIS Express

По умолчанию приложения ASP.NET работают с сервером IIS. Однако надо заметить, что по сравнению с предыдущими версиями ASP.NET при работе с ASP.NET Core IIS не использует инфраструктуру System.Web , что значительно повышает производительность приложения. Кроме того, IIS поддерживает множество различного функционала, имеет множество возможностей по администрированию и управлению сервером и размещенными на нем приложениями.

AspNetCoreModule

Хостирование приложений ASP.NET Core на IIS происходит с помощью нативного модуля IIS под названием AspNetCoreModule , который сконфигурирован таким образом, чтобы перенаправлять запросы на веб-сервер Kestrel. Этот модуль управляет запуском внешнего процесса dotnet.exe, в рамках которого хостируется приложение, и перенаправляет все запросы от IIS к этому хостирующему процессу.

При получении первого запроса к приложению AspNetCoreModule запускает процесс для этого приложения и перезапускает процесс, если приложение падает.

Вначале все входящие запросы проходят через драйвер Http.Sys, который перенаправляет их на IIS на основной порт (80) или на порт SSL (443). Затем запрос от IIS перенаправляется приложению ASP.NET Core на определенный порт, на котором запущено приложение (любой другой порт, отличный от 80/443). Веб-сервер Kestrel получает запрос и передает его в виде объекта HttpContext в конвейер middleware ASP.NET Core. Конвейер middleware в приложении обрабатывает запрос и возвращает IIS результат обработки, который затем посылается HTTP-клиенту (например, веб-бразеру).

Для использования модуля он должен быть установлен. Он распространяется в рамках пакета ASP.NET Core Server Hosting Bundle. Но при установки Visual Studio с ASP.NET Core модуль AspNetCoreModule уже автоматически устанавливается для IIS Express / IIS, поэтому разработчикам, как правило, не придется его дополнительно доустанавливать.

Также для использования модуля непосредственно в приложении в проекте должен быть установлен Nuget-пакет Microsoft.AspNetCore.Server.IISIntegration .

Для интеграции с IIS для объекта WebHostBuilder вызывается метод UseIISIntegration() . Этот метод ищет переменные окружения, которые устаналиваются модулем AspNetCoreModule, если подобных переменных не установлено, то метод по сути ничего не делает.

Мы можем вызвать этот метод явно в файле Program.cs:

Однако это необязательно делать, поскольку при запуске приложения через IIS система автоматически вызывает данный метод.

Среди преимуществ использования именно IIS, а не Kestrel следует отметить работу со статическими файлами. В стандартном веб-приложении ASP.NET Core за взаимодействие со статическими файлами отвечает middleware StaticFiles, которое было рассмотрено в одной из предыдущих тем. Но на данный момент оно слабо отптимизировано и не поддерживает кэширование. И если мы используем чистый Kestrel, то он при обращении к статическим файлам каждый раз считывает их из файловой системы. А если мы используем IIS в качестве прокси для сервера, то мы можем воспользоваться встроенными возможностями IIS по кэшированию. В частности, IIS кэширует ранее считанный с диска статический файл и при последующих обращениях к нему берет этот файл из кэша, тем самым увеличивая производительность.

Kestrel

Kestrel представляет кроссплатформенный веб-сервер, основанный на кросплатформенной библиотеке асинхронного ввода/вывода libuv. Kestrel по умолчанию включается в проект ASP.NET Core.

При инициализации хоста у объекта WebHostBuilder вызывается метод UseKestrel() , который позволяет задействовать Kestrel. Несмотря на то, что по умолчанию исходный код в файле Program.cs не содержит этого вызова, этот метод вызывается автоматически.

Однако при настройке хоста мы можем явным образом вызвать метод UseKestrel для конфигурации сервера:

Для настройки Kestrela применяются свойства и методы объекта KestrelServerOptions . В частности, метод Listen позволяет установить порт, по которому Kestrel будет запускаться.

Свойство Limits устанавливает предельные значения для различных конфигурационных настроек. Так, свойство MaxConcurrentConnections задает максимально количество оновременно открытых соединений.

Свойство MaxRequestBodySize устанавливает максимальный размер для запроса в байтах.

Свойство MinRequestBodyDataRate задает минимальную скорость передачи данных в запросе в байтах в секунду.

Свойство MinResponseDataRate задает минимальную скорость передачи данных в исходящем потоке в байтах в секунду.

При развертывании на Windows Kestrel может применять IIS в качестве прокси-сервера, а при развертывании на Linux как прокси-серверы могут использоваться Apache и Nginx. Но также Kestrel может работать самостоятельно внтури своего процесса без IIS.

Так, по умолчанию в Visual Studio доступны две возможности для запуска: с проксированием через IIS и напрямую.

При выборе возможностей вариантов запуска мы можем по умолчанию встретить два профиля:

IIS Express (запуск с проксированием через IIS Express)

Профиль, который совпадает с названием проекта (в моем случае это HelloApp) — тот пункт, который позволяет запускать приложение в отдельном процессе без всякого проксирования через IIS. Так как в файле Program.cs установлен в качестве сервера Kestrel (методом UseKestrel() ), то в данном случае приложение будет запускать именно Kestrel. Причем по умолчанию приложение будет запускаться на 5000-порту.

И если мы выберем для запуска второй пункт, то у нас запустится консольное приложение dotnet.exe , которое запустит наше приложение. И после этого мы сможем обращаться к нашему приложению из любого браузера:

Запуск приложения с помощью Kestrel довольно прост, нам не надо устанавливать и настраивать другие веб-серверы. Однако специалисты Microsoft рекомендуют такой способ запуска преимущественно в рамках локальной внутренней сети. А если приложение открыто для глобальной сети интернет, то рекомендумым способом запуска для обеспечения большей безопасности является именно проксирование через IIS, Apache, Nginx. Подобный метод имеет ряд преимуществ по сравнению с обычным запуском приложения на Kestrel в виде самохостирующегося процесса. В частности, прокси-серверы позволяет скрыть приложения, если они не должны быть доступны напрямую. Кроме того, веб-серверы позволяет управлять нагрузкой ко всем приложениям, и предоставляют другие функции по управлению приложениями.

Собственно при создании проекта ASP.NET Core в Visual Studio такой способ используется по умолчанию.

HTTP.sys

HTTP.sys представляет HTTP-сервер для ASP.NET Core, который работает только в ОС Windows. Ранне данный сервер назывался WebListener. Он запускается поверх драйвера ядра Http.Sys . Весь функционал сервера сосредоточен в пакете Microsoft.AspNetCore.Server.HttpSys .

Итак, изменим файл Program.cs, чтобы в нем использовался не Kestrel, а HttpSys:

Если метод UseKestrel() задает в качестве сервера Kestrel, то вызов метода UseHttpSys() аналогичным образом устанавливает в качестве сервера HTTP.sys.

Теперь запустим приложение, выбрав профиль, который совпадает с названием проекта:

И у нас запустится та же самая консоль, что и при работе через Kestrel, только теперь все вызовы к приложению будут идти через WebListener.

Размещение и развертывание ASP.NET Core Host and deploy ASP.NET Core

В общем при развертывании приложения ASP.NET Core в среде внешнего размещения выполняются следующие действия. In general, to deploy an ASP.NET Core app to a hosting environment:

• Развертывание опубликованного приложения в папке на сервере размещения. Deploy the published app to a folder on the hosting server.
• Настройка диспетчера процессов, который запускает приложение при поступлении запросов и перезапускает его после аварийного завершения или после перезагрузки сервера. Set up a process manager that starts the app when requests arrive and restarts the app after it crashes or the server reboots.
• Для конфигурации настройте такой прокси-сервер, который перенаправляет запросы в приложение. For configuration of a reverse proxy, set up a reverse proxy to forward requests to the app.

Публикация в папку Publish to a folder

Команда интерфейса командной строки dotnet publish компилирует код приложения и копирует файлы, необходимые для его выполнения, в папку publish. The dotnet publish command compiles app code and copies the files required to run the app into a publish folder. При развертывании из Visual Studio шаг dotnet publish выполняется автоматически перед копированием файлов место развертывания. When deploying from Visual Studio, the dotnet publish step occurs automatically before the files are copied to the deployment destination.

Файлы параметров публикации Publish settings files

Файлы *.json публикуются по умолчанию. *.json files are published by default. Чтобы опубликовать другие файлы параметров, укажите их в элементе в файле проекта. To publish other settings files, specify them in an element in the project file. В следующем примере публикуются XML-файлы: The following example publishes XML files:

Содержимое папки Folder contents

Папка publish содержит один или несколько файлов сборки и зависимости приложения, а также может включать среду выполнения .NET. The publish folder contains one or more app assembly files, dependencies, and optionally the .NET runtime.

Приложения .NET Core могут публиковаться как автономные развертывания или развертывания, зависящие от платформы. A .NET Core app can be published as self-contained deployment or framework-dependent deployment. Если приложение автономное, в папку publish добавляются файлы сборки, содержащие среду выполнения .NET. If the app is self-contained, the assembly files that contain the .NET runtime are included in the publish folder. Если приложение зависит от платформы, файлы среды выполнения .NET не добавляются, так как приложение ссылается на версию .NET, установленную на сервере. If the app is framework-dependent, the .NET runtime files aren’t included because the app has a reference to a version of .NET that’s installed on the server. По умолчанию используется модель развертывания с зависимостью от платформы. The default deployment model is framework-dependent. Дополнительные сведения см. в статье Развертывание приложений .NET Core. For more information, see .NET Core application deployment.

В дополнение к EXE— и DLL-файлам папка публикации для приложения ASP.NET Core обычно содержит файлы конфигурации, статические ресурсы и представления MVC. In addition to .exe and .dll files, the publish folder for an ASP.NET Core app typically contains configuration files, static assets, and MVC views. Для получения дополнительной информации см. Структура каталогов ASP.NET Core. For more information, see Структура каталогов ASP.NET Core.

Настройка диспетчер процессов Set up a process manager

Приложение ASP.NET Core — это консольное приложение, которое должно запускаться при загрузке сервера и перезапускаться после его аварийного завершения. An ASP.NET Core app is a console app that must be started when a server boots and restarted if it crashes. Для автоматического запуска и перезапуска требуется диспетчер процессов. To automate starts and restarts, a process manager is required. Далее приведены наиболее распространенные диспетчеры процессов для ASP.NET Core. The most common process managers for ASP.NET Core are:

Настройка обратного прокси-сервера Set up a reverse proxy

Если приложение использует сервер Kestrel, вы можете использовать Nginx, Apache или IIS в качестве обратного прокси-сервера. If the app uses the Kestrel server, Nginx, Apache, or IIS can be used as a reverse proxy server. Обратный прокси-сервер получает HTTP-запросы из Интернета и пересылает их в Kestrel. A reverse proxy server receives HTTP requests from the Internet and forwards them to Kestrel.

Любая из этих конфигураций — с обратным прокси-сервером и без него — является поддерживаемой конфигурацией для размещения. Either configuration—with or without a reverse proxy server—is a supported hosting configuration. Дополнительные сведения см. в статье Использование Kestrel с обратным прокси-сервером. For more information, see When to use Kestrel with a reverse proxy.

Любая из этих конфигураций — с обратным прокси-сервером и без него — является поддерживаемой конфигурацией для размещения. Either configuration—with or without a reverse proxy server—is a supported hosting configuration. Дополнительные сведения см. в статье Использование Kestrel с обратным прокси-сервером. For more information, see When to use Kestrel with a reverse proxy.

Сценарии использования прокси-сервера и подсистемы балансировки нагрузки Proxy server and load balancer scenarios

Для приложений, размещенных за прокси-серверами и подсистемами балансировки нагрузки, может потребоваться дополнительная настройка. Additional configuration might be required for apps hosted behind proxy servers and load balancers. Без дополнительной настройки приложение может не иметь доступ к схеме (HTTP/HTTPS) и удаленному IP-адресу, где был сформирован запрос. Without additional configuration, an app might not have access to the scheme (HTTP/HTTPS) and the remote IP address where a request originated. Дополнительные сведения см. в разделе Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки. For more information, see Configure ASP.NET Core to work with proxy servers and load balancers.

Использование Visual Studio и MSBuild для автоматизации развертывания Use Visual Studio and MSBuild to automate deployments

Помимо копирования выходных данных из dotnet publish на сервер в процессе развертывания часто требуется выполнение и других задач. Deployment often requires additional tasks besides copying the output from dotnet publish to a server. Например, может потребоваться включить дополнительные файлы в папку publish или исключить их из нее. For example, extra files might be required or excluded from the publish folder. Visual Studio использует для веб-развертывания MSBuild и настраивает MSBuild для решения многих других задач в процессе развертывания. Visual Studio uses MSBuild for web deployment, and MSBuild can be customized to do many other tasks during deployment. Дополнительные сведения см. в статье Профили публикации Visual Studio (.pubxml) для развертывания приложений ASP.NET Core (Профили публикации в Visual Studio) и книге Using MSBuild and Team Foundation Build (Использование MSBuild и сборки Team Foundation). For more information, see Профили публикации Visual Studio (.pubxml) для развертывания приложений ASP.NET Core and the Using MSBuild and Team Foundation Build book.

Развертывание приложений можно выполнять напрямую из Visual Studio в службу приложений Azure, используя компонент веб-публикации или встроенную поддержку Git. By using the Publish Web feature or built-in Git support, apps can be deployed directly from Visual Studio to the Azure App Service. Azure DevOps Services поддерживает непрерывное развертывание в Службе приложений Azure. Azure DevOps Services supports continuous deployment to Azure App Service. Дополнительные сведения см. в разделе Сборка DevOps с использованием ASP.NET Core и Azure. For more information, see DevOps with ASP.NET Core and Azure.

Публикация в Azure Publish to Azure

См. сведения о публикации приложения в Azure с помощью Visual Studio (Публикация приложения ASP.NET Core в Azure с помощью Visual Studio). See Публикация приложения ASP.NET Core в Azure с помощью Visual Studio for instructions on how to publish an app to Azure using Visual Studio. Дополнительный пример приведен в статье Создание веб-приложения ASP.NET Core в Azure. An additional example is provided by Create an ASP.NET Core web app in Azure.

Публикация с помощью MSDeploy в Windows Publish with MSDeploy on Windows

Инструкции о том, как опубликовать приложение с помощью профиля публикации Visual Studio или из командной строки Windows с помощью команды dotnet msbuild, см. в статье Профили публикации Visual Studio (.pubxml) для развертывания приложений ASP.NET Core. See Профили публикации Visual Studio (.pubxml) для развертывания приложений ASP.NET Core for instructions on how to publish an app with a Visual Studio publish profile, including from a Windows command prompt using the dotnet msbuild command.

службы IIS Internet Information Services (IIS)

Сведения о развертывании служб IIS с конфигурацией, предоставляемой файлом web.config, см. в статьях в разделе Размещение ASP.NET Core в Windows со службами IIS. For deployments to Internet Information Services (IIS) with configuration provided by the web.config file, see the articles under Размещение ASP.NET Core в Windows со службами IIS.

Размещение в веб-ферме Host in a web farm

Сведения о конфигурации для размещения приложений ASP.NET Core в среде веб-фермы (например, при развертывании множества экземпляров приложения для масштабируемости) см. в разделе Размещение ASP.NET Core в веб-ферме. For information on configuration for hosting ASP.NET Core apps in a web farm environment (for example, deployment of multiple instances of your app for scalability), see Размещение ASP.NET Core в веб-ферме.

Размещение в Docker Host on Docker

Выполнение проверок работоспособности Perform health checks

Используйте ПО промежуточного слоя для проверки работоспособности приложения и его зависимостей. Use Health Check Middleware to perform health checks on an app and its dependencies. Для получения дополнительной информации см. Проверки работоспособности в ASP.NET Core. For more information, see Проверки работоспособности в ASP.NET Core.

Дополнительные ресурсы Additional resources

В общем при развертывании приложения ASP.NET Core в среде внешнего размещения выполняются следующие действия. In general, to deploy an ASP.NET Core app to a hosting environment:

• Развертывание опубликованного приложения в папке на сервере размещения. Deploy the published app to a folder on the hosting server.
• Настройка диспетчера процессов, который запускает приложение при поступлении запросов и перезапускает его после аварийного завершения или после перезагрузки сервера. Set up a process manager that starts the app when requests arrive and restarts the app after it crashes or the server reboots.
• Для конфигурации настройте такой прокси-сервер, который перенаправляет запросы в приложение. For configuration of a reverse proxy, set up a reverse proxy to forward requests to the app.

Публикация в папку Publish to a folder

Команда интерфейса командной строки dotnet publish компилирует код приложения и копирует файлы, необходимые для его выполнения, в папку publish. The dotnet publish command compiles app code and copies the files required to run the app into a publish folder. При развертывании из Visual Studio шаг dotnet publish выполняется автоматически перед копированием файлов место развертывания. When deploying from Visual Studio, the dotnet publish step occurs automatically before the files are copied to the deployment destination.

Содержимое папки Folder contents

Папка publish содержит один или несколько файлов сборки и зависимости приложения, а также может включать среду выполнения .NET. The publish folder contains one or more app assembly files, dependencies, and optionally the .NET runtime.

Приложения .NET Core могут публиковаться как автономные развертывания или развертывания, зависящие от платформы. A .NET Core app can be published as self-contained deployment or framework-dependent deployment. Если приложение автономное, в папку publish добавляются файлы сборки, содержащие среду выполнения .NET. If the app is self-contained, the assembly files that contain the .NET runtime are included in the publish folder. Если приложение зависит от платформы, файлы среды выполнения .NET не добавляются, так как приложение ссылается на версию .NET, установленную на сервере. If the app is framework-dependent, the .NET runtime files aren’t included because the app has a reference to a version of .NET that’s installed on the server. По умолчанию используется модель развертывания с зависимостью от платформы. The default deployment model is framework-dependent. Дополнительные сведения см. в статье Развертывание приложений .NET Core. For more information, see .NET Core application deployment.

В дополнение к EXE— и DLL-файлам папка публикации для приложения ASP.NET Core обычно содержит файлы конфигурации, статические ресурсы и представления MVC. In addition to .exe and .dll files, the publish folder for an ASP.NET Core app typically contains configuration files, static assets, and MVC views. Для получения дополнительной информации см. Структура каталогов ASP.NET Core. For more information, see Структура каталогов ASP.NET Core.

Настройка диспетчер процессов Set up a process manager

Приложение ASP.NET Core — это консольное приложение, которое должно запускаться при загрузке сервера и перезапускаться после его аварийного завершения. An ASP.NET Core app is a console app that must be started when a server boots and restarted if it crashes. Для автоматического запуска и перезапуска требуется диспетчер процессов. To automate starts and restarts, a process manager is required. Далее приведены наиболее распространенные диспетчеры процессов для ASP.NET Core. The most common process managers for ASP.NET Core are:

Настройка обратного прокси-сервера Set up a reverse proxy

Если приложение использует сервер Kestrel, вы можете использовать Nginx, Apache или IIS в качестве обратного прокси-сервера. If the app uses the Kestrel server, Nginx, Apache, or IIS can be used as a reverse proxy server. Обратный прокси-сервер получает HTTP-запросы из Интернета и пересылает их в Kestrel. A reverse proxy server receives HTTP requests from the Internet and forwards them to Kestrel.

Любая из этих конфигураций — с обратным прокси-сервером и без него — является поддерживаемой конфигурацией для размещения. Either configuration—with or without a reverse proxy server—is a supported hosting configuration. Дополнительные сведения см. в статье Использование Kestrel с обратным прокси-сервером. For more information, see When to use Kestrel with a reverse proxy.