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


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

Замечание

Сведения о 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 с включенной автоматизацией сборки служба приложений следует следующей последовательности:

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