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.
Microsoft Foundry Agent Service prend en charge plusieurs options de mise en réseau, d’une configuration entièrement publique pour un prototypage rapide afin d’effectuer une isolation réseau à l’intérieur de votre propre réseau virtuel. Cet article compare les options, mappe chacun à des objectifs communs et vous pointe vers le modèle de déploiement et le guide de configuration de l’option que vous choisissez.
Après avoir choisi une option, suivez le guide pratique lié pour le déployer, puis validez le déploiement. Si vous rencontrez des problèmes, utilisez les conseils de résolution des problèmes liés.
Comportement de mise en réseau par défaut
Lorsque vous créez une ressource Foundry sans configuration réseau, vous obtenez une base de référence entièrement publique :
- Entrée : le point de terminaison Foundry est accessible via l’Internet public. N’importe quel appelant avec des informations d’identification valides et l’URL du point de terminaison peut l’atteindre.
- Trafic sortant : les agents accèdent à vos données et aux ressources Azure via le réseau public, et ne peuvent accéder qu’aux points de terminaison accessibles depuis Internet.
- Stockage : l’état de l’agent utilise le stockage géré par Microsoft par défaut. Si vous apportez votre propre stockage et d’autres ressources Azure, vous configurez l’accès réseau à ces ressources dans le cadre de votre configuration réseau.
Rien n’est privé tant que vous n’avez pas choisi l’une des options de la section suivante. Chaque option modifie le côté entrant, le côté sortant ou les deux.
Options de mise en réseau
Une configuration réseau combine deux décisions connexes :
- Accès sortant (sortie) : comment vos agents atteignent vos données et d’autres ressources Azure. Cette décision détermine l’isolation principale : conserver la sortie publique ou la limiter à un réseau virtuel afin que le trafic reste sur votre réseau privé. Le réseau virtuel peut être celui que vous apportez et gérez (réseau virtuel BYO) ou un Microsoft gère pour vous.
- Accès entrant : quels réseaux peuvent atteindre votre point de terminaison Foundry. Public (éventuellement limité aux adresses IP sélectionnées) ou privé via un point de terminaison privé.
Les deux décisions sont connectées. Lorsque vous isolez la sortie dans un réseau virtuel, l’accès entrant au point de terminaison Foundry passe également par un point de terminaison privé, car les ressources de ce réseau virtuel atteignent le point de terminaison sur le réseau privé. Commencez par le modèle de sortie, car ce choix détermine l’isolation et les options entrantes disponibles. Le tableau suivant présente les trois modèles de sortie et les choix entrants disponibles avec chacun d’eux.
| Modèle de sortie | Choix d’entrée | Idéal pour |
|---|---|---|
| Sortie publique | Public (adresses IP sélectionnées éventuellement) ou un point de terminaison privé dans votre réseau virtuel | Aucune isolation de sortie. Utilisez le trafic entrant public pour le prototypage et les tests, ou un point de terminaison privé pour restreindre les appelants pendant que la sortie reste publique. |
| Réseau virtuel BYO | Point de terminaison privé dans votre réseau virtuel | Isolation complète où vous contrôlez les plages d’adresses IP, le peering et le routage. Les agents sont injectés dans un sous-réseau que vous délèguez et gérez. |
| Réseau virtuel managé | Point de terminaison privé dans votre réseau virtuel | Isolation complète sans gérer les plages d’adresses IP ou lorsque votre espace IP se chevauche. Les agents s’exécutent dans un réseau virtuel géré par Microsoft. |
Avec un trafic de sortie public, l’ajout d’un point de terminaison privé sécurise uniquement le chemin d’entrée : les clients accèdent au point de terminaison Foundry via un réseau privé, mais le trafic de sortie de l’agent n’est pas isolé.
Avec le réseau virtuel BYO, vous pouvez apporter vos propres ressources de données ou utiliser des ressources de données gérées par la plateforme. Pour plus d’informations, consultez La configuration requise pour le réseau virtuel bring-your-own.
Note
L’isolation réseau s’applique au niveau du compte Foundry et du projet. Il inclut les agents hébergés, les agents de requête et les autres ressources Foundry du compte. Les deux types d’agents consomment des ressources réseau différemment à l’intérieur d’une configuration isolée. Pour plus de détails, consultez Analyse approfondie de la mise en réseau de Foundry Agent Service.
Options de mise en réseau par scénario
Le tableau suivant mappe les objectifs courants à une option recommandée et à un modèle de déploiement. Les modèles d’infrastructure en tant que code se trouvent dans le référentiel d’exemple de configuration de l’infrastructure Foundry (Bicep, avec un miroir Terraform).
| Votre objectif | Option recommandée | Déployer avec |
|---|---|---|
| Chemin le plus rapide vers un agent opérationnel, sans isolation | Stockage public, géré par Microsoft | Déployer votre premier agent hébergé : guide de démarrage rapide (Azure Developer CLI ou VS Code) |
| Conserver les données de l’agent dans vos propres ressources Azure, sans isolation | Stockage public utilisant votre propre stockage (standard) | 41-standard-agent-setup |
| Limiter qui peut appeler le point de terminaison ; un trafic sortant public est acceptable | Sortie publique avec un point de terminaison privé | 10-private-network-basic |
| Isolation complète sans sortie publique, vous contrôlez le réseau et souhaitez apporter vos propres ressources de données | Réseau virtuel BYO avec des ressources « apportez vos propres données » (norme de sécurité par le réseau) | 15-private-network-standard-agent-setup |
| Isolation complète sans sortie publique, vous contrôlez le réseau, mais ne souhaitez pas gérer les ressources de données | Réseau virtuel BYO avec des ressources de données gérées par la plateforme | 11-private-network-basic-vnet |
| Isolation complète, mais vous ne pouvez pas gérer les plages d’adresses IP ou votre espace IP se chevauche | Réseau virtuel managé | 18-managed-virtual-network |
| Isolation complète derrière une passerelle d’API | Réseau virtuel BYO avec Gestion des API Azure | 16-private-network-standard-agent-apim-setup |
| Accéder à des ressources locales à partir d’agents | Réseau virtuel BYO plus VPN ou ExpressRoute |
15-private-network-standard-agent-setup plus Accéder aux ressources locales |
Pour obtenir le catalogue de modèles complet et ce que chacun d’eux provisionne, consultez le fichier README de configuration de l’infrastructure.
Exigences relatives au réseau virtuel apporté par le client
Le réseau virtuel BYO et le réseau virtuel managé fournissent une isolation complète. La différence est celle qui exécute le réseau : avec un réseau virtuel managé, Microsoft gère les exigences de cette section pour vous. Choisissez le réseau virtuel BYO lorsque vous souhaitez contrôler entièrement un réseau que vous gérez déjà : vos propres plages d’adresses IP, pare-feu, peering et routage.
Lorsque vous choisissez un réseau virtuel BYO, planifiez ces exigences avant de déployer. La procédure d’installation et la présentation approfondie les couvrent entièrement.
- Sous-réseau dédié et délégué. Déléguer un sous-réseau à
Microsoft.App/environments. Le sous-réseau ne peut pas être partagé par plusieurs ressources Foundry. Dimensionnez-le en fonction de l’échelle prévue ; consultez Planifiez la taille de votre sous-réseau. - Espace d’adressage RFC 1918 uniquement. Utilisez
10.0.0.0/8,172.16.0.0/12ou192.168.0.0/16. Les plages publiques et CGNAT ne sont pas prises en charge. Les plages de classes A (10.x) sont disponibles uniquement dans certaines régions. - Votre choix de ressources de données. Avec le réseau virtuel BYO, vous choisissez comment les ressources de données de l’agent (stockage Azure, Recherche Azure AI et Azure Cosmos DB) sont fournies :
- Ressources de données gérées par la plateforme. Utilisez des ressources de données multilocataire gérées par la plateforme afin de ne pas apporter ou configurer vos propres ressources. Choisissez cette option lorsque vos agents n'ont pas besoin de ressources de données gérées par le client( par exemple, de nombreux scénarios d'agent hébergé) ou lorsque vous souhaitez éviter la planification de capacité pour les ressources telles que Azure Cosmos DB. Cette option supprime la nécessité de configurer les ressources de données que vous n’utilisez pas.
- Apportez vos propres ressources de données. Utilisez vos propres services stockage Azure, Recherche Azure AI et Azure Cosmos DB pour que toutes les données des agents restent dans votre locataire Azure. Choisissez cette option lorsque vous avez besoin de données d’agent dans les ressources que vous possédez et gérez.
- Points de terminaison privés et zones DNS privées pour le compte Foundry, ainsi que pour chaque ressource de données que vous apportez, afin que la résolution de noms reste au sein du réseau virtuel.
- Même région pour la ressource Foundry et le réseau virtuel. D’autres ressources peuvent se trouver dans différentes régions, avec des implications sur les coûts interrégions.
Important
Définissez la configuration du réseau virtuel lorsque vous créez le compte Foundry. L’injection de réseau fait partie du flux de création de ressources et ne peut pas être ajoutée à un compte existant. La configuration réseau prend effet lorsque vous créez le premier agent hébergé et que vous ne pouvez pas modifier l’injection de réseau par la suite. Pour passer à une autre configuration réseau, créez de nouveaux projets. La configuration s’applique au niveau du compte ; elle couvre donc à la fois les agents hébergés et les agents basés sur des requêtes. Choisissez un réseau virtuel BYO avant de créer le compte.
Pour obtenir un diagramme de topologie de l’option de réseau virtuel BYO : sous-réseau délégué, machines virtuelles micro-agents hébergés et points de terminaison privés pour vos ressources de données, consultez Présentation approfondie de la mise en réseau du service de l’agent Foundry.
Prise en charge des outils avec isolation réseau
Tous les outils d’agent ne prennent pas en charge l’isolation réseau. Certains outils ne sont pas pris en charge derrière un réseau virtuel, et certains atteignent leur destination sur l’Internet public plutôt que sur votre réseau privé. Avant de vous engager dans une configuration isolée, vérifiez les outils de l’agent avec isolation réseau pour vérifier que les outils utilisés par vos agents sont pris en charge.
Planifier la taille de votre sous-réseau
Le sous-réseau doit être au moins en /27, et vous ne pouvez pas en modifier la taille après l’avoir attribué ; dimensionnez-le donc en fonction de l’échelle prévue. Tous les projets du compte Foundry partagent le sous-réseau. Prévoyez donc l’utilisation combinée de chaque projet, agent et session simultanée dans le compte. Azure réserve cinq adresses IP dans chaque sous-réseau pour une utilisation interne.
- Les agents hébergés s’exécutent dans une machine virtuelle Micro dédiée avec sa propre interface réseau, de sorte que chacun utilise une adresse IP à partir du sous-réseau. L’utilisation des adresses IP augmente en fonction du nombre de projets, des agents hébergés dans chaque projet et de leurs sessions simultanées. Les nouvelles révisions consomment également temporairement des adresses IP pendant le déploiement, lorsque les anciennes et nouvelles révisions s’exécutent en parallèle.
- Les agents de prompt ne consomment pas d’adresse IP par révision. Ils utilisent un petit pool statique d’adresses IP (jusqu’à environ 10 par projet), quel que soit le nombre d’agents d’invite ou de révisions que vous exécutez.
| Taille du sous-réseau | Recommendation |
|---|---|
| /24 | Recommandé pour la production avec des agents hébergés. Laisse une marge de capacité pour faire évoluer les agents hébergés à l’échelle des projets, prendre en charge les sessions simultanées et gérer les mises à niveau sur place. |
| /27 | Minimum pris en charge. Fonctionne pour la production lorsque vous exécutez des agents de requête ou pour des déploiements d’agents hébergés plus petits. Laisse moins de marge pour la mise à l’échelle des agents hébergés et des sessions simultanées. |
Pour connaître le modèle d’allocation IP, les limites de session simultanée et les mathématiques de dimensionnement, consultez Présentation approfondie de la mise en réseau du service de l’agent Foundry.
Agents hébergés par rapport aux agents de requête
L’option de mise en réseau s’applique à votre compte Foundry entier, mais les deux types d’agents consomment différemment les ressources réseau, comme décrit dans Planifier la taille de votre sous-réseau. Les deux types atteignent vos ressources via des points de terminaison privés dans votre réseau virtuel.
Étapes suivantes
- Déployez l’option avec la procédure d’installation ou le modèle à partir de la table.
- Validez le déploiement : confirmez la délégation du sous-réseau, la désactivation de l’accès public et le fait que les points de terminaison se résolvent en adresses IP privées depuis l’intérieur du réseau virtuel. Consultez Vérifier le déploiement.
- Résolvez les erreurs de déploiement ou de connectivité avec le guide de résolution des problèmes.