Delen via

Overwegingen voor het gebruik van Container Apps in een multitenant-oplossing

  • Artikel

U kunt Azure Container Apps gebruiken om microservices en toepassingen in containers uit te voeren op een serverloos platform. In dit artikel worden enkele van de functies van Container Apps beschreven die nuttig zijn voor multitenant-oplossingen. Het biedt ook koppelingen naar richtlijnen die u kunnen helpen tijdens uw planningsfase.

Isolatiemodellen

Wanneer u werkt met een systeem met meerdere tenants dat gebruikmaakt van Container Apps, moet u het vereiste isolatieniveau bepalen. Container Apps ondersteunt verschillende modellen van multitenancy:

  • U kunt vertrouwde multitenancy implementeren met behulp van een gedeelde omgeving. Dit model kan bijvoorbeeld geschikt zijn wanneer uw tenants allemaal afkomstig zijn van uw organisatie.
  • U kunt vijandige multitenancy implementeren door afzonderlijke omgevingen voor elke tenant te implementeren. Dit model kan bijvoorbeeld geschikt zijn wanneer u de code die uw tenants uitvoeren niet vertrouwt.

De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste tenantisolatiemodellen voor Container Apps. De modellen worden verderop in dit artikel beschreven.

Overweging Eén omgeving per tenant Tenantspecifieke container-apps Gedeelde container-apps
Gegevensisolatie Hoog Beperkt Beperkt
Isolatie van prestaties Hoog Gemiddeld. Geen netwerkisolatie. Beperkt
Implementatiecomplexiteit Gemiddeld Laag tot gemiddeld Beperkt
Operationele complexiteit Gemiddeld Beperkt Beperkt
Resourcekosten Hoog Beperkt Beperkt
Voorbeeldscenario Het uitvoeren van vijandige multitenant-workloads in geïsoleerde omgevingen voor beveiliging en naleving Kosten, netwerkresources en bewerkingen optimaliseren voor vertrouwde multitenant-toepassingen Een multitenant-oplossing implementeren op bedrijfslogicaniveau

Gedeelde container-apps

U kunt overwegen om gedeelde container-apps te implementeren in één Container Apps-omgeving die wordt gebruikt voor al uw tenants.

Diagram met een gedeeld Container Apps-isolatiemodel. Alle tenants delen één Container App-omgeving en container-apps.

Deze aanpak is over het algemeen kostenefficiënt en vereist de minste operationele overhead, omdat er minder resources zijn om te beheren.

Als u dit isolatiemodel echter wilt gebruiken, moet uw toepassingscode multitenancybewust zijn. Dit isolatiemodel garandeert geen isolatie op netwerk-, reken-, bewakings- of gegevensniveau. Uw toepassingscode moet tenantisolatie verwerken. Dit model is niet geschikt voor vijandige multitenancyworkloads waarin u de code die wordt uitgevoerd niet vertrouwt.

Dit model is mogelijk onderhevig aan problemen met ruis: de workload van een tenant kan van invloed zijn op de prestaties van de workload van een andere tenant. Als u toegewezen doorvoer moet opgeven om dit probleem te verhelpen, is het model voor gedeelde container-apps mogelijk niet geschikt.

Notitie

Het patroon Implementatiestempels is handig wanneer tenants verschillende kostenmodellen hebben. Tenants kunnen bijvoorbeeld worden toegewezen aan gedeelde of toegewezen Container Apps-omgevingen, afhankelijk van hun prijscategorie. Met deze implementatiestrategie kunt u de limieten van Container Apps voor één abonnement per regio overschrijden en lineair schalen naarmate het aantal tenants toeneemt.

Tenantspecifieke container-apps

Een andere benadering die u kunt overwegen is het isoleren van uw tenants door tenantspecifieke container-apps in een gedeelde omgeving te implementeren.

Diagram met een Container Apps-isolatiemodel waarin tenantspecifieke container-apps worden geïmplementeerd in een gedeelde Container Apps-omgeving.

Dit isolatiemodel biedt logische isolatie tussen elke tenant. Het biedt deze voordelen:

  • Kostenefficiëntie. Door een Container Apps-omgeving, virtueel netwerk en andere gekoppelde resources zoals een Log Analytics-werkruimte te delen, kunt u in het algemeen uw totale kosten en beheercomplexiteit per tenant verminderen.
  • Scheiding van upgrades en implementaties. De binaire toepassingsbestanden van elke tenant kunnen onafhankelijk van die van andere container-apps in dezelfde omgeving worden geïmplementeerd en bijgewerkt. Deze aanpak kan handig zijn als u verschillende tenants op verschillende tijdstippen moet upgraden naar specifieke versies van uw code.
  • Resource-isolatie. Aan elke container-app in uw omgeving worden eigen CPU- en geheugenbronnen toegewezen. Als voor een specifieke tenant meer resources nodig zijn, kunt u meer CPU en geheugen toewijzen aan de specifieke container-app van die tenant. Houd er rekening mee dat er limieten zijn voor de totale CPU- en geheugentoewijzingen voor container-apps.

Deze benadering biedt echter geen hardware- of netwerkisolatie tussen tenants. Alle container-apps in één omgeving delen hetzelfde virtuele netwerk. U moet kunnen vertrouwen dat de workloads die zijn geïmplementeerd in de apps, de gedeelde resources niet misbruiken.

Container Apps biedt ingebouwde ondersteuning voor Dapr, die gebruikmaakt van een modulair ontwerp om functionaliteit als onderdelen te leveren. In Container Apps zijn Dapr-onderdelen resources op omgevingsniveau. Wanneer u één omgeving deelt tussen meerdere tenants, moet u ervoor zorgen dat u de Dapr-onderdelen op de juiste tenantspecifieke container-app kunt toepassen om isolatie te garanderen en het risico op gegevenslekken te voorkomen.

Notitie

Gebruik geen revisies om verschillende versies van uw app te maken voor verschillende tenants. Revisies bieden geen isolatie van resources. Ze zijn ontworpen voor implementatiescenario's waarin u meerdere versies van uw app moet hebben die worden uitgevoerd als onderdeel van een update-implementatieproces, zoals in blauw/groene implementaties en A/B-tests.

Eén omgeving per tenant

U kunt overwegen om één Container Apps-omgeving te implementeren voor elk van uw tenants. Een Container Apps-omgeving is de isolatiegrens rond een groep container-apps. Een omgeving biedt reken- en netwerkisolatie op het gegevensvlak. Elke omgeving wordt geïmplementeerd in een eigen virtueel netwerk, dat wordt gedeeld door alle apps in de omgeving. Elke omgeving heeft een eigen Dapr- en bewakingsconfiguratie.

Diagram met een Container Apps-isolatiemodel waarin elke tenant een eigen Container App-omgeving krijgt.

Deze benadering biedt het sterkste gegevens- en prestatieisolatieniveau, omdat de gegevens en het verkeer van elke tenant zijn geïsoleerd naar een specifieke omgeving. En wanneer u dit model gebruikt, hoeven uw toepassingen niet multitenancybewust te zijn. Wanneer u deze benadering gebruikt, hebt u gedetailleerdere controle over hoe u resources toewijst aan container-apps in de omgeving. U kunt toewijzingen bepalen op basis van de vereisten van uw tenant. Sommige tenants vereisen bijvoorbeeld meer CPU- en geheugenresources dan andere, zodat u meer resources aan de toepassingen van deze tenants kunt bieden terwijl u profiteert van de isolatie die tenantspecifieke omgevingen bieden.

Er gelden echter lage limieten voor het aantal omgevingen dat u binnen een abonnement per regio kunt implementeren. In sommige situaties kunt u deze quota verhogen door een ondersteuning voor Azure ticket te maken.

Zorg ervoor dat u de verwachte groei in het aantal tenants weet voordat u dit isolatiemodel implementeert. Houd er rekening mee dat deze benadering vaak hogere totale eigendomskosten en hogere niveaus van implementatie en operationele complexiteit met zich meebrengt vanwege de extra resources die u moet implementeren en beheren.

Container Apps-functies die ondersteuning bieden voor multitenancy

Aangepaste domeinnamen

Met Container Apps kunt u DNS met jokertekens gebruiken en uw eigen TLS-certificaten met jokertekens toevoegen. Wanneer u tenantspecifieke subdomeinen gebruikt, kunt u dns- en TLS-certificaten met jokertekens eenvoudig schalen naar een groot aantal tenants zonder dat u elke nieuwe tenant handmatig opnieuw hoeft te configureren.

In Container Apps beheert u certificaten op omgevingsniveau. Inkomend verkeer moet ook zijn ingeschakeld voor de container-app voordat u er een aangepast domein aan kunt binden.

Verificatie en autorisatie aanvragen

Container Apps kan verificatietokens valideren namens uw app. Als een aanvraag geen token bevat, is het token ongeldig of is de aanvraag niet geautoriseerd, kunt u Container Apps configureren om de aanvraag te blokkeren of om te leiden naar uw id-provider, zodat de gebruiker zich kan aanmelden.

Als uw tenants Microsoft Entra-id gebruiken als id-provider, kunt u Container Apps configureren om het /algemene eindpunt te gebruiken om gebruikerstokens te valideren. Dit zorgt ervoor dat, ongeacht de Microsoft Entra-tenant van de gebruiker, hun tokens worden gevalideerd en geaccepteerd.

U kunt Container Apps ook integreren met Azure Active Directory B2C voor gebruikersverificatie via partneridentiteitsproviders.

Raadpleeg deze hulpbronnen voor meer informatie:

Notitie

De verificatie- en autorisatiefuncties in Container Apps zijn vergelijkbaar met die in Azure-app Service. Er zijn echter enkele verschillen. Zie Overwegingen voor het gebruik van ingebouwde verificatie voor meer informatie.

Beheerde identiteiten

U kunt beheerde identiteiten van Microsoft Entra-id gebruiken om uw container-app toegang te geven tot andere resources die worden geverifieerd door Microsoft Entra-id. Wanneer u beheerde identiteiten gebruikt, hoeft uw container-app geen referenties te beheren voor service-naar-service-communicatie. U kunt specifieke machtigingen verlenen aan de identiteit van uw container-app voor op rollen gebaseerd toegangsbeheer.

Wanneer u beheerde identiteiten gebruikt, moet u rekening houden met uw keuze voor isolatiemodel. Stel dat u uw container-apps deelt tussen al uw tenants en tenantspecifieke databases implementeert. U moet ervoor zorgen dat de toepassing van één tenant geen toegang heeft tot de database van een andere tenant.

Zie Beheerde identiteiten in Azure Container Apps voor meer informatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

  • Daniel Larsen | Principal Customer Engineer, FastTrack voor Azure
  • Will Velida | Customer Engineer 2, FastTrack voor Azure

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen