Delen via

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

U kunt Azure Container Apps gebruiken om microservices en toepassingen in containers uit te voeren op een serverloos platform. In dit artikel worden verschillende functies van Container Apps beschreven die nuttig zijn voor multitenant-oplossingen. Het biedt ook resources 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 voor elke tenant Tenantspecifieke container-apps Gedeelde container-apps
Gegevensisolatie Hoog Laag Laag
Prestatie-isolatie Hoog Gemiddeld, geen netwerkisolatie Laag
Implementatiecomplexiteit Gemiddeld Laag tot gemiddeld Laag
Operationele complexiteit Gemiddeld Laag Laag
Resourcekosten Hoog Laag Laag
Voorbeeldscenario Voert vijandige multitenant-workloads uit in geïsoleerde omgevingen voor beveiliging en naleving. Optimaliseert kosten, netwerkresources en bewerkingen voor vertrouwde multitenant-toepassingen. Implementeert een multitenant-oplossing op bedrijfslogicaniveau.

Gedeelde container-apps

Overweeg om gedeelde container-apps te implementeren in één Container Apps-omgeving die al uw tenants gebruiken.

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

Deze aanpak is doorgaans kostenefficiënt en vereist de minst 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, wat betekent dat de workload van de ene tenant van invloed kan zijn op de prestaties van de workload van een andere tenant. Als u specifieke capaciteit moet opgeven om dit probleem te verhelpen, is het model voor gedeelde container-apps mogelijk niet geschikt.

Opmerking

Het patroon Implementatiestempels is handig wanneer tenants zich op verschillende prijsmodellen bevinden. Huurders kunnen bijvoorbeeld worden toegewezen aan gedeelde of toegewezen Container Apps-omgevingen, afhankelijk van hun prijsklasse. Met deze implementatiestrategie kunt u de limiet voor Container Apps voor één abonnement voor elke 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 zorgt voor logische scheiding tussen tenants en biedt verschillende 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 voor elke tenant verminderen.

  • Scheiding van upgrades en implementaties. De binaire bestanden van elke tenant kunnen onafhankelijk van de binaire bestanden van andere container-apps in dezelfde omgeving worden geïmplementeerd en bijgewerkt. Deze methode kan handig zijn als u verschillende tenants op verschillende tijdstippen moet upgraden naar specifieke versies van uw code.

  • Resourceisolatie. 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 in de apps zijn geïmplementeerd, 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 Dapr-onderdelen correct zijn afgestemd op de juiste tenantspecifieke container-app om isolatie te garanderen en gegevenslekken te voorkomen.

Opmerking

Gebruik geen revisies om verschillende versies van uw app te maken voor verschillende tenants. Revisies bieden geen isolatie van middelen. Ze zijn ontworpen voor implementatiescenario's waarbij meerdere versies van een app moeten worden uitgevoerd tijdens een update-implementatie. Deze aanpak omvat strategieën zoals blauwgroene implementaties en A/B-tests.

Eén omgeving voor elke tenant

Overweeg 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. Alle apps in de omgeving delen dit virtuele netwerk. Elke omgeving heeft een eigen Dapr- en bewakingsconfiguratie.

Diagram met een Container Apps-isolatiemodel waarin elke tenant een eigen Container Apps-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. Dit model vereist niet dat uw toepassingen multitenancybewust 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 voor elke regio kunt implementeren. In sommige scenario's kunt u deze quota verhogen door een Azure-ondersteuningsticket te maken.

Zorg ervoor dat u de verwachte groei in het aantal tenants kent voordat u dit isolatiemodel implementeert. Deze aanpak veroorzaakt vaak een hogere totale eigendomskosten en hogere niveaus van implementatie en operationele complexiteit 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 (Domain Name System) met jokertekens gebruiken en uw eigen TLS-certificaten (Transport Layer Security) toevoegen. Wanneer u tenantspecifieke subdomeinen gebruikt, kunt u met dns- en TLS-certificaten met jokertekens uw oplossing 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 de aanvraag 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. Deze aanpak zorgt ervoor dat de tokens van gebruikers worden gevalideerd en geaccepteerd, ongeacht de Microsoft Entra-tenant van de gebruiker.

U kunt Container Apps ook integreren met externe Microsoft Entra-id voor gebruikersverificatie via partneridentiteitsproviders.

Zie de volgende bronnen voor meer informatie:

Opmerking

De verificatie- en autorisatiefuncties in Container Apps zijn vergelijkbaar met de functies 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 door Microsoft Entra ID worden geverifieerd. 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 Container Apps voor meer informatie.

Workloadprofielen op toegewezen rekenkracht

Container Apps biedt een speciaal abonnement waarmee u toegewezen resources voor een tenant kunt reserveren. Dit plan is handig voor het beperken van de resources die beschikbaar zijn voor een tenant, die kan worden gedeeld in meerdere container-apps. Het helpt ook te voldoen aan specifieke tenantvereisten, zoals hogere geheugen-naar-CPU-verhoudingen of GPU-beschikbaarheid.

Zie Workloadprofielen in Container Apps voor meer informatie.

Routering op basis van regels

Met regelgebaseerde routering kunt u binnenkomend verkeer omleiden naar specifieke container-apps of container-app-revisies. Aanvragen kunnen worden gerouteerd op basis van het HTTP-aanvraagpad en u kunt het pad in de URL herschrijven. Deze functie is handig voor systemen met meerdere tenants die aanvragen moeten toewijzen aan tenantspecifieke container-apps of revisies die gebruikmaken van het pad in de aanvraag. Deze mogelijkheid wordt doorgaans gebruikt met het isolatiemodel voor tenantspecifieke container-apps .

Zie Regelgebaseerde routering gebruiken met Container Apps voor meer informatie.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteurs:

  • 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