Configurar uma aplicação ASP.NET Core para Serviço de Aplicações do Azure

Artigo
06/01/2023

Nota

Para ASP.NET no .NET Framework, veja Configurar uma aplicação ASP.NET para Serviço de Aplicações do Azure. Se a sua aplicação ASP.NET Core for executada num contentor personalizado do Windows ou Linux, consulte Configurar um contentor personalizado para Serviço de Aplicações do Azure.

ASP.NET Core aplicações têm de ser implementadas para Serviço de Aplicações do Azure como binários compilados. A ferramenta de publicação do Visual Studio cria a solução e, em seguida, implementa diretamente os binários compilados, enquanto o motor de implementação Serviço de Aplicações implementa primeiro o repositório de código e, em seguida, compila os binários.

Este guia fornece conceitos e instruções fundamentais para programadores ASP.NET Core. Se nunca utilizou Serviço de Aplicações do Azure, siga primeiro o início rápido ASP.NET Core e ASP.NET Core com Base de Dados SQL tutorial.

Mostrar versões de runtime do .NET Core suportadas

No Serviço de Aplicações, as instâncias do Windows já têm todas as versões suportadas do .NET Core instaladas. Para mostrar o runtime do .NET Core e as versões do SDK disponíveis para si, navegue para https://<app-name>.scm.azurewebsites.net/DebugConsole e execute o seguinte comando na consola baseada no browser:

dotnet --info

Mostrar versão do .NET Core

Para mostrar a versão atual do .NET Core, execute o seguinte comando no Cloud Shell:

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

Para mostrar todas as versões suportadas do .NET Core, execute o seguinte comando no Cloud Shell:

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

Definir a versão do .NET Core

Defina a arquitetura de destino no ficheiro de projeto para o projeto ASP.NET Core. Para obter mais informações, consulte Selecionar a versão do .NET Core a utilizar na documentação do .NET Core.

Execute o seguinte comando no Cloud Shell para definir a versão do .NET Core como 3.1:

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

Personalizar a automatização de compilação

Se implementar a sua aplicação com o Git ou pacotes zip com a automatização de compilação ativada, o Serviço de Aplicações compilar passos de automatização através da seguinte sequência:

Execute o script personalizado se especificado por PRE_BUILD_SCRIPT_PATH.
Execute dotnet restore para restaurar as dependências do NuGet.
Execute dotnet publish para criar um binário para produção.
Execute o script personalizado se especificado por POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND e POST_BUILD_COMMAND são variáveis de ambiente que estão vazias por predefinição. Para executar comandos de pré-compilação, defina PRE_BUILD_COMMAND. Para executar comandos pós-compilação, defina POST_BUILD_COMMAND.

O exemplo seguinte especifica as duas variáveis para uma série de comandos, separados por vírgulas.

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"

Para outras variáveis de ambiente para personalizar a automatização de compilação, veja Configuração do Oryx.

Para obter mais informações sobre como Serviço de Aplicações executa e compila aplicações ASP.NET Core no Linux, veja Documentação do Oryx: Como as aplicações .NET Core são detetadas e criadas.

Aceder a variáveis de ambiente

No Serviço de Aplicações, pode configurar as definições da aplicação fora do código da aplicação. Em seguida, pode aceder-lhes em qualquer classe com o padrão de injeção de dependências ASP.NET Core padrão:

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 configurar uma definição de aplicação com o mesmo nome no Serviço de Aplicações e em appsettings.json, por exemplo, o valor Serviço de Aplicações tem precedência sobre o valor appsettings.json. O valor appsettings.json local permite-lhe depurar a aplicação localmente, mas o valor Serviço de Aplicações permite-lhe executar a aplicação em produção com definições de produção. As cadeias de ligação funcionam da mesma forma. Desta forma, pode manter os segredos da aplicação fora do repositório de código e aceder aos valores adequados sem alterar o código.

Nota

Tenha em atenção que os dados de configuração hierárquica em appsettings.json são acedidos com o __ delimitador (sublinhado duplo) padrão no Linux para .NET Core. Para substituir uma definição de configuração hierárquica específica no Serviço de Aplicações, defina o nome da definição da aplicação com o mesmo formato delimitado na chave. pode executar o seguinte exemplo no Cloud Shell:

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

Nota

Tenha em atenção que os dados de configuração hierárquica em appsettings.json são acedidos com o : delimitador padrão para .NET Core. Para substituir uma definição de configuração hierárquica específica no Serviço de Aplicações, defina o nome da definição da aplicação com o mesmo formato delimitado na chave. pode executar o seguinte exemplo no Cloud Shell:

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

Implementar soluções de vários projetos

