Compartir a través de


Información general sobre las sesiones dinámicas de Azure Container Apps

Las sesiones dinámicas de Azure Container Apps proporcionan acceso rápido a entornos de espacio aislado seguros que son ideales para ejecutar código o aplicaciones que requieren un aislamiento seguro de otras cargas de trabajo.

Las sesiones tienen los atributos siguientes:

  • Aislamiento sólido: las sesiones están aisladas entre sí y del entorno del host. Cada sesión se ejecuta en su propio espacio aislado de Hyper-V, lo que proporciona seguridad y aislamiento de nivel empresarial. Opcionalmente, puedes habilitar el aislamiento de red para mejorar aún más la seguridad.

  • Acceso sencillo: se accede a las sesiones mediante una API REST. Un identificador único marca cada sesión. Si no existe una sesión con un identificador determinado, se asigna automáticamente una nueva sesión.

  • Totalmente administrado: la plataforma administra completamente el ciclo de vida de una sesión. Las sesiones se limpian automáticamente cuando ya no están en uso.

  • Inicio rápido: una nueva sesión tarda milisegundos en asignarse. Los inicios rápidos se logran manteniendo automáticamente un grupo de sesiones listas pero sin asignar.

  • Escalable: las sesiones se pueden ejecutar a gran escala. Puedes ejecutar cientos o miles de sesiones simultáneamente.

Tipos de sesión

Azure Container Apps admite dos tipos de sesiones:

Tipo Descripción Modelo de facturación
Intérprete de código Intérprete de código totalmente administrado Por sesión (consumo)
Contenedor personalizado Traiga su propio contenedor Plan dedicado de Container Apps

Intérprete de código

Las sesiones de intérprete de código permiten ejecutar código en un espacio aislado preinstalado con bibliotecas populares. Son ideales para ejecutar código que no es de confianza, como el código que proporcionan los usuarios de la aplicación o el código que genera un modelo de lenguaje grande (LLM). Obtén más información sobre las sesiones de intérprete de código.

Contenedor personalizado

Las sesiones de contenedor personalizadas permiten ejecutar tus propias imágenes de contenedor en espacios aislados y seguros. Puedes usarlas a fin de ejecutar un intérprete de código personalizado para un lenguaje que no se admite de manera predeterminada o para ejecutar cargas de trabajo que requieren un aislamiento seguro. Obtén más información sobre las sesiones de contenedor personalizadas

Conceptos

Los conceptos clave de las sesiones dinámicas de Azure Container Apps son grupos de sesiones y sesiones.

Grupos de sesiones

Para proporcionar tiempos de asignación de sesiones secundarias, Azure Container Apps mantiene un grupo de sesiones listas pero sin asignar. Al enviar una solicitud a una nueva sesión, la plataforma te asigna una sesión del grupo. A medida que se asignan las sesiones, la plataforma reabastece automáticamente el grupo para mantener un número constante de sesiones listas.

Puedes configurar grupos para establecer el número máximo de sesiones que se pueden asignar simultáneamente mediante la propiedad maxConcurrentSessions. Puedes establecer la duración de espera de la última solicitud antes de que se elimine la propiedad cooldownPeriodInSeconds. En el caso de las sesiones de contenedor personalizadas, también puedes especificar la imagen de contenedor y la configuración que se usarán para las sesiones del grupo, incluido el número de sesiones de destino que se mantendrán listas en el grupo mediante readySessionInstances.

Sesiones

Una sesión es un entorno de espacio aislado que ejecuta el código o la aplicación. Cada sesión está aislada de otras sesiones y del entorno de host con un espacio aislado de Hyper-V. Opcionalmente, puedes habilitar el aislamiento de red para mejorar aún más la seguridad.

Puede interactuar con las sesiones de un grupo de sesiones mediante el envío de solicitudes HTTP. Cada grupo de sesiones tiene un punto de conexión de administración del grupo único.

En el caso de las sesiones de intérprete de código, también puedes usar una integración con un marco de LLM.

Identificadores de sesión

Para enviar una solicitud HTTP a una sesión, debe proporcionar un identificador de sesión en la solicitud. El identificador de sesión se pasa en un parámetro de consulta denominado identifier en la dirección URL al realizar una solicitud a una sesión.

  • Si ya existe una sesión con el identificador, la solicitud se envía a la sesión existente.
  • Si no existe una sesión con el identificador, se asigna automáticamente una nueva sesión antes de que se le envíe la solicitud.

Recorte de pantalla del uso del grupo de sesiones y de las sesiones.

Formato del identificador

El identificador de sesión es una cadena de forma libre, lo que significa que puedes definirlo de cualquier manera que se adapte a las necesidades de la aplicación.

El identificador de sesión es una cadena que defines que es única dentro del grupo de sesiones. Si va a crear una aplicación web, puede usar el identificador del usuario como identificador de sesión. Si vas a crear un bot de chat, puedes usar el identificador de conversación.

El identificador debe ser una cadena de 4 a 128 caracteres de longitud y solo puede contener caracteres alfanuméricos y caracteres especiales de esta lista: |, -, &, ^, %, $, #, (, ), {, }, [, ], ;, < y >.

Protección de Identificadores de sesión

