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

2025-07-07

Замечание

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

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

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

Показать поддерживаемые версии среды выполнения .NET Core

В App Service в Windows экземпляры уже установлены все поддерживаемые версии .NET Core. Чтобы просмотреть доступные для вас версии среды выполнения и пакета SDK для .NET Core, перейдите на сайт Kudu.

Перейдите к вашему приложению на портале Azure и выберите Средства разработки>Дополнительные средства. Нажмите кнопку "Перейти". В Kudu выберите консоль отладки для CMD или PowerShell.

Выполните следующую команду в консоли на основе браузера:

dotnet --info

Показать версию .NET Core

Чтобы отобразить текущую версию .NET Core, выполните следующую команду в Azure 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

Установите целевую платформу в файл проекта для вашего проекта ASP.NET Core. Дополнительные сведения см. в разделе "Выбор используемой версии .NET Core".

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

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

Что происходит с устаревшими средами выполнения в сервисе приложений?

Устаревшие среды выполнения сняты с поддержки поддерживающей организацией или имеют значительные уязвимости. Соответственно, они удаляются из страниц создания и настройки на портале. Если устаревшая среда выполнения скрыта на портале, любое приложение, которое по-прежнему используется этой средой выполнения, продолжает выполняться.

Если вы хотите создать приложение с устаревшей версией среды выполнения, которая больше не отображается на портале, используйте Azure CLI, шаблон ARM или Bicep. Эти варианты развертывания позволяют создавать устаревшие среды выполнения, которые были удалены на портале, но по-прежнему поддерживаются.

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

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

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

Выполнить пользовательский скрипт, если это указано PRE_BUILD_SCRIPT_PATH.
Чтобы восстановить зависимости NuGet, выполните команду dotnet restore.
Чтобы создать двоичный файл для рабочей среды, выполните команду 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.

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

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

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 App Service".

Доступ к данным иерархической конфигурации в appsettings.json осуществляется с использованием __ разделителя двойного подчеркивания, стандартного для Linux на .NET Core. Чтобы переопределить определенное иерархическое значение конфигурации в App Service, задайте имя параметра приложения с тем же разделённым форматом в ключе. В 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. Чтобы переопределить определенное иерархическое значение конфигурации в App Service, задайте имя параметра приложения с тем же разделённым форматом в ключе. Вы можете выполнить следующий пример в Azure 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-развертывание с включенной автоматизацией сборки, механизм развертывания службы приложений выбирает первый веб-сайт или проект веб-приложения, который он находит, в качестве приложения службы приложений. Вы можете указать, какой проект должен использовать App Service, задав настройку приложения 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. Смотрите ведение журналов в .NET Core и ASP.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 секунд.

Чтобы прекратить потоковую передачу журнала в любое время, нажмите 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 происходит в сетевых подсистемах балансировки нагрузки. Все 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 с контейнером, ваше приложение должно быть запущено.

Используйте команду az webapp ssh .

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

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

Замечание

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

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

Игнорировать сообщение робота933456 в журналах

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

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 указывает, что путь не существует, и он сигнализирует службе приложений о том, что контейнер работоспособен и готов реагировать на запросы.

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

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

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

Поделиться через

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

Показать поддерживаемые версии среды выполнения .NET Core

Показать версию .NET Core

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

Что происходит с устаревшими средами выполнения в сервисе приложений?

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

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

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

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

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

Обнаружить HTTPS-сеанс

Переписать или перенаправить URL

Открыть SSH-сессию в браузере

Игнорировать сообщение робота933456 в журналах

Связанный контент

Обратная связь

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