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.

Nota

As sessões dinâmicas dos Aplicativos de Contêiner do Azure estão atualmente em visualização.

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.

Identificadores de sessão

Ao interagir com sessões em um pool, você deve definir um identificador de sessão para gerenciar cada sessão. 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. Este identificador é um elemento-chave para determinar o comportamento da sessão:

• Reutilização de sessões existentes: esta sessão é reutilizada se já existir uma sessão em execução que corresponda ao identificador.
• Alocação de novas sessões: Se nenhuma sessão em execução corresponder ao identificador, uma nova sessão será automaticamente alocada do pool.

O identificador de sessão é uma cadeia de caracteres que você define que é exclusiva dentro do pool de sessões. Se estiver a criar uma aplicação Web, pode utilizar o ID do utilizador. 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 .>

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.

Para sessões de interpretador de código, você também pode usar uma integração com uma 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 que tenha as atribuições de função necessárias no pool de sessões.

Protegendo identificadores de sessão

O identificador de sessão é uma informação confidencial que requer um processo seguro à medida que você cria e gerencia seu valor. Para proteger esse valor, seu aplicativo deve 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

A autenticação é tratada usando tokens do Microsoft Entra (anteriormente Azure Ative Directory). Os tokens válidos do Microsoft Entra são gerados por uma identidade pertencente às funções Executor de Sessão e Colaborador do Azure ContainerApps no pool de sessões.

Para atribuir as funções a uma identidade, use os seguintes comandos da CLI do Azure:

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

az role assignment create \
    --role "Contributor" \
    --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.

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.

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

As sessões dinâmicas dos Aplicativos de Contêiner do Azure estão atualmente em visualização. Aplicam-se as seguintes limitações:

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

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

• Não há suporte para registro em log. Seu aplicativo pode registrar solicitações na API de gerenciamento do pool de sessões e suas respostas.

Próximos passos

Sessões de intérprete de código