Hosting di più siti in un gateway applicazione

L'hosting di più siti 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 con caratteri jolly nel listener.

Importante

Le regole vengono elaborate nell'ordine in cui sono elencate nel portale per lo SKU v1. Per la priorità della regola di utilizzo sku v2 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 multisito per assicurarsi che il traffico client venga instradato al back-end accurato, è importante avere le regole di routing delle richieste presenti nell'ordine corretto. Ad esempio, se sono presenti 2 listener con nome host associato come *.contoso.com e shop.contoso.com rispettivamente, il listener con il shop.contoso.com nome host deve essere elaborato prima del listener con *.contoso.com. Se il listener con *.contoso.com viene elaborato prima, nessun traffico client verrà ricevuto dal listener più specifico shop.contoso.com .

Questo ordinamento può essere stabilito fornendo un valore di campo "Priorità" alle regole di gestione 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. Nel caso in cui il traffico client in ingresso corrisponda a più listener, la regola di routing delle richieste con priorità massima verrà usata per la gestione della richiesta. Ogni regola di gestione 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, questa modifica l'ordine di valutazione delle regole basate sul percorso all'interno di una PathBasedRouting regola di routing delle richieste.

Nota

Se si vuole usare la priorità della regola, è necessario specificare i valori dei campi di priorità delle regole per tutte le regole di routing delle richieste esistenti. Dopo aver usato il campo della priorità della regola, qualsiasi nuova regola di routing creata deve avere anche un valore del campo di priorità della regola come parte della relativa configurazione. A partire dall'API versione 2021-08-01, il campo di priorità della regola sarebbe un campo obbligatorio come parte delle regole di routing delle richieste. Da questa versione dell'API, i valori dei campi di priorità della regola verranno popolati automaticamente per le regole di gestione delle richieste esistenti in base all'ordinamento corrente della valutazione come parte della prima chiamata PUT. Tutti gli aggiornamenti futuri per richiedere le regole di gestione devono avere il campo di priorità della regola fornito come parte della configurazione.

Importante

I valori di campo priorità regola per le regole di routing delle richieste esistenti in base all'ordine corrente verranno popolati automaticamente se eventuali aggiornamenti di configurazione vengono applicati usando l'API versione 2021-08-01 e successiva, il portale, Azure PowerShell e l'interfaccia della riga di comando di Azure. Tutti gli aggiornamenti futuri per richiedere le regole di gestione devono avere il campo di priorità della regola fornito come parte della configurazione.

Nomi host con caratteri jolly nel listener

gateway applicazione consente il routing basato su host usando il listener HTTP(S) multisito. 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) multisito. Ad esempio, *.contoso.com.

Usando un carattere jolly nel nome host, è possibile corrispondere a più nomi host in un singolo listener. Ad esempio, *.contoso.com può corrispondere a ecom.contoso.comb2b.contoso.com e customer1.b2b.contoso.com 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 le richieste per entrambi i nomi host.

Nota

Questa funzionalità è disponibile solo per Standard_v2 e WAF_v2 SKU di 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, usare -HostNames "*.contoso.com","*.fabrikam.com"

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

Nella portale di Azure, nel listener multisito, è necessario scegliere il tipo host Multiple/Wildcard per indicare fino a cinque nomi host con caratteri jolly consentiti.

Caratteri consentiti nel campo nomi host

• (A-Z,a-z,0-9) - caratteri alfanumerici
• - - trattino o meno
• . - periodo 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 un nome host. Ad esempio, component1*.component2*.component3. (*.contoso-*.com) è valido.
• Possono essere presenti fino a due asterischi * in un nome host. Ad esempio, *.contoso.* è valido e *.contoso.*.*.com non è valido.
• Può essere presente un massimo di 4 caratteri jolly in un nome host. Ad esempio, ????.contoso.com, w??.contoso*.edu.* sono validi, ma ????.contoso.* non sono validi.
• L'uso dell'asterisco * e del punto ? interrogativo in un componente di un nome host (*? o o ?***) non è valido. Ad esempio, *?.contoso.com e **.contoso.com non sono validi.

Considerazioni e limitazioni sull'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 multisito, è possibile immettere anche il nome host, in genere si tratta del CN del certificato SSL. Quando si specificano più nomi host nel listener o si usano caratteri jolly, è necessario considerare quanto segue:
  • Se è un nome host jolly come *.contoso.com, è necessario caricare un certificato con caratteri jolly con CN come *.contoso.com
  • Se più nomi host sono menzionati nello stesso listener, è necessario caricare un certificato SAN (Nomi alternativi soggetto) con i nomi host corrispondenti ai nomi host indicati.
• Non è possibile usare un'espressione regolare per indicare 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 dell'host locale 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 verranno indirizzate al pool back-end a seconda del tipo di regola (base o basato sul percorso).
• La proprietà "hostname" accetta una stringa come input, in cui è possibile menzionare un solo nome di dominio non jolly. La proprietà "hostnames" accetta 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 multisito.

Intestazioni host e indicazione nome server (SNI)

Per abilitare l'hosting di più siti nella stessa infrastruttura sono disponibili tre comuni meccanismi.

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 gateway applicazione supporta un singolo indirizzo IP pubblico in cui è in ascolto del traffico. Quindi più applicazioni, ognuna con il proprio indirizzo IP non è attualmente supportata.

gateway applicazione supporta più applicazioni in ascolto 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 ospitati nel gateway applicazione possono supportare anche l'offload TLS con estensione TLS (Server Name Indication) (SNI). 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 più hosting del sito in gateway applicazione

• Uso del portale di Azure
• Uso di Azure PowerShell
• Utilizzare l'interfaccia della riga di comando di Azure

Per una distribuzione basata su modello end-to-end, vedere il modello di Resource Manager con hosting di più siti.