Configurar um aplicativo ASP.NET Core para o Serviço de Aplicativo do Azure

Aplicações ASP.NET Core devem ser implantadas no Azure App Service como binários compilados. A ferramenta de publicação do Visual Studio cria a solução e, em seguida, implanta os binários compilados diretamente. O mecanismo de implantação do Serviço de Aplicativo implanta primeiro o repositório de código e, em seguida, compila os binários.

Este guia fornece conceitos-chave e instruções para desenvolvedores ASP.NET Core. Se este artigo for sua primeira vez usando o Serviço de Aplicativo do Azure, primeiro siga Implantar um aplicativo Web ASP.NET e Implantar um aplicativo ASP.NET Core e do Banco de Dados SQL do Azure no Serviço de Aplicativo do Azure.

dotnet --info

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

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

Definir a versão do .NET Core

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

O que acontece com tempos de execução desatualizados no Serviço de Aplicativo?

Tempos de execução desatualizados são preteridos pela organização mantenedora ou têm vulnerabilidades significativas. Assim, eles são removidos das páginas de criação e configuração no portal. Quando um tempo de execução desatualizado é oculto do portal, qualquer aplicativo que ainda esteja usando esse tempo de execução continua a ser executado.

Se você quiser criar um aplicativo com uma versão de tempo de execução desatualizada que não é mais mostrada no portal, use a CLI do Azure, um modelo ARM ou Bicep. Essas alternativas de implantação permitem criar tempos de execução preteridos que são removidos do portal, mas ainda estão sendo suportados.

Se um tempo de execução for totalmente removido da plataforma do Serviço de Aplicativo, o proprietário da assinatura do Azure receberá um aviso por email antes da remoção.

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"

Aceder a variáveis de ambiente

No Serviço de Aplicativo, você pode definir as configurações do aplicativo fora do código do aplicativo. Em seguida, você pode acessá-los em qualquer classe usando o padrão padrão de injeção de dependência do 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");
        }
    }
}

Se você definir uma configuração de aplicativo com o mesmo nome no Serviço de Aplicativo e no appsettings.json, o valor do Serviço de Aplicativo terá precedência sobre o appsettings.json valor. Usando o valor local appsettings.json , você pode depurar o aplicativo localmente. Usando o valor do Serviço de Aplicativo, você pode executar o aplicativo em produção com configurações de produção. As cadeias de conexão funcionam da mesma maneira. Usando esse método, você pode manter os segredos do aplicativo fora do repositório de código e acessar os valores apropriados sem alterar o código.

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"

Implementar soluções multiprojeto

Quando uma solução do Visual Studio inclui vários projetos, o processo de publicação do Visual Studio seleciona o projeto a ser implantado. Quando implantas no motor de implementação do App Service, como através do Git ou com a implementação ZIP com automação de compilação ativada, o motor de implementação do App Service seleciona o primeiro projeto de site ou aplicação web que encontra como a aplicação do App Service. Você pode especificar qual projeto o Serviço de Aplicativo deve usar especificando a configuração do PROJECT aplicativo. Por exemplo, execute o seguinte comando no Cloud Shell:

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

Aceder aos registos de diagnósticos

O ASP.NET Core oferece um provedor de log integrado para o Serviço de Aplicativo. No arquivo do program.cs seu projeto, adicione o provedor ao seu aplicativo por meio do ConfigureLogging método de extensão, conforme mostrado no exemplo a seguir:

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

Em seguida, você pode configurar e gerar logs com o padrão .NET Core padrão. Consulte Efetuando login no .NET Core e no ASP.NET Core.

Para acessar os logs do console gerados de dentro do código do aplicativo no Serviço de Aplicativo, ative o log de diagnóstico executando o seguinte comando no Cloud Shell:

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

Os valores possíveis para --level são Error, Warning, Infoe Verbose. Cada nível subsequente inclui o nível anterior. Por exemplo, Error inclui apenas mensagens de erro. Verbose inclui todas as mensagens.

Depois de ativar o log de diagnóstico, execute o seguinte comando para ver o fluxo de log:

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

Se os logs do console não aparecerem imediatamente, verifique novamente em 30 segundos.

Para interromper o streaming de logs a qualquer momento, selecione Ctrl+C.

Para obter mais informações sobre como solucionar problemas de aplicativos ASP.NET Core no Serviço de Aplicativo, consulte Solucionar problemas do ASP.NET Core no Serviço de Aplicativo do Azure e no IIS.

Aceda a uma página detalhada de exceções

Quando o aplicativo ASP.NET Core gera uma exceção no depurador do Visual Studio, o navegador exibe uma página de exceção detalhada. No Serviço de Aplicativo, uma mensagem genérica "HTTP 500" ou "Ocorreu um erro ao processar sua solicitação" substitui essa página. Para exibir a página de exceção detalhada no Serviço de Aplicativo, adicione a configuração do ASPNETCORE_ENVIRONMENT aplicativo ao seu aplicativo executando o seguinte comando no Cloud Shell.

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

Detetar sessão HTTPS

No App Service, a terminação TLS acontece nos balanceadores de carga de rede. Todas as solicitações HTTPS chegam ao seu aplicativo como solicitações HTTP não criptografadas. Se a lógica do seu aplicativo precisar saber se as solicitações do usuário estão criptografadas, configure o middleware de cabeçalhos encaminhados em Startup.cs:

• Configure o middleware com ForwardedHeadersOptions para encaminhar os cabeçalhos X-Forwarded-For e X-Forwarded-Proto em Startup.ConfigureServices.
• Adicione intervalos de endereços IP privados às redes conhecidas, para que o middleware possa confiar no balanceador de carga do Serviço de Aplicativo.
• Invoque o método UseForwardedHeaders no método Startup.Configure antes de chamar outro middleware.

Quando você monta os três elementos, seu código se parece com o exemplo a seguir:

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();
}

Para obter mais informações, consulte Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga.

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

Conteúdo relacionado

• Tutorial: Implantar um aplicativo ASP.NET Core e do Banco de Dados SQL do Azure

• Referência de variáveis de ambiente e configurações de aplicativo