Condividi tramite

Considerazioni sull'uso di App Contenitore di Azure in una soluzione multi-tenant

  • Articolo

È possibile usare App Contenitore di Azure per eseguire microservizi e applicazioni in contenitori in una piattaforma serverless. Questo articolo descrive diverse funzionalità di App contenitore utili per le soluzioni multi-tenant. Fornisce anche risorse che possono essere utili durante la fase di pianificazione.

Modelli di isolamento

Quando si utilizza un sistema multi-tenant che impiega Container Apps, bisogna determinare il livello di isolamento richiesto. Le app contenitori supportano modelli diversi di multitenancy.

  • È possibile implementare la multi-tenancy fidata usando un ambiente condiviso. Ad esempio, questo modello potrebbe essere adatto quando i tenant provengono tutti dall'interno dell'organizzazione.

  • È possibile implementare la multitenancy ostile distribuendo ambienti separati per ogni tenant. Ad esempio, questo modello potrebbe essere adatto quando non si considera attendibile il codice eseguito dai tenant.

La tabella seguente riepiloga le differenze tra i principali modelli di isolamento tenancy per le Applicazioni Container. I modelli sono descritti più avanti in questo articolo.

Considerazione Un ambiente per ogni tenant Applicazioni contenitore specifiche per tenant Applicazioni contenitore condivise
Isolamento dei dati Alto Basso Basso
Isolamento delle prestazioni Alto Livello intermedio, nessun isolamento di rete Basso
Complessità della distribuzione Intermedio Da basso a medio Basso
Complessità operativa Intermedio Basso Basso
Costo risorsa Alto Basso Basso
Scenario di esempio Esegue carichi di lavoro multi-tenant ostili in ambienti isolati per la sicurezza e la conformità. Ottimizza i costi, le risorse di rete e le operazioni per le applicazioni multi-tenant attendibili. Implementa una soluzione multi-tenant a livello di logica di business.

Applicazioni contenitore condivise

Si consiglia di distribuire app di contenitore condivise in un unico ambiente di app di contenitore utilizzato da tutti i tenant.

Diagramma che mostra un modello di isolamento condiviso delle Container Apps. Tutti i tenant condividono un unico ambiente di Container Apps e di applicazioni.

Questo approccio è in genere conveniente e richiede il minor sovraccarico operativo perché sono presenti meno risorse da gestire.

Tuttavia, se si vuole usare questo modello di isolamento, il codice dell'applicazione deve essere adatto alla multitenancy. Questo modello di isolamento non garantisce l'isolamento a livello di rete, calcolo, monitoraggio o dati. Il codice dell'applicazione deve gestire l'isolamento del tenant. Questo modello non è adatto per carichi di lavoro multi-tenancy ostili in cui non si considera attendibile il codice in esecuzione.

Questo modello è potenzialmente soggetto a problemi vicini rumorosi, il che significa che il carico di lavoro di un tenant potrebbe influire sulle prestazioni del carico di lavoro di un altro tenant. Se è necessario fornire un throughput dedicato per mitigare questo problema, il modello di app per container condiviso potrebbe non essere adatto.

Annotazioni

Il modello Deployment Stamps è utile quando i tenant utilizzano modelli tariffari diversi. Ad esempio, i tenant possono essere assegnati agli ambienti di app di contenitori condivisi o dedicati a seconda del piano tariffario. Questa strategia di distribuzione consente di superare il limite di App contenitore per una singola sottoscrizione per ogni area e scalare in modo lineare man mano che aumenta il numero di tenant.

Applicazioni contenitore specifiche per tenant

Un altro approccio da considerare consiste nell'isolare i tenant distribuendo app contenitore specifiche del tenant all'interno di un ambiente condiviso.

Diagramma che mostra un modello di isolamento delle applicazioni contenitore in cui le applicazioni contenitore specifiche per il tenant vengono distribuite all'interno di un ambiente applicazioni contenitore condiviso.

