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

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

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

dotnet --info

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

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

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

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

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"

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

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

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

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 секунд.

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

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

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

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

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

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