Componenti del gateway applicazione
Un gateway applicazione funge da unico punto di contatto per i client. Distribuisce il traffico delle applicazioni in ingresso tra più pool back-end, tra cui macchine virtuali di Azure, set di scalabilità di macchine virtuali, Servizio app di Azure e server locali o esterni. Per distribuire il traffico, un gateway applicazione usa diversi componenti descritti in questo articolo.
Indirizzi IP front-end
Un indirizzo IP front-end è l'indirizzo IP associato a un gateway applicazione. È possibile configurare un gateway applicazione per avere un indirizzo IP pubblico, un indirizzo IP privato o entrambi. Un gateway applicazione supporta un indirizzo IP pubblico o privato. La rete virtuale e l'indirizzo IP pubblico devono trovarsi nella stessa posizione del gateway applicazione. Dopo la creazione, un indirizzo IP front-end è associato a un listener.
Indirizzo IP pubblico statico e dinamico
Lo SKU V2 del gateway di app Azure può essere configurato per supportare sia l'indirizzo IP interno statico che l'indirizzo IP pubblico statico o solo l'indirizzo IP pubblico statico. Non può essere configurato per supportare solo l'indirizzo IP interno statico.
Lo SKU V1 può essere configurato per supportare l'indirizzo IP interno statico o dinamico e l'indirizzo IP pubblico dinamico. L'indirizzo IP dinamico di gateway applicazione non cambia in un gateway in esecuzione. Può cambiare solo quando si arresta o si avvia il gateway. Non cambia in caso di errori di sistema, aggiornamenti, aggiornamenti host di Azure e così via.
Il nome DNS associato a un gateway applicazione non cambia nel ciclo di vita del gateway. Di conseguenza, è necessario usare un alias CNAME e puntarlo all'indirizzo DNS del gateway applicazione.
Listener
Un listener è un'entità logica che verifica la presenza di richieste di connessione in ingresso. Un listener accetta una richiesta se il protocollo, la porta, il nome host e l'indirizzo IP associati alla richiesta corrispondono agli stessi elementi associati alla configurazione del listener.
Prima di usare un gateway applicazione è necessario aggiungere almeno un listener. Un gateway applicazione può disporre di più listener, che possono essere usati per lo stesso protocollo.
Quando un listener rileva richieste in ingresso dai client, il gateway applicazione instrada queste richieste ai membri nel pool back-end configurato nella regola.
I listener supportano le porte e i protocolli descritti di seguito.
Porti
La porta è la posizione in cui un listener è in ascolto delle richieste dei client. È possibile configurare le porte per gli SKU v1 e v2 come indicato di seguito.
| SKU | Intervallo di porte supportato | Eccezioni |
|---|---|---|
| V2 | Da 1 a 64999 | 22 |
| V1 | Da 1 a 65502 | 3389 |
Protocolli
gateway applicazione supporta protocolli Web HTTP, HTTPS, HTTP/2 e WebSocket con il proxy di livello 7. I protocolli TLS e TCP sono supportati con il proxy di livello 4 (anteprima) e possono essere configurati nella stessa risorsa.
Nota
Il supporto del protocollo HTTP/2 è disponibile per i client che si connettono solo a listener del gateway applicazione. La comunicazione con i pool di server back-end avviene sempre tramite HTTP/1.1. Per impostazione predefinita, il supporto di HTTP/2 è disabilitato. È possibile scegliere di abilitarlo.
- Scegliere tra i protocolli HTTP, HTTPS, TLS o TCP nella configurazione del listener.
- Il supporto per i protocolli WebSocket e HTTP/2 viene fornito in modo nativo e il supporto di WebSocket è abilitato per impostazione predefinita. Non esistono impostazioni configurabili dall'utente per abilitare o disabilitare in modo selettivo il supporto di WebSocket. Usare WebSocket con i listener HTTP e HTTPS.
Usare un listener HTTPS o TLS per la terminazione TLS. Un listener HTTPS/TLS esegue l'offload della crittografia e della decrittografia nel gateway applicazione, in modo che i server non siano sovraccaricati dal sovraccarico di calcolo.
Pagine di errore personalizzate
gateway applicazione consente di creare pagine di errore personalizzate invece di visualizzare le pagine di errore predefinite. Con una pagina di errore personalizzata è possibile usare il layout e il marchio aziendali. gateway applicazione visualizza una pagina di errore personalizzata quando una richiesta non riesce a raggiungere il back-end.
Per altre informazioni, vedere Pagine di errore personalizzate per il gateway applicazione.
Tipi di listener
Esistono due tipi di listener:
Di base. Questo tipo di listener è in ascolto di un singolo sito di dominio, in cui ha un singolo mapping DNS all'indirizzo IP del gateway applicazione. Questa configurazione del listener è necessaria quando si ospita un singolo sito dietro un gateway applicazione.
Multisito. Questa configurazione del listener è necessaria quando si vuole configurare il routing in base al nome host o al nome di dominio per più applicazioni Web nello stesso gateway applicazione. Consente di configurare una topologia più efficiente per le distribuzioni aggiungendo fino a più di 100 siti Web a un unico gateway applicazione. Ogni sito Web può essere indirizzato al proprio pool back-end. Ad esempio, tre domini, contoso.com, fabrikam.com e adatum.com, puntano all'indirizzo IP del gateway applicazione. Creare tre listener multisito e configurare ogni listener per la rispettiva impostazione di porta e protocollo.
È anche possibile definire nomi host con caratteri jolly in un listener multisito e fino a cinque nomi host per ogni listener. Per altre informazioni, vedere nomi host jolly nel listener.
Per altre informazioni su come configurare un listener multisito, vedere Hosting di più siti in gateway applicazione tramite portale di Azure.
Dopo aver creato un listener, associarlo a una regola di routing delle richieste. Questa regola determina il modo in cui la richiesta ricevuta nel listener deve essere instradata al back-end. La regola di routing delle richieste contiene anche il pool back-end da instradare a e l'impostazione HTTP in cui vengono menzionati la porta back-end, il protocollo e così via.
Richiedere regole di routing
Una regola di routing delle richieste è un componente chiave di un gateway applicazione perché determina come instradare il traffico nel listener. La regola associa il listener, il pool di server back-end e le impostazioni HTTP back-end.
Quando un listener accetta una richiesta, la regola di routing della richiesta inoltra la richiesta al back-end o la reindirizza altrove. Se la richiesta viene inoltrata al back-end, la regola di routing delle richieste definisce il pool di server back-end a cui inoltrarlo. La regola di routing delle richieste determina anche se le intestazioni nella richiesta devono essere riscritte. Un listener può essere collegato a una regola.
Esistono due tipi di regole di routing delle richieste:
Di base. Tutte le richieste nel listener associato (ad esempio, blog.contoso.com/*) vengono inoltrate al pool back-end associato usando l'impostazione HTTP associata.
Basato sul percorso. Questa regola di routing consente di instradare le richieste nel listener associato a un pool back-end specifico, in base all'URL nella richiesta. Se il percorso dell'URL in una richiesta corrisponde al modello di percorso in una regola basata sul percorso, la regola instrada tale richiesta. Applica il modello di percorso solo al percorso URL, non ai relativi parametri di query. Se il percorso URL in una richiesta del listener non corrisponde ad alcuna delle regole basate sul percorso, instrada la richiesta alle impostazioni HTTP e al pool back-end predefinito.
Per altre informazioni, vedere Routing basato su URL.
Supporto del reindirizzamento
La regola di routing delle richieste consente anche di reindirizzare il traffico nel gateway applicazione. Si tratta di un meccanismo di reindirizzamento generico che consente di eseguire il reindirizzamento da e verso qualsiasi porta definita usando le regole.
È possibile scegliere la destinazione di reindirizzamento come un altro listener (che consente di abilitare il reindirizzamento HTTP automatico a HTTPS) o un sito esterno. È anche possibile scegliere di fare in modo che il reindirizzamento sia temporaneo o permanente oppure aggiungere il percorso URI e la stringa di query all'URL reindirizzato.
Per altre informazioni, vedere Reindirizzare il traffico nel gateway applicazione.
Riscrivere l'URL e le intestazioni HTTP
Usando le regole di riscrittura, è possibile aggiungere, rimuovere o aggiornare le intestazioni delle richieste e delle risposte HTTP(S), nonché i parametri del percorso URL e della stringa di query quando i pacchetti di richieste e risposte si spostano tra il client e i pool back-end tramite il gateway applicazione.
Le intestazioni e i parametri URL possono essere impostati su valori statici o su altre intestazioni e variabili server. Ciò consente di usare casi d'uso importanti, ad esempio l'estrazione di indirizzi IP client, la rimozione di informazioni riservate sul back-end, l'aggiunta di maggiore sicurezza e così via.
Per altre informazioni, vedere Riscrivere intestazioni HTTP e URL nel gateway applicazione.
Impostazioni HTTP
Un gateway applicazione instrada il traffico ai server back-end (specificati nella regola di routing delle richieste che includono le impostazioni HTTP) usando il numero di porta, il protocollo e altre impostazioni descritte in dettaglio in questo componente.
La porta e il protocollo usati nelle impostazioni HTTP determinano se il traffico tra il gateway applicazione e i server back-end è crittografato (fornendo TLS end-to-end) o non crittografato.
Questo componente viene usato anche per:
Determinare se una sessione utente deve essere mantenuta nello stesso server usando l'affinità di sessione basata su cookie.
Rimuovere normalmente i membri del pool back-end usando lo svuotamento delle connessioni.
Associare un probe personalizzato per monitorare l'integrità del back-end, impostare l'intervallo di timeout della richiesta, eseguire l'override del nome host e del percorso nella richiesta e fornire una facilità con un clic per specificare le impostazioni per il back-end servizio app.
Pool back-end
Un pool back-end instrada la richiesta ai server back-end che gestiscono la richiesta. I pool back-end possono contenere:
- Schede di interfaccia di rete
- set di scalabilità di macchine virtuali
- Indirizzi IP pubblici
- Indirizzi IP interni
- FQDN
- Back-end multi-tenant (ad esempio servizio app)
gateway applicazione membri del pool back-end non sono associati a un set di disponibilità. Un gateway applicazione può comunicare con istanze esterne alla rete virtuale in cui si trova. Di conseguenza, i membri dei pool back-end possono essere tra cluster, tra data center o all'esterno di Azure, purché ci sia connettività IP.
Se si usano indirizzi IP interni come membri del pool back-end, è necessario usare il peering di rete virtuale o un gateway VPN. Il peering di rete virtuale è supportato e vantaggioso per il bilanciamento del carico del traffico in altre reti virtuali.
Un gateway applicazione può anche comunicare con i server locali quando sono connessi da Azure ExpressRoute o tunnel VPN se il traffico è consentito.
È possibile creare pool back-end diversi per diversi tipi di richieste. Ad esempio, creare un pool back-end per le richieste generali e quindi un altro pool back-end per le richieste ai microservizi per l'applicazione.
Dopo aver aggiunto i set di scalabilità di macchine virtuali come membro del pool back-end, è necessario aggiornare le istanze dei set di scalabilità di macchine virtuali. Finché non si aggiornano le istanze dei set di scalabilità, il back-end non sarà integro.
Probe di integrità
Per impostazione predefinita, un gateway applicazione monitora l'integrità di tutte le risorse nel pool back-end e rimuove automaticamente quelle non integre. Monitora quindi le istanze non integre e le aggiunge al pool back-end integro quando diventano disponibili e rispondono ai probe di integrità.
Oltre al monitoraggio del probe di integrità predefinito, è anche possibile personalizzare il probe di integrità in base ai requisiti dell'applicazione. I probe personalizzati consentono un controllo più granulare sul monitoraggio dell'integrità. Quando si usano probe personalizzati, è possibile configurare un nome host personalizzato, un percorso URL, un intervallo di probe e il numero di risposte non riuscite da accettare prima di contrassegnare l'istanza del pool back-end come non integri, codici di stato personalizzati e corrispondenza del corpo della risposta e così via. È consigliabile configurare probe personalizzati per monitorare l'integrità di ogni pool back-end.
Per altre informazioni, vedere Monitorare l'integrità del gateway applicazione.
Passaggi successivi
Creare un gateway applicazione: