Compartilhar via

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

Observação

Para ASP.NET no .NET Framework, veja Configurar um aplicativo ASP.NET para o Serviço de Aplicativo do Azure. Se o aplicativo ASP.NET Core for executado em um contêiner personalizado do Windows ou do Linux, veja Configurar um contêiner personalizado para o Serviço de Aplicativo do Azure.

Os aplicativos ASP.NET Core devem ser implantados no Serviço de Aplicativo do Azure como binários compilados. A ferramenta de publicação do Visual Studio cria a solução e 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 os principais conceitos e instruções para desenvolvedores de 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.

Mostrar versões suportadas druntime do .NET Core

No Serviço de Aplicativo, as instâncias do Windows já têm todas as versões do .NET Core com suporte instaladas. Para ver o runtime do .NET Core e as versões do SDK que estão disponíveis para você, acesse seu site do Kudu.

Acesse seu aplicativo no portal do Azure e selecione Ferramentas de Desenvolvimento>Ferramentas Avançadas. Selecione Ir. No Kudu, selecione o console de depuração para CMD ou PowerShell.

Execute o seguinte comando no console baseado em navegador:

dotnet --info

Exibir a versão do .NET Core

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

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

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

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

Defina a versão do .NET Core

Defina a estrutura de destino no arquivo de projeto para seu projeto ASP.NET Core. Para obter mais informações, consulte Selecionar a versão do .NET Core a ser usada.

Para definir a versão do .NET Core como 8.0, execute o seguinte comando no Cloud Shell:

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

O que acontece com ambientes de execução obsoletos no Azure App Service?

Runtimes desatualizados são preteridos pela organização de manutenção ou têm vulnerabilidades significativas. Assim, eles são removidos da criação e configuração de páginas no portal. Quando um runtime desatualizado está oculto do portal, qualquer aplicativo que ainda esteja usando esse runtime continuará sendo executado.

Caso queira criar um aplicativo com uma versão de runtime desatualizada que não é mais mostrada no portal, use a CLI do Azure, um modelo do ARM ou o Bicep. Essas alternativas de implantação permitem criar runtimes preteridos que são removidos do portal, mas que ainda estão sendo suportados.

Se um runtime 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.

Personalizar a automação de build

Se você implantar seu aplicativo usando pacotes Git ou ZIP com automação de build habilitada, a automação de build do Serviço de Aplicativo seguirá esta sequência:

  1. Executar o script personalizado se especificado por PRE_BUILD_SCRIPT_PATH.
  2. Para restaurar dependências do NuGet, execute dotnet restore.
  3. Para criar um binário para produção, execute dotnet publish.
  4. Executar o script personalizado se especificado por POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND e POST_BUILD_COMMAND são variáveis de ambiente vazias por padrão. Para executar comandos pré-build, defina PRE_BUILD_COMMAND. Para executar comandos pós-build, defina POST_BUILD_COMMAND.

O exemplo a seguir 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 que você pode usar para personalizar a automação de build, consulte a configuração do Oryx.

Para obter mais informações sobre como o Serviço de Aplicativo executa e compila aplicativos do ASP.NET Core no Linux, veja a Documentação do Oryx: Como aplicativos .NET Core são detectados e compilados.

Acessar as 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 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 em appsettings.json, o valor do Serviço de Aplicativo terá precedência sobre o valor em appsettings.json. 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 as 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.

Observação

Você também pode considerar opções de conectividade mais seguras que não exigem segredos de conexão. Para obter mais informações, veja Conectividade segura com os serviços e bancos de dados do Serviço de Aplicativo do Azure.

Os dados de configuração hierárquica em appsettings.json são acessados por meio do delimitador __ (sublinhado duplo) que é padrão no Linux para .NET Core. Para substituir uma definição de configuração hierárquica específica no Serviço de Aplicativo, defina o nome da configuração do aplicativo com o mesmo formato delimitado na chave. Você 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"

Os dados de configuração hierárquica em appsettings.json são acessados por meio do delimitador : que é padrão no .NET Core. Para substituir uma definição de configuração hierárquica específica no Serviço de Aplicativo, defina o nome da configuração do aplicativo com o mesmo formato delimitado na chave. Você pode executar o exemplo a seguir no Azure Cloud Shell:

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

Implantar soluções multiprojetos

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 você faz a implantação no mecanismo de implantação do Serviço de Aplicativo, por exemplo, com o Git ou a implantação ZIP com a automação de build habilitada, o mecanismo de implantação do Serviço de Aplicativo escolhe o primeiro site ou projeto de aplicativo Web que ele encontra como o aplicativo do Serviço de Aplicativo. Você pode definir qual projeto o Serviço de Aplicativo deve usar especificando a configuração do aplicativo PROJECT. 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"

Acessar os logs de diagnóstico

ASP.NET Core oferece um provedor de log interno para o Serviço de Aplicativo. No arquivo program.cs do seu projeto, adicione o provedor ao aplicativo através do método de extensão ConfigureLogging, 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 padrão do .NET Core. Consulte Como fazer logon no .NET Core e no ASP.NET Core.

Para acessar os logs de console gerados 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, Info e Verbose. Cada nível seguinte inclui o anterior. Por exemplo, Error inclui apenas as 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 log a qualquer momento, selecione Ctrl+C.

Para obter mais informações sobre como solucionar problemas em aplicativos ASP.NET Core no Azure App Service, consulte Solucionar problemas do ASP.NET Core no Azure App Service e no IIS.

Acessar uma página de exceções detalhadas

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 "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 comando a seguir no Cloud Shell.

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

Detectar a sessão HTTPS

No Serviço de Aplicativo, a terminação de TLS é realizada nos balanceadores de carga de rede. Todas as solicitações HTTPS chegam ao 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 em Startup.Configure antes de chamar outros middlewares.

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

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 o ASP.NET Core para funcionar com os servidores proxy e balanceadores de carga.

Reescrever ou redirecionar URL

Para reescrever ou redirecionar uma URL, use o middleware de reescrita de URL no ASP.NET Core.

Abra a sessão SSH aberta no navegador

Se você quiser abrir uma sessão SSH direta com seu contêiner, seu aplicativo deverá estar em execução.

Use o comando az webapp ssh .

Se você não estiver autenticado, será necessário autenticar-se com sua assinatura do Azure para se conectar. Quando você estiver autenticado, verá um shell no navegador, no qual poderá executar comandos dentro do seu contêiner.

Conexão SSH

Observação

Todas as alterações feitas fora do /home diretório são armazenadas no próprio contêiner e não persistem além de uma reinicialização do aplicativo.

Para abrir uma sessão SSH remota no seu computador local, veja Abrir a sessão SSH no shell remoto.

Ignore a mensagem robots933456 nos logs

Você poderá ver a seguinte mensagem nos logs de contêiner:

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

Você pode ignorar essa mensagem com segurança. /robots933456.txt é um caminho de URL fictício que o Serviço de Aplicativo usa para verificar se o contêiner atende a solicitações. Uma resposta 404 indica que o caminho não existe e sinaliza ao Serviço de Aplicativo que o contêiner está íntegro e pronto para responder às solicitações.

Conteúdo relacionado

  • Last updated on