Hosting multi-sito del gateway applicazione

  • Articolo

L'hosting multi-sito consente di configurare più applicazioni Web nella stessa porta dei gateway applicazione usando listener pubblici. 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 altre informazioni, vedere nomi host jolly nel listener.

Multi-site Application Gateway

Importante

Le regole vengono elaborate nell'ordine in cui sono elencate nel portale per lo SKU v1. Per lo SKU v2 usare la priorità della regola per specificare l'ordine di elaborazione. È consigliabile configurare i listener multisito prima di configurare un listener di base. In questo modo il traffico viene indirizzato al back-end appropriato. Se un listener di base viene elencato per primo e corrisponde a una richiesta in ingresso, sarà tale listener a elaborarla.

Per le richieste http://contoso.com viene eseguito il routing verso ContosoServerPool mentre per le richieste http://fabrikam.com viene eseguito il routing verso FabrikamServerPool.

Analogamente, è possibile ospitare più sottodomini dello stesso dominio padre nella stessa distribuzione del gateway applicazione. Ad esempio, è possibile ospitare http://blog.contoso.com e http://app.contoso.com in una singola distribuzione del gateway applicazione.

Ordine di valutazione delle regole di routing delle richieste

Quando si usano listener multi-sito per assicurarsi che il traffico client venga instradato fino al back-end accurato, è importante che le regole di routing delle richieste siano nell'ordine corretto. Ad esempio, se si hanno 2 listener con nomi host associati *.contoso.com e shop.contoso.com, il listener con il nome host shop.contoso.com deve essere elaborato prima del listener con *.contoso.com. Se il listener con *.contoso.com viene elaborato per primo, non viene ricevuto alcun traffico client dal listener shop.contoso.com più specifico.

L'ordine delle regole può essere stabilito fornendo un valore di campo priorità alle regole di routing delle richieste associate ai listener. È possibile specificare un valore intero da 1 a 20000, dove 1 è la priorità più bassa e 20000 la priorità più alta. Se il traffico client in ingresso corrisponde a più listener, la regola di routing delle richieste con priorità più alta viene usata per gestire la richiesta. Ogni regola di routing delle richieste deve avere un valore di priorità univoco.

Il campo priorità influisce solo sull'ordine di valutazione di una regola di routing delle richieste che non modifica l'ordine di valutazione delle regole basate sul percorso all'interno di una regola di routing delle richieste PathBasedRouting.

Nota

Per usare la priorità delle regole, è necessario specificare i valori dei campi di priorità delle regole per tutte le regole di routing delle richieste esistenti. Quando il campo della priorità della regola è in uso, qualsiasi nuova regola di routing creata deve avere un valore di campo di priorità di regola come parte della configurazione.

Importante

A partire dall'API versione 2021-08-01, il campo di priorità di regola è un campo obbligatorio nelle regole di routing delle richieste. I valori dei campi di priorità delle regole per le regole di routing delle richieste esistenti, in base all'ordinamento corrente della valutazione come parte della prima chiamata PUT, vengono popolati automaticamente se vengono applicati aggiornamenti della configurazione usando la versione 2021-08-01 e successive, il portale, Azure PowerShell e l'interfaccia della riga di comando di Azure. Gli aggiornamenti futuri delle regole di routing delle richieste devono avere il campo di priorità della regola come parte della configurazione.

Nomi host jolly nel listener

Il gateway applicazione consente il routing basato su host usando il listener HTTP(S) multi-sito. A questo punto, è possibile usare caratteri jolly come asterisco (*) e punto interrogativo (?) nel nome host e fino a 5 nomi host per listener HTTP(S) multi-sito. Ad esempio, *.contoso.com.

Usando un carattere jolly nel nome host, è possibile trovare più nomi host in un singolo listener. Ad esempio, *.contoso.com può corrispondere a ecom.contoso.com, b2b.contoso.com, customer1.b2b.contoso.com e così via. Usando una matrice di nomi host, è possibile configurare più di un nome host per un listener per instradare le richieste a un pool back-end. Ad esempio, un listener può contenere contoso.com, fabrikam.com che accetta richieste per entrambi i nomi host.

Wildcard Listener

Nota

Questa funzionalità è disponibile solo per Standard_v2 e WAF_v2 SKU del gateway applicazione.

In Azure PowerShellè necessario usare -HostNames anziché -HostName. Con HostNames è possibile menzionare fino a 5 nomi host come valori delimitati da virgole e usare caratteri jolly. Ad esempio, -HostNames "*.contoso.com","*.fabrikam.com".

Nell'interfaccia della riga di comando di Azure si deve usare --host-names anziché --host-name. Con i nomi host, è possibile menzionare fino a 5 nomi host come valori delimitati da virgole e usare caratteri jolly. Ad esempio, --host-names "*.contoso.com,*.fabrikam.com".

Nel portale di Azure, nel listener multi-sito, si deve scegliere il tipo di host multiple/wildcard per menzionare fino a cinque nomi host con caratteri jolly consentiti.

Wildcard Listener UI

Caratteri consentiti nel campo nomi host

  • (A-Z,a-z,0-9) - Caratteri alfanumerici
  • - - trattino o segno del meno
  • . - punto come delimitatore
  • * - può corrispondere a più caratteri nell'intervallo consentito
  • ? - può corrispondere a un singolo carattere nell'intervallo consentito

