Configurar uma aplicação ASP.NET Core para o Serviço de Aplicações do Azure
Nota
Para ASP.NET no .NET Framework, consulte Configurar um aplicativo ASP.NET para o Serviço de Aplicativo do Azure. Se seu aplicativo ASP.NET Core for executado em um contêiner personalizado do Windows ou Linux, consulte Configurar um contêiner personalizado para o Serviço de Aplicativo do Azure.
ASP.NET aplicativos principais 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, em seguida, implanta os binários compilados diretamente, enquanto 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 você nunca usou o Serviço de Aplicativo do Azure, siga primeiro o tutorial de início rápido do ASP.NET Core e do ASP.NET Core com o Banco de Dados SQL.
Mostrar versões do runtime do .NET Core suportadas
No Serviço de Aplicativo, as instâncias do Windows já têm todas as versões suportadas do .NET Core instaladas. Para mostrar as versões de tempo de execução e SDK do .NET Core disponíveis para você, navegue e https://<app-name>.scm.azurewebsites.net/DebugConsole execute o seguinte comando no console baseado em navegador:
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 estrutura de destino no arquivo de projeto para seu projeto ASP.NET Core. Para obter mais informações, consulte Selecione 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 automatização de compilação
Se você implantar seu aplicativo usando o Git ou pacotes zip com a automação de compilação habilitada, a automação de compilação do Serviço de Aplicativo percorrerá a seguinte sequência:
- Execute um script personalizado se especificado pelo
PRE_BUILD_SCRIPT_PATH. - Execute
dotnet restorepara restaurar dependências do NuGet. - Execute
dotnet publishpara construir um binário para produção. - Execute um script personalizado se especificado pelo
POST_BUILD_SCRIPT_PATH.
PRE_BUILD_COMMAND e POST_BUILD_COMMAND são variáveis de ambiente que estão vazias por padrã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 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 para personalizar a automação de compilação, consulte Configuração do Oryx.
Para obter mais informações sobre como o Serviço de Aplicativo executa e cria aplicativos ASP.NET Core no Linux, consulte a documentação do Oryx: Como os aplicativos .NET Core são detetados e criados.
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, 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, por exemplo, o valor do Serviço de Aplicativo terá precedência sobre o valor appsettings.json . O valor appsettings.json local permite depurar o aplicativo localmente, mas o valor do Serviço de Aplicativo permite executar o aplicativo em produção com 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 repositório de código e acessar os valores apropriados sem alterar o código.
Nota
Considere opções de conectividade mais seguras que não exijam segredos de conexão. Para obter mais informações, consulte Conectividade segura com serviços e bancos de dados do Azure do Serviço de Aplicativo do Azure.
Nota
Observe que os dados de configuração hierárquica no appsettings.json são acessados usando 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 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"
Nota
Observe que os dados de configuração hierárquica no appsettings.json são acessados usando o : delimitador padrão do .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"
Implementar soluções multiprojeto
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ê implanta no mecanismo de implantação do Serviço de Aplicativo, como com o Git, ou com a implantação ZIP com a automação de compilação habilitada, o mecanismo de implantação do Serviço de Aplicativo escolhe o primeiro Site ou Projeto de Aplicativo Web que encontra como o aplicativo do Serviço de Aplicativo. 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 fornece um provedor de log interno para o Serviço de Aplicativo. Em 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>();
});
Em seguida, você pode configurar e gerar logs 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 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
Obter uma página de exceções detalhada
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 HTTP 500 genérico 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 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 Serviço de Aplicativo, a terminação TLS/SSL acontece nos balanceadores de carga de rede, portanto, 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 são criptografadas ou não, configure o middleware de cabeçalhos encaminhados em Startup.cs:
- Configure o middleware com ForwardedHeadersOptions para encaminhar os
X-Forwarded-Forcabeçalhos eX-Forwarded-ProtonoStartup.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 antes
Startup.Configurede chamar outro middleware.
Juntando 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.
Reescrever ou redirecionar URL
Para reescrever ou redirecionar URL, use o middleware de reconfiguração de URL no ASP.NET Core.
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.
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.
Próximos passos
Ou veja mais recursos:
Referência de variáveis de ambiente e configurações de aplicativo
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários