Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
L'hosting multisito consente di configurare più applicazioni web sulla stessa porta dei gateway applicativi usando listener esposti pubblicamente. 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 applicativo. Si creeranno tre listener multisito e si configurerà ogni listener per la rispettiva impostazione della porta e del protocollo.
In un listener multisito è inoltre possibile definire nomi host con caratteri wildcard e fino a 5 nomi host per listener. Per maggiori 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 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 di un gateway applicativo.
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 PathBasedRouting regola di routing delle richieste.
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. Una volta utilizzato il campo di priorità della regola, qualsiasi nuova regola di instradamento creata deve includere nella sua configurazione un valore per il campo di priorità della regola.
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 del campo Priorità per le regole di instradamento delle richieste esistenti, in base all'ordine di valutazione corrente durante la prima chiamata PUT, vengono compilati automaticamente se vengono applicati aggiornamenti della configurazione usando la versione API 2021-08-01 e successive, il portale, Azure PowerShell e 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 wildcard nel listener
Application Gateway consente il routing basato su host tramite listener HTTP(S) multisito. Ora è possibile usare caratteri jolly come l'asterisco (*) e il punto interrogativo (?) nel nome host e fino a 5 nomi host per ogni listener HTTP(S) multisito. Ad esempio, *.contoso.com.
Utilizzando un carattere jolly nel nome host, è possibile far corrispondere più nomi host all'interno di 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.
Nota
Questa funzionalità è disponibile solo per le SKU Standard_v2 e WAF_v2 di Application Gateway.
In Azure PowerShellè necessario usare -HostNames anziché -HostName. Con HostNames, è possibile specificare fino a 5 nomi host separati da virgole e utilizzare 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 specificare fino a 5 nomi host separati da virgole e utilizzare caratteri jolly. Ad esempio, --host-names "*.contoso.com,*.fabrikam.com".
Nel portale di Azure, in corrispondenza del listener multisito, è necessario scegliere il tipo di host Multiple/Wildcard per specificare 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 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 nomi host multipli in un listener
Le seguenti condizioni si applicano quando si utilizzano caratteri jolly o più nomi host in un listener.
| Constraint | Limit | Esempio |
|---|---|---|
| Nomi host in un singolo ascoltatore | Fino a 5 | Non applicabile |
Asterisco (*) in una componente di un nome di stile di dominio o di un nome host |
Può essere menzionato solo una volta |
component1*.component2*.component3.
(*.contoso-*.com) è valido. |
Asterischi (*) in un nome host |
Fino a due |
*.contoso.* è valido ed *.contoso.*.*.com è invalido. |
| Personaggi jolly in un nome host | Massimo di 4 |
????.contoso.com e w??.contoso*.edu.* sono validi, ma ????.contoso.* sono invalidi. |
Asterisco (*) e punto interrogativo (?) insieme in una componente di un nome host (*? o ?***) |
Non valido |
*?.contoso.com e **.contoso.com sono invalidi. |
Comportamento di corrispondenza di *.contoso.com |
Non corrisponde contoso.com |
*.contoso.com Specifica che un punto è presente prima di Contoso, quindi contoso.com non corrisponde. |
Considerazioni e limitazioni sull'uso di caratteri wildcard o di nomi host multipli 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 oppure si utilizzano caratteri jolly, è necessario considerare quanto segue:
- Se si tratta di un nome host wildcard come *.contoso.com, devi caricare un certificato wildcard con un CN come *.contoso.com
- Se nello stesso listener sono specificati più nomi host, è necessario caricare un certificato SAN (Subject Alternative Names) con i CN corrispondenti ai nomi host indicati.
- Non è possibile usare un'espressione regolare per menzionare il nome host. È possibile usare solo caratteri jolly come l'asterisco (*) e il punto interrogativo (?) per creare il modello del nome host.
- Per la verifica dello stato del back-end, non è possibile associare più probe personalizzate a una singola impostazione HTTP. In alternativa, è possibile verificare uno dei siti Web sul back-end oppure usare "127.0.0.1" per verificare il localhost del server back-end. Tuttavia, quando si utilizzano caratteri wildcard o più nomi host in un listener, le richieste per tutti i pattern di dominio specificati vengono instradate al pool di back-end a seconda del tipo di regola (di base o basata sul percorso).
- La proprietà "hostname" accetta come input una stringa in cui è possibile specificare un solo nome di dominio senza caratteri jolly. La proprietà "hostnames" accetta come input un array di stringhe, in cui è possibile specificare fino a 5 nomi di dominio wildcard. 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 multisito per TLS e listener protocollo TCP
La funzionalità multisito è anche disponibile per il proxy Layer4, ma solo per i relativi listener TLS. Il traffico per ogni applicazione può essere indirizzato al proprio pool back-end inserendo nomi di dominio nel listener TLS. Per il funzionamento della funzionalità multisito nei listener TLS, Application Gateway usa il valore dell'indicazione del nome del server (SNI) (i client presentano principalmente l'estensione SNI per ottenere il certificato TLS corretto). Un listener TLS multisito selezionerebbe questo valore SNI dai dati handshake TLS di una connessione in entrata per trasferire tale connessione al pool backend appropriato. Per eredità, la connessione TCP non presenta un concetto del nome host o del nome di dominio, di conseguenza non è disponibile per i listener TCP.
Intestazioni Host e indicazione del nome del server (SNI)
Esistono tre meccanismi comuni per abilitare l'hosting multisito sulla stessa infrastruttura.
- Ospitare più applicazioni Web con un indirizzo IP univoco per ognuna.
- Usare il nome host per ospitare più applicazioni Web nello stesso indirizzo IP.
- Usare porte diverse per ospitare più applicazioni Web nello stesso indirizzo IP.
Attualmente Application Gateway supporta un singolo indirizzo IP pubblico su cui riceve il traffico. Di conseguenza, non è attualmente possibile supportare più applicazioni ognuna con il proprio indirizzo IP.
Application Gateway supporta più applicazioni, ciascuna in ascolto su porte diverse, ma questo scenario prevede che le applicazioni accettino il traffico su porte non standard.
Application Gateway si basa sulle intestazioni host HTTP 1.1 per ospitare più siti Web sullo stesso indirizzo IP pubblico e sulla stessa porta. I siti ospitati in Application Gateway possono anche supportare l'offload TLS con l'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 l'hosting multisito in Application Gateway
- Tramite il portale di Azure
- Uso di Azure PowerShell
- Utilizzare l'interfaccia della riga di comando di Azure
Consultare il template di Resource Manager che usa l'hosting multisito per una distribuzione end-to-end basata su template.