Настройка приложения ASP.NET Core для службы приложений Azure

Мақала
07/02/2024

Примечание.

Сведения о ASP.NET в платформа .NET Framework см. в разделе "Настройка приложения ASP.NET для службы приложение Azure". Если приложение ASP.NET Core выполняется в пользовательском контейнере Windows или Linux, см. раздел "Настройка пользовательского контейнера для службы приложение Azure".

Приложения ASP.NET Core необходимо развертывать в Службе приложений Azure в виде скомпилированных двоичных файлов. Средство публикации Visual Studio создает решение, а затем напрямую развертывает скомпилированные двоичные файлы, тогда как механизм развертывания службы приложений сначала развертывает репозиторий кода, а затем компилирует двоичные файлы.

В этом руководстве представлены ключевые концепции и инструкции для разработчиков ASP.NET Core. Если ранее вы не работали со Службой приложений Azure, сначала ознакомьтесь с кратким руководством по ASP.NET Core и ASP.NET Core с базой данных SQL.

Отображение поддерживаемых версий среды выполнения .NET Core

В службе приложений на экземплярах Windows уже установлены все поддерживаемые версии .NET Core. Чтобы просмотреть доступные вам версии среды выполнения .NET Core и SDK, перейдите к https://<app-name>.scm.azurewebsites.net/DebugConsole и выполните следующую команду в консоли на основе браузера:

dotnet --info

Отображение версии .NET Core

Чтобы отобразить сведения о текущей версии .NET Core, выполните следующую команду в Cloud Shell:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

Чтобы отобразились сведения обо всех поддерживаемых версиях .NET Core, выполните следующую команду в Cloud Shell:

az webapp list-runtimes --os linux | grep DOTNET

Указание версии .NET Core

Задайте требуемую версию .NET Framework в файле своего проекта ASP.NET Core. Подробнее см. в разделе Выбор используемой версии .NET Core в документации .NET Core.

Выполните следующую команду в Cloud Shell , чтобы задать для .NET Core версию 8.0:

az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"

Настройка автоматизации сборки

Примечание.

Создание приложений .NET 9 (STS) с помощью Windows Служба приложений с помощью MSBuild или SCM_DO_BUILD еще не поддерживается. Поддержка этих сценариев сборки будет поступать после начальной даты общедоступной версии и к 4 декабря 2024 г. Развертывания, которые создаются вне Служба приложений с помощью Visual Studio, Visual Studio Code, GitHub Actions и Azure DevOps, полностью поддерживаются.

Если приложение развертывается с использованием Git или ZIP-пакетов с включенной автоматизацией сборки, то автоматизация сборки Службы приложений проходит в такой последовательности:

Запустите пользовательский скрипт, если он указан PRE_BUILD_SCRIPT_PATH.
Выполните команду dotnet restore, чтобы восстановить зависимости NuGet.
Выполните команду dotnet publish, чтобы создать двоичный файл для рабочей среды.
Запустите пользовательский скрипт, если он указан POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND и POST_BUILD_COMMAND являются переменными среды, которые по умолчанию пустые. Чтобы выполнить команды предварительной сборки, определите PRE_BUILD_COMMAND. Чтобы выполнить команды после сборки, определите POST_BUILD_COMMAND.

В следующем примере указываются две переменные для ряда команд, разделенных запятыми.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"

Другие переменные среды для настройки автоматизации сборки см. в разделе "Конфигурация Oryx".

Подробнее о том, как Служба приложений выполняет и создает приложения ASP.NET Core в Linux, см. в документации по Oryx: как обнаруживать и создавать приложения .NET Core.

Доступ к переменным среды

В Службе приложений можно задать параметры приложения вне кода приложения. Затем вы сможете обратиться к ним в любом классе посредством стандартного шаблона внедрения зависимостей ASP.NET Core:

using Microsoft.Extensions.Configuration;

namespace SomeNamespace 
{
    public class SomeClass
    {
        private IConfiguration _configuration;
    
