Integrare un'app in una rete virtuale di Azure

Nota

A partire dal 1° giugno 2024, tutte le app del servizio app appena create avranno la possibilità di generare un nome host predefinito univoco usando la convenzione di denominazione <app-name>-<random-hash>.<region>.azurewebsites.net. I nomi delle app esistenti rimarranno invariati.

Esempio: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Per altri dettagli, vedere Nome host predefinito univoco per la risorsa del servizio app.

Questo articolo descrive la funzionalità Integrazione rete virtuale di Servizio app di Azure e come configurarla con le app di Servizio app. Con Reti virtuale di Azure è possibile inserire molte risorse di Azure in una rete non instradabile su Internet. La funzionalità di integrazione della rete virtuale del servizio app consente alle app di accedere alle risorse in o tramite una rete virtuale.

Nota

Le informazioni sull'integrazione rete virtuale richiesta dal gateway sono state spostate in un nuovo percorso.

Il servizio app esiste in due varianti:

• I piani tariffari di calcolo dedicati, che includono Basic, Standard, Premium, Premium v2 e Premium v3.
• Ambiente del servizio app, che viene distribuito direttamente nella rete virtuale con un'infrastruttura di supporto dedicata e usa i piani tariffari Isolated e Isolated v2.

La funzionalità di integrazione della rete virtuale viene usata nei piani tariffari di calcolo dedicati del servizio app di Azure. Se l'app si trova in un Ambiente del servizio app, si integra già con una rete virtuale e non richiede di configurare la funzionalità Integrazione rete virtuale per raggiungere le risorse nella stessa rete virtuale. Per altre informazioni su tutte le funzionalità di rete, vedere Funzionalità di rete del servizio app.

L'integrazione della rete virtuale consente all'app di accedere alle risorse nella rete virtuale, ma non concede l'accesso privato in ingresso nel senso opposto, ovvero dalla rete virtuale all'app. Per accesso privato si intende rendere l'app accessibile solo da una rete privata, ad esempio da una rete virtuale di Azure. L'integrazione della rete virtuale viene usata solo per effettuare chiamate in uscita dall'app alla rete virtuale. Per informazioni sull'accesso privato in ingresso, vedere Endpoint privato.

Funzionalità di integrazione della rete virtuale:

• Richiede un piano tariffario supportati Basic o Standard, Premium, Premium v2, Premium v3 o Elastic Premium App Service.
• Supporta TCP e UDP.
• Funziona con app del servizio app, app per le funzioni e app per la logica.

Ci sono alcuni aspetti che l'integrazione della rete virtuale non supporta, ad esempio:

• Montaggio di un'unità.
• Aggiunta al dominio di Windows Server Active Directory.
• NetBIOS.

L'integrazione della rete virtuale supporta la connessione a una rete virtuale nella stessa area. L'uso dell'integrazione della rete virtuale consente all'app di accedere a:

• Risorse nella rete virtuale con cui si è integrati.
• Le risorse nelle reti virtuali con peering alla rete virtuale con cui l'app è integrata, incluse le connessioni di peering globali.
• Risorse nelle connessioni Azure ExpressRoute.
• Servizi protetti dell'endpoint servizio.
• Servizi abilitati per gli endpoint privati.

Quando si usa l'integrazione della rete virtuale, è possibile usare le funzionalità di rete di Azure seguenti:

• Gruppi di sicurezza di rete: è possibile bloccare il traffico in uscita con un gruppo di sicurezza di rete usato nella subnet di integrazione. Le regole in ingresso non si applicano perché non è possibile usare l'integrazione rete virtuale per consentire l'accesso in ingresso all'app.
• Tabelle di route (route definite dall'utente): è possibile inserire una tabella di route nella subnet di integrazione per inviare il traffico in uscita in cui si vuole.
• Gateway NAT: è possibile usare un gateway NAT per ottenere un indirizzo IP in uscita dedicato e attenuare l'esaurimento delle porte SNAT.

Informazioni su come abilitare l'integrazione rete virtuale.

Funzionamento dell'integrazione della rete virtuale

Le app nel servizio app sono ospitate in ruoli di lavoro. L'integrazione della rete virtuale funziona montando interfacce virtuali nei ruoli di lavoro con indirizzi nella subnet delegata. Le interfacce virtuali usate non sono risorse a cui i clienti hanno accesso diretto. Poiché l'indirizzo da dove parte si trova nella rete virtuale, può accedere alla maggior parte degli elementi nella rete virtuale o tramite la rete virtuale, come una macchina virtuale nella rete virtuale.

Quando l'integrazione della rete virtuale è abilitata, l'app effettua chiamate in uscita attraverso la rete virtuale. Gli indirizzi in uscita elencati nel portale delle proprietà dell'app sono gli indirizzi ancora usati dall'app. Tuttavia, se la chiamata in uscita è verso una macchina virtuale o un endpoint privato nella rete virtuale di integrazione o nella rete virtuale con peering, l'indirizzo in uscita è un indirizzo che provieviene dalla subnet di integrazione. L'indirizzo IP privato assegnato a un'istanza viene esposto tramite la variabile di ambiente "WEBSITE_PRIVATE_IP".

Quando tutto il routing del traffico è abilitato, tutto il traffico in uscita viene inviato alla rete virtuale. Se non è abilitato tutto il routing del traffico, solo il traffico privato (RFC1918) e gli endpoint di servizio configurati nella subnet di integrazione vengono inviati alla rete virtuale. Il traffico in uscita verso Internet viene instradato direttamente dall'app.

La funzionalità Integrazione rete virtuale supporta due interfacce virtuali per ogni ruolo di lavoro. Due interfacce virtuali per ruolo di lavoro indicano due integrazioni di rete virtuale per ogni piano di servizio app. In altre parole, un piano di servizio app può avere integrazioni di rete virtuale con un massimo di due subnet/reti virtuali. Le app nello stesso piano di servizio app possono usare solo una delle integrazioni di rete virtuale in una subnet specifica, quindi un'app può avere una sola integrazione di rete virtuale in un determinato momento.

Requisiti della subnet

L'integrazione della rete virtuale dipende da una subnet dedicata. Quando si crea una subnet, la subnet di Azure usa cinque indirizzi IP dall'inizio. Un indirizzo viene usato dalla subnet di integrazione per ogni istanza del piano di servizio app. Se si ridimensiona l'app facendola diventare a quattro istanze, vengono usati quattro indirizzi.

Quando si aumenta o si riduce la dimensione dell'istanza, la quantità di indirizzi IP usati dal piano di servizio app viene temporaneamente raddoppiata durante il completamento dell'operazione di ridimensionamento. Le nuove istanze devono essere completamente operative prima del deprovisioning delle istanze esistenti. L'operazione di scalabilità influisce sulle istanze supportate reali e disponibili per una determinata dimensione della subnet. Gli aggiornamenti della piattaforma necessitano di indirizzi IP gratuiti per garantire che gli aggiornamenti possano verificarsi senza interruzioni del traffico in uscita. Infine, dopo aver completato le operazioni di aumento, riduzione o in/out sono state completate potrebbe passare un breve periodo di tempo prima che vengano rilasciarti gli indirizzi IP. In rari casi, questa operazione può richiedere fino a 12 ore e, in caso di ridimensionamento, sono necessari più indirizzi IP rispetto alla scalabilità massima.

Poiché le dimensioni della subnet non possono essere modificate dopo l'assegnazione, usarne sufficientemente grande per supportare qualsiasi dimensione che l'app potrebbe raggiungere. È anche consigliabile riservare gli indirizzi IP per futuri aggiornamenti della piattaforma. Per evitare problemi con la capacità della subnet, è consigliabile allocare due indirizzi IP della scalabilità massima pianificata. Un /26 con 64 indirizzi copre la scala massima di un singolo piano di servizio app multi-tenant. Quando si creano subnet nel portale di Azure come parte dell'integrazione con la rete virtuale, è necessaria una dimensione minima di /27. Se la subnet esiste già prima dell'integrazione tramite il portale, è possibile usare una subnet /28.

Con MPSJ (Multi Plan Subnet Join), è possibile aggiungere più piani di servizio app nella stessa subnet. Tutti i piani di servizio app devono trovarsi nella stessa sottoscrizione, ma la rete virtuale o la subnet possono trovarsi in una sottoscrizione diversa. Ogni istanza di ogni piano di servizio app richiede un indirizzo IP dalla subnet e per usare MPSJ è necessaria una subnet con dimensione minima di /26. Se si prevede di aggiungere molti piani e/o piani su larga scala, è consigliabile pianificare intervalli di subnet più grandi.

Importante

A causa di un bug noto, MPSJ ha esito negativo se vengono creati più siti e si tenta di eseguire l'integrazione con la rete virtuale contemporaneamente. Presto verrà distribuita una correzione. Nel frattempo, è possibile risolvere il problema con uno dei metodi seguenti:

• Se si creano siti manualmente, creare e integrare i siti uno alla volta.
• Se si creano siti a livello di codice, ad esempio usando i modelli Terraform o ARM, aggiungere un elemento dependsOn a ogni sito nei modelli per dipendere dalla creazione del sito precedente per tutti i siti, ma il primo sito nel modello. In questo modo viene creato un ritardo tra la creazione del sito e l'integrazione della rete virtuale per ogni sito e pertanto non viene bloccato dal bug noto. Per altre informazioni, vedere Definire l'ordine di distribuzione delle risorse nei modelli di Resource Manager.

Limiti specifici dei contenitori Windows

I contenitori Windows usano un indirizzo IP aggiuntivo per ogni app per ogni istanza del piano di servizio app ed è necessario ridimensionare di conseguenza la subnet. Se sono ad esempio presenti 10 istanze del piano di servizio app del contenitore Windows con quattro app in esecuzione, sono necessari 50 indirizzi IP e indirizzi aggiuntivi per supportare la scalabilità orizzontale (in/out).

Calcolo di esempio:

Per ogni istanza del piano di servizio app è necessario avere: 4 app contenitore Windows = 4 indirizzi IP 1 indirizzo IP per ogni istanza del piano di servizio app 4 + 1 = 5 indirizzi IP

Per 10 istanze: 5 x 10 = 50 indirizzi IP per piano di servizio app

Poiché si dispone di 1 piano di servizio app, 1 x 50 = 50 indirizzi IP.

Esistono inoltre limitazioni correlate al numero di core disponibili nel livello del ruolo di lavoro usato. Ogni core aggiunge tre unità di rete. Il ruolo di lavoro stesso usa un'unità e ogni connessione di rete virtuale usa un'unità. Le unità rimanenti possono essere usate per le app.

Calcolo di esempio:

Istanza del piano di servizio app con quattro app in esecuzione e con l'integrazione rete virtuale. Le app sono connesse a due subnet diverse (connessioni di rete virtuale). Questa configurazione richiede sette unità di rete (1 ruolo di lavoro + 2 connessioni + 4 app). Le dimensioni minime per l'esecuzione di questa configurazione sono I2v2 (quattro core x 3 unità = 12 unità).

Con I1v2 è possibile eseguire un massimo di quattro app con la stessa connessione (1) o 3 app con 2 connessioni.

Autorizzazioni

Per configurare l'integrazione della rete virtuale tramite il portale di Azure, l'interfaccia della riga di comando o l'impostazione diretta della proprietà virtualNetworkSubnetId del sito, è necessario disporre almeno delle seguenti autorizzazioni per il controllo degli accessi in base al ruolo nella subnet o autorizzazioni a un livello superiore:

Azione	Descrizione
Microsoft.Network/virtualNetworks/read	Leggere la definizione della rete virtuale
Microsoft.Network/virtualNetworks/subnets/read	Leggere la definizione di subnet di rete virtuale
Microsoft.Network/virtualNetworks/subnets/join/action	Aggiunge una rete virtuale

Se la rete virtuale si trova in una sottoscrizione diversa rispetto all'app, è necessario assicurarsi che la sottoscrizione con la rete virtuale sia registrata per il provider Microsoft.Web di risorse. È possibile registrare in modo esplicito il provider seguendo questa documentazione, ma la registrazione viene eseguita automaticamente anche durante la creazione della prima app Web in una sottoscrizione.

Route

È possibile controllare il traffico attraverso l'integrazione della rete virtuale. Esistono tre tipi di routing da considerare quando si configura l'integrazione della rete virtuale. Il routing delle applicazioni definisce il traffico instradato dall'app e alla rete virtuale. Il routing della configurazione influisce sulle operazioni che si verificano prima o durante l'avvio dell'app. Esempi sono il pull delle immagini del contenitore e le impostazioni dell'app con riferimento a Key Vault. Il routing di rete è la possibilità di gestire il modo in cui il traffico dell'app e della configurazione viene instradato dalla rete virtuale e in uscita.

Tramite il routing delle applicazioni o le opzioni di routing di configurazione, è possibile configurare il traffico inviato tramite l'integrazione della rete virtuale. Il traffico è soggetto al routing di rete solo se viene inviato tramite l'integrazione della rete virtuale.

Reindirizzamento domande di lavoro

Il routing delle applicazioni si applica al traffico inviato dall'app dopo l'avvio. Vedere Routing della configurazione per il traffico durante l'avvio. Quando si configura il routing delle applicazioni, è possibile instradare tutto il traffico o solo il traffico privato, noto anche come traffico RFC1918, nella rete virtuale. Questo comportamento viene configurato tramite impostando il traffico Internet in uscita. Se il routing del traffico Internet in uscita è disabilitato, l'app instrada solo il traffico privato alla rete virtuale. Se si vuole instradare tutto il traffico dell'app in uscita alla rete virtuale, assicurarsi che il traffico Internet in uscita sia abilitato.

• Solo il traffico configurato nel routing dell'applicazione o della configurazione è soggetto ai gruppi di sicurezza di rete e alle route definite dall'utente applicate alla subnet di integrazione.
• Quando il routing del traffico Internet in uscita è abilitato, l'indirizzo di origine per il traffico in uscita dall'app è ancora uno degli indirizzi IP elencati nelle proprietà dell'app. Se si instrada il traffico attraverso un firewall o un gateway NAT, l'indirizzo IP di origine proviene da questo servizio.

Informazioni su come configurare il routing delle applicazioni.

Nota

La connettività SMTP in uscita (porta 25) è supportata per il servizio app quando il traffico SMTP viene instradato attraverso l'integrazione della rete virtuale. Se viene supportata o meno è determinato da un'impostazione nell'abbonamento in cui viene distribuita la rete virtuale. Per le reti virtuali/subnet create prima di 1. Ad agosto 2022, è necessario avviare una modifica di configurazione temporanea alla rete virtuale/subnet per sincronizzare l'impostazione dall'abbonamento. Un esempio può essere quello di aggiungere una subnet temporanea, associare/dissociare temporaneamente un gruppo di sicurezza di rete o configurare temporaneamente un endpoint di servizio. Per altre informazioni, vedere Risolvere i problemi di connettività SMTP in uscita in Azure.

Routing di configurazione

Quando si usa l'integrazione della rete virtuale, è possibile configurare la modalità di gestione delle parti del traffico di configurazione. Per impostazione predefinita, il traffico di configurazione passa direttamente attraverso la route pubblica, ma per i singoli componenti menzionati, è possibile configurarlo attivamente per essere indirizzato tramite l'integrazione della rete virtuale.

Condivisione contenuto

Per impostazione predefinita, Funzioni di Azure usa una condivisione di contenuti come origine della distribuzione quando si ridimensionano le app per le funzioni in un piano Premium. È necessario configurare un'impostazione aggiuntiva per garantire che il traffico venga instradato verso questa condivisione di contenuti tramite l'integrazione della rete virtuale. Per altre informazioni, vedere Come configurare il routing della condivisione di contenuti.

Oltre a configurare il routing, è necessario assicurarsi anche che qualsiasi firewall o gruppo di sicurezza di rete configurato sul traffico dalla subnet consenta il traffico verso la porta 443 e 445.

Pull dell'immagine del contenitore

Quando si usano contenitori personalizzati, è possibile eseguire il pull del contenitore tramite l'integrazione della rete virtuale. Per instradare il traffico pull del contenitore attraverso l'integrazione della rete virtuale, è necessario assicurarsi che l'impostazione di routing sia configurata. Informazioni su come configurare il routing pull delle immagini.

Backup/ripristino

Il servizio app include backup/ripristino predefiniti, ma se si vuole eseguire il backup nel proprio account di archiviazione, è possibile usare la funzionalità di backup/ripristino personalizzata. Se si vuole instradare il traffico all'account di archiviazione tramite l'integrazione della rete virtuale, è necessario configurare l'impostazione di route. Il backup del database non è supportato tramite l'integrazione della rete virtuale.

Impostazioni dell'app che usano riferimenti a Key Vault

Le impostazioni dell'app che usano i riferimenti a Key Vault tentano di ottenere segreti sulla route pubblica. Se Key Vault blocca il traffico pubblico e l'app usa l'integrazione della rete virtuale, viene effettuato un tentativo di ottenere i segreti tramite l'integrazione della rete virtuale.

Nota

• La configurazione dei certificati SSL/TLS da insiemi di credenziali delle chiavi private non è attualmente supportata.
• I log del servizio app per gli account di archiviazione privati non sono attualmente supportati. È consigliabile usare la registrazione diagnostica e consentire servizi attendibili per l'account di archiviazione.

Impostazioni dell'app di routing

Il Servizio app include impostazioni dell'app esistenti per configurare il routing delle applicazioni e della configurazione. Se esistono entrambe, le proprietà del sito eseguono l'override delle impostazioni dell'app. Le proprietà del sito hanno il vantaggio di essere controllabili con Criteri di Azure e di essere convalidate al momento della configurazione. È consigliabile usare le proprietà del sito.

È comunque possibile usare l'impostazione WEBSITE_VNET_ROUTE_ALL dell'app esistente per configurare il routing delle applicazioni.

Esistono anche impostazioni dell'app per alcune opzioni di routing della configurazione. Queste impostazioni dell'app sono denominate WEBSITE_CONTENTOVERVNET e WEBSITE_PULL_IMAGE_OVER_VNET.

Routing di rete

È possibile usare le tabelle di route per instradare il traffico in uscita dall'app senza restrizioni. Le destinazioni comuni possono includere dispositivi firewall o gateway. È anche possibile usare un gruppo di sicurezza di rete (NSG) per bloccare il traffico in uscita verso le risorse nella rete virtuale o su Internet. Un gruppo di sicurezza di rete applicato alla subnet di integrazione è valido indipendentemente dalle tabelle di route applicate alla subnet di integrazione.

Le tabelle di route e i gruppi di sicurezza di rete si applicano solo al traffico indirizzato tramite l'integrazione della rete virtuale. Per informazioni dettagliate, vedere Routing delle applicazioni e Routing della configurazione. Le route non si applicano alle risposte da richieste di app in ingresso e regole in ingresso in un gruppo di sicurezza di rete non si applicano all'app. L'integrazione della rete virtuale influisce solo sul traffico in uscita dall'app. Per controllare il traffico in ingresso verso l'app, usare la funzionalità Restrizioni di accesso o gli endpoint privati.

Quando si configurano gruppi di sicurezza di rete o tabelle di route applicabili al traffico in uscita, bisogna assicurarsi di prendere in considerazione le dipendenze dell'applicazione. Le dipendenze dell'applicazione includono endpoint necessari per l'app durante il runtime. Oltre alle API e ai servizi che l'app chiama, questi endpoint possono anche essere endpoint derivati, ad esempio endpoint di controllo dell'elenco di revoche di certificati (CRL) e endpoint di identità/autenticazione, come Microsoft Entra ID. Se si usa la distribuzione continua nel Servizio app, potrebbe anche essere necessario dover consentire gli endpoint a seconda del tipo e della linguaggio. In particolare, per la distribuzione continua di Linux è necessario consentire oryx-cdn.microsoft.io:443. Per Python è anche necessario consentire files.pythonhosted.org, pypi.org.

Azure usa la porta UDP 30.000 per eseguire controlli di integrità della rete. Se si blocca questo traffico, non influisce direttamente sull'app, ma sarà più difficile per il supporto di Azure rilevare e risolvere i problemi correlati alla rete.

Quando si vuole instradare il traffico in uscita in locale, è possibile usare una tabella di route per inviare il traffico in uscita al gateway ExpressRoute di Azure. Se si instrada il traffico a un gateway, impostare le route nella rete esterna per l'invio di risposte. Le route BGP (Border Gateway Protocol) influiscono anche sul traffico dell'app. Se sono presenti route BGP da elementi come un gateway ExpressRoute, ciò influisce sul traffico in uscita dell'app. Analogamente alle route definite dall'utente, le route BGP influiscono sul traffico in base all'impostazione dell'ambito di routing.

Endpoint di servizio

L'integrazione rete virtuale consente di raggiungere i servizi di Azure protetti con gli endpoint servizio. Per accedere a un servizio protetto da endpoint di servizio, seguire questa procedura:

1. Configurare l'integrazione rete virtuale con l'app Web per connettersi a una subnet specifica per l'integrazione.
2. Passare al servizio di destinazione e configurare gli endpoint servizio nella subnet di integrazione.

Endpoint privati

Per effettuare chiamate agli endpoint privati, assicurarsi che le ricerche DNS vengano risolte nell'endpoint privato. È possibile applicare questo comportamento in uno dei modi seguenti:

• Eseguire l'integrazione con zone private di DNS di Azure. Quando la rete virtuale non dispone di un server DNS personalizzato, l'integrazione viene eseguita automaticamente quando le zone sono collegate alla rete virtuale.
• Gestire l'endpoint privato nel server DNS usato dall'app. Per gestire la configurazione, è necessario conoscere l'indirizzo IP dell'endpoint privato. Puntare quindi l'endpoint che si sta tentando di raggiungere verso tale indirizzo, usando un record A.
• Configurare il server DNS per l'inoltro a zone private di DNS di Azure.

Zone private di DNS di Azure

Dopo l'integrazione dell'app con la rete virtuale, usa lo stesso server DNS con cui è configurata la rete virtuale. Se non viene specificato alcun DNS personalizzato, usa quello predefinito di Azure e una delle zone private collegate alla rete virtuale.

Limiti

Esistono alcune limitazioni con l'uso dell'integrazione della rete virtuale:

• La funzionalità è disponibile in tutte le distribuzioni del servizio app in Premium v2 e Premium v3. È disponibile anche nel livello Basic e Standard, ma solo nelle versioni più recenti del servizio app. Se si usa una versione più vecchia, è possibile usare la funzionalità solo da un piano di servizio app Premium v2. Se ci si vuole assicurare di poter usare la funzionalità in un piano di servizio app Basic o Standard, creare l'app in un piano di servizio app Premium v3. Questi piani sono supportati solo nelle versioni più recenti. Una volta creato è il piano, è possibile ridurne le prestazioni.
• La funzionalità non è disponibile per le app del piano isolato in un ambiente del servizio app.
• Non è possibile raggiungere le risorse tra connessioni di peering con reti virtuali classiche.
• La funzionalità richiede una subnet inutilizzata che corrisponda a un blocco /28 IPv4 o superiore in una rete virtuale di Azure Resource Manager. MPSJ richiede un blocco /26 o superiore.
• L'app e la rete virtuale devono essere nella stessa area.
• La rete virtuale di integrazione non può avere spazi indirizzi IPv6 definiti.
• La subnet di integrazione non può avere criteri dell'endpoint di servizio abilitati.
• Non è possibile eliminare una rete virtuale con un'app integrata. Rimuovere l'integrazione prima di eliminare la rete virtuale.
• Non è possibile avere più di due integrazioni di rete virtuale per ogni piano di servizio app. Più app nello stesso piano di servizio app possono usare la stessa integrazione di rete virtuale.
• Non è possibile modificare la'abbonamento di un'app o un piano mentre è presente un'app che usa l'integrazione della rete virtuale.

Accedere alle risorse locali

Non è necessaria alcuna configurazione aggiuntiva per consentire alla funzionalità di integrazione della rete virtuale di raggiungere le risorse locali tramite la rete virtuale. È sufficiente connettere la rete virtuale alle risorse locali usando ExpressRoute o una VPN da sito a sito.

Peering

Se si usa il peering con l'integrazione della rete virtuale, non è necessario eseguire altre operazioni di configurazione.

Gestire l'integrazione della rete virtuale

La connessione e la disconnessione con una rete virtuale avvengono a livello di app. Le operazioni che possono influire sull'integrazione della rete virtuale tra più app avvengono a livello di piano di servizio app. Dal portale dell'app >Rete>Integrazione rete virtuale è possibile ottenere i dettagli della rete virtuale. È possibile visualizzare informazioni simili a livello di piano di servizio app nel portale Piano di servizio app>Rete>Integrazione rete virtuale.

Nella visualizzazione dell'app dell'istanza di integrazione della rete virtuale, è possibile disconnettere l'app dalla rete virtuale ed è possibile configurare il routing delle applicazioni. Per disconnettere l'app da una rete virtuale, selezionare Disconnetti. Qquando si disconnette da una rete virtuale, l'app viene riavviata. La disconnessione non modifica la rete virtuale. La subnet non viene rimossa. Se si vuole eliminare la rete virtuale, disconnettere prima l'app dalla rete virtuale.

L'indirizzo IP privato assegnato all'istanza viene esposto tramite la variabile di ambiente "WEBSITE_PRIVATE_IP". L'interfaccia utente della console Kudu mostra anche l'elenco delle variabili di ambiente disponibili per l'app Web. Questo indirizzo IP viene assegnato dall'intervallo di indirizzi della subnet integrata. Questo indirizzo IP viene usato dall'app Web per connettersi alle risorse tramite la rete virtuale di Azure.

Nota

Il valore di WEBSITE_PRIVATE_IP è associato alla modifica. Tuttavia, sarà un indirizzo IP all'interno dell'intervallo di indirizzi della subnet di integrazione, quindi sarà necessario consentire l'accesso dall'intero intervallo di indirizzi.

Dettagli sui prezzi

La funzionalità di integrazione della rete virtuale non prevede costi aggiuntivi per l'uso oltre i costi del piano tariffario del piano di servizio app.

Risoluzione dei problemi

La funzionalità è facile da configurare, ma ciò non significa che l'esperienza non comporti problemi. Se si verificano problemi di accesso all'endpoint desiderato, è possibile eseguire vari passaggi a seconda di ciò che si sta osservando. Per altre informazioni, vedere la guida alla risoluzione dei problemi di integrazione della rete virtuale.

Nota

• L'integrazione della rete virtuale non è supportata per gli scenari Docker Compose nel Servizio app.
• Le restrizioni di accesso non si applicano al traffico proveniente da un endpoint privato.

Eliminazione del piano di servizio app o dell'app prima di disconnettere l'integrazione di rete

Se l'app o il piano di servizio app sono stati eliminati senza disconnettere prima l'integrazione della rete virtuale, non è possibile eseguire alcuna operazione di aggiornamento/eliminazione nella rete virtuale o nella subnet usata per l'integrazione con la risorsa eliminata. Una delega della subnet 'Microsoft.Web/serverFarms' rimane assegnata alla subnet e impedisce le operazioni di aggiornamento ed eliminazione.

Per eseguire di nuovo l'aggiornamento o l'eliminazione della subnet o della rete virtuale, è necessario ricreare l'integrazione della rete virtuale e quindi disconnetterla:

1. Ricreare il piano di servizio app e l'app (è obbligatorio usare esattamente lo stesso nome dell'app Web di prima).
2. Passare a Rete nell'app nel portale di Azure e configurare l'integrazione rete virtuale.
3. Dopo aver configurato l'integrazione della rete virtuale, selezionare il pulsante "Disconnetti".
4. Eliminare il piano di servizio app o l'app.
5. Aggiornare/eliminare la subnet o la rete virtuale.

Se si verificano ancora problemi con l'integrazione rete virtuale dopo aver seguito questa procedura, contattare il supporto tecnico Microsoft.