El identificador de sesión es información confidencial que debe administrar de forma segura. La aplicación debe asegurarse de que cada usuario o inquilino solo tenga acceso a sus propias sesiones.

Las estrategias específicas que impiden el uso incorrecto de los identificadores de sesión difieren en función del diseño y la arquitectura de la aplicación. Sin embargo, la aplicación siempre debe tener un control completo sobre la creación y el uso de identificadores de sesión para que un usuario malintencionado no pueda acceder a la sesión de otro usuario.

Entre las estrategias de ejemplo se incluyen:

  • Una sesión por usuario: si la aplicación usa una sesión por usuario, cada usuario debe autenticarse de forma segura y la aplicación debe usar un identificador de sesión único para cada usuario que haya iniciado sesión.
  • Una sesión por conversación de agente: si la aplicación usa una sesión por conversación del agente de IA, asegúrese de que la aplicación usa un identificador de sesión único para cada conversación que el usuario final no pueda modificar.

Importante

Si no se protege el acceso a las sesiones, se puede producir un acceso incorrecto o no autorizado a los datos almacenados en las sesiones de los usuarios.

Autenticación y autorización

Al enviar solicitudes a una sesión mediante la API de administración del grupo, la autenticación se controla mediante tokens de Microsoft Entra (anteriormente Azure Active Directory). Solo los tokens de Microsoft Entra de una identidad que pertenezca al rol Ejecutor de sesión de Azure ContainerApps en el grupo de sesiones están autorizados para llamar a la API de administración del grupo.

Para asignar el rol a una identidad, use el siguiente comando de la CLI de Azure:

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

Si usas una integración del marco de LLM, el marco controla automáticamente la generación y administración de tokens. Asegúrate de que la aplicación está configurada con una identidad administrada con las asignaciones de roles necesarias en el grupo de sesiones.

Si usas directamente los puntos de conexión de la API de administración del grupo, debes generar un token e incluirlo en el encabezado Authorization de las solicitudes HTTP. Además de las asignaciones de roles mencionadas anteriormente, el token debe contener una notificación de audiencia (aud) con el valor https://dynamicsessions.io.

Para generar un token mediante la CLI de Azure, ejecuta el siguiente comando:

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

Importante

Se puede usar un token válido para crear y acceder a cualquier sesión del grupo. Mantén los tokens seguros y no los compartas con partes que no sean de confianza. Los usuarios finales deben acceder a las sesiones mediante la aplicación, no directamente. Nunca deben tener acceso a los tokens usados para autenticar las solicitudes en el grupo de sesiones.

Ciclo de vida

El runtime de Container Apps administra automáticamente el ciclo de vida de cada sesión de un grupo de sesiones.

  • Pendiente: cuando se inicia una sesión, se encuentra en estado pendiente. El periodo de tiempo que una sesión pasa en estado pendiente depende de la imagen de contenedor y la configuración que especifiques para el grupo de sesiones. No se agrega una sesión pendiente al grupo de sesiones listas.

  • Lista: cuando una sesión termina de iniciarse y está lista, se agrega al grupo. La sesión está disponible en este estado para la asignación. En el caso de las sesiones de contenedor personalizadas, puedes especificar el número objetivo de sesiones listas para mantenerse en el grupo. Aumenta este número si las sesiones se asignan más rápido de lo que el grupo se reabastece.

  • Asignada: cuando se envía una solicitud a una sesión que no se ejecuta, el grupo proporciona una nueva sesión y la coloca en un estado asignado. Las solicitudes posteriores con el mismo identificador de sesión se enrutan a la misma sesión.

  • Eliminando: cuando una sesión deja de recibir solicitudes durante el tiempo que define la configuración de cooldownPeriodInSeconds, la sesión y su espacio aislado de Hyper-V se eliminan completamente y de forma segura.

Seguridad

Las sesiones dinámicas de Azure Container Apps se crean para ejecutar aplicaciones y código que no son de confianza en un entorno seguro y aislado. Aunque las sesiones están aisladas entre sí, los usuarios de la sesión pueden acceder a todo en una sola sesión, incluidos los archivos y las variables de entorno. Solo debes configurar o cargar datos confidenciales en una sesión si confías en los usuarios de la sesión.

De manera predeterminada, se impide que las sesiones realicen solicitudes de red salientes. Puede controlar el acceso de red mediante la configuración del estado de red en el grupo de sesiones.

Además, siga las instrucciones de la sección de autenticación y autorización para asegurarse de que solo los usuarios autorizados pueden acceder a las sesiones y las de la sección sobre cómo proteger los identificadores de sesión para asegurarse de que los identificadores de sesión son seguros.

Limitaciones de vista previa

Las siguientes limitaciones se aplican a las sesiones dinámicas:

  • Actualmente solo está disponible en las siguientes regiones:

    Region Intérprete de código Contenedor personalizado
    Este de Australia
    EUAP del centro de EE. UU.
    EUAP de Este de EE. UU. 2
    Este de EE. UU.
    Este de Asia
    Centro-oeste de Alemania
    Norte de Italia
    Centro-Norte de EE. UU -
    Centro de Polonia
    Norte de Suiza
    Centro-Oeste de EE. UU.
    Oeste de EE. UU. 2

Pasos siguientes