Usare Frontdoor di Azure in una soluzione multi-tenant

Frontdoor di Azure è una rete per la distribuzione di contenuti cloud moderna (CDN) che offre accesso rapido e affidabile tra gli utenti e i contenuti Web statici e dinamici delle applicazioni in tutto il mondo. Questo articolo descrive alcune delle funzionalità di Frontdoor di Azure utili quando si lavora in sistemi multi-tenant. Fornisce anche collegamenti ad altre indicazioni ed esempi.

Quando si usa Frontdoor di Azure come parte di una soluzione multi-tenant, è necessario prendere alcune decisioni in base alla progettazione e ai requisiti della soluzione. È necessario considerare i fattori seguenti:

• Quanti tenant si hanno e quanti si prevede di avere in futuro?
• Si condivide il livello applicazione tra più tenant, si distribuiscono molte istanze di applicazioni a tenant singolo o si distribuiscono indicatori di distribuzione separati condivisi da più tenant?
• I tenant vogliono portare i propri nomi di dominio?
• Si useranno domini con caratteri jolly?
• È necessario usare i propri certificati TLS o microsoft gestirà i certificati TLS?
• Sono state considerate le quote e i limiti applicabili a Frontdoor di Azure? Sai quali limiti ti avvicinerai man mano che crei? Se si sospetta di avvicinarsi a questi limiti, è consigliabile usare più profili frontdoor di Azure. In alternativa, valutare se è possibile modificare il modo in cui si usa Frontdoor di Azure per evitare i limiti. Si noti che lo SKU Premium ha limiti superiori rispetto allo SKU Standard.
• Gli utenti o i tenant hanno requisiti per il filtro degli indirizzi IP, il blocco geografico o la personalizzazione delle regole WAF?
• Tutti i server applicazioni dei tenant sono con connessione Internet?

Funzionalità di Frontdoor di Azure che supportano la multi-tenancy

Questa sezione descrive diverse funzionalità principali di Frontdoor di Azure utili per le soluzioni multi-tenant. Descrive in che modo Frontdoor di Azure consente di configurare domini personalizzati, incluse informazioni sui domini con caratteri jolly e sui certificati TLS. Riepiloga anche come usare le funzionalità di routing di Frontdoor di Azure per supportare la multi-tenancy.

Domini personalizzati

Frontdoor di Azure fornisce un nome host predefinito per ogni endpoint creato, ad esempio contoso.z01.azurefd.net. Per la maggior parte delle soluzioni, è invece possibile associare il proprio nome di dominio all'endpoint frontdoor di Azure. I nomi di dominio personalizzati consentono di usare la personalizzazione e configurare il routing in base al nome host fornito nella richiesta di un client.

In una soluzione multi-tenant è possibile usare nomi di dominio o sottodomini specifici del tenant e configurare Frontdoor di Azure per instradare il traffico del tenant al gruppo di origine corretto per il carico di lavoro del tenant. Ad esempio, è possibile configurare un nome di dominio personalizzato come tenant1.app.contoso.com. Con Frontdoor di Azure è possibile configurare più domini personalizzati in un singolo profilo frontdoor di Azure.

Per altre informazioni, vedere Esercitazione: Aggiungere un dominio personalizzato alla Frontdoor.

Domini con caratteri jolly

I domini con caratteri jolly semplificano la configurazione dei record DNS e della configurazione del routing del traffico frontdoor di Azure quando si usano un dominio stem condiviso e sottodomini specifici del tenant. Si supponga, ad esempio, che i tenant accedano alle applicazioni usando sottodomini come tenant1.app.contoso.com e tenant2.app.contoso.com. È possibile configurare un dominio con caratteri jolly, *.app.contoso.com, anziché configurare singolarmente ogni dominio specifico del tenant.

Frontdoor di Azure supporta la creazione di domini personalizzati che usano caratteri jolly. È quindi possibile configurare una route per le richieste che arrivano nel dominio con caratteri jolly. Quando si esegue l'onboarding di un nuovo tenant, non è necessario riconfigurare i server DNS, rilasciare nuovi certificati TLS o aggiornare la configurazione del profilo frontdoor di Azure.

