Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Microsoft Foundry Agent Service supporta diverse opzioni di rete, da una configurazione completamente pubblica per la prototipazione rapida fino al completo isolamento di rete all'interno della propria rete virtuale. Questo articolo confronta le opzioni, associa ciascuna di esse a obiettivi comuni e ti indirizza al modello di distribuzione e alla guida alla configurazione per l'opzione che scegli.
Dopo aver scelto un'opzione, seguire la procedura collegata per distribuirla, quindi convalidare la distribuzione. Se si riscontrano problemi, utilizzare la guida alla risoluzione dei problemi collegata.
Comportamento di rete predefinito
Quando si crea una risorsa Foundry senza alcuna configurazione di rete, si ottiene una baseline completamente pubblica:
- In ingresso: l'endpoint Foundry è raggiungibile tramite la rete Internet pubblica. Qualsiasi chiamante con credenziali valide e l'URL dell'endpoint può raggiungerlo.
- In uscita: gli agenti accedono ai dati e alle risorse di Azure tramite la rete pubblica e possono raggiungere solo gli endpoint accessibili via Internet.
- Archiviazione: lo stato dell'agente usa l'archiviazione gestita Microsoft per impostazione predefinita. Se si usa la propria risorsa di archiviazione e altre risorse di Azure, configurare l'accesso di rete a tali risorse come parte della configurazione di rete.
Nulla è privato finché non si sceglie una delle opzioni nella sezione successiva. Ogni opzione modifica il lato in ingresso, il lato in uscita o entrambi.
Opzioni di rete
Una configurazione di rete combina due decisioni correlate:
- Accesso in uscita (in uscita): come gli agenti raggiungono i dati e altre risorse Azure. Questa decisione determina l'isolamento principale: mantenere l'uscita pubblica o limitarla a una rete virtuale in modo che il traffico rimanga nella rete privata. La rete virtuale può essere una rete che si crea e si gestisce autonomamente (rete virtuale BYO) oppure una rete virtuale gestita da Microsoft.
- Accesso in ingresso: le reti che possono raggiungere l'endpoint Foundry. Pubblico (facoltativamente limitato agli indirizzi IP selezionati) o privato tramite un endpoint privato.
Le due decisioni sono connesse. Quando si isola l'uscita in una rete virtuale, l'accesso in ingresso all'endpoint Foundry passa anche attraverso un endpoint privato, perché le risorse in tale rete virtuale raggiungono l'endpoint tramite la rete privata. Iniziare con il modello in uscita, perché tale scelta determina l'isolamento e le opzioni in ingresso disponibili. La tabella seguente illustra i tre modelli in uscita e le scelte in ingresso disponibili con ognuna.
| Modello di uscita | Scelte in ingresso | Ideale per |
|---|---|---|
| Uscita pubblica | Pubblico (facoltativamente con indirizzi IP selezionati), oppure un endpoint privato nella rete virtuale | Nessun isolamento in uscita. Usare l'ingresso pubblico per la creazione di prototipi e i test o un endpoint privato per limitare i chiamanti mentre il traffico in uscita rimane pubblico. |
| Rete virtuale BYO | Endpoint privato nella rete virtuale | Isolamento completo in cui si controllano gli intervalli IP, il peering e il routing. Gli agenti vengono distribuiti in una subnet che deleghi e gestisci. |
| Rete virtuale gestita | Endpoint privato nella rete virtuale | Isolamento completo senza gestire gli intervalli IP o quando lo spazio IP si sovrappone. Gli agenti vengono eseguiti in una rete virtuale gestita da Microsoft. |
Con l'uscita pubblica, l'aggiunta di un endpoint privato protegge solo il percorso in ingresso: i chiamanti raggiungono privatamente l'endpoint Foundry, ma l'uscita dell'agente non è isolata.
Con la rete virtuale BYO è possibile usare risorse dati personalizzate o risorse dati gestite dalla piattaforma. Per altre informazioni, vedere Requisiti di rete virtuale Bring Your Own.
Annotazioni
L'isolamento di rete si applica a livello di account e progetto Foundry. Comprende gli agenti ospitati, i prompt agent e le altre risorse di Foundry nell’account. I due tipi di agenti usano le risorse di rete in modo diverso all'interno di una configurazione isolata. Per informazioni dettagliate, vedere Approfondimenti sulla rete del servizio Foundry Agent.
Opzioni di rete per scenario
La tabella seguente esegue il mapping degli obiettivi comuni a un'opzione consigliata e a un modello di distribuzione. I modelli di infrastruttura come codice si trovano nel repository di configurazione dell'infrastruttura degli esempi di Foundry (Bicep, con un mirror Terraform).
| Il tuo obiettivo | Opzione consigliata | Eseguire la distribuzione con |
|---|---|---|
| Il modo più rapido per ottenere un agente funzionante, senza isolamento | Archiviazione pubblica, gestita da Microsoft | Guida introduttiva alla distribuzione del tuo primo agente ospitato (Azure Developer CLI o VS Code) |
| Mantenere i dati dell'agente nelle proprie risorse Azure, senza isolamento | Archiviazione pubblica, fornita dal cliente (standard) | 41-standard-agent-setup |
| Limitare chi può chiamare l'endpoint, l'uscita pubblica è accettabile | Uscita pubblica con un endpoint privato | 10-private-network-basic |
| Isolamento completo senza uscita pubblica, si controlla la rete e si vuole portare le proprie risorse dati | Rete virtuale BYO con risorse dati proprie (standard con protezione di rete) | 15-private-network-standard-agent-setup |
| Isolamento completo senza uscita pubblica, si controlla la rete, ma non si vogliono gestire le risorse dei dati | Rete virtuale BYO con risorse dati gestite dalla piattaforma | 11-private-network-basic-vnet |
| Isolamento completo, ma non è possibile gestire intervalli IP o sovrapposizioni dello spazio IP | Rete virtuale gestita | 18-managed-virtual-network |
| Isolamento completo dietro un gateway API | Rete virtuale BYO con Gestione API di Azure | 16-private-network-standard-agent-apim-setup |
| Raggiungere le risorse locali dagli agenti | Rete virtuale BYO più VPN o ExpressRoute |
15-private-network-standard-agent-setup più Accedere alle risorse locali |
Per il catalogo completo dei modelli e con relativa destinazione del provisioning, consultare il file README della configurazione dell'infrastruttura.
Requisiti per la rete virtuale personalizzata
Sia la rete virtuale BYO che la rete virtuale gestita offrono l'isolamento completo. La differenza sta in chi gestisce la rete: con una rete virtuale gestita, Microsoft gestisce per te i requisiti descritti in questa sezione. Scegliere Rete virtuale BYO quando si vuole il controllo completo di una rete già gestita, ovvero intervalli IP, firewall, peering e routing personalizzati.
Quando si sceglie la rete virtuale BYO, pianificare questi requisiti prima della distribuzione. La procedura di installazione e l'approfondimento li coprono completamente.
- Una subnet dedicata e delegata. Delegare una subnet a
Microsoft.App/environments. La subnet non può essere condivisa da più di una risorsa Foundry. Dimensionarla in base alla scalabilità prevista; vedi Pianifica le dimensioni della subnet. - Solo spazio indirizzi RFC 1918. Usare
10.0.0.0/8,172.16.0.0/12o192.168.0.0/16. Gli intervalli pubblici e CGNAT non sono supportati. Gli intervalli di classe A (10.x) sono disponibili solo in determinate aree. - Scelta delle risorse dati. Con la rete virtuale BYO è possibile scegliere come vengono fornite le risorse dati dell'agente (Archiviazione di Azure, Azure AI Search e Azure Cosmos DB):
- Risorse dati gestite dalla piattaforma. Usa risorse dati multitenant gestite dalla piattaforma, così non dovrai fornire né configurare le tue risorse. Scegliere questa opzione quando gli agenti non necessitano di risorse dati gestite dal cliente, ad esempio molti scenari di agenti ospitati, o quando si vuole evitare la pianificazione della capacità per risorse come Azure Cosmos DB. Questa opzione rimuove la necessità di configurare le risorse dati non usate.
- Risorse dati personali. Usare Archiviazione di Azure, Azure AI Search e Azure Cosmos DB in modo che tutti i dati dell'agente rimangano nel tenant. Scegli questa opzione quando ti servono i dati dell'agente nelle risorse di tua proprietà e che gestisci.
- Endpoint privati e zone DNS private per l'account Foundry e per ciascuna risorsa di dati apportata, in modo che la risoluzione dei nomi rimanga all'interno della rete virtuale.
- Stessa area per la risorsa Foundry e la rete virtuale. Altre risorse possono trovarsi in aree diverse, con implicazioni relative ai costi tra aree.
Importante
Impostare la configurazione della rete virtuale quando si crea l'account Foundry. L'iniezione di rete fa parte del flusso di creazione della risorsa e non può essere aggiunta a un account esistente. La configurazione di rete diventa effettiva quando si crea il primo agente ospitato e non è possibile modificare l'inserimento della rete in un secondo momento. Per passare a una configurazione di rete diversa, creare nuovi progetti. La configurazione viene applicata a livello di account, quindi copre sia gli agenti ospitati che gli agenti prompt. Prima di creare l'account, scegliere una rete virtuale BYO.
Per un diagramma topologico dell'opzione BYO per la rete virtuale, che include la subnet delegata, le micro VM dell'agente ospitato e gli endpoint privati per le risorse di dati, vedere Approfondimento sulla rete del servizio Foundry Agent.
Supporto per gli strumenti con isolamento di rete
Non tutti gli strumenti dell'agente supportano l'isolamento di rete. Alcuni strumenti non sono supportati dietro una rete virtuale e alcuni raggiungono la destinazione tramite La rete Internet pubblica anziché la rete privata. Prima di eseguire il commit in una configurazione isolata, controllare gli strumenti di Agent con isolamento di rete per verificare che gli strumenti usati dagli agenti siano supportati.
Pianificare le dimensioni della subnet
La subnet deve essere almeno /27 e non è possibile modificarne le dimensioni dopo averlo assegnato, quindi ridimensionarlo per la scala prevista. Tutti i progetti nell'account Foundry condividono la subnet, quindi pianificare l'utilizzo combinato di ogni progetto, agente e sessione simultanea nell'account. Azure riserva cinque indirizzi IP in ogni subnet per l'uso interno.
- Gli agenti ospitati vengono eseguiti in una macchina virtuale micro dedicata con la propria interfaccia di rete, quindi ognuno usa un indirizzo IP dalla subnet. L'utilizzo degli IP aumenta in funzione del numero di progetti, degli agenti ospitati in ciascun progetto e delle relative sessioni simultanee. Le nuove revisioni usano temporaneamente gli indirizzi IP durante l'implementazione, quando le revisioni precedenti e nuove vengono eseguite in parallelo.
- I Prompt agent non consumano un indirizzo IP per ogni revisione. Usano un piccolo pool statico di indirizzi IP (fino a circa 10 per progetto), indipendentemente dal numero di agenti di richiesta o revisioni eseguiti.
| Dimensioni della subnet | Raccomandazione |
|---|---|
| /24 | Consigliato per la produzione con agenti ospitati. Lascia margine per scalare gli agenti ospitati nei vari progetti, supportare sessioni simultanee e assorbire gli aggiornamenti in loco. |
| /27 | Minimo supportato. È adatto agli ambienti di produzione quando si eseguono agenti di prompt o per distribuzioni più piccole di agenti ospitati. Lascia meno margine per aumentare la scalabilità degli agenti ospitati e delle sessioni concorrenti. |
Per il modello di allocazione IP, i limiti delle sessioni simultanee e la matematica di dimensionamento, vedere Approfondimenti sulla rete del servizio Foundry Agent.
Agenti ospitati rispetto agli agenti di prompt
L'opzione di rete si applica all'intero account Foundry, ma i due tipi di agente usano le risorse di rete in modo diverso, come descritto in Pianificare le dimensioni della subnet. Entrambi i tipi raggiungono le risorse tramite endpoint privati nella rete virtuale.
Passaggi successivi
- Distribuisci l'opzione con la guida alla configurazione o il modello della tabella.
- Convalidare la distribuzione: confermare la delega della subnet, verificare che l'accesso pubblico sia disabilitato e che gli endpoint vengano risolti in indirizzi IP privati dall'interno della rete virtuale. Vedere Verificare la distribuzione.
- Risolvere eventuali errori di distribuzione o connettività con la guida alla risoluzione dei problemi.