        public SomeClass(IConfiguration configuration)
        {
            _configuration = configuration;
        }
    
        public SomeMethod()
        {
            // retrieve nested App Service app setting
            var myHierarchicalConfig = _configuration["My:Hierarchical:Config:Data"];
            // retrieve App Service connection string
            var myConnString = _configuration.GetConnectionString("MyDbConnection");
        }
    }
}

Если вы настраиваете параметр приложения с одним и тем же именем в Службе приложений и, к примеру, в appsettings.json, значение Службы приложений имеет приоритет над значением appsettings.json. Локальное appsettings.json значение позволяет локально отлаживать приложение, но значение Служба приложений позволяет запускать приложение в рабочей среде с параметрами рабочей среды. Строки подключения работают точно так же. Таким образом, вы можете хранить секреты своего приложения вне репозитория кода и получать доступ к соответствующим значениям без изменения кода.

Примечание.

Рассмотрите более безопасные параметры подключения, которые не требуют секретов подключения вообще. Дополнительные сведения см. в статье "Безопасное подключение к службам и базам данных Azure" из службы приложение Azure.

Примечание.

Обратите внимание, что доступ к данным иерархической конфигурации в appsettings.json можно получить с помощью стандартного для Linux to .NET Core в виде символа __ (двойное подчеркивание). Чтобы переопределить параметры иерархической конфигурации в Службе приложений, укажите имя параметра приложения в том же формате с разделителями. В Cloud Shell вы можете выполнить следующий пример:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"

Примечание.

Обратите внимание, что доступ к данным иерархической конфигурации в appsettings.json можно получить с помощью стандартного для .NET Core разделителя :. Чтобы переопределить параметры иерархической конфигурации в Службе приложений, укажите имя параметра приложения в том же формате с разделителями. В Cloud Shell вы можете выполнить следующий пример:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My:Hierarchical:Config:Data="some value"

Развертывание многопроектных решений

Если решение Visual Studio включает несколько проектов, процесс публикации Visual Studio уже включает выбор проекта для развертывания. При развертывании в подсистеме развертывания Службы приложений, например с использованием Git или ZIP с включенной автоматизацией сборки, подсистема развертывания Службы приложений выбирает первый веб-сайт или проект веб-приложения, который оно находит, в качестве приложения Службы приложений. Чтобы указать, какую службу приложений проекта следует использовать, задайте параметр PROJECT приложения. Например, выполните следующую команду в Cloud Shell:

az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"

Доступ к журналам диагностики

ASP.NET Core предлагает встроенный поставщик ведения журнала для Службы приложений. В рамках Program.cs своего проекта добавьте поставщик в приложение посредством метода расширения ConfigureLogging, как показано в следующем примере:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureLogging(logging =>
        {
            logging.AddAzureWebAppDiagnostics();
        })
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

Затем вы сможете настраивать и создавать журналы по стандартному шаблону .NET Core.

Чтобы получить доступ к журналам консоли, созданным в коде приложения в Службе приложений, включите ведение журнала диагностики, выполнив следующую команду в Cloud Shell:

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

Возможные значения для --level: Error, Warning, Info и Verbose. Каждый последующий уровень включает предыдущий уровень. Например: Error включает только сообщения об ошибках, а Verbose включает все сообщения.

Включив ведение журнала диагностики, выполните следующую команду, чтобы просмотреть поток данных журнала:

az webapp log tail --resource-group <resource-group-name> --name <app-name>

Если журналы консоли не отображаются, проверьте еще раз через 30 секунд.

Примечание.

Вы также можете проверить файлы журнала в браузере на странице https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Чтобы остановить потоковую передачу журналов, нажмите клавиши Ctrl+C.

Подробнее об устранениях неполадок в приложениях ASP.NET Core в Службе приложений см. в разделе Устранение неполадок в ASP.NET Core в Службе приложений Azure и IIS

Получить подробную страницу исключений