I domini con caratteri jolly funzionano correttamente se si invia tutto il traffico a un singolo gruppo di origine. Tuttavia, se si dispone di francobolli separati della soluzione, un dominio con caratteri jolly a livello singolo non è sufficiente. È necessario usare domini stem multilivello o fornire una configurazione aggiuntiva, ad esempio eseguendo l'override delle route da usare per il sottodominio di ogni tenant. Per altre informazioni, vedere Considerazioni sull'uso dei nomi di dominio in una soluzione multi-tenant.

Frontdoor di Azure non rilascia certificati TLS gestiti per i domini con caratteri jolly, quindi è necessario acquistare e fornire il proprio certificato.

Per altre informazioni, vedere Domini con caratteri jolly.

Certificati TLS gestiti

L'acquisizione e l'installazione di certificati TLS possono essere complesse e soggette a errori. E i certificati TLS scadono dopo un periodo di tempo, in genere un anno, e devono essere rieguiti e reinstallati per evitare interruzioni del traffico dell'applicazione. Quando si usano i certificati TLS gestiti di Frontdoor di Azure, Microsoft è responsabile del rilascio, dell'installazione e del rinnovo dei certificati per il dominio personalizzato.

L'applicazione di origine potrebbe essere ospitata in un altro servizio di Azure che fornisce anche certificati TLS gestiti, ad esempio app Azure Servizio. Frontdoor di Azure funziona in modo trasparente con l'altro servizio per sincronizzare i certificati TLS.

Se si consente ai tenant di fornire i propri domini personalizzati e si vuole che Frontdoor di Azure rilasci i certificati per questi nomi di dominio, i tenant non devono configurare record CAA nei server DNS che potrebbero impedire a Frontdoor di Azure di emettere certificati per loro conto. Per altre informazioni, vedere Certificati TLS/SSL.

Per altre informazioni sui certificati TLS, vedere TLS end-to-end con Frontdoor di Azure.

Routing

Un'applicazione multi-tenant può avere uno o più stamp dell'applicazione che servono i tenant. I francobolli vengono spesso usati per abilitare distribuzioni in più aree e supportare la scalabilità di una soluzione in un numero elevato di tenant.

Frontdoor di Azure offre un potente set di funzionalità di routing che possono supportare una serie di architetture multi-tenant. È possibile usare il routing per distribuire il traffico tra le origini all'interno di un timbro o per inviare il traffico al timbro corretto per un tenant specifico. È possibile configurare il routing in base a singoli nomi di dominio, nomi di dominio con caratteri jolly e percorsi URL. È anche possibile usare il motore regole per personalizzare ulteriormente il comportamento di routing.

Per altre informazioni, vedere Panoramica dell'architettura di routing.

Motore di regole

È possibile usare il motore regole di Frontdoor di Azure per personalizzare il modo in cui Frontdoor di Azure elabora le richieste nel perimetro di rete. Il motore regole consente di eseguire piccoli blocchi di logica all'interno della pipeline di elaborazione delle richieste di Frontdoor di Azure. È possibile usare il motore regole per un'ampia gamma di attività, tra cui:

• Recuperare informazioni sulla richiesta HTTP, inclusi i segmenti dell'URL e del percorso e propagare le informazioni a un'altra parte della richiesta.
• Modificare gli elementi della richiesta HTTP prima dell'invio all'origine.
• Modificare alcune parti della risposta HTTP prima che venga restituita al client.
• Eseguire l'override della configurazione di routing per una richiesta, ad esempio modificando il gruppo di origine a cui deve essere inviata una richiesta.

Ecco alcuni approcci di esempio per l'uso del motore regole di Frontdoor di Azure in una soluzione multi-tenant:

• Si supponga di distribuire un livello applicazione multi-tenant in cui si usano anche sottodomini con caratteri jolly specifici del tenant, come descritto negli scenari di esempio seguenti. È possibile usare il motore regole per estrarre l'identificatore del tenant dal sottodominio della richiesta e aggiungerlo a un'intestazione della richiesta. Questa regola può aiutare il livello applicazione a determinare il tenant da cui proviene la richiesta.
• Si supponga di distribuire un livello applicazione multi-tenant e di usare il routing basato sul percorso ( https://application.contoso.com/tenant1/welcome ad esempio, e https://application.contoso.com/tenant2/welcome rispettivamente per i tenant 1 e 2). È possibile usare il motore regole per estrarre il segmento di identificatore del tenant dal segmento di percorso URL e riscrivere l'URL in modo da includere l'identificatore del tenant in un parametro della stringa di query o un'intestazione di richiesta da utilizzare per l'applicazione.

Per altre informazioni, vedere Che cos'è il motore regole di Frontdoor di Azure?.

Scenari di esempio

Gli scenari di esempio seguenti illustrano come configurare diverse architetture multi-tenant in Frontdoor di Azure e come le decisioni prese possono influire sulla configurazione DNS e TLS.

Molte soluzioni multi-tenant implementano lo schema Deployment Stamps. Quando si usa questo approccio di distribuzione, in genere si distribuisce un singolo profilo frontdoor di Azure condiviso e si usa Frontdoor di Azure per instradare il traffico in ingresso al timbro appropriato. Questo modello di distribuzione è quello più comune e gli scenari da 1 a 4 in questo articolo illustrano come usarlo per soddisfare una serie di requisiti.

In alcune situazioni, tuttavia, è possibile distribuire un profilo frontdoor di Azure in ogni stamp della soluzione. Lo scenario 5 descrive questo modello di distribuzione.

Scenario 1: Dominio con caratteri jolly gestiti dal provider, singolo timbro

Contoso sta creando una piccola soluzione multi-tenant. L'azienda distribuisce un singolo timbro in una singola area e tale stamp serve tutti i tenant. Tutte le richieste vengono instradate allo stesso server applicazioni. Contoso ha deciso di usare domini con caratteri jolly per tutti i tenant, ad esempio tenant1.contoso.com e tenant2.contoso.com.

Contoso distribuisce Frontdoor di Azure usando questa configurazione:

Configurazione del DNS

Configurazione una tantum: Contoso configura due voci DNS:

• Record TXT con caratteri jolly per *.contoso.com. Viene impostato sul valore specificato da Frontdoor di Azure durante il processo di onboarding del dominio personalizzato.
• Un record CNAME con caratteri jolly, *.contoso.com, che è un alias per l'endpoint frontdoor di Azure di Contoso: contoso.z01.azurefd.net.

Quando viene eseguito l'onboarding di un nuovo tenant: non è necessaria alcuna configurazione aggiuntiva.

Configurazione TLS

Configurazione monouso: Contoso acquista un certificato TLS con caratteri jolly, lo aggiunge a un insieme di credenziali delle chiavi e concede ad Azure Frontdoor l'accesso all'insieme di credenziali.

Quando viene eseguito l'onboarding di un nuovo tenant: non è necessaria alcuna configurazione aggiuntiva.

Configurazione di Frontdoor di Azure

Configurazione monouso: Contoso crea un profilo frontdoor di Azure e un singolo endpoint. Aggiungono un dominio personalizzato al nome *.contoso.com e associano il certificato TLS con caratteri jolly alla risorsa di dominio personalizzata. Configura quindi un singolo gruppo di origine che contiene una singola origine per il server applicazioni. Infine, configura una route per connettere il dominio personalizzato al gruppo di origine.

Quando viene eseguito l'onboarding di un nuovo tenant: non è necessaria alcuna configurazione aggiuntiva.

Vantaggi

• Questa configurazione è relativamente semplice da configurare e offre ai clienti URL di marca Contoso.
• L'approccio supporta un numero elevato di tenant.
• Quando viene eseguito l'onboarding di un nuovo tenant, Contoso non deve apportare modifiche ai certificati Frontdoor, DNS o TLS di Azure.

Svantaggi

• Questo approccio non è facilmente scalabile oltre un singolo stamp o area dell'applicazione.
• Contoso deve acquistare un certificato TLS con caratteri jolly e rinnovare e installare il certificato alla scadenza.

Scenario 2: Dominio con caratteri jolly gestiti dal provider, più francobolli

Proseware sta creando una soluzione multi-tenant in più stamp distribuiti sia in Australia che in Europa. Tutte le richieste all'interno di una singola area vengono gestite dal timbro in tale area. Come Contoso, Proseware ha deciso di usare domini con caratteri jolly per tutti i tenant, ad esempio tenant1.proseware.com e tenant2.proseware.com.

Proseware distribuisce Frontdoor di Azure usando questa configurazione:

Configurazione del DNS

Configurazione una tantum: Proseware configura due voci DNS:

• Record TXT con caratteri jolly per *.proseware.com. Viene impostato sul valore specificato da Frontdoor di Azure durante il processo di onboarding del dominio personalizzato.
• Un record CNAME con caratteri jolly, *.proseware.com, che è un alias per l'endpoint frontdoor di Azure di Proseware: proseware.z01.azurefd.net.

Quando viene eseguito l'onboarding di un nuovo tenant: non è necessaria alcuna configurazione aggiuntiva.

Configurazione TLS

Configurazione monouso: Proseware acquista un certificato TLS con caratteri jolly, lo aggiunge a un insieme di credenziali delle chiavi e concede ad Azure Frontdoor l'accesso all'insieme di credenziali.

Quando viene eseguito l'onboarding di un nuovo tenant: non è necessaria alcuna configurazione aggiuntiva.

Configurazione di Frontdoor di Azure

Configurazione monouso: Proseware crea un profilo frontdoor di Azure e un singolo endpoint. L'azienda configura più gruppi di origine, uno per ogni stamp applicazione/server in ogni area.

Quando viene eseguito l'onboarding di un nuovo tenant: Proseware aggiunge una risorsa di dominio personalizzata a Frontdoor di Azure. Usano il nome *.proseware.com e associano il certificato TLS con caratteri jolly alla risorsa di dominio personalizzata. Crea quindi una route per specificare il gruppo di origine (stamp) a cui devono essere indirizzate le richieste del tenant. Nel diagramma precedente viene tenant1.proseware.com instradato al gruppo di origine nell'area Australia e tenant2.proseware.com viene instradato al gruppo di origine nell'area Europa.

Vantaggi

• Quando viene eseguito l'onboarding dei nuovi tenant, non sono necessarie modifiche alla configurazione DNS o TLS.
• Proseware gestisce una singola istanza di Frontdoor di Azure per instradare il traffico a più francobolli in più aree.

Svantaggi

• Proseware deve riconfigurare Frontdoor di Azure ogni volta che viene eseguito l'onboarding di un nuovo tenant.
• Proseware deve prestare attenzione alle quote e ai limiti di Frontdoor di Azure, in particolare per il numero di route e domini personalizzati e al limite di routing composito.
• Proseware deve acquistare un certificato TLS con caratteri jolly.
• Proseware è responsabile del rinnovo e dell'installazione del certificato alla scadenza.

Scenario 3: Sottodomini con caratteri jolly gestiti dal provider

Fabrikam sta creando una soluzione multi-tenant. L'azienda distribuisce francobolli in Australia e il Stati Uniti. Tutte le richieste all'interno di una singola area verranno gestite dal timbro in tale area. Fabrikam userà domini stem basati su stamp, ad esempio tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.come tenant3.us.fabrikam.com.

L'azienda distribuisce Frontdoor di Azure usando questa configurazione:

Configurazione del DNS

Configurazione una tantum: Fabrikam configura le due voci DNS con caratteri jolly seguenti per ogni timbro.

• Record TXT con caratteri jolly per ogni timbro: *.australia.fabrikam.com e *.us.fabrikam.com. Vengono impostati sui valori specificati da Frontdoor di Azure durante il processo di onboarding del dominio personalizzato.
• Record CNAME con caratteri jolly per ogni stamp *.australia.fabrikam.com e *.us.fabrikam.com, che sono entrambi alias per l'endpoint frontdoor di Azure: fabrikam.z01.azurefd.net.

Quando viene eseguito l'onboarding di un nuovo tenant: non è necessaria alcuna configurazione aggiuntiva.

Configurazione TLS

Configurazione una tantum: Fabrikam acquista un certificato TLS con caratteri jolly per ogni stamp, li aggiunge a un insieme di credenziali delle chiavi e concede ad Azure Frontdoor l'accesso all'insieme di credenziali.

Quando viene eseguito l'onboarding di un nuovo tenant: non è necessaria alcuna configurazione aggiuntiva.

Configurazione di Frontdoor di Azure

Configurazione monouso: Fabrikam crea un profilo frontdoor di Azure e un singolo endpoint. Configurano un gruppo di origine per ogni timbro. Creano domini personalizzati, usando un carattere jolly, per ogni sottodominio basato su stamp: *.australia.fabrikam.com e *.us.fabrikam.com. Creano una route per il dominio personalizzato di ogni stamp per inviare il traffico al gruppo di origine appropriato.

Quando viene eseguito l'onboarding di un nuovo tenant: non è necessaria alcuna configurazione aggiuntiva.

Vantaggi

• Questo approccio consente a Fabrikam di ridimensionare un numero elevato di tenant in più timbri.
• Quando viene eseguito l'onboarding dei nuovi tenant, non sono necessarie modifiche alla configurazione DNS o TLS.
• Fabrikam gestisce una singola istanza di Frontdoor di Azure per instradare il traffico a più stamp in più aree.

Svantaggi

• Poiché gli URL usano una struttura di dominio stem multipart, gli URL possono essere più complessi per consentire agli utenti di lavorare con .
• Fabrikam deve acquistare più certificati TLS con caratteri jolly.
• Fabrikam è responsabile del rinnovo e dell'installazione dei certificati TLS alla scadenza.

Scenario 4: Domini vanity

Adventure Works Cycles sta creando una soluzione multi-tenant. L'azienda distribuisce francobolli in più aree, ad esempio Australia e Stati Uniti. Tutte le richieste all'interno di una singola area verranno gestite dal timbro in tale area. Adventure Works consentirà ai tenant di portare i propri nomi di dominio. Ad esempio, il tenant 1 potrebbe configurare un nome di dominio personalizzato come tenant1app.tenant1.com.

L'azienda distribuisce Frontdoor di Azure usando questa configurazione:

Configurazione del DNS

Configurazione una tantum: nessuna.

Quando viene eseguito l'onboarding di un nuovo tenant: il tenant deve creare due record nel proprio server DNS:

• Record TXT per la convalida del dominio. Ad esempio, il tenant 1 deve configurare un record TXT denominato tenant1app.tenant1.com e impostarlo sul valore specificato da Frontdoor di Azure durante il processo di onboarding del dominio personalizzato.
• Un record CNAME con alias per l'endpoint di Frontdoor di Azure Adventure Works. Ad esempio, il tenant 1 deve configurare un record CNAME denominato tenant1app.tenant1.com ed eseguirne il mapping a adventureworks.z01.azurefd.net.

Configurazione TLS

Adventure Works e i relativi tenant devono decidere chi rilascia i certificati TLS:

• L'opzione più semplice consiste nell'usare Frontdoor di Azure per rilasciare e gestire i certificati, ma i tenant non devono configurare i record CCA nei server DNS. In tal caso, i record potrebbero impedire all'autorità di certificazione frontdoor di Azure di emettere certificati.
• In alternativa, i tenant possono fornire i propri certificati. È necessario collaborare con Adventure Works per caricare il certificato in un insieme di credenziali delle chiavi e fornire l'accesso a Frontdoor di Azure.

Configurazione di Frontdoor di Azure

Configurazione monouso: Adventure Works crea un profilo frontdoor di Azure e un singolo endpoint. Configurano un gruppo di origine per ogni timbro. Non creano route o risorse di dominio personalizzate.

Quando viene eseguito l'onboarding di un nuovo tenant: Adventure Works aggiunge una risorsa di dominio personalizzata a Frontdoor di Azure. Usano il nome di dominio fornito dal tenant e associano il certificato TLS appropriato alla risorsa di dominio personalizzata. Crea quindi una route per specificare il gruppo di origine (stamp) a cui devono essere indirizzate le richieste del tenant. Nel diagramma precedente viene tenant1app.tenant1.com instradato al gruppo di origine nell'area Australia e tenant2app.tenant3.com viene instradato al gruppo di origine nell'area degli Stati Uniti.

Vantaggi

• I clienti possono fornire i propri nomi di dominio. Frontdoor di Azure instrada in modo trasparente le richieste alla soluzione multi-tenant.
• Adventure Works gestisce una singola istanza di Frontdoor di Azure per instradare il traffico a più francobolli in più aree.

Svantaggi

• Adventure Works deve riconfigurare Frontdoor di Azure ogni volta che viene eseguito l'onboarding di un nuovo tenant.
• I tenant devono essere coinvolti nel processo di onboarding. Devono apportare modifiche DNS ed eventualmente rilasciare certificati TLS.
• I tenant controllano i record DNS. Le modifiche apportate ai record DNS potrebbero influire sulla possibilità di accedere alla soluzione Adventure Works.
• Adventure Works deve prestare attenzione alle quote e ai limiti di Frontdoor di Azure, in particolare per il numero di route e domini personalizzati e il limite di routing composito.

Scenario 5: Profilo frontdoor di Azure per timbro

È possibile distribuire un profilo frontdoor di Azure per ogni timbro. Se sono presenti 10 francobolli, si distribuiscono 10 istanze di Frontdoor di Azure. Questo approccio può essere utile se è necessario limitare l'accesso alla gestione della configurazione di Frontdoor di Azure di ogni stamp. Può essere utile anche se è necessario usare più profili frontdoor di Azure per evitare di superare le quote o i limiti delle risorse.

Se si dispone di un timbro che serve più tenant, è necessario considerare come instradare il traffico a ogni tenant. Esaminare gli approcci descritti negli scenari precedenti e valutare la possibilità di combinare gli approcci in base alle esigenze.

Vantaggi

• Se si estende la configurazione tra più profili, è meno probabile che si raggiungano i limiti delle risorse di Frontdoor di Azure. Ad esempio, se è necessario supportare un numero elevato di domini personalizzati, è possibile dividere i domini tra più profili frontdoor di Azure e rimanere entro i limiti di ogni profilo.
• Questo approccio consente di definire l'ambito delle autorizzazioni di gestione delle risorse di Frontdoor di Azure. È possibile usare il controllo degli accessi in base al ruolo di Azure per concedere agli amministratori l'accesso al profilo di un singolo timbro.

Svantaggi

• Questo approccio comporta in genere un costo elevato perché si distribuiscono più profili. Per altre informazioni, vedere Informazioni sulla fatturazione di Frontdoor.
• È previsto un limite al numero di profili frontdoor di Azure che è possibile distribuire in una singola sottoscrizione di Azure. Per altre informazioni, vedere Quote e limiti di Frontdoor.
• È necessario configurare separatamente il profilo frontdoor di Azure di ogni stamp ed è necessario gestire la configurazione DNS, i certificati TLS e la configurazione TLS per ogni timbro.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Raj Nemani | Direttore, Partner Technology Strategist
• John Downs | Principal Software Engineer

Altri contributori:

• Mick Alberts | Writer tecnico
• Fernando Antivero | Fullstack Developer & Cloud Platform Engineer
• Duong Au | Senior Content Developer, C+E Skilling Content R&D
• Harikrishnan M B (HARI) | Product Manager 2, Rete di Azure
• Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Formazione: Introduzione a Frontdoor di Azure
• Introduzione a Frontdoor di Azure
• Che cos'è Frontdoor di Azure?

Risorse correlate

• Progettare soluzioni multi-tenant in Azure
• Elenco di controllo per la progettazione e la creazione di soluzioni multi-tenant in Azure
• Modelli di tenancy da considerare per una soluzione multi-tenant