Configurar um aplicativo ASP.NET Core para o Serviço de Aplicativo do Azure
Observação
Para ASP.NET em .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, consulte 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, enquanto o mecanismo de implantação do Serviço de Aplicativo implanta o repositório de código primeiro e, em seguida, compila os binários.
Este guia fornece os principais conceitos e instruções para desenvolvedores de ASP.NET Core. Se você nunca usou o Serviço de Aplicativo do Azure, primeiro siga o Início Rápido do ASP.NET Core e o Tutorial do ASP.NET Core com Banco de Dados SQL.
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 mostrar as versões de runtime do .NET Core e do SDK disponíveis para você, navegue até https://<app-name>.scm.azurewebsites.net/DebugConsole e execute o comando a seguir 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 Cloud Shell:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
Para mostrar todas as versões compatíveis do .NET Core, 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 saber mais, veja Selecionar a versão do .NET Core a ser usada na documentação do .NET Core.
Execute o seguinte comando no Cloud Shell para definir a versão do .NET Core como 8.0:
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"
Personalizar a automação de build
Observação
Ainda não há suporte para a criação de aplicativos .NET 9 (STS) com o Serviço de Aplicativo do Windows usando o MSBuild ou SCM_DO_BUILD. O suporte para esses cenários de build virá após a data de disponibilidade geral inicial e até 04 de dezembro de 2024. As implantações que são compiladas fora do Serviço de Aplicativo por meio do Visual Studio, do Visual Studio Code, do GitHub Actions e do Azure DevOps têm suporte completo.
Se você implantar seu aplicativo usando o Git ou pacotes zip com a automação de compilação habilitada, as etapas de automação de compilação do Serviço de Aplicativo terão a seguinte sequência:
- Executar script personalizado se especificado por
PRE_BUILD_SCRIPT_PATH. - Execute
dotnet restorepara restaurar as dependências NuGet. - Execute
dotnet publishpara criar um binário para produção. - Executar 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 de pré-construção, 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 obter outras variáveis de ambiente para personalizar a automação de build, confira Configuração do Oryx.
Para obter mais informações sobre como o Serviço de Aplicativo executa e compila aplicativos de ASP.NET Core no Linux, confira a Documentação do Oryx: Como aplicativos .NET Core são detectados e compilados.
Acessar variáveis de ambiente
No Serviço de Aplicativo, você pode definir configurações de aplicativo fora do código do aplicativo. Então, eles podem ser acessados em qualquer classe usando o padrão normal de injeção de dependência de 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, por exemplo, o valor do Serviço de Aplicativo terá precedência sobre o valor de appsettings.json. O valor de appsettings.json local permite que você depure o aplicativo localmente, mas o valor do Serviço de Aplicativo permite que você execute o aplicativo em produção com as configurações de produção. As cadeias de conexão funcionam da mesma maneira. Dessa forma, você pode manter os segredos do aplicativo fora do seu repositório de código e acessar os valores apropriados sem alterar seu código.
Observação
Considere opções de conectividade mais seguras que não exijam segredos de conexão. Para obter mais informações, veja Conectividade segura com serviços e bancos de dados do Azure do Serviço de Aplicativo do Azure.
Observação
Observe que os dados de configuração hierárquica no appsettings.json é acessado usando o delimitador (sublinhado duplo) do __, que é padrão no Linux para o .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 Cloud Shell:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"
Observação
Observe que os dados de configuração hierárquica no appsettings.json é acessado usando o : delimitador padrão para o .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 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 já inclui a seleção do projeto a ser implantado. Quando você usa o mecanismo de implantação do Serviço de Aplicativo, como com o Git ou ZIP com a automação de compilação ativada, o mecanismo de implantação do Serviço de Aplicativo escolhe o primeiro site da Web 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 logs de diagnóstico
O ASP.NET Core fornece um provedor de registro em log interno para o Serviço de Aplicativo. No Program.cs do 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>();
});
Então, você pode configurar e gerar logs com o padrão normal .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 mensagens de erro e Verbose inclui todas as mensagens.
Depois que o log de diagnósticos estiver ativado, execute o seguinte comando para ver o fluxo de logs:
az webapp log tail --resource-group <resource-group-name> --name <app-name>
Se você não vir os logs do console imediatamente, verifique novamente após 30 segundos.
Observação
Você também pode inspecionar os arquivos de log do navegador em https://<app-name>.scm.azurewebsites.net/api/logs/docker.
Para interromper o streaming de log a qualquer momento, digite Ctrl+C.
Para saber mais sobre como solucionar problemas de aplicativos ASP.NET Core no Serviço de Aplicativo, veja Solucionar problemas ASP.NET Core no Serviço de Aplicativo Azure e IIS
Obter a página de exceções detalhadas
Quando seu aplicativo ASP.NET Core gera uma exceção no depurador do Visual Studio, o navegador exibe uma página de exceção detalhada, mas no Serviço de Aplicativo essa página é substituída por um genérico HTTP 500 ou Ocorreu um erro ao processar sua solicitação. Para exibir a página de exceção detalhada no Serviço de Aplicativo, adicione a ASPNETCORE_ENVIRONMENT configuração do 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 sessão HTTPS
No Serviço de Aplicativo, a terminação TLS/SSL ocorre nos balanceadores de carga de rede, assim 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 ou não, configure o Middleware de Cabeçalhos Encaminhados em Startup.cs:
- Configure o middleware com ForwardedHeadersOptions para encaminhar os cabeçalhos
X-Forwarded-ForeX-Forwarded-ProtoemStartup.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.
- Execute o comando do método UseForwardedHeaders em
Startup.Configureantes de chamar outro middleware.
Ao colocar todos os três elementos juntos, seu código ficará semelhante ao 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, veja Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga.
Reescrever ou redirecionar URL
Para reescrever ou redirecionar a URL, use o middleware de reescrita de URL no ASP.NET Core.
Abra a sessão SSH aberta no navegador
Para abrir uma sessão SSH direta com seu contêiner, seu aplicativo deve estar em execução.
Cole a seguinte URL no seu navegador e substitua <app-name> pelo nome do aplicativo:
https://<app-name>.scm.azurewebsites.net/webssh/host
Se você ainda não estiver autenticado, será necessário autenticar com sua assinatura do Azure para se conectar. Uma vez autenticado, consulte um shell no navegador, onde você pode executar comandos dentro de seu contêiner.
Observação
Quaisquer alterações feitas fora do diretório /home são armazenadas no próprio contêiner e não persistem além da reinicialização do aplicativo.
Para abrir uma sessão SSH remota no seu computador local, consulte Abrir a sessão SSH no shell remoto.
robots933456 em 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 é capaz de atender a solicitações. Uma resposta 404 indica apenas que o caminho não existe, mas informa ao Serviço de Aplicativo que o contêiner está íntegro e pronto para responder a solicitações.
Próximas etapas
Ou veja mais recursos:
Referência de variáveis de ambiente e configurações de aplicativo