Considerazioni sull'uso di app contenitore in una soluzione multi-tenant
È possibile usare App Contenitore di Azure per eseguire microservizi e applicazioni in contenitori in una piattaforma serverless. Questo articolo descrive alcune delle funzionalità di App contenitore utili per le soluzioni multi-tenant. Fornisce anche collegamenti a indicazioni utili durante la fase di pianificazione.It also provides links to guidance that can help you during your planning phase.
Modelli di isolamento
Quando si usa un sistema multi-tenant che usa App contenitore, è necessario determinare il livello di isolamento richiesto. App contenitore supporta modelli diversi di multi-tenancy:
- È possibile implementare la multi-tenancy attendibile usando un ambiente condiviso. Ad esempio, questo modello potrebbe essere appropriato quando i tenant provengono tutti dall'interno dell'organizzazione.
- È possibile implementare la multi-tenancy ostile distribuendo ambienti separati per ogni tenant. Ad esempio, questo modello potrebbe essere appropriato 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 app contenitore. I modelli sono descritti più avanti in questo articolo.
| Considerazioni | Un ambiente per tenant | App contenitore specifiche del tenant | App contenitore condiviso |
|---|---|---|---|
| Isolamento dei dati | Alto | Basso | Basso |
| Isolamento delle prestazioni | Alto | Medio. Nessun isolamento di rete. | Basso |
| Complessità della distribuzione | Medio | Da basso a medio | Basso |
| Complessità operativa | Medio | Basso | Basso |
| Costo risorsa | Alto | Basso | Basso |
| Scenario di esempio | Esecuzione di carichi di lavoro multi-tenant ostili in ambienti isolati per la sicurezza e la conformità | Ottimizzazione dei costi, delle risorse di rete e delle operazioni per applicazioni multi-tenant attendibili | Implementazione di una soluzione multi-tenant a livello di logica di business |
App contenitore condiviso
È possibile prendere in considerazione la distribuzione di app contenitore condivise in un singolo ambiente app contenitore usato per tutti i tenant.
Questo approccio è in genere conveniente e richiede il minor sovraccarico operativo perché sono disponibili meno risorse da gestire.
Tuttavia, se si vuole usare questo modello di isolamento, il codice dell'applicazione deve essere compatibile con più tenancy. 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 è appropriato per carichi di lavoro multi-tenancy ostili in cui non si considera attendibile il codice in esecuzione.
Inoltre, questo modello è potenzialmente soggetto a problemi adiacente rumorosi: il carico di lavoro di un tenant potrebbe influire sulle prestazioni del carico di lavoro di un altro tenant. Se è necessario fornire una velocità effettiva dedicata per attenuare questo problema, il modello di app contenitore condiviso potrebbe non essere appropriato.
Nota
Il modello Deployment Stamps è utile quando i tenant si trovano in modelli di costo diversi. Ad esempio, i tenant possono essere assegnati a ambienti di app contenitore condivise o dedicate a seconda del piano tariffario. Questa strategia di distribuzione consente di superare i limiti di App contenitore per una singola sottoscrizione per ogni area e scalare in modo lineare man mano che aumenta il numero di tenant.
App contenitore specifiche del tenant
Un altro approccio da considerare consiste nell'isolare i tenant distribuendo app contenitore specifiche del tenant all'interno di un ambiente condiviso.
Questo modello di isolamento fornisce l'isolamento logico tra ogni tenant. Offre questi vantaggi:
- Efficienza dei costi. Condividendo un ambiente, 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 da quelli 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 app contenitore all'interno dell'ambiente viene allocata alle 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 contenitore include il supporto predefinito per Dapr, che usa una progettazione modulare per offrire funzionalità come componenti. In App contenitore i componenti dapr sono risorse a livello di ambiente. Quando si condivide un singolo ambiente tra più tenant, assicurarsi di definire correttamente l'ambito dei componenti dapr all'app contenitore specifica del tenant corretta per garantire l'isolamento ed evitare il rischio di perdita di dati.
Nota
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 è necessario avere più versioni dell'app in esecuzione come parte di un processo di implementazione degli aggiornamenti, come nelle distribuzioni blu/verde e test A/B.
Un ambiente per tenant
È possibile valutare la possibilità di distribuire un ambiente app contenitore per ognuno 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 dati. Ogni ambiente viene distribuito nella propria rete virtuale, condivisa da tutte le app all'interno dell'ambiente. Ogni ambiente ha una propria configurazione dapr e monitoraggio.
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. Quando si usa questo modello, non è necessario 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 per il numero di ambienti che è possibile distribuire all'interno di una sottoscrizione per area. In alcune situazioni, è possibile aumentare queste quote creando un ticket di supporto tecnico di Azure.
Assicurarsi di conoscere la crescita prevista nel numero di tenant prima di implementare questo modello di isolamento. Tenere presente che 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 necessarie per distribuire e gestire.
Funzionalità di App contenitore che supportano la multi-tenancy
Nomi di dominio personalizzati
App contenitore consente di usare il DNS con caratteri jolly e di aggiungere certificati TLS con caratteri jolly. Quando si usano sottodomini specifici del tenant, i certificati DNS e TLS con caratteri jolly consentono di ridimensionare facilmente la soluzione in un numero elevato di tenant senza dover riconfigurare manualmente ogni nuovo tenant.
In App contenitore 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
App contenitore può convalidare i token di autenticazione per conto dell'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 reindirizzarla al provider di identità in modo che l'utente possa accedere.
Se i tenant usano Microsoft Entra ID come provider di identità, è possibile configurare App contenitore per l'uso dell'endpoint /common per convalidare i token utente. In questo modo si garantisce che, indipendentemente dal tenant di Microsoft Entra dell'utente, i relativi token vengano convalidati e accettati.
È anche possibile integrare App contenitore con Azure Active Directory B2C per l'autenticazione utente tramite provider di identità partner.
Per ulteriori informazioni, vedi queste risorse:
- Autorizzazione di App Contenitore di Azure
- Abilitare l'autenticazione e l'autorizzazione in App Azure Container con Microsoft Entra ID
Nota
Le funzionalità di autenticazione e autorizzazione in App contenitore sono simili a quelle del servizio app Azure. Esistono tuttavia alcune differenze. Per altre informazioni, vedere Considerazioni sull'uso dell'autenticazione predefinita.
Identità gestite
È possibile usare le identità gestite dall'ID Microsoft Entra per consentire all'app contenitore di accedere ad altre risorse autenticate dall'ID Microsoft Entra. 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. Si supponga, ad esempio, di condividere le app contenitore tra tutti i tenant e distribuire database specifici del 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 App Azure Container.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- Daniel Larsen | Principal Customer Engineer, FastTrack per Azure
- Will Velida | Customer Engineer 2, FastTrack per Azure
Altri contributori:
- John Downs | Principal Software Engineer
- Chad Kittel | Principal Software Engineer, Microsoft
- Xuhong Liu | Senior Service Engineer, FastTrack per Azure
- Aarthi Murugan | Senior Program Manager, CS Tech Strategy App Innovation
- Kendall Roden | Senior Program Manager, App Azure Container
- Paolo Salvatori | Principal Customer Engineer, FastTrack per Azure
- Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.