Когда приложение ASP.NET Core создает исключение в отладчике Visual Studio, браузер отображает подробную страницу исключений, но в Служба приложений эта страница заменяется универсальным HTTP 500 или ошибка при обработке запроса. Чтобы отобразить подробную страницу исключений в Служба приложений, добавьте ASPNETCORE_ENVIRONMENT параметр приложения в приложение, выполнив следующую команду в Cloud Shell.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"

Обнаружение сеанса HTTPS

В Службе приложений завершение TLS/SSL-запросов происходит в подсистеме балансировки нагрузки сети, поэтому все HTTPS-запросы достигают вашего приложения в виде незашифрованных HTTP-запросов. Если вашей логике приложения необходимо знать, зашифровываются ли запросы пользователя, настройте в Startup.cs ПО промежуточного слоя для перенаправления заголовков:

Настройте ПО промежуточного слоя с помощью ForwardedHeadersOptions, чтобы заголовки X-Forwarded-For и X-Forwarded-Proto перенаправлялись в Startup.ConfigureServices.
Добавьте в известные сети диапазоны частных IP-адресов, чтобы ПО промежуточного слоя доверяло подсистеме балансировки нагрузки Службы приложений.
Прежде чем вызывать другое ПО промежуточного слоя, вызовите метод UseForwardedHeaders в Startup.Configure.

После того как вы объедините все эти три компонента, ваш код будет выглядеть следующим образом:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders =
            ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
        // These three subnets encapsulate the applicable Azure subnets. At the moment, it's not possible to narrow it down further.
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:10.0.0.0"), 104));
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:192.168.0.0"), 112));
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:172.16.0.0"), 108));
    });
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseForwardedHeaders();

    ...

    app.UseMvc();
}

Дополнительные сведения см. в разделе Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки.

Перезапись или перенаправление URL-адреса

Чтобы перезаписать или перенаправить URL-адрес, используйте ПО промежуточного слоя перезаписи URL-адресов в ASP.NET Core.

Открытие сеанса SSH в браузере

Чтобы открыть прямой сеанс SSH с контейнером, необходимо запустить приложение.

Вставьте следующий URL-адрес в браузер и замените <app-name> именем вашего приложения:

https://<app-name>.scm.azurewebsites.net/webssh/host

Если вы не прошли аутентификацию, это потребуется сделать, подключившись с помощью подписки Azure. После выполнения проверки подлинности отобразится оболочка в браузере. Здесь можно запускать команды внутри контейнера.

SSL-подключение

Примечание.

Любые изменения, внесенные не в каталоге /home, сохраняются в самом контейнере и не применяются до перезапуска приложения.

Чтобы открыть удаленный сеанс SSH на локальном компьютере см. инструкцию в разделе Открытие сеанса SSH из удаленной оболочки.

robots933456 в журналах

В журналах контейнера может отобразиться следующее сообщение:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Это сообщение можно проигнорировать. /robots933456.txt — это фиктивный URL-путь, с помощью которого Служба приложений проверяет, может ли контейнер обслуживать запросы. Ответ 404 означает, что путь не существует. При этом он информирует Службу приложений о том, что контейнер работоспособен и готов отвечать на запросы.

Следующие шаги

Руководство по приложению ASP.NET Core с База данных SQL

Служба приложений под управлением Linux: вопросы и ответы

Кроме того, ознакомьтесь с дополнительными ресурсами:

Справка по переменным среды и параметрам приложений

Бөлісу құралы:

Настройка приложения ASP.NET Core для службы приложений Azure

Отображение поддерживаемых версий среды выполнения .NET Core

Отображение версии .NET Core

Указание версии .NET Core

Настройка автоматизации сборки

Доступ к переменным среды

Развертывание многопроектных решений

Доступ к журналам диагностики

Получить подробную страницу исключений

Обнаружение сеанса HTTPS

Перезапись или перенаправление URL-адреса

Открытие сеанса SSH в браузере

robots933456 в журналах

Следующие шаги

Кері байланыс

Қосымша ресурстар