Azure Container Apps

O Azure Container Apps (ACA) é um serviço de hospedagem de contêineres sem servidor totalmente gerenciado, criado sobre o Kubernetes e o KEDA (dimensionamento automático orientado por eventos do Kubernetes). Diferentemente do AKS, você não gerencia diretamente o plano de controle, os pools de nós ou os manifestos do Kubernetes. Em vez disso, você implanta contêineres usando uma CLI simples ou uma definição YAML, e o Azure cuida de toda a orquestração. O ACA é ideal para microsserviços, backends de API, trabalhadores orientados por eventos e tarefas de processamento em segundo plano que precisam ser dimensionados dinamicamente, inclusive com dimensionamento para zero.

Um ambiente do Container Apps é o limite isolado dentro do qual um ou mais aplicativos Container Apps são executados. Todos os aplicativos em um ambiente compartilham a mesma rede virtual e o mesmo espaço de trabalho do Log Analytics. Os ambientes têm como escopo uma região e um grupo de recursos. Você pode implantar vários ambientes para isolar equipes ou estágios (produção e preparação). Opcionalmente, um ambiente pode ser injetado em uma VNet na sua própria rede virtual, permitindo a comunicação privada entre aplicativos Container Apps e outros serviços do Azure sem passar pela internet pública.

Para implantar um aplicativo Container Apps, você especifica a imagem do contêiner (do Azure Container Registry ou de qualquer registro público), o número de réplicas e as variáveis de ambiente. O aplicativo fica acessível publicamente por meio de uma URL HTTPS gerada automaticamente se você habilitar a entrada externa. A configuração de entrada inclui a porta de destino, a divisão de tráfego para implantações azul-verde e se deve permitir somente HTTP ou HTTPS. O ACA obtém a imagem no momento da implantação; o ambiente precisa ter permissões de leitura no registro.

O Container Apps é dimensionado usando escaladores do KEDA que são acionados com base em métricas externas. Entre os escaladores integrados do KEDA estão: tráfego HTTP (solicitações simultâneas por réplica), profundidade da fila do Azure Service Bus (mensagens aguardando), Azure Storage Queue, Cron (baseado em horário) e CPU/Memória. Quando a métrica do escalador chega a zero e minReplicas está definido como 0, o Container Apps faz o dimensionamento para zero — sem custo de computação até que novas solicitações cheguem. O dimensionamento para zero é excelente para trabalhadores orientados por eventos com cargas de trabalho esporádicas.

O Dapr (Runtime de Aplicativos Distribuídos) é um runtime portátil e orientado por eventos que simplifica a criação de microsserviços. O Container Apps oferece integração nativa com o Dapr — você a habilita por aplicativo com um único sinalizador. O Dapr fornece blocos de construção para: invocação de serviços (com nova tentativa e mTLS), mensagens de publicação/assinatura (abstraindo Service Bus e Event Hubs), gerenciamento de estado (abstraindo Redis e Cosmos DB) e vinculações de saída. Com o Dapr, os microsserviços se comunicam por meio do sidecar do Dapr sem conhecer os detalhes da infraestrutura subjacente.

Cada implantação em um aplicativo Container Apps cria uma nova revisão. No modo de várias revisões, você pode dividir o tráfego entre revisões para implantações azul-verde ou canário. Por exemplo, envie 10% do tráfego para uma nova revisão e 90% para a revisão estável atual. Monitore as taxas de erro e a latência da nova revisão antes de aumentar o peso do tráfego para 100%. Revisões antigas podem ser desativadas, mas são mantidas no histórico, permitindo uma reversão instantânea ao transferir o peso do tráfego de volta.

O Container Apps oferece duas formas de injetar configurações: variáveis de ambiente (para configurações não confidenciais, como sinalizadores de recursos ou URLs de API) e segredos (para valores confidenciais, como cadeias de conexão). Os segredos são armazenados no nível do aplicativo Container Apps e referenciados por variáveis de ambiente ou componentes do Dapr. Para a configuração mais segura, faça referência a segredos do Azure Key Vault usando uma identidade gerenciada, para que o valor do segredo seja obtido em tempo de execução e nunca seja armazenado no plano de configuração do aplicativo Container Apps.

Container Apps Jobs estende a plataforma para oferecer suporte a cargas de trabalho executadas até a conclusão — contêineres que são iniciados, executam uma tarefa e são encerrados. Os Jobs oferecem três tipos de acionamento: Manual (acionado por meio da API ou da CLI), Agendado (expressão cron) e Orientado por eventos (o escalonador KEDA aciona cada execução). Os Jobs são cobrados apenas pelo tempo real de execução e são ideais para processamento em lote, geração de relatórios, migrações de banco de dados e pipelines de inferência de ML executados periodicamente ou em resposta a eventos.

Container Apps envia logs do sistema (eventos da plataforma, como criação de revisão e escalabilidade) e logs do console (a saída stdout/stderr da sua aplicação) para o espaço de trabalho do Log Analytics anexado ao ambiente. Consulte os logs com KQL: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. As métricas do Azure Monitor integradas incluem a contagem de réplicas, a contagem de solicitações, a latência das solicitações e a utilização de CPU/memória por réplica — tudo disponível no portal do Azure sem nenhuma configuração adicional.

Escolha a plataforma de contêineres do Azure adequada: Container Apps é ideal para microsserviços, trabalhadores orientados por eventos e APIs quando você deseja os benefícios do Kubernetes sem gerenciar o cluster — especialmente quando a redução a zero é valiosa. AKS é ideal quando você precisa de controle total do Kubernetes, operadores personalizados ou configurações específicas de nós (GPU, memória alta). App Service é ideal para aplicações web tradicionais e APIs quando a equipe de desenvolvimento prefere um modelo PaaS simples, sem a sobrecarga de gerenciamento de contêineres. Os três oferecem suporte a contêineres; a diferença está no equilíbrio entre complexidade de gerenciamento e controle.

Container Apps oferece suporte a dois modos de entrada: Externa (acessível publicamente por meio de um ponto de extremidade HTTPS com balanceamento de carga e TLS automático) e Interna (acessível somente de dentro do mesmo ambiente do Container Apps ou a partir de recursos emparelhados à VNet). A entrada interna é usada para serviços de backend que nunca devem ser expostos à internet. Os Apps podem chamar uns aos outros usando o nome DNS interno gerado automaticamente http://myapi dentro do mesmo ambiente, permitindo uma comunicação simples entre serviços sem implantar um gateway de API.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que Azure Container Apps oferece hospedagem de contêineres sem servidor, baseada em Kubernetes e KEDA, sem gerenciamento de cluster; os escalonadores KEDA permitem a redução a zero com base na profundidade da fila, no tráfego HTTP ou em agendamentos cron; e a integração com Dapr simplifica a comunicação entre microsserviços e o gerenciamento de estado. A seguir, conectaremos tudo em um fluxo de trabalho completo de desenvolvimento de ponta a ponta.