Visão geral do .NET em Aplicativos de Contêiner do Azure
Para implantar um aplicativo .NET em um ambiente nativo da nuvem, como os Aplicativos de Contêiner do Azure, há decisões que você precisa tomar para garantir que seu aplicativo seja executado sem problemas e com segurança. Este guia aborda os principais conceitos envolvidos na implantação de um aplicativo .NET em Aplicativos de Contêiner do Azure.
Os Aplicativos de Contêiner do Azure são um serviço de contêiner sem servidor totalmente gerenciado que permite executar aplicativos em contêineres sem precisar gerenciar a infraestrutura subjacente. O Container Apps inclui suporte interno para recursos, incluindo dimensionamento automático, verificações de integridade e certificados TLS (Transport Layer Security).
Este artigo detalha os conceitos e preocupações importantes para você ao implantar um aplicativo .NET em Aplicativos de Contêiner do Azure.
Selecione um tipo de recurso
O Container Apps suporta dois tipos de recursos: aplicativos e trabalhos. Os aplicativos executam serviços continuamente, enquanto os trabalhos são tarefas de curta duração projetadas para serem executadas até a conclusão.
Ao se preparar para implantar seu aplicativo, considere as diferenças entre esses dois tipos de aplicativo, pois seu comportamento afeta a forma como você gerencia seu aplicativo .NET. A tabela a seguir descreve a diferença nos casos de uso entre e jobs.
| Caso de utilização | Tipo de recurso |
|---|---|
| Uma API da Web ASP.NET Core que atende a solicitações HTTP | Aplicação |
| Um aplicativo de console .NET Core que processa alguns dados e, em seguida, sai | Tarefa |
| Um serviço em segundo plano em execução contínua que processa mensagens de uma fila | Aplicação |
| Um serviço de otimização de imagem que é executado somente quando imagens grandes são salvas em uma conta de armazenamento. | Tarefa |
| Um aplicativo usando uma estrutura como Hangfire, Quartz.NET ou o SDK de WebJobs do Azure | Aplicação |
Contentorizar e implementar a sua aplicação .NET
Para aplicativos ou trabalhos, você precisa criar uma imagem de contêiner para empacotar seu aplicativo .NET. Para obter mais informações sobre como criar imagens de contêiner, consulte Imagens do Docker para ASP.NET Core.
Depois de configurado, você pode implantar seu aplicativo nos Aplicativos de Contêiner do Azure seguindo estes guias:
- Tutorial: Implantar em aplicativos de contêiner do Azure usando o Visual Studio
- Guia de início rápido: criar e implantar a partir de um repositório para Aplicativos de Contêiner do Azure
- Criar um trabalho com Aplicativos de Contêiner do Azure
Usar a entrada HTTP
Os Aplicativos de Contêiner do Azure incluem uma entrada HTTP interna que permite expor seus aplicativos ao tráfego vindo de fora do contêiner. A entrada de Aplicativos de Contêiner fica entre seu aplicativo e o usuário final. Como a entrada atua como um intermediário, tudo o que o usuário final vê termina na entrada, e tudo o que seu aplicativo vê começa na entrada.
A entrada gerencia a terminação TLS e domínios personalizados, eliminando a necessidade de configurá-los manualmente em seu aplicativo. Através da entrada, a porta 443 é exposta para o tráfego HTTPS e, opcionalmente, a porta 80 para o tráfego HTTP. A entrada encaminha solicitações para seu aplicativo na porta de destino.
Se seu aplicativo precisar de metadados sobre a solicitação original, ele poderá usar cabeçalhos encaminhados pelo X.
Para saber mais, consulte Entrada HTTP em Aplicativos de Contêiner do Azure.
Definir uma porta de destino
Para receber tráfego, a entrada é configurada em uma porta de destino onde seu aplicativo escuta o tráfego.
Quando o ASP.NET Core está sendo executado em um contêiner, o aplicativo escuta as portas conforme configurado na imagem do contêiner. Quando você usa as imagens oficiais do ASP.NET Core, seu aplicativo é configurado para ouvir HTTP em uma porta padrão. A porta padrão depende da versão ASP.NET Core.
| Runtime | Porta de destino |
|---|---|
| ASP.NET Core 7 e anteriores | 80 |
| ASP.NET Core 8 e posterior | 8080 |
Ao configurar a entrada, defina a porta de destino como o número correspondente à imagem do contêiner que você está usando.
Definir X-forwarded headers
À medida que a entrada lida com a solicitação HTTP original, seu aplicativo vê a entrada como o cliente. Há algumas situações em que seu aplicativo precisa saber o endereço IP do cliente original ou o protocolo original (HTTP ou HTTPS). Você pode acessar o protocolo e as informações de IP através do cabeçalho da X-Forwarded-* solicitação.
Você pode ler os valores originais desses cabeçalhos acessando o ForwardedHeaders objeto.
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
options.KnownNetworks.Clear();
options.KnownProxies.Clear();
});
Para obter mais informações sobre como trabalhar com cabeçalhos de solicitação, consulte Configurar ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga.
Crie aplicativos .NET nativos da nuvem
Os aplicativos implantados em aplicativos de contêiner geralmente funcionam melhor quando você se baseia nos princípios nativos da nuvem. As seções a seguir ajudam a detalhar preocupações comuns em torno de aplicativos nativos da nuvem.
Configuração da aplicação
Ao implantar seu aplicativo .NET em Aplicativos de Contêiner do Azure, use variáveis de ambiente para armazenar informações de configuração em vez de usar appsettings.json. Essa prática permite que você configure seu aplicativo de diferentes maneiras em diferentes ambientes. Além disso, o uso de variáveis de ambiente facilita o gerenciamento de valores de configuração sem a necessidade de reconstruir e reimplantar sua imagem de contêiner.
Nos Aplicativos de Contêiner do Azure, você define variáveis de ambiente ao definir o contêiner do seu aplicativo ou trabalho. Armazene valores confidenciais em segredos e faça referência a eles como variáveis de ambiente. Para saber mais sobre como gerenciar segredos, consulte Gerenciar segredos em Aplicativos de Contêiner do Azure.
Identidade gerida
Os Aplicativos de Contêiner do Azure dão suporte à identidade gerenciada, o que permite que seu aplicativo acesse outros serviços do Azure sem precisar trocar credenciais. Para saber mais sobre a comunicação segura entre os serviços do Azure, consulte Identidades gerenciadas em Aplicativos de Contêiner do Azure.
Registo
Em um ambiente nativo da nuvem, o registro em log é crucial para monitorar e solucionar problemas de seus aplicativos. Por padrão, os Aplicativos de Contêiner do Azure usam o Azure Log Analytics para coletar logs de seus contêineres. Você pode configurar outros provedores de log. Para saber mais sobre o registo de aplicações, consulte Opções de armazenamento e monitorização de registos em Aplicações de Contentor do Azure.
Quando você configura um provedor de log que grava logs no console, os Aplicativos de Contêiner do Azure coletam e armazenam mensagens de log para você.
Sondas do estado de funcionamento
Os Aplicativos de Contêiner do Azure incluem suporte interno para testes de integridade, que permitem monitorar a integridade de seus aplicativos. Se uma sonda determinar que seu aplicativo está em um estado não íntegro, seu contêiner será reiniciado automaticamente. Para saber mais sobre testes de integridade, consulte Sondas de integridade em Aplicativos de Contêiner do Azure.
Para ter a chance de implementar uma lógica personalizada para determinar a integridade do seu aplicativo, você pode configurar um ponto de extremidade de verificação de integridade. Para saber mais sobre pontos de extremidade de verificação de integridade, consulte Verificações de integridade no ASP.NET Core.
Considerações sobre dimensionamento automático
Por padrão, os Aplicativos de Contêiner do Azure dimensionam automaticamente seus aplicativos ASP.NET Core com base no número de solicitações HTTP de entrada. Você também pode configurar regras personalizadas de dimensionamento automático com base em outras métricas, como uso de CPU ou memória. Para saber mais sobre dimensionamento, consulte Definir regras de dimensionamento em Aplicativos de Contêiner do Azure.
No .NET 8.0.4 e posterior, os aplicativos ASP.NET Core que usam proteção de dados são configurados automaticamente para manter os dados protegidos acessíveis a todas as réplicas à medida que o aplicativo é dimensionado. Quando seu aplicativo começa a ser dimensionado, um gerenciador de chaves lida com as chaves de gravação e compartilhamento em várias revisões. À medida que o aplicativo é implantado, a variável autoConfigureDataProtection de ambiente é definida true automaticamente para habilitar esse recurso. Para obter mais informações sobre essa configuração automática, consulte esta solicitação pull do GitHub.
O dimensionamento automático altera o número de réplicas do seu aplicativo com base nas regras definidas. Por padrão, os Aplicativos de Contêiner roteiam aleatoriamente o tráfego de entrada para as réplicas do seu aplicativo ASP.NET Core. Como o tráfego pode ser dividido entre réplicas diferentes, seu aplicativo deve ser sem monitoração de estado para que seu aplicativo não enfrente problemas relacionados ao estado.
Recursos como antifalsificação, autenticação, SignalR, Blazor Server e Razor Pages dependem da proteção de dados e exigem configuração extra para funcionar corretamente ao dimensionar para várias réplicas.
Configurar a proteção de dados
ASP.NET Core tem recursos especiais para proteger e desproteger dados, como dados de sessão e tokens antifalsificação. Por padrão, as chaves de proteção de dados são armazenadas no sistema de arquivos, o que não é adequado para um ambiente nativo da nuvem.
Se você estiver implantando um aplicativo .NET Aspire , a proteção de dados será configurada automaticamente para você. Em todas as outras situações, você precisa configurar a proteção de dados manualmente.
Configurar ASP.NET Core SignalR
ASP.NET Core SignalR requer um backplane para distribuir mensagens para várias réplicas de servidor. Ao implantar seu aplicativo ASP.NET Core com SignalR em Aplicativos de Contêiner do Azure, você deve configurar um dos backplanes suportados, como o Serviço Azure SignalR ou Redis. Para saber mais sobre backplanes, consulte ASP.NET hospedagem e dimensionamento do Core SignalR.
Configurar o Blazor Server
ASP.NET estado de armazenamento dos aplicativos do Core Blazor Server no servidor, o que significa que cada cliente deve estar conectado à mesma réplica do servidor durante a sessão. Ao implantar seu aplicativo Blazor Server em Aplicativos de Contêiner do Azure, você deve habilitar sessões adesivas para garantir que os clientes sejam roteados para a mesma réplica. Para saber mais, consulte Afinidade de sessão em aplicativos de contêiner do Azure.