Questo modello di isolamento garantisce la separazione logica tra i tenant offrendo diversi vantaggi:

  • Efficienza dei costi. Condividendo un ambiente di App contenitore, una rete virtuale e altre risorse collegate come un'area di lavoro Log Analytics, è in genere possibile ridurre la complessità complessiva dei costi e della gestione per ogni tenant.

  • Separazione degli aggiornamenti e delle distribuzioni. I file binari dell'applicazione di ogni tenant possono essere distribuiti e aggiornati in modo indipendente dai file binari di altre app contenitore nello stesso ambiente. Questo approccio può essere utile se è necessario aggiornare tenant diversi a versioni specifiche del codice in momenti diversi.

  • Isolamento delle risorse. Ogni applicazione contenitore nel tuo ambiente ha assegnate le proprie risorse di CPU e memoria. Se un tenant specifico richiede più risorse, è possibile allocare più CPU e memoria all'app contenitore specifica del tenant. Tenere presente che esistono limiti per le allocazioni totali di CPU e memoria nelle app contenitore.

Tuttavia, questo approccio non fornisce alcun isolamento hardware o di rete tra i tenant. Tutte le app contenitore in un singolo ambiente condividono la stessa rete virtuale. È necessario essere in grado di considerare attendibile che i carichi di lavoro distribuiti nelle app non usino in modo improprio le risorse condivise.

App per container ha il supporto predefinito per Dapr, che utilizza una progettazione modulare per offrire funzionalità come componenti modulari. Nelle App Contenitore, i componenti Dapr sono risorse a livello di ambiente. Quando si condivide un singolo ambiente tra più tenant, assicurarsi che i componenti dapr siano inclusi correttamente nell'ambito dell'app contenitore specifica del tenant corretta per garantire l'isolamento e prevenire la perdita di dati.

Annotazioni

Non usare le revisioni per creare versioni diverse dell'app per tenant diversi. Le revisioni non forniscono l'isolamento delle risorse. Sono progettati per scenari di distribuzione in cui più versioni di un'app devono essere eseguite durante un'implementazione degli aggiornamenti. Questo approccio include strategie come distribuzioni blu-verde e test A/B.

Un ambiente per ogni tenant

Si consiglia di distribuire un ambiente App Container per ciascuno dei tenant. Un ambiente app contenitore è il limite di isolamento intorno a un gruppo di app contenitore. Un ambiente fornisce l'isolamento di calcolo e di rete nel piano dei dati. Ogni ambiente viene distribuito nella propria rete virtuale. Tutte le app all'interno dell'ambiente condividono questa rete virtuale. Ogni ambiente ha una propria configurazione Dapr e di monitoraggio.

Diagramma che mostra un modello di isolamento di Container Apps in cui ogni tenant ha il proprio ambiente Container Apps.

Questo approccio offre il livello più elevato di isolamento dei dati e delle prestazioni perché i dati e il traffico di ogni tenant sono isolati in un ambiente specifico. Questo modello non richiede che le applicazioni siano in grado di supportare la multi-tenancy. Quando si usa questo approccio, si ha un controllo più granulare sulla modalità di allocazione delle risorse alle app contenitore all'interno dell'ambiente. È possibile determinare le allocazioni in base ai requisiti del tenant. Ad esempio, alcuni tenant potrebbero richiedere più risorse di CPU e memoria rispetto ad altre, in modo da poter fornire più risorse alle applicazioni di questi tenant sfruttando al contempo l'isolamento fornito dagli ambienti specifici del tenant.

Esistono tuttavia limiti limitati al numero di ambienti che è possibile distribuire all'interno di una sottoscrizione per ogni area. In alcuni scenari, è possibile aumentare queste quote creando un ticket di supporto di Azure.

Assicurarsi di conoscere la crescita prevista nel numero di tenant prima di implementare questo modello di isolamento. Questo approccio comporta spesso un costo totale più elevato di proprietà e livelli più elevati di distribuzione e complessità operativa a causa delle risorse aggiuntive che è necessario distribuire e gestire.

Funzionalità delle App di contenitori che supportano la multitenancy

Nomi di dominio personalizzati

Container Apps consente di utilizzare il sistema DNS (Domain Name System) con wildcard e di aggiungere i propri certificati TLS (Transport Layer Security) con wildcard. Quando si usano sottodomini specifici per il tenant, sia i certificati DNS con wildcard che i certificati TLS consentono di ridimensionare facilmente la soluzione in un numero elevato di tenant senza dover riconfigurare manualmente ogni nuovo tenant.

Nelle applicazioni container, si gestiscono i certificati a livello di ambiente. Prima di poter associare un dominio personalizzato, è necessario abilitare anche l'ingresso per l'app contenitore.

Richiedere l'autenticazione e l'autorizzazione

Le app contenitore possono convalidare i token di autenticazione per conto della tua app. Se una richiesta non contiene un token, il token non è valido o la richiesta non è autorizzata, è possibile configurare App contenitore per bloccare la richiesta o reindirizzare la richiesta al provider di identità in modo che l'utente possa accedere.

Se i tenant usano Microsoft Entra ID come provider di identità, è possibile configurare le App container per l'uso dell'endpoint /common per convalidare i token utente. Questo approccio garantisce che i token degli utenti vengano convalidati e accettati, indipendentemente dal tenant di Microsoft Entra dell'utente.

È anche possibile integrare App contenitore con Microsoft Entra External ID per l'autenticazione utente tramite provider di identità partner.

Per altre informazioni, vedere le risorse seguenti:

Annotazioni

Le funzionalità di autenticazione e autorizzazione in App contenitore sono simili alle funzionalità del servizio app di Azure. Esistono tuttavia alcune differenze. Per altre informazioni, vedere Considerazioni sull'uso dell'autenticazione predefinita.

Identità gestite

È possibile usare identità gestite da Microsoft Entra ID per consentire all'app contenitore di accedere ad altre risorse autenticate da Microsoft Entra ID. Quando si usano identità gestite, l'app contenitore non deve gestire le credenziali per la comunicazione da servizio a servizio. È possibile concedere autorizzazioni specifiche all'identità dell'app contenitore per il controllo degli accessi in base al ruolo.

Quando si usano le identità gestite, tenere presente la scelta del modello di isolamento. Ad esempio, supponiamo di condividere le applicazioni container tra tutti i tenant e di distribuire database specifici per tenant. È necessario assicurarsi che l'applicazione di un tenant non possa accedere al database di un tenant diverso.

Per altre informazioni, vedere Identità gestite in Container Apps.

Profili di carico di lavoro in calcolo dedicato

Applicazioni container offre un piano dedicato che consente di riservare risorse dedicate per un cliente. Questo piano è utile per limitare le risorse disponibili a un tenant, che possono essere condivise tra più app contenitore. Consente anche di soddisfare requisiti specifici del tenant, ad esempio rapporti di memoria a CPU più elevati o disponibilità gpu.

Per ulteriori informazioni, vedere Profili di carico di lavoro in Container Apps.

Routing basato su regole

Il routing basato su regole consente di indirizzare il traffico in ingresso a app contenitore o revisioni dell'app contenitore specifiche. Le richieste possono essere instradate in base al percorso della richiesta HTTP ed è possibile riscrivere il percorso nell'URL. Questa funzionalità è utile per i sistemi multi-tenant che devono eseguire il mapping delle richieste alle app contenitore o alle revisioni specifiche del tenant che usano il percorso nella richiesta. Questa funzionalità viene in genere usata con il modello di isolamento delle app contenitore specifiche del tenant .

Per ulteriori informazioni, vedere Usare il routing basato su regole con Container Apps.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

  • Daniel Larsen | Ingegnere Cliente Principale, FastTrack per Azure
  • Will Velida | Customer Engineer 2, FastTrack per Azure

Altri collaboratori:

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

Passaggi successivi