Visão geral das sessões dinâmicas dos Aplicativos de Contêiner do Azure

As sessões dinâmicas do Azure Container Apps fornecem acesso rápido a ambientes sandbox seguros que são ideais para executar código ou aplicações que requerem um forte isolamento de outras cargas de trabalho.

As sessões têm os seguintes atributos:

• Isolamento forte: as sessões são isoladas umas das outras e do ambiente host. Cada sessão é executada em sua própria área restrita do Hyper-V, fornecendo segurança e isolamento de nível empresarial. Opcionalmente, você pode habilitar o isolamento de rede para aumentar ainda mais a segurança.

• Acesso simples: as sessões são acessadas por meio de uma API REST. Um identificador exclusivo marca cada sessão. Se uma sessão com um determinado identificador não existir, uma nova sessão será automaticamente alocada.

• Totalmente gerenciado: a plataforma gerencia totalmente o ciclo de vida de uma sessão. As sessões são limpas automaticamente quando não estão mais em uso.

• Arranque rápido: uma nova sessão é alocada em milissegundos. O arranque rápido é conseguido através da manutenção automática de um conjunto de sessões prontas, mas não alocadas.

• Escalável: as sessões podem ser executadas em alta escala. Você pode executar centenas ou milhares de sessões simultaneamente.

Tipos de sessão

Os Aplicativos de Contêiner do Azure dão suporte a dois tipos de sessões:

Tipo	Description	Modelo de faturação
Interpretador de código	Interpretador de código totalmente gerenciado	Por sessão (consumo)
Contentor personalizado	Traga o seu próprio recipiente	Plano Dedicado de Aplicativos de Contêiner

Interpretador de código

As sessões do interpretador de código permitem executar código em uma área restrita pré-instalada com bibliotecas populares. Eles são ideais para executar código não confiável, como código fornecido por usuários do seu aplicativo ou código gerado por um modelo de linguagem grande (LLM). Saiba mais sobre sessões de interpretadores de código.

Contentor personalizado

As sessões de contêiner personalizadas permitem que você execute suas próprias imagens de contêiner em caixas de proteção seguras e isoladas. Você pode usá-los para executar um interpretador de código personalizado para um idioma que não é suportado pronto para uso ou para executar cargas de trabalho que exigem um isolamento forte. Saiba mais sobre sessões de contêiner personalizadas.

Conceitos

Os principais conceitos nas sessões dinâmicas dos Aplicativos de Contêiner do Azure são pools de sessões e sessões.

Pools de sessões

Para fornecer tempos de alocação de sessão sub-segundo, os Aplicativos de Contêiner do Azure mantêm um pool de sessões prontas, mas não alocadas. Quando você envia uma solicitação para uma nova sessão, a plataforma aloca uma sessão do pool para você. À medida que as sessões são alocadas, a plataforma reabastece automaticamente o pool para manter um número constante de sessões prontas.

Você pode configurar pools para definir o número máximo de sessões que podem ser alocadas simultaneamente por meio da maxConcurrentSessions propriedade. Você pode definir a duração da espera a partir da última solicitação antes que uma sessão seja excluída da cooldownPeriodInSeconds propriedade. Para sessões de contêiner personalizadas, você também pode especificar a imagem de contêiner e as configurações a serem usadas para as sessões no pool, incluindo o número de sessões de destino a serem mantidas prontas no pool via readySessionInstances.

Sessões

Uma sessão é um ambiente em área restrita que executa seu código ou aplicativo. Cada sessão é isolada de outras sessões e do ambiente host com uma área restrita do Hyper-V . Opcionalmente, você pode habilitar o isolamento de rede para aumentar ainda mais a segurança.

Você interage com sessões em um pool de sessões enviando solicitações HTTP. Cada pool de sessões tem um ponto de extremidade exclusivo de gerenciamento de pool.

Para sessões de interpretador de código, você também pode usar uma integração com uma estrutura LLM.

Identificadores de sessão

Para enviar uma solicitação HTTP para uma sessão, você deve fornecer um identificador de sessão na solicitação. Você passa o identificador de sessão em um parâmetro de consulta nomeado identifier na URL quando faz uma solicitação para uma sessão.

• Se já existir uma sessão com o identificador, o pedido é enviado para a sessão existente.
• Se uma sessão com o identificador não existir, uma nova sessão será automaticamente alocada antes que a solicitação seja enviada a ela.

Formato do identificador

O identificador de sessão é uma cadeia de caracteres de forma livre, o que significa que você pode defini-lo de qualquer maneira que atenda às necessidades do seu aplicativo.

O identificador de sessão é uma cadeia de caracteres que você define que é exclusiva dentro do pool de sessões. Se você estiver criando um aplicativo Web, poderá usar o ID do usuário como identificador de sessão. Se você estiver criando um chatbot, poderá usar o ID da conversa.

O identificador deve ser uma cadeia de caracteres com 4 a 128 caracteres e pode conter apenas caracteres alfanuméricos e caracteres especiais desta lista: |, -, &, ^, $)({}#%];[<e .>

Protegendo identificadores de sessão

O identificador de sessão é uma informação confidencial que deve ser gerida de forma segura. Seu aplicativo precisa garantir que cada usuário ou locatário tenha acesso apenas às suas próprias sessões.

As estratégias específicas que evitam o uso indevido de identificadores de sessão diferem dependendo do design e da arquitetura do seu aplicativo. No entanto, seu aplicativo sempre deve ter controle total sobre a criação e o uso de identificadores de sessão para que um usuário mal-intencionado não possa acessar a sessão de outro usuário.

Exemplos de estratégias incluem:

• Uma sessão por usuário: se seu aplicativo usa uma sessão por usuário, cada usuário deve ser autenticado com segurança e seu aplicativo deve usar um identificador de sessão exclusivo para cada usuário conectado.
• Uma sessão por conversa de agente: se seu aplicativo usa uma sessão por conversa de agente de IA, certifique-se de que seu aplicativo use um identificador de sessão exclusivo para cada conversa que não possa ser modificada pelo usuário final.

Importante

A falha em proteger o acesso às sessões pode resultar em uso indevido ou acesso não autorizado aos dados armazenados nas sessões dos usuários.

Autenticação e autorização

Quando você envia solicitações para uma sessão usando a API de gerenciamento de pool, a autenticação é tratada usando tokens do Microsoft Entra (anteriormente Azure Ative Directory). Somente os tokens Microsoft Entra de uma identidade pertencente à função Executor de Sessão do Azure ContainerApps no pool de sessões estão autorizados a chamar a API de gerenciamento do pool.

Para atribuir a função a uma identidade, use o seguinte comando da CLI do Azure:

az role assignment create \
    --role "Azure ContainerApps Session Executor" \
    --assignee <PRINCIPAL_ID> \
    --scope <SESSION_POOL_RESOURCE_ID>

Se você estiver usando uma integração de estrutura LLM, a estrutura lida com a geração e o gerenciamento de tokens para você. Verifique se o aplicativo está configurado com uma identidade gerenciada com as atribuições de função necessárias no pool de sessões.

Se você estiver usando os pontos de extremidade da API de gerenciamento do pool diretamente, deverá gerar um token e incluí-lo no Authorization cabeçalho de suas solicitações HTTP. Além das atribuições de função mencionadas anteriormente, o token precisa conter uma declaração de audiência (aud) com o valor https://dynamicsessions.io.

CLI do Azure

Para gerar um token usando a CLI do Azure, execute o seguinte comando:

az account get-access-token --resource https://dynamicsessions.io

C#

Em C#, você pode usar a Azure.Identity biblioteca para gerar um token. Primeiro, instale a biblioteca:

dotnet add package Azure.Identity

Em seguida, use o seguinte código para gerar um token:

using Azure.Identity;

var credential = new DefaultAzureCredential();
var token = credential.GetToken(new TokenRequestContext(new[] { "https://dynamicsessions.io/.default" }));
var accessToken = token.Token;

JavaScript

Em JavaScript, você pode usar a @azure/identity biblioteca para gerar um token. Primeiro, instale a biblioteca:

npm install @azure/identity

Em seguida, use o seguinte código para gerar um token:

const { DefaultAzureCredential } = require("@azure/identity");
const { TokenCredential } = require("@azure/core-auth");

const credential = new DefaultAzureCredential();
const token = await credential.getToken("https://dynamicsessions.io/.default");
const accessToken = token.token;

Python

Em Python, você pode usar a azure-identity biblioteca para gerar um token. Primeiro, instale a biblioteca:

pip install azure-identity

Em seguida, use o seguinte código para gerar um token:

from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
token = credential.get_token("https://dynamicsessions.io/.default")
access_token = token.token

Importante

Um token válido pode ser usado para criar e acessar qualquer sessão no pool. Mantenha seus tokens seguros e não os compartilhe com partes não confiáveis. Os usuários finais devem acessar as sessões por meio de seu aplicativo, não diretamente. Eles nunca devem ter acesso aos tokens usados para autenticar solicitações no pool de sessões.

Ciclo de vida

O tempo de execução dos Aplicativos de Contêiner gerencia automaticamente o ciclo de vida de cada sessão em um pool de sessões.

• Pendente: quando uma sessão está iniciando, ela está no estado pendente. A quantidade de tempo que uma sessão passa no estado pendente depende da imagem do contêiner e das configurações especificadas para o pool de sessões. Uma sessão pendente não é adicionada ao pool de sessões prontas.

• Pronto: Quando uma sessão termina de iniciar e está pronta, ela é adicionada ao pool. A sessão está disponível neste estado para alocação. Para sessões de contêiner personalizadas, você pode especificar o número de destino de sessões prontas para manter no pool. Aumente esse número se as sessões forem alocadas mais rapidamente do que o pool está sendo reabastecido.

• Alocado: quando você envia uma solicitação para uma sessão não em execução, o pool fornece uma nova sessão e a coloca em um estado alocado. As solicitações subsequentes com o mesmo identificador de sessão são roteadas para a mesma sessão.

• Excluindo: quando uma sessão para de receber solicitações durante o tempo definido pela cooldownPeriodInSeconds configuração, a sessão e sua área restrita do Hyper-V são excluídas completa e seguramente.

Segurança

As sessões dinâmicas dos Aplicativos de Contêiner do Azure são criadas para executar código e aplicativos não confiáveis em um ambiente seguro e isolado. Embora as sessões sejam isoladas umas das outras, qualquer coisa dentro de uma única sessão, incluindo arquivos e variáveis de ambiente, é acessível pelos usuários da sessão. Você só deve configurar ou carregar dados confidenciais para uma sessão se confiar nos usuários da sessão.

Por padrão, as sessões são impedidas de fazer solicitações de rede de saída. Você pode controlar o acesso à rede definindo as configurações de status da rede no pool de sessões.

Além disso, siga as orientações na seção de autenticação e autorização para garantir que apenas usuários autorizados possam acessar sessões e na seção de proteção de identificadores de sessão para garantir que os identificadores de sessão sejam seguros.

Limitações de pré-visualização

As seguintes limitações aplicam-se às sessões dinâmicas:

• Só está disponível nas seguintes regiões:

  País/Região	Interpretador de código	Contentor personalizado
  Leste da Austrália	✔	✔
  E.U.A. Central - EUAP	✔	✔
  E.U.A. Leste 2 - EUAP	✔	✔
  E.U.A. Leste	✔	✔
  Ásia Leste	✔	✔
  Alemanha Centro-Oeste	✔	✔
  Norte da Itália	✔	✔
  E.U.A. Centro-Norte	✔	-
  Polónia Central	✔	✔
  Norte da Suíça	✔	✔
  E.U.A. Centro-Oeste	✔	✔
  E.U.A. Oeste 2	✔	✔

Próximos passos

Sessões de intérprete de código