Rete per l'ambiente del servizio app
L'ambiente del servizio app è una distribuzione a tenant singolo del servizio app di Azure che ospita contenitori Windows e Linux, app Web, app per le API, app per la logica e app per le funzioni. Quando si installa un ambiente del servizio app, selezionare la rete virtuale di Azure in cui si vuole che venga distribuita. Tutto il traffico delle applicazioni in ingresso e in uscita si trova all'interno della rete virtuale specificata. Si esegue la distribuzione in una singola subnet nella rete virtuale e non è possibile distribuire nient'altro in tale subnet.
Nota
Questo articolo riguarda ambiente del servizio app v3, usato con piani di servizio app isolato v2.
Requisiti della subnet
È necessario delegare la subnet a Microsoft.Web/hostingEnvironmentse la subnet deve essere vuota.
Le dimensioni della subnet possono influire sui limiti di scalabilità delle istanze del piano di servizio app all'interno dell'ambiente del servizio app. Per la scalabilità di produzione, è consigliabile usare uno /24 spazio indirizzi (256 indirizzi) per la subnet. Se si prevede di ridimensionare la capacità massima di 200 istanze nella ambiente del servizio app e si pianificano frequenti operazioni di aumento/riduzione delle prestazioni, è consigliabile usare uno /23 spazio indirizzi (512 indirizzi) per la subnet.
Se si usa una subnet più piccola, tenere presente quanto segue:
- Ogni subnet ha cinque indirizzi riservati a scopo di gestione. Oltre agli indirizzi di gestione, ambiente del servizio app ridimensiona dinamicamente l'infrastruttura di supporto e usa tra 7 e 27 indirizzi, a seconda della configurazione e del carico. È possibile usare gli indirizzi rimanenti per le istanze nel piano di servizio app. La dimensione minima della subnet è uno
/27spazio indirizzi (32 indirizzi). - Per qualsiasi combinazione di sistema operativo/SKU del piano servizio app usata nella ambiente del servizio app come I1v2 Windows, viene creata un'istanza di standby per ogni 20 istanze attive. Le istanze di standby richiedono anche indirizzi IP.
- Quando si ridimensionano i piani di servizio app nel ambiente del servizio app verso l'alto o verso il basso, la quantità di indirizzi IP usati dal piano di servizio app viene temporaneamente raddoppiata mentre l'operazione di ridimensionamento viene completata. Le nuove istanze devono essere completamente operative prima del deprovisioning delle istanze esistenti.
- Gli aggiornamenti della piattaforma necessitano di indirizzi IP gratuiti per garantire che gli aggiornamenti possano verificarsi senza interruzioni del traffico in uscita.
- Al termine delle operazioni di aumento, riduzione o riduzione, potrebbe verificarsi un breve periodo di tempo prima del rilascio degli indirizzi IP. In rari casi, questa operazione può essere fino a 12 ore.
- Se gli indirizzi all'interno della subnet si esauriscono, potrebbe non essere possibile aumentare il numero di istanze dei piani di servizio app nell'ambiente del servizio app. Si potrebbe inoltre verificare un aumento della latenza in caso di traffico intenso, se Microsoft non è in grado di dimensionare l'infrastruttura di supporto.
Nota
I contenitori di 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 il ambiente del servizio app ha ad esempio 2 windows Container servizio app piani ogni con 25 istanze e ognuna con 5 app in esecuzione, saranno necessari 300 indirizzi IP e indirizzi aggiuntivi per supportare la scalabilità orizzontale (in/out).
Calcolo di esempio:
Per ogni istanza del piano di servizio app, è necessario: 5 app contenitore di Windows = 5 indirizzi IP 1 indirizzo IP per ogni istanza del piano servizio app 5 + 1 = 6 indirizzi IP
Per 25 istanze: 6 x 25 = 150 indirizzi IP per piano servizio app
Poiché sono presenti 2 piani di servizio app, 2 x 150 = 300 indirizzi IP.
Indirizzi
Un ambiente del servizio app ha le informazioni di rete seguenti al momento della creazione:
| Tipo di indirizzo | Descrizione |
|---|---|
| Rete virtuale dell'ambiente del servizio app | La rete virtuale distribuita in. |
| Subnet dell'ambiente del servizio app | La subnet distribuita in. |
| Suffisso di dominio | Suffisso di dominio usato dalle app effettuate. |
| IP virtuale (VIP) | Tipo di indirizzo VIP utilizzato. I due valori possibili sono interni ed esterni. |
| Indirizzo in ingresso | L'indirizzo in ingresso è l'indirizzo in cui vengono raggiunte le app. Se si ha un indirizzo VIP interno, si tratta di un indirizzo nella subnet dell'ambiente del servizio app. Se l'indirizzo è esterno, si tratta di un indirizzo pubblico. |
| Indirizzi in uscita predefiniti | Le app usano questo indirizzo, per impostazione predefinita, quando si effettuano chiamate in uscita a Internet. |
È possibile trovare i dettagli nella parte Indirizzi IP del portale, come illustrato nello screenshot seguente:
Quando si ridimensionano i piani di servizio app nel ambiente del servizio app, si usano più indirizzi all'esterno della subnet. Il numero di indirizzi usati varia in base al numero di istanze del piano di servizio app presenti e al volume del traffico. Le app nell'ambiente del servizio app non hanno indirizzi dedicati nella subnet. Gli indirizzi specifici usati da un'app nella subnet cambiano nel tempo.
Bring your own inbound address
È possibile portare il proprio indirizzo in ingresso nella ambiente del servizio app. Se si crea un ambiente del servizio app con un indirizzo VIP interno, è possibile specificare un indirizzo IP statico nella subnet. Se si crea un ambiente del servizio app con un indirizzo VIP esterno, è possibile usare il proprio indirizzo IP pubblico di Azure specificando l'ID risorsa dell'indirizzo IP pubblico. Di seguito sono riportate alcune limitazioni per l'aggiunta di un indirizzo in ingresso:
- Per ambiente del servizio app con indirizzo VIP esterno, la risorsa indirizzo IP pubblico di Azure deve trovarsi nella stessa sottoscrizione del ambiente del servizio app.
- Non è possibile modificare l'indirizzo in ingresso dopo la creazione del ambiente del servizio app.
Porte e restrizioni di rete
Affinché l'app riceva il traffico, assicurarsi che le regole del gruppo di sicurezza di rete in ingresso consentano alla subnet ambiente del servizio app di ricevere traffico dalle porte necessarie. Oltre a qualsiasi porta, si vuole ricevere traffico, è necessario assicurarsi che Azure Load Balancer sia in grado di connettersi alla subnet sulla porta 80. Questa porta viene usata per i controlli di integrità della macchina virtuale interna. È comunque possibile controllare il traffico della porta 80 dalla rete virtuale alla subnet.
È consigliabile configurare la regola NSG in ingresso seguente:
| Porte di origine/destinazione | Direction | Source (Sorgente) | Destination | Scopo |
|---|---|---|---|---|
| * / 80,443 | In entrata | VirtualNetwork | intervallo di subnet ambiente del servizio app | Consentire il traffico dell'app e il traffico ping di integrità interno |
Il requisito minimo per ambiente del servizio app essere operativo è:
| Porte di origine/destinazione | Direction | Source (Sorgente) | Destination | Scopo |
|---|---|---|---|---|
| * / 80 | In entrata | AzureLoadBalancer | intervallo di subnet ambiente del servizio app | Consenti traffico ping integrità interno |
Se si usa la regola minima richiesta, potrebbe essere necessaria una o più regole per il traffico dell'applicazione. Se si usa una delle opzioni di distribuzione o debug, è necessario consentire anche questo traffico alla subnet ambiente del servizio app. L'origine di queste regole può essere la rete virtuale o uno o più indirizzi IP client o intervalli IP specifici. La destinazione è sempre l'intervallo di subnet ambiente del servizio app. Il traffico ping di integrità interno sulla porta 80 è isolato tra il servizio di bilanciamento del carico e i server interni. Nessun traffico esterno può raggiungere l'endpoint ping di integrità.
Le normali porte di accesso alle app in ingresso sono le seguenti:
| Utilizzo | Porti |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Debug remoto in Visual Studio | 4022, 4024, 4026 |
| Servizio Distribuzione Web | 8172 |
Nota
Per l'accesso FTP, anche se si vuole impedire FTP standard sulla porta 21, è comunque necessario consentire il traffico da LoadBalancer all'intervallo di subnet ambiente del servizio app sulla porta 21, perché viene usato per il traffico ping di integrità interno per il servizio ftp in particolare.
Routing di rete
È possibile impostare tabelle di route senza restrizioni. È possibile eseguire il tunneling di tutto il traffico delle applicazioni in uscita dal ambiente del servizio app a un dispositivo firewall in uscita, ad esempio Firewall di Azure. In questo scenario, l'unica cosa che è necessario preoccuparsi è che 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, le dipendenze possono anche essere endpoint derivati, ad esempio endpoint di controllo dell'elenco di revoche di certificati (CRL) e endpoint di identità/autenticazione, ad esempio MICROSOFT Entra ID. Se si usa la distribuzione continua in servizio app, potrebbe anche essere necessario consentire gli endpoint a seconda del tipo e della lingua. In particolare per la distribuzione continua di Linux, è necessario consentire oryx-cdn.microsoft.io:443.
È possibile inserire i dispositivi web application firewall, ad esempio app Azure lication Gateway, davanti al traffico in ingresso. In questo modo è possibile esporre app specifiche su tale ambiente del servizio app.
L'applicazione usa uno degli indirizzi in uscita predefiniti per il traffico in uscita verso endpoint pubblici. Se si vuole personalizzare l'indirizzo in uscita delle applicazioni in un ambiente del servizio app, è possibile aggiungere un gateway NAT alla subnet.
Nota
La connettività SMTP in uscita (porta 25) è supportata per ambiente del servizio app v3. 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 e risoluzione dei problemi, vedere Risolvere i problemi di connettività SMTP in uscita in Azure.
Endpoint privato
Per abilitare gli endpoint privati per le app ospitate nel ambiente del servizio app, è prima necessario abilitare questa funzionalità a livello di ambiente del servizio app.
È possibile attivarlo tramite il portale di Azure. Nel riquadro di configurazione ambiente del servizio app attivare l'impostazione Allow new private endpoints.
In alternativa, l'interfaccia della riga di comando seguente può abilitarla:
az appservice ase update --name myasename --allow-new-private-endpoint-connections true
Per altre informazioni sull'endpoint privato e sull'app Web, vedere Endpoint privato dell'app Web di Azure
DNS
Le sezioni seguenti descrivono le considerazioni e la configurazione DNS che si applicano in ingresso e in uscita dal ambiente del servizio app. Gli esempi usano il suffisso appserviceenvironment.net di dominio dal cloud pubblico di Azure. Se si usano altri cloud come Azure per enti pubblici, è necessario usare il rispettivo suffisso di dominio. Per ambiente del servizio app domini, il nome del sito viene troncato a 40 caratteri a causa dei limiti DNS. Se si dispone di uno slot, il nome dello slot viene troncato a 19 caratteri.
Configurazione DNS per il ambiente del servizio app
Se il ambiente del servizio app viene creato con un indirizzo VIP esterno, le app vengono inserite automaticamente nel DNS pubblico. Se il ambiente del servizio app viene creato con un indirizzo VIP interno, quando si crea il ambiente del servizio app, se si seleziona la configurazione automatica delle zone private DNS di Azure, il DNS viene configurato nella rete virtuale. Se si sceglie di configurare il DNS manualmente, è necessario usare il proprio server DNS o configurare le zone private dns di Azure. Per trovare l'indirizzo in ingresso, passare al portale di ambiente del servizio app e selezionare Indirizzi IP.
Se si vuole usare il proprio server DNS, aggiungere i record seguenti:
- Creare una zona per
<App Service Environment-name>.appserviceenvironment.net. - Creare un record A in tale zona che punta * all'indirizzo IP in ingresso usato dal ambiente del servizio app.
- Creare un record A in tale zona che punta all'indirizzo IP in ingresso usato dal ambiente del servizio app.
- Creare una zona in
<App Service Environment-name>.appserviceenvironment.netdenominatascm. - Creare un record A nella
scmzona che punta * all'indirizzo IP usato dall'endpoint privato del ambiente del servizio app.
Per configurare DNS nelle zone private di DNS di Azure:
- Creare una zona privata DNS di Azure denominata
<App Service Environment-name>.appserviceenvironment.net. - Creare un record A in tale zona che punta * all'indirizzo IP in ingresso.
- Creare un record A in tale zona che punta @ all'indirizzo IP in ingresso.
- Creare un record A in tale zona che punta *.scm all'indirizzo IP in ingresso.
Oltre al dominio predefinito fornito quando viene creata un'app, è anche possibile aggiungere un dominio personalizzato all'app. È possibile impostare un nome di dominio personalizzato senza convalida nelle app. Se si usano domini personalizzati, è necessario assicurarsi che siano configurati record DNS. È possibile seguire le indicazioni precedenti per configurare zone e record DNS per un nome di dominio personalizzato (sostituire il nome di dominio predefinito con il nome di dominio personalizzato). Il nome di dominio personalizzato funziona per le richieste di app, ma non funziona per il scm sito. Il scm sito è disponibile solo in <appname.scm>.<asename.appserviceenvironment.net>.
Configurazione DNS per l'accesso FTP
Per l'accesso FTP al servizio di bilanciamento del carico interno (ILB) ambiente del servizio app v3 in particolare, è necessario assicurarsi che DNS sia configurato. Configurare una zona privata DNS di Azure o un DNS personalizzato equivalente con le impostazioni seguenti:
- Creare una zona privata DNS di Azure denominata
ftp.appserviceenvironment.net. - Creare un record A in tale zona che punta
<App Service Environment-name>all'indirizzo IP in ingresso.
Oltre a configurare IL DNS, è anche necessario abilitarlo nella configurazione ambiente del servizio app e a livello di app.
Configurazione DNS dal ambiente del servizio app
Le app nel ambiente del servizio app usano il DNS con cui è configurata la rete virtuale. Se si vuole che alcune app usino un server DNS diverso, è possibile impostarla manualmente per ogni app, con le impostazioni WEBSITE_DNS_SERVER dell'app e WEBSITE_DNS_ALT_SERVER. WEBSITE_DNS_ALT_SERVER configura il server DNS secondario. Il server DNS secondario viene usato solo quando non è presente alcuna risposta dal server DNS primario.