Partager via

Sessions de conteneur personnalisées Azure Container Apps (préversion)

  • Article

Outre l’interpréteur de code intégré fourni par les sessions dynamiques Azure Container Apps, vous pouvez également utiliser des conteneurs personnalisés pour définir vos propres bacs à sable de session.

Remarque

Les sessions dynamiques Azure Container Apps sont actuellement en préversion. Pour plus d’informations, consultez les limitations de la préversion .

Utilisations pour les sessions de conteneur personnalisées

Les conteneurs personnalisés vous permettent de créer des solutions adaptées à vos besoins. Ils vous permettent d’exécuter du code ou des applications dans des environnements rapides et éphémères et offrent des espaces bac à sable sécurisés avec Hyper-V. En outre, ils peuvent être configurés avec une isolation réseau facultative. Voici quelques exemples :

  • Interpréteurs de code : quand vous devez exécuter du code non approuvé dans des bacs à sable sécurisés par un langage non pris en charge dans l’interpréteur intégré, ou si vous avez besoin d’un contrôle total sur l’environnement de l’interpréteur de code.

  • Exécution isolée : Lorsque vous devez exécuter des applications dans des scénarios hostiles et multi-locataires dans lesquels chaque locataire ou utilisateur dispose de son propre environnement sandbox. Ces environnements sont isolés les uns des autres et de l’application hôte. Voici quelques exemples d’applications qui exécutent du code fourni par l’utilisateur, du code qui accorde à l’utilisateur final l’accès à un interpréteur de commandes cloud, des agents d’IA et des environnements de développement.

Utilisation de sessions de conteneur personnalisées

Pour utiliser des sessions de conteneur personnalisées, vous créez d’abord un pool de sessions avec une image conteneur personnalisée. Azure Container Apps démarre automatiquement les conteneurs dans leurs propres bacs à sable Hyper-V à l’aide de l’image fournie. Une fois le conteneur démarré, il est disponible pour le pool de sessions.

Lorsque votre application demande une session, une instance est allouée instantanément à partir du pool. La session reste active jusqu’à ce qu’elle entre dans un état inactif, qui est ensuite automatiquement arrêté et détruit.

Création d’un pool de sessions de conteneur personnalisé

Pour créer un pool de sessions de conteneur personnalisé, vous devez fournir des paramètres de configuration d’image de conteneur et de pool.

Vous appelez ou communiquez avec chaque session à l’aide de requêtes HTTP. Le conteneur personnalisé doit exposer un serveur HTTP sur un port que vous spécifiez pour répondre à ces requêtes.

Pour créer un pool de sessions de conteneur personnalisé à l’aide d’Azure CLI, assurez-vous de disposer des dernières versions d’Azure CLI et de l’extension Azure Container Apps avec les commandes suivantes :

az upgrade
az extension add --name containerapp --upgrade --allow-preview true -y

Les pools de sessions de conteneur personnalisés nécessitent un profil de charge de travail activé pour l’environnement Azure Container Apps. Si vous n’avez pas d’environnement, utilisez la commande az containerapp env create -n <ENVIRONMENT_NAME> -g <RESOURCE_GROUP> --location <LOCATION> --enable-workload-profiles pour en créer un.

Utilisez la commande az containerapp sessionpool create pour créer un pool de sessions de conteneur personnalisé.

L’exemple suivant crée un pool de sessions nommé my-session-pool avec une image conteneur personnalisée myregistry.azurecr.io/my-container-image:1.0.

Avant d’envoyer la demande, remplacez les espaces réservés entre crochets <> par les valeurs appropriées pour votre pool de sessions et l’identificateur de session.

az containerapp sessionpool create \
    --name my-session-pool \
    --resource-group <RESOURCE_GROUP> \
    --environment <ENVIRONMENT> \
    --registry-server myregistry.azurecr.io \
    --registry-username <USER_NAME> \
    --registry-password <PASSWORD> \
    --container-type CustomContainer \
    --image myregistry.azurecr.io/my-container-image:1.0 \ 
    --cpu 0.25 --memory 0.5Gi \
    --target-port 80 \
    --cooldown-period 300 \
    --network-status EgressDisabled \
    --max-sessions 10 \
    --ready-sessions 5 \
    --env-vars "key1=value1" "key2=value2"

Cette commande crée un pool de sessions avec les paramètres suivants :