Quando uma solução do Visual Studio inclui vários projetos, o processo de publicação do Visual Studio já inclui a seleção do projeto a implementar. Quando implementa no motor de implementação Serviço de Aplicações, como com o Git ou com a implementação zip com a automatização de compilação ativada, o motor de implementação Serviço de Aplicações escolhe o primeiro Web Site ou Projeto de Aplicação Web que encontra como a aplicação Serviço de Aplicações. Pode especificar que projeto Serviço de Aplicações deve utilizar ao especificar a definição da aplicaçãoPROJECT. 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

ASP.NET Core fornece um fornecedor de registo incorporado para Serviço de Aplicações. Em Program.cs do seu projeto, adicione o fornecedor à sua aplicação através do ConfigureLogging método de extensão, conforme mostrado no exemplo seguinte:

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

Em seguida, pode configurar e gerar registos com o padrão .NET Core padrão.

Para aceder aos registos da consola gerados a partir do código da sua aplicação no Serviço de Aplicações, ative o registo de diagnósticos ao executar 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, Info e Verbose. Cada nível subsequente inclui o nível anterior. Por exemplo: Error inclui apenas mensagens de erro e Verbose inclui todas as mensagens.

Depois de ativar o registo de diagnósticos, execute o seguinte comando para ver o fluxo de registos:

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

Se não vir os registos da consola imediatamente, volte a consultar dentro de 30 segundos.

Nota

Também pode inspecionar os ficheiros de registo no browser em https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Para parar a transmissão de registos em qualquer altura, escreva Ctrl+C.

Para obter mais informações sobre a resolução de problemas ASP.NET Core aplicações no Serviço de Aplicações, veja Resolver problemas de ASP.NET Core no Serviço de Aplicações do Azure e no IIS

Obter a página de exceções detalhadas

Quando a aplicação ASP.NET Core gera uma exceção no depurador do Visual Studio, o browser apresenta uma página de exceção detalhada, mas no Serviço de Aplicações essa página é substituída por um erro HTTP 500 genérico ou ocorreu um erro ao processar o seu pedido. Para apresentar a página de exceção detalhada no Serviço de Aplicações, adicione a definição da aplicação ASPNETCORE_ENVIRONMENT à sua aplicação ao executar 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 Serviço de Aplicações, a terminação TLS/SSL ocorre nos balanceadores de carga de rede, pelo que todos os pedidos HTTPS chegam à sua aplicação como pedidos HTTP não encriptados. Se a lógica da sua aplicação precisar de saber se os pedidos do utilizador estão encriptados ou não, configure o Middleware cabeçalhos reencaminhados em Startup.cs:

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

Ao juntar os três elementos, o código tem o seguinte aspeto:

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, veja Configurar ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga.

Abrir sessão SSH no browser

Para abrir uma sessão SSH direta com o seu contentor, a sua aplicação deve estar em execução.

Cole o seguinte URL no browser e substitua <app-name> pelo nome da aplicação:

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

Se ainda não estiver autenticado, é necessário fazê-lo com a sua subscrição do Azure para se ligar. Uma vez autenticado, pode ver uma shell no browser, na qual pode executar comandos dentro do seu contentor.

Ligação SSH

Nota

Todas as alterações realizadas fora do diretório /home são armazenadas no próprio contentor e não persistem para além do reinício da aplicação.

Para abrir uma sessão SSH remota a partir do computador local, veja Abrir sessão SSH a partir da shell remota.

robots933456 nos registos

Pode ver a seguinte mensagem nos registos do contentor:

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

Pode ignorar esta mensagem. /robots933456.txt é um caminho de URL fictício que o Serviço de Aplicações utiliza para verificar se o contentor consegue satisfazer pedidos. Uma resposta 404 indica simplesmente que o caminho não existe, mas permite que o Serviço de Aplicações saiba que o contentor está em bom estado de funcionamento e pronto para responder aos pedidos.

Passos seguintes

Tutorial: ASP.NET Core aplicação com Base de Dados SQL

FAQ do Serviço de Aplicações no Linux

Em alternativa, veja mais recursos:

Referência de variáveis de ambiente e definições de aplicações

Configurar uma aplicação ASP.NET Core para Serviço de Aplicações do Azure

Mostrar versões de runtime do .NET Core suportadas

Mostrar versão do .NET Core

Definir a versão do .NET Core

Personalizar a automatização de compilação

Aceder a variáveis de ambiente

Implementar soluções de vários projetos

Aceder aos registos de diagnósticos

Obter a página de exceções detalhadas

Detetar sessão HTTPS

Abrir sessão SSH no browser

robots933456 nos registos

Passos seguintes

Recursos adicionais