Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les bacs à sable Azure Container Apps offrent des environnements de calcul rapides, sécurisés et éphémères avec des fonctionnalités intégrées de suspension et de reprise. Les sandboxes sont un type de ressource à part entière (Microsoft.App/SandboxGroups) dans Container Apps, au même titre que les applications, les tâches et les sessions dynamiques.
Important
Pour gérer et créer des bacs à sable, vous avez besoin du rôle Azure Container Apps SandboxGroup Data Owner. Attribuez ce rôle à tous les utilisateurs qui créent et gèrent des bacs à sable.
Les bacs à sable créés pendant la préversion peuvent ne pas être compatibles avec les futures versions et doivent peut-être être recréés.
L’aire d’API pour Python SDK et les commandes CLI Azure Container Apps peuvent changer pendant la préversion.
Créer et gérer des environnements de bac à sable
Vous pouvez créer et gérer des bacs à sable dans le portail Sandboxes ou par programmation à l’aide de Azure Container Apps CLI ou sdk.
Caractéristiques clés des bacs à sable Container Apps
Démarrage inférieur à une seconde : les bacs à sable sont provisionnés à partir de pools prédéfinis pour une disponibilité quasi-instantanée.
Isolation renforcée : chaque bac à sable s’exécute dans son propre environnement cloisonné sécurisé, adapté à l’exécution de code non fiable en toute sécurité.
Échelle à zéro : vous ne payez aucun frais CPU ou mémoire lorsque les bacs à sable sont arrêtés.
Scale-out : Le service peut prendre en charge des milliers de sandbox simultanées à la demande.
Prise en charge des images de conteneur OCI : utilisez l’image publique fournie ou vos propres images de conteneur comme systèmes de fichiers racine de bac à sable.
Suspendre et reprendre : Capturez un instantané complet de l’état, y compris la mémoire et le disque, puis reprenez plus tard avec des temps de restauration inférieurs à la seconde.
Contrôle du cycle de vie : Vous pouvez gérer l’ensemble du cycle de vie du bac à sable, y compris les instantanés d’état, le stockage persistant et les politiques réseau (sortie et entrée).
Quand utiliser des bacs à sable (sandbox)
Utilisez des bacs à sable lorsque vous avez besoin d’environnements de calcul isolés avec un contrôle explicite du cycle de vie, un état persistant ou un accès programmable via SDK.
| Scénario | Utilisez des bacs à sable ? | Pourquoi |
|---|---|---|
| Exécution de code d’IA avec préservation de l’état | Yes | Suspendre entre les tâches, reprendre avec un contexte complet intact |
| Environnements de développement | Yes | Environnements suspendus à la demande qui conservent l’état entre les sessions |
| Flux de travail de l’agent | Yes | Donner aux agents IA des espaces de travail persistants et isolés au-delà des limites des tâches |
| Sessions utilisateur interactives | Yes | Chaque utilisateur obtient son propre environnement de calcul isolé |
| Calcul multilocataire sécurisé | Yes | Isolation renforcée pour exécuter des charges de travail non fiables issues de plusieurs locataires |
| Charges de travail en rafale | Yes | Passer de zéro à des milliers de bacs à sable à la demande |
| Pipelines CI/CD | Yes | Environnements éphémères de compilation et de test qui retombent à zéro lorsqu’ils sont inactifs |
Choisir l’option de calcul adaptée pour Container Apps
Utilisez le tableau suivant pour sélectionner le type de calcul Container Apps qui correspond à votre charge de travail.
| Type de calcul | Idéal pour | Lifecycle | State |
|---|---|---|---|
| Applications | Services de longue durée, API, applications web | Continue | Sans état (magasins d’états externes) |
| Tâches | Tâches exécutées jusqu’à leur terme, traitement par lots | Démarrer → exécuter → terminé | Sans état |
| Sessions dynamiques | Exécution de code managé, scripts générés par LLM | Géré par pool de sessions | Éphémère |
| Bacs à sable | Calcul isolé programmable avec contrôle de cycle de vie | Vous gérez : créer, suspendre, reprendre, supprimer | Avec état (instantanés, volumes) |
Concepts clés
Prerequisites
Pour créer ou gérer des bacs à sable, vous avez besoin de l’attribution de rôle Azure Container Apps SandboxGroup Data Owner. Sans ce rôle, vous ne pouvez pas effectuer d’opérations dans le sandbox. Attribuez ce rôle à l’étendue souhaitée (abonnement Azure ou groupe de ressources Azure) dans le portail Azure ou à l’aide du Azure CLI.
Avant d’exécuter la commande suivante, remplacez les espaces réservés entourés de <> par vos propres valeurs.
az role assignment create \
--assignee "<USER_EMAIL_OR_OBJECT_ID>" \
--role "Container Apps SandboxGroup Data Owner" \
--scope "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>"
Groupes de bacs à sable
Un groupe de bacs à sable est la limite de gestion de niveau supérieur pour les bacs à sable. Il s'agit d'une ressource Azure Resource Manager (ARM) que vous créez dans un groupe de ressources et une région. Tous les bacs à sable, images de disque, instantanés, volumes et secrets sont limités à un groupe de bacs à sable.
Utilisez des groupes de bacs à sable pour organiser les bacs à sable par application, équipe ou environnement.
Bacs à sable
Un bac à sable est une instance de calcul isolée individuelle au sein d’un groupe de bacs à sable. Chaque bac à sable s’exécute à partir d’une image de disque ou d’un instantané et possède sa propre limite de processeur, de mémoire, de disque et de réseau.
Vous interagissez avec des bacs à sable en exécutant des commandes, en gérant des fichiers, en exposant des ports et en contrôlant l’état du cycle de vie.
Images de disque
Les images de disque sont des images de conteneur OCI converties pour être utilisées comme systèmes de fichiers racines de sandbox. Vous pouvez utiliser des images publiques ou créer des images privées à partir de vos propres registres de conteneurs.
Vous pouvez générer des images de disque à partir de :
- Images publiques : images préconstruites disponibles pour tous les groupes de sandbox.
- Images de registre de conteneurs : extraction à partir de registres publics ou privés avec authentification facultative.
Snapshots
Les instantanés capturent l’état complet d’un sandbox en cours d’exécution, y compris la mémoire et le disque. Utilisez des instantanés pour :
- Suspendre et reprendre : suspendre un bac à sable et le restaurer ultérieurement avec tous les processus et données intacts.
- Cloner des environnements : créez des bacs à sable à partir d’un état connu.
- Partagez des bases de référence : distribuez des environnements préconfigurés au sein de votre équipe.
Volumes
Microsoft gère les volumes et fournit un stockage persistant que vous pouvez monter dans des bacs à sable. Deux types de volumes sont disponibles :
| Type de volume | Description |
|---|---|
| Azure Blob | Partagez des données entre plusieurs environnements de test (téléversements et téléchargements, artefacts persistants). Montable sur plusieurs bacs à sable à la fois. |
| Disque de données | Volume à hautes performances pour les bases de données, les caches de compilation et les ensembles de travail volumineux. Montable sur un seul bac à sable à la fois. |
États du cycle de vie
Les bacs à sable passent par les états suivants :
| State | Description |
|---|---|
| Course à pied | Exécution active, utilisation du processeur et de la mémoire |
| Arrêté | Arrêté par l’utilisateur, l’API ou la politique du cycle de vie |
Lorsque le bac à sable est arrêté, l’opération prend et préserve un instantané basé sur le mode Suspension (voir la section suivante).
Vous pouvez configurer des politiques de cycle de vie pour chaque bac à sable :
- Auto-suspension : Suspendre un bac à sable inactif après un délai configurable. Un sandbox devient inactif lorsqu’il n’a aucun trafic entrant, qu’aucun code n’est exécuté (via l’API d’exécution), qu’aucune session shell interactive n’est ouverte et qu’aucune opération sur les fichiers n’est effectuée.
- Mode de suspension : Choisissez entre le mode mémoire (instantané complet - disque + mémoire) ou le mode disque (préserver le disque uniquement).
- Suppression automatique : supprime automatiquement les bacs à sable après un nombre de jours spécifié après l’arrêt du bac à sable.
Architecture
Les bacs à sable utilisent une architecture à deux plans :
| Avion | Point de terminaison | Operations |
|---|---|---|
| Plan de contrôle ARM | management.azure.com |
Créez, mettez à jour, supprimez et listez des groupes de bac à sable. Gérer les connexions de réseau virtuel. |
| Plan de données ADC | management.azuredevcompute.io |
Gérez les bacs à sable, les images de disque, les instantanés, les fichiers, les volumes, les secrets, les ports et les stratégies de sortie. |
Vous créez et gérez des groupes de bacs à sable via le plan de contrôle ARM. Toutes les opérations sur chaque environnement de test et ses ressources transitent par le plan de données ADC, dans le périmètre d’un groupe d’environnements de test donné.
Niveaux de ressources
Chaque environnement de test se voit attribuer un niveau de ressources qui détermine l’allocation du CPU, de la mémoire et de l’espace disque.
| Niveau | CPU (Unité centrale de traitement) | Mémoire | Disque |
|---|---|---|---|
| XS | 0,25 cœur | 0,5 Go | 20 Go |
| S | 0,5 cœur | 1 Go | 20 Go |
| M (par défaut) | 1 cœur | 2 Go | 20 Go |
| L | 2 cœurs | 4 Go | 40 Go |
| XL | 4 cœurs | 8 Go | 80 Go |
Considerations
Tenez compte de ces points lors de l’utilisation de bacs à sable (sandbox) :
- Entra ID obligatoire : seuls les comptes Microsoft Entra ID peuvent accéder aux bacs à sable (sandbox). Les comptes Microsoft personnels ne sont pas pris en charge.
- Contrôles réseau : Vous pouvez configurer des politiques de sortie pour contrôler le trafic sortant des bacs à sable, y compris les règles de refus ou de permis basées sur le domaine, les règles réseau basées sur CIDR, et l’intégration VNet.
Bacs à sable et sessions dynamiques
Les bacs à sable et les sessions dynamiques fournissent tous deux des environnements de calcul isolés dans Container Apps, mais ils servent des besoins différents.
| Sessions dynamiques | Bacs à sable | |
|---|---|---|
| Modèle d’accès | Routage des requêtes HTTP via un point de terminaison de gestion de pool de sessions | Contrôle direct du Kit de développement logiciel (SDK) et de l’interface CLI sur des bacs à sable individuels |
| State | Éphémère, détruit après le refroidissement | Avec gestion de l’état, suspension, reprise et captures instantanées |
| Contrôle développeur | Le pool gère l’allocation et le cycle de vie | Vous gérez le cycle de vie du bac à sable, les fichiers, les ports et les stratégies |
| Modèle d’image | Interpréteur de code (intégré) ou conteneur personnalisé | Images de disque (OCI), captures instantanées, packages de contenu |
| Stockage persistant | Non disponible | Volumes (Azure Blob, Disque de données) |
| Mise en réseau | Isolation de base | Stratégies de sortie, intégration au réseau virtuel, gestion des ports |
| SDKs | API REST via un point de terminaison de pool | SDK Python (azure-containerapps-sandbox) et API REST |
Choisissez des sessions dynamiques quand vous avez besoin d’une expérience d’exécution managée qui extrait l’infrastructure. Choisissez des bacs à sable lorsque vous avez besoin d’un contrôle programmable sur le calcul isolé avec persistance d’état.