Paramètre active Description
--name my-session-pool Nom du pool de sessions.
--resource-group my-resource-group Groupe de ressources qui contient le pool de sessions.
--environment my-environment Nom ou ID de ressource de l’environnement de l’application conteneur.
--container-type CustomContainer Type de conteneur du pool de sessions. Doit être CustomContainer pour les sessions de conteneur personnalisées.
--image myregistry.azurecr.io/my-container-image:1.0 Image conteneur à utiliser pour le pool de sessions.
--registry-server myregistry.azurecr.io Nom d’hôte du serveur de registre de conteneurs.
--registry-username my-username Nom d’utilisateur à connecter au registre de conteneurs.
--registry-password my-password Mot de passe à connecter au registre de conteneurs.
--cpu 0.25 Le CPU requis en cœurs.
--memory 0.5Gi Mémoire requise.
--target-port 80 Port de session utilisé pour le trafic d’entrée.
--cooldown-period 300 Nombre de secondes pendant lesquelles une session peut être inactive avant la fin de la session. La période d’inactivité est réinitialisée chaque fois que l’API de la session est appelée. La valeur doit être comprise entre 300 et 3600.
--network-status Indique si le trafic réseau sortant est autorisé à partir de la session. Les valeurs valides sont EgressDisabled (valeur par défaut) et EgressEnabled.
--max-sessions 10 Nombre maximal de sessions qui peuvent être allouées en même temps.
--ready-sessions 5 Nombre cible de sessions prêtes dans le pool de sessions à tout moment. Augmentez ce nombre si les sessions sont allouées plus rapidement que le pool est réapprovisionné.
--env-vars "key1=value1" "key2=value2" Variables d’environnement à définir dans le conteneur.

Pour mettre à jour le pool de sessions, utilisez la commande az containerapp sessionpool update.

Important

Si la session est utilisée pour exécuter du code non approuvé, n’incluez pas d’informations ou de données auxquelles vous ne souhaitez pas que le code non approuvé accède. Supposons que le code est malveillant et dispose d’un accès complet au conteneur, y compris ses variables d’environnement, secrets et fichiers.

Utilisation des sessions

Votre application interagit avec une session à l’aide de l’API de gestion du pool de sessions.

Un point de terminaison de gestion de pool pour les sessions de conteneur personnalisées suit ce format : https://<SESSION_POOL>.<ENVIRONMENT_ID>.<REGION>.azurecontainerapps.io.

Pour récupérer le point de terminaison de gestion du pool de sessions, utilisez la commande az containerapp sessionpool show :

az containerapp sessionpool show \
    --name <SESSION_POOL_NAME> \
    --resource-group <RESOURCE_GROUP> \
    --query "properties.poolManagementEndpoint" \
    --output tsv

Toutes les demandes adressées au point de terminaison de gestion du pool doivent inclure un en-tête Authorization avec un jeton du porteur. Pour savoir comment s’authentifier auprès de l’API de gestion de pool, consultez d’authentification.

Chaque requête d’API doit également inclure le paramètre de chaîne de requête identifier avec l’ID de session. Cet ID de session unique permet à votre application d’interagir avec des sessions spécifiques. Pour en savoir plus sur les identificateurs de session, consultez identificateurs de session.

Important

L’identificateur de session est une information sensible qui nécessite un processus sécurisé lorsque vous créez et gérez sa valeur. Pour protéger cette valeur, votre application doit s’assurer que chaque utilisateur ou locataire a uniquement accès à ses propres sessions. La non-sécurisation de l’accès aux sessions peut entraîner une mauvaise utilisation ou un accès non autorisé aux données stockées dans les sessions de vos utilisateurs. Pour plus d’informations, consultez Identificateurs de session.

Transfert de requêtes au conteneur de la session :

Tout ce qui se trouve dans le chemin après le point de terminaison de gestion de pool de base est transféré au conteneur de la session.

Par exemple, si vous appelez <POOL_MANAGEMENT_ENDPOINT>/api/uploadfile, la requête est acheminée vers le conteneur de la session sur 0.0.0.0:<TARGET_PORT>/api/uploadfile.

Interaction continue avec la session :

Vous pouvez continuer à adresser des requêtes à la même session. Si aucune requête n’est adressée à la session pendant une période plus longue que la période de refroidissement, la session est automatiquement supprimée.

Exemple de requête

L'exemple suivant montre une demande adressée à une session de conteneur personnalisée par un ID utilisateur.

Avant d’envoyer la demande, remplacez les espaces réservés entre crochets <> par les valeurs propres à votre demande.

POST https://<SESSION_POOL_NAME>.<ENVIRONMENT_ID>.<REGION>.azurecontainerapps.io/<API_PATH_EXPOSED_BY_CONTAINER>?identifier=<USER_ID>
Authorization: Bearer <TOKEN>
{
  "command": "echo 'Hello, world!'"
}

Cette demande est transmise à la session du conteneur personnalisé avec l'identifiant de l'ID de l'utilisateur. Si la session n’est pas déjà en cours d’exécution, Azure Container Apps alloue une session à partir du pool avant de transférer la demande.

Dans l’exemple, le conteneur de la session reçoit la requête à http://0.0.0.0:<INGRESS_PORT>/<API_PATH_EXPOSED_BY_CONTAINER>.

Étapes suivantes

Présentation des sessions dynamiques Azure Container Apps