Condizioni per l'uso di caratteri jolly e più nomi host in un listener

  • È possibile menzionare solo fino a 5 nomi host in un singolo listener
  • L'asterisco * può essere menzionato una sola volta in un componente di un nome di stile di dominio o di un nome host. Ad esempio, component1*.component2*.component3. (*.contoso-*.com) è valido.
  • In un nome host ci possono essere solo due asterischi *. Ad esempio, *.contoso.* è valido e *.contoso.*.*.com non è valido.
  • In un nome host ci possono essere massimo di 4 caratteri jolly. Ad esempio, ????.contoso.com, w??.contoso*.edu.* sono validi, ma ????.contoso.* non è valido.
  • L'uso di asterisco * e punto interrogativo ? insieme in un componente di un nome host (*?, ?* o **) non è valido. Ad esempio, *?.contoso.com e **.contoso.com non sono validi.

Considerazioni e limitazioni relative all'uso di caratteri jolly o più nomi host in un listener

  • La terminazione SSL e SSL end-to-end richiede di configurare il protocollo come HTTPS e caricare un certificato da usare nella configurazione del listener. Se si tratta di un listener multi-sito, è possibile immettere anche il nome host, in genere questo è il CN del certificato SSL. Quando si specificano più nomi host nel listener o si usano caratteri jolly, si deve considerare quanto segue:
    • Se si tratta di un nome host con caratteri jolly come *.contoso.com, si deve caricare un certificato con caratteri jolly con CN come *.contoso.com
    • Se nello stesso listener vengono menzionati più nomi host, è necessario caricare un certificato SAN (Nomi alternativi soggetto) con i nomi host corrispondenti ai nomi host indicati.
  • Non è possibile usare un'espressione regolare per menzionare il nome host. È possibile usare solo caratteri jolly come asterisco (*) e punto interrogativo (?) per formare il modello di nome host.
  • Per il controllo dell'integrità back-end, non è possibile associare più probe personalizzati per ogni impostazione HTTP. È invece possibile eseguire il probe di uno dei siti Web nel back-end o usare "127.0.0.1" per eseguire il probe del localhost del server back-end. Tuttavia, quando si usano caratteri jolly o più nomi host in un listener, le richieste per tutti i modelli di dominio specificati vengono instradate al pool back-end a seconda del tipo di regola (base o in base al percorso).
  • La proprietà "hostname" prende una stringa come input, in cui è possibile menzionare un solo nome di dominio senza caratteri jolly. La proprietà "hostnames" prende una matrice di stringhe come input, in cui è possibile menzionare fino a 5 nomi di dominio con caratteri jolly. Entrambe queste proprietà non possono essere usate contemporaneamente.

Vedere creare più siti usando azure PowerShell o usando l'interfaccia della riga di comando di Azure per la guida dettagliata su come configurare i nomi host con caratteri jolly in un listener multi-sito.

Listener multi-sito per il proxy di livello 4 del gateway applicazione

L'hosting multi-sito consente di configurare più applicazioni TLS back-end o TCP sulla stessa porta del gateway applicazione. A tale scopo, è possibile usare solo listener TLS. In questo modo è possibile configurare una topologia più efficiente per le distribuzioni aggiungendo più applicazioni back-end sulla stessa porta usando un singolo gateway applicazione. Il traffico per ogni applicazione può essere indirizzato al proprio pool back-end inserendo nomi di dominio nel listener TLS.

Ad esempio, è possibile creare tre listener multisito ognuno con il proprio dominio (contoso.com, fabrikam.com e *.adatum.com) e indirizzarli ai rispettivi pool back-end con applicazioni diverse. Tutti e tre i domini devono puntare all'indirizzo IP front-end del gateway applicazione. Questa funzionalità è in fase di anteprima per l'uso con il proxy di livello 4.

Informazioni sulle funzionalità:

  • Il listener multi-sito consente di aggiungere listener usando lo stesso numero di porta.
  • Per i listener TLS multi-sito, il gateway applicazione usa il valore SNI (Server Name Indication). Il valore SNI viene usato principalmente per mostrare ai client il certificato del server di dominio e instradare una connessione al pool back-end appropriato. Questa operazione viene eseguita selezionando il nome comune nei dati di handshake TLS di una connessione in ingresso.
  • Il gateway applicazione consente il routing basato su dominio usando il listener TLS multi-sito. È possibile usare caratteri jolly come asterisco (*) e punto interrogativo (?) nel nome host e fino a 5 domini per listener TLS multi-sito. ad esempio *.contoso.com.
  • La connessione TCP non ha intrinsecamente alcun concetto di nome host o nome di dominio. Di conseguenza, con il proxy di livello 4 il listener multi-sito non è supportato per i listener TCP.

Intestazioni host e indicazione nome server (SNI)

Esistono tre meccanismi comuni per abilitare l'hosting multi-sito nella stessa infrastruttura.

  1. Ospitare più applicazioni Web con un indirizzo IP univoco per ognuna.
  2. Usare il nome host per ospitare più applicazioni Web nello stesso indirizzo IP.
  3. Usare porte diverse per ospitare più applicazioni Web nello stesso indirizzo IP.

Attualmente il gateway applicazione supporta un singolo indirizzo IP pubblico dove ascolta il traffico. Di conseguenza, non è attualmente possibile supportare più applicazioni ognuna con il proprio indirizzo IP.

Il gateway applicazione supporta più applicazioni che ascoltano su porte diverse, ma questo scenario richiede alle applicazioni di accettare il traffico su porte non standard.

Il gateway applicazione si basa su intestazioni host HTTP 1.1 per ospitare più siti Web nello stesso indirizzo IP pubblico e nella stessa porta. I siti ospiti nel gateway applicazione possono anche supportare l'offload TLS con l'estensione TLS SNI (Server Name Indication). In questo scenario il browser client e la Web farm back-end devono quindi supportare HTTP/1.1 e l'estensione TLS definita nella specifica RFC 6066.

Passaggi successivi

Informazioni su come configurare l'hosting multi-sito nel gateway applicazione

Vedere modello di Resource Manager usando hosting multi-sito per una distribuzione basata su modelli end-to-end.