Componenti del gateway applicazione
Un gateway applicazione funge da singolo 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/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 ottenere un indirizzo IP pubblico, un indirizzo IP privato o entrambi. Un gateway applicazione supporta un solo indirizzo IP pubblico o privato. La rete virtuale e l'indirizzo IP pubblico devono trovarsi nella stessa posizione del gateway applicazione. Una volta creato, l'indirizzo IP front-end è associato a un listener.
Indirizzo IP pubblico statico e dinamico
Lo SKU V2 del gateway applicazione di Azure può essere configurato in modo che supporti sia l'indirizzo IP interno statico sia l'indirizzo IP pubblico statico o solo l'indirizzo IP pubblico statico. Non può essere configurato in modo che supporti solo l'indirizzo IP interno statico.
Lo SKU V1 può essere configurato in modo che supporti l'indirizzo IP interno statico o dinamico e l'indirizzo IP pubblico dinamico. L'indirizzo IP dinamico del gateway applicazione non cambia in un gateway in esecuzione. Può subire modifiche solo quando si arresta o si avvia il gateway. Rimane invariato in caso di errori di sistema, aggiornamenti, aggiornamenti host di Azure e così via.
Il nome DNS associato a un gateway applicazione non cambia durante il ciclo di vita del gateway. Di conseguenza, è consigliabile usare un alias CNAME che punti 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. È possibile associare più listener a un gateway applicazione, quindi usarli per lo stesso protocollo.
Dopo che un listener ha rilevato le richieste in ingresso dai client, il gateway applicazione indirizza queste richieste ai membri nel pool back-end configurato nella regola.
I listener supportano le porte e i protocolli di seguito.
Porti
Una porta è la posizione in cui un listener è in ascolto della richiesta client. Le porte per gli SKU v1 e v2 possono essere configurate come indicato di seguito.
| SKU | Intervallo di porte supportato | Eccezione/i |
|---|---|---|
| V2 | Da 1 a 64.999 | 22, 53 |
| V1 | Da 1 a 65.502 | 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 protocolli WebSocket e HTTP/2 è fornito in modo nativo e il supporto 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 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
Il gateway applicazione consente di creare pagine di errore personalizzate da visualizzare al posto delle pagine di errore predefinite. Con una pagina di errore personalizzata è possibile usare il layout e il marchio aziendali. Il gateway applicazione visualizza una pagina di errore personalizzata quando una richiesta non riesce a raggiungere il back-end.
Per maggiori informazioni, vedere Pagine di errore personalizzate per il gateway applicazione.
Tipi di listener
Ci sono due tipi di listener:
Di base. Questo tipo di listener è in ascolto di un singolo sito di dominio in cui esegue un singolo mapping DNS all'indirizzo IP del gateway applicazione. Questa configurazione del listener è obbligatoria quando si ospita un singolo sito dietro un gateway applicazione.
Multisito. Questa configurazione del listener è obbligatoria quando si desidera configurare il routing in base al nome host o al nome di dominio per più di un'applicazione 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. Si creeranno tre listener multisito e si configurerà ogni listener per la rispettiva impostazione della porta e del protocollo.
È anche possibile definire nomi host con caratteri jolly in un listener multisito e fino a cinque nomi host per ogni listener. Per maggiori informazioni, vedere Nomi host con caratteri jolly nel listener.
Per maggiori informazioni su come configurare un listener multisito, vedere Hosting di più siti nel gateway applicazione tramite il portale di Azure.
Dopo aver creato un listener, associarlo a una regola di gestione delle richieste. Tale regola determina il modo in cui la richiesta ricevuta nel listener viene indirizzata al back-end. La regola di gestione delle richieste contiene anche il pool back-end di indirizzamento e l'impostazione HTTP in cui vengono menzionati la porta back-end, il protocollo e così via.
Richiedere regole di routing
Una regola di gestione delle richieste è un componente chiave di un gateway applicazione in quanto determina come indirizzare il traffico verso il 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 gestione delle richieste trasferisce la richiesta al back-end o la reindirizza altrove. Se la richiesta viene inoltrata al back-end, la regola di gestione delle richieste definisce il pool di server back-end di destinazione. La regola di gestione delle richieste determina anche se è necessario riscrivere le intestazioni nella richiesta. Un listener può essere associato a una sola regola.
Esistono due tipi di regole di gestione 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 gestione consente di indirizzare le richieste verso il listener associato a un pool back-end specifico, in base all'URL contenuto nella richiesta. Se il percorso dell'URL in una richiesta corrisponde al modello di percorso in una regola basata sul percorso, questa indirizza la richiesta in questione. Il modello di percorso viene applicato solo al percorso dell'URL, non ai relativi parametri di query. Se il percorso dell'URL in una richiesta del listener non corrisponde ad alcuna regola basata sul percorso, la richiesta viene indirizzata alle impostazioni HTTP e al pool back-end predefinito.
Per maggiori informazioni, vedere Routing basato sull'URL.
Supporto del reindirizzamento
La regola di gestione delle richieste consente anche di reindirizzare il traffico al gateway applicazione. Si tratta di un meccanismo di reindirizzamento generico che consente di eseguire il reindirizzamento da e verso qualsiasi porta definita mediante regole.
È possibile scegliere come destinazione di reindirizzamento un altro listener (questa opzione può essere utile per abilitare il reindirizzamento automatico da HTTP a HTTPS) o un sito esterno. È anche possibile scegliere se il reindirizzamento sarà temporaneo o permanente, oppure accordare il percorso dell'URI e la stringa di query all'URL reindirizzato.
Per maggiori informazioni, vedere Reindirizzare il traffico sul 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 maggiori informazioni, vedere Riscrivere le intestazioni HTTP e URL sul gateway applicazione.
Impostazioni HTTP
Un gateway applicazione indirizza il traffico ai server back-end (specificati nella regola di gestione delle richieste che includono le impostazioni HTTP) usando il numero di porta, il protocollo e altre impostazioni descritte 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 anche usato per:
Determinare se una sessione utente deve essere mantenuta nello stesso server usando l'affinità di sessione basata su cookie.
Rimuovere in modo graduale i membri del pool back-end usando lo svuotamento della connessione.
Associare un probe personalizzato per monitorare lo stato del back-end, impostare l'intervallo di timeout della richiesta, eseguire l'override del nome host e del percorso nella richiesta e offrire una pratica opzione con un clic per specificare le impostazioni del back-end del servizio app.
Pool back-end
Un pool back-end indirizza la richiesta ai server back-end che la gestiscono. 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 (come il servizio app)
I membri del pool back-end del gateway applicazione non sono associati a un set di disponibilità. Un gateway applicazione può comunicare con le istanze all'esterno della rete virtuale in cui si trova. Di conseguenza, i membri del pool back-end possono trovarsi tra cluster, data center o all'esterno di Azure, purché dotati di connettività IP.
Se si usano indirizzi IP interni come membri del pool back-end, optare per il peering di reti virtuali o per un gateway VPN. Il peering di reti virtuali è supportato e favorisce il traffico di bilanciamento del carico in altre reti virtuali.
Se il traffico è consentito, un gateway applicazione può anche comunicare con i server locali connessi da tunnel Azure ExpressRoute o VPN.
È possibile creare diversi pool back-end per diversi tipi di richieste. Ad esempio, un pool back-end per le richieste generali e un altro pool back-end per le richieste di microservizi per l'applicazione.
Dopo aver aggiunto i set di scalabilità di macchine virtuali come membro del pool back-end, è necessario aggiornarne le istanze. Finché non si aggiornano le istanze dei set di scalabilità, il back-end risulterà non integro.
Probe di integrità
Per impostazione predefinita, un gateway applicazione monitora lo stato di tutte le risorse nel pool back-end e rimuove automaticamente quelle non integre. Continua quindi a monitorare le istanze non integre e le aggiunge nuovamente al pool back-end integro, dopo che sono diventate 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 dello stato. 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 integra, i codici di stato personalizzati, la corrispondenza del corpo della risposta e così via. È consigliabile configurare probe personalizzati per monitorare lo stato di ciascun pool back-end.
Per maggiori informazioni, vedere Monitorare lo stato del gateway applicazione.
Passaggi successivi
Creare un gateway applicazione: