Bewerken

Share via


Azure Spring Apps geïntegreerd met landingszones

Azure Application Gateway
Azure Key Vault
Azure Spring Apps

Met deze referentiearchitectuur wordt de Basislijnarchitectuur van Azure Spring Apps geïmplementeerd in Azure-landingszones.

In dit scenario verwacht uw organisatie dat de workload federatieve resources gebruikt die worden beheerd door centrale teams (platform) Gecentraliseerd beheer, zoals netwerken voor on-premises connectiviteit, identiteitstoegangsbeheer en beleid. In deze richtlijnen wordt ervan uitgegaan dat de organisatie Azure-landingszones heeft aangenomen om consistente governance toe te passen en kosten te besparen voor meerdere workloads.

Belangrijk

Deze referentiearchitectuur maakt deel uit van de richtlijnen voor de azure Spring Apps-landingszoneversneller. De aanbevolen procedures zijn bedoeld voor een workloadeigenaar die aan de voorgaande verwachtingen wil voldoen.

De workload wordt geïmplementeerd in een azure-toepassingslandingszoneabonnement dat is ingericht door de organisatie. Als eigenaar van de workload bent u eigenaar van de resources in dit abonnement.

De workload is afhankelijk van azure-platformlandingszones-abonnementen voor gedeelde resources. De platformteams zijn eigenaar van deze resources. U bent echter verantwoordelijk voor de rijvereisten van dit team, zodat uw workload werkt zoals verwacht. Deze richtlijnen geven aantekeningen bij deze vereisten als platformteam.

We raden u ten zeerste aan het concept van Azure-landingszones te begrijpen.

De ontwerpkeuzen die in deze architectuur worden gemaakt, worden behandeld in de belangrijkste technische ontwerpgebieden voor deze accelerator. Zie De azure Spring Apps-landingszoneversneller voor meer informatie.

Tip

GitHub logo De architectuur wordt ondersteund door een voorbeeld van een implementatie op GitHub die enkele ontwerpopties illustreert. Houd rekening met de implementatie als uw eerste stap in de richting van productie.

Architectuur

In het volgende diagram ziet u de architectuur voor deze benadering:

Diagram that shows an architecture for an Azure Spring Apps workload in a landing zone.

Deze architectuur wordt doorgaans gebruikt voor:

  • Privétoepassingen: interne toepassingen die zijn geïmplementeerd in hybride cloudomgevingen.
  • Openbare toepassingen: extern gerichte toepassingen.

Deze use cases zijn vergelijkbaar, met uitzondering van de configuratie van beveiligings- en netwerkverkeersregels.

Onderdelen

In de volgende secties worden de onderdelen van deze architectuur beschreven. De onderdelen worden verdeeld op basis van de verantwoordelijkheden van het eigendom, zodat u kunt bepalen wat u met de platformteams van de organisatie kunt delen. Zie de sectie Gerelateerde resources voor productdocumentatie over Azure-services.

Resources die eigendom zijn van het toepassingsteam

Uw team is verantwoordelijk voor het maken en onderhouden van de volgende resources.

  • Azure Spring Apps Standard host uw Java Spring Boot-toepassingen in Azure.

  • Azure-toepassing Gateway Standard_v2 is de omgekeerde proxy waarmee binnenkomend webverkeer naar Azure Spring Apps wordt gerouteerd. Deze SKU heeft Azure Web Application Firewall geïntegreerd waarmee verkeer wordt gecontroleerd op OWASP-beveiligingsproblemen (Open Web Application Security Project).

  • Azure Virtual Machines fungeert als een jumpbox voor beheerbewerkingen.

  • Azure Database for MySQL slaat toepassingsgegevens op.

  • Azure Key Vault slaat geheimen en configuratie op, zoals een verbindingsreeks naar de database.

  • Log Analytics is een functie van Azure Monitor die ook wel Azure Monitor-logboeken wordt genoemd. Log Analytics is de bewakingssink waarin logboeken en metrische gegevens van de toepassing en de Azure-services worden opgeslagen.

  • Azure-toepassing Insights wordt gebruikt als een APM-hulpprogramma (Application Performance Management) om alle bewakingsgegevens van toepassingen te verzamelen en deze rechtstreeks in Log Analytics op te slaan.

Resources die eigendom zijn van het platform

In deze architectuur wordt ervan uitgegaan dat de volgende resources al bestaan. De centrale teams van de organisatie bezitten en onderhouden deze resources. Uw toepassing is afhankelijk van deze services om operationele overhead te verminderen en de kosten te optimaliseren.

  • Azure Firewall inspecteert en beperkt uitgaand verkeer.

  • Azure Bastion biedt veilige toegang tot de management jump box.

  • Azure ExpressRoute biedt privéconnectiviteit van on-premises naar Azure-infrastructuur.

  • Azure DNS biedt cross-premises naamomzetting.

  • Azure VPN Gateway verbindt de toepassing met externe teams in uw on-premises netwerk.

Overwegingen voor toepassingen

De referentie-implementatie bevat een voorbeeldtoepassing die een typische microservicestoepassing illustreert die wordt gehost in een Azure Spring Apps-exemplaar. De volgende secties bevatten details over de gehoste toepassing. Zie PetClinic Store-voorbeeld voor meer informatie.

Servicedetectie

In een microservicespatroon moet de mogelijkheid van het serviceregister worden ondersteund voor het routeren van gebruikersaanvragen en service-naar-servicecommunicatie.

Services moeten kunnen communiceren met andere services. Wanneer er nieuwe exemplaren worden weergegeven, worden ze toegevoegd aan het register, zodat ze dynamisch kunnen worden gedetecteerd. In deze architectuur is Managed Spring Cloud Service Registry (OSS) ingeschakeld voor Azure Spring Apps. Deze service onderhoudt een register van live-app-exemplaren, maakt taakverdeling aan de clientzijde mogelijk en koppelt serviceproviders los van clients zonder afhankelijk te zijn van een Domain Name Service (DNS).

Het Azure Spring Apps-exemplaar implementeert het routeringspatroon van de gateway, dat één toegangspunt biedt voor extern verkeer. De gateway stuurt binnenkomende aanvragen naar de actieve service-exemplaren in het register. In dit ontwerp wordt het patroon geïmplementeerd met een opensource-implementatie van Spring Cloud Gateway. Het biedt een functieset die verificatie en autorisatie, tolerantiefuncties en frequentiebeperking omvat.

Configuratieserver

Voor microservices moeten configuratiegegevens worden gescheiden van de code. In deze architectuur maakt Azure Spring Apps Config Server het beheer van resources mogelijk via een pluggable opslagplaats die lokale opslag en Git-opslagplaatsen ondersteunt.

Redundantie

U kunt beschikbaarheidszones gebruiken bij het maken van een Azure Spring Apps-exemplaar.

Met deze functie distribueert Azure Spring Apps automatisch fundamentele resources over logische secties van de onderliggende Azure-infrastructuur. Deze distributie biedt een hoger beschikbaarheidsniveau en beschermt tegen hardwarefouten of geplande onderhoudsgebeurtenissen.

Zoneredundantie zorgt ervoor dat onderliggende VM-knooppunten (virtuele machines) gelijkmatig worden verdeeld over alle beschikbaarheidszones. Zoneredundantie garandeert echter geen gelijkmatige distributie van app-exemplaren. Als een app-exemplaar mislukt omdat de bijbehorende zone uitvalt, maakt Azure Spring Apps een nieuw app-exemplaar voor deze app op een knooppunt in een andere beschikbaarheidszone.

Als u uw eigen resource inschakelt in Azure Spring Apps, zoals uw eigen permanente opslag, schakelt u zoneredundantie in voor de resource. Zie Uw eigen permanente opslag inschakelen in Azure Spring Apps voor meer informatie.

Beschikbaarheidszones worden niet ondersteund in alle regio's. Zie Azure-regio's met ondersteuning voor beschikbaarheidszones om te zien welke regio's beschikbaarheidszones ondersteunen.

Schaalbaarheid

Azure Spring Apps biedt kant-en-klare mogelijkheden voor automatisch schalen waarmee apps kunnen worden geschaald op basis van metrische drempelwaarden of tijdens een specifiek tijdvenster. Automatisch schalen wordt aanbevolen wanneer apps omhoog moeten schalen of uitschalen als reactie op veranderende vraag.

Azure Spring Apps biedt ook ondersteuning voor het handmatig schalen van uw toepassingen door cpu, geheugen/GB per exemplaar en het aantal app-exemplaren aan te passen. Dit type schaalaanpassing is geschikt voor eenmalige schaalaanpassingsactiviteiten die u mogelijk wilt uitvoeren voor bepaalde apps. Pas de waarden aan om te voldoen aan de schaalbehoeften van uw toepassing en zorg ervoor dat uw instellingen binnen de maximumlimieten voor elk kenmerk vallen.

Belangrijk

Het handmatig schalen van toepassingen door instellingen aan te passen verschilt van de optie voor handmatig schalen voor de instelling voor automatisch schalen in Azure Portal.

Aandachtspunten voor netwerken

In dit ontwerp is de workload afhankelijk van resources die eigendom zijn van het platformteam voor toegang tot on-premises resources, het beheren van uitgaand verkeer, enzovoort. Zie De azure Spring Apps-landingszoneversneller: Netwerktopologie en -connectiviteit voor meer informatie.

Netwerktopologie

Het platformteam bepaalt de netwerktopologie. In deze architectuur wordt uitgegaan van een stertopologie.

Virtueel hubnetwerk

Het connectiviteitsabonnement bevat een virtueel hubnetwerk dat wordt gedeeld door de hele organisatie. Het netwerk bevat netwerkresources die eigendom zijn van en worden onderhouden door het platformteam. De volgende platformteambronnen vallen binnen het bereik van deze architectuur:

  • Azure Firewall beheert uitgaand verkeer naar internet.
  • Azure Bastion beveiligt de toegang tot de management jump box.
Virtueel spoke-netwerk

De landingszone van de toepassing heeft ten minste één vooraf ingericht virtueel netwerk dat is gekoppeld aan het hubnetwerk. U bent eigenaar van de resources in dit netwerk, zoals de load balancer die binnenkomende HTTP/s-verbindingen naar Azure Spring Apps routeert en beveiligt via internet.

Het vooraf ingerichte virtuele netwerk en peerings moeten de verwachte groei van de workload kunnen ondersteunen. Maak een schatting van de grootte van het virtuele netwerk en evalueer regelmatig de vereisten met het platformteam. Zie Vereisten voor virtueel netwerk voor meer informatie.

Belangrijk

Platformteam

  • Wijs de azure Spring Apps-resourceproviderrechten Owner toe aan het gemaakte virtuele netwerk.
  • Geef afzonderlijke adressen op voor virtuele netwerken die deelnemen aan peerings.
  • Wijs IP-adresruimten toe die groot genoeg zijn om de resources van de serviceruntime en implementaties te bevatten en bieden ook ondersteuning voor schaalbaarheid.

VNet-injectie en subnetten

Azure Spring Apps wordt via het VNET-injectieproces in het netwerk geïmplementeerd. Dit proces isoleert de toepassing van internet, systemen in privénetwerken, andere Azure-services en zelfs de serviceruntime. Binnenkomend en uitgaand verkeer van de toepassing wordt toegestaan of geweigerd op basis van netwerkregels.

Isolatie wordt bereikt via subnetten. U bent verantwoordelijk voor het toewijzen van subnetten in het virtuele spoke-netwerk. Azure Spring Apps vereist twee toegewezen subnetten voor de serviceruntime en voor Java Spring Boot-toepassingen.

De subnetten moeten zijn toegewezen aan één Azure Spring Apps-exemplaar. Meerdere exemplaren kunnen niet dezelfde subnetten delen.

De minimale grootte van elk subnet is /28. De werkelijke grootte is afhankelijk van het aantal toepassingsexemplaren dat Door Azure Spring Apps kan worden ondersteund. Zie Kleinere subnetbereiken gebruiken voor meer informatie.

Waarschuwing

De geselecteerde subnetgrootte kan niet overlappen met de bestaande adresruimte van het virtuele netwerk. De grootte mag ook niet overlappen met adresbereiken van peers of on-premises subnetten.

Netwerkbediening

Azure-toepassing Gateway met Web Application Firewall beperkt binnenkomend verkeer naar het virtuele spoke-netwerk vanaf internet. Web Application Firewall-regels staan HTTP/s-verbindingen toe of weigeren.

Verkeer binnen het netwerk wordt beheerd met behulp van netwerkbeveiligingsgroepen (NSG's) op subnetten. NSG's filteren verkeer op basis van de geconfigureerde IP-adressen en poorten. In dit ontwerp worden NSG's op alle subnetten geplaatst. Het Azure Bastion-subnet staat HTTPS-verkeer toe van internet, gatewayservices, load balancers en het virtuele netwerk. Alleen RDP- en SSH-communicatie met de virtuele netwerken is toegestaan vanuit het subnet.

Privékoppelingen worden gebruikt om de connectiviteit tussen Azure Spring Apps en andere Azure-services te beheren, zoals toegang tot de sleutelkluis en database. De privé-eindpunten worden in een afzonderlijk subnet geplaatst.

DNS-records van de toepassingshost moeten worden opgeslagen in Azure Privé-DNS om ervoor te zorgen dat de beschikbaarheid tijdens een geografische fout blijft bestaan.

Hoewel het connectiviteitsabonnement privé-DNS-zones heeft, maakt u uw eigen Azure Privé-DNS-zones ter ondersteuning van de services die toegankelijk zijn voor privé-eindpunten.

Belangrijk

Platformteam

  • De Azure Privé-DNS-zones delegeren aan het toepassingsteam.
  • Stel in het hubnetwerk de waarde van de DNS-server in op Standaard (door Azure geleverde) ter ondersteuning van privé-DNS-zones die worden beheerd door het toepassingsteam.

Uitgaand verkeer van het virtuele netwerk moet worden beperkt om exfiltratieaanvallen van gegevens te voorkomen. Dit verkeer wordt gerouteerd via de gecentraliseerde Azure Firewall (volgende hop) die de stroom toestaat of weigert met behulp van een FQDN (Fully Qualified Domain Name).

Belangrijk

Platformteam

  • UDR's maken voor aangepaste routes.
  • Wijs Azure-beleid toe om te voorkomen dat het toepassingsteam subnetten maakt die niet over de nieuwe routetabel beschikken.
  • Geef voldoende RBAC-machtigingen (op rollen gebaseerd toegangsbeheer) voor het toepassingsteam, zodat ze de routes kunnen uitbreiden op basis van de workloadvereisten.

Identiteits- en toegangsbeheer

De identiteits-implementatie van de workload moet overeenkomen met de best practices van de organisatie om ervoor te zorgen dat de toepassing niet in strijd is met de beveiligings- of governancegrenzen van de organisatie. Zie De azure Spring Apps-landingszoneversneller: Identiteits- en toegangsbeheer voor meer informatie.

Microsoft Entra-id wordt aanbevolen voor het verifiëren van gebruikers en services die communiceren met het Azure Spring Apps-exemplaar.

De aanbevolen methode is om door Microsoft Entra beheerde identiteiten in te schakelen voor Azure-resources voor de toepassing, zodat de app zichzelf kan verifiëren bij andere services. In deze architectuur worden door het systeem toegewezen beheerde identiteiten gebruikt voor gebruiksgemak van beheer.

Voor autorisatie gebruikt u Op rollen gebaseerd toegangsbeheer van Azure (RBAC) door het principe van minimale bevoegdheden toe te passen bij het verlenen van machtigingen.

Overwegingen voor bewaking

Het Azure-landingszoneplatform biedt gedeelde waarneembaarheidsbronnen als onderdeel van de beheerabonnementen. Het inrichten van uw eigen bewakingsresources wordt echter aanbevolen om het algehele beheer van de workload te vereenvoudigen. Zie De azure Spring Apps-landingszoneversneller: Bewerkingen bewaken voor meer informatie.

Met deze architectuur worden de volgende resources gemaakt:

  • Azure-toepassing Insights is de APM-oplossing (Application Performance Monitoring) en is volledig geïntegreerd in de service via een Java-agent. Deze agent biedt inzicht in alle geïmplementeerde toepassingen en afhankelijkheden zonder extra code.
  • De Azure Log Analytics-werkruimte is de geïntegreerde sink voor alle logboeken en metrische gegevens die zijn verzameld van Azure-services en de toepassing.

Configureer het Azure Spring Apps-exemplaar om diagnostische logboeken van de toepassing te verzenden naar de ingerichte Log Analytics-werkruimte. Zie Toepassingen end-to-end bewaken voor meer informatie.

Verzamel logboeken en metrische gegevens voor andere Azure-services. De diagnostische opstartgegevens zijn ingeschakeld voor de jumpbox, zodat u gebeurtenissen kunt vastleggen terwijl de virtuele machine wordt opgestart.

Configureer diagnostische instellingen voor het verzenden van resourcelogboeken voor alle andere Azure-resources naar een Log Analytics-werkruimte. Resourcelogboeken worden pas verzameld wanneer ze naar een bestemming worden gerouteerd. Voor elke Azure-resource is een eigen diagnostische instelling vereist.

Gegevenscorrelatie vanuit meerdere werkruimten

Logboeken en metrische gegevens die worden gegenereerd door de workload en de bijbehorende infrastructuuronderdelen, worden opgeslagen in de Log Analytics-werkruimte van de workload. Logboeken en metrische gegevens die worden gegenereerd door gecentraliseerde services, zoals Active Directory en Azure Firewall, worden echter opgeslagen in een centrale Log Analytics-werkruimte die wordt beheerd door platformteams. Het correleren van gegevens uit verschillende sinks kan leiden tot complexiteit.

Overweeg een scenario van een gebruikersstroom waarbij de workload afhankelijk is van de gecentraliseerde services. Een deel van de gegevens kan worden verzameld op workloadniveau en geëxporteerd naar de centrale Log Analytics-werkruimte waar deze is gecorreleerd met platformlogboeken.

Andere vermeldingen kunnen echter alleen voorkomen in de werkruimte van de werkbelasting vanwege problemen zoals gegevensvolume, indelingsinteroperabiliteit of beveiligingsbeperkingen. Niet-gerelateerde logboekvermeldingen die bestaan in twee of meer werkruimten voor één gebruikersstroom, kunnen het lastiger maken om bepaalde problemen op te lossen. Deze extra complexiteiten vereisen dat de teams samenwerken om toepassingsincidenten op te lossen.

Om u te helpen met dit type samenwerking, moet u vertrouwd raken met de procedures die door uw organisatie zijn ingesteld. Wanneer er een beveiligingsincident optreedt, kunnen beheerders op workloadniveau worden gevraagd om de logboeken van hun systemen te controleren op tekenen van schadelijke activiteiten of kopieën van hun logboeken te verstrekken aan incidenthandlers voor verdere analyse. Wanneer workloadbeheerders toepassingsproblemen oplossen, hebben ze mogelijk hulp nodig van platformbeheerders om logboekvermeldingen van bedrijfsnetwerken, beveiliging of andere platformservices te correleren.

Belangrijk

Platformteam

  • RBAC verlenen om logboeksinks op te vragen en te lezen voor relevante platformbronnen.
  • Schakel logboeken in voor AzureFirewallApplicationRule, AzureFirewallNetworkRuleen AzureFirewallDnsProxy. Het toepassingsteam moet de verkeersstromen van de toepassing en aanvragen naar de DNS-server bewaken.
  • Geef het toepassingsteam voldoende machtigingen om hun bewerkingen uit te voeren.

Zie De azure Spring Apps-landingszoneversneller: Bewerkingen bewaken voor meer informatie.

Statuscontroles

Azure-toepassing Gateway gebruikt statustests om ervoor te zorgen dat binnenkomend verkeer wordt doorgestuurd naar responsieve back-endinstanties. Azure Spring Apps Readiness, Liveness en Startup-tests worden aanbevolen. Als er een fout opgetreden is, kunnen deze tests helpen bij een probleemloze beëindiging. Zie Statustests configureren voor meer informatie.

Beveiligingsoverwegingen

De gecentraliseerde teams bieden netwerk- en identiteitscontroles als onderdeel van het platform. De workload moet echter over de beveiliging beschikken om de kwetsbaarheid voor aanvallen te verminderen. Zie De azure Spring Apps-landingszoneversneller: Beveiliging voor meer informatie.

Inactieve gegevens

Data-at-rest moeten worden versleuteld. De toepassing zelf is staatloos. Alle gegevens worden bewaard in een externe database, waarbij deze architectuur gebruikmaakt van Azure Database for MySQL. Deze service versleutelt de gegevens, inclusief back-ups en tijdelijke bestanden die zijn gemaakt tijdens het uitvoeren van query's.

Actieve gegevens

Gegevens die onderweg zijn, moeten worden versleuteld. Verkeer tussen de browser van de gebruiker en Azure-toepassing Gateway moet worden versleuteld om ervoor te zorgen dat gegevens ongewijzigd blijven tijdens de overdracht. In deze architectuur accepteert Azure-toepassing Gateway alleen HTTPS-verkeer en onderhandelt tls-handshake. Deze controle wordt afgedwongen via NSG-regels in het Application Gateway-subnet. Het TLS-certificaat wordt rechtstreeks tijdens de implementatie geladen.

Verkeer van Application Gateway naar het Azure Spring Apps-exemplaar wordt opnieuw versleuteld om ervoor te zorgen dat alleen veilig verkeer de toepassing bereikt. De Azure Spring Apps-serviceruntime ontvangt dat verkeer en fungeert als het TLS-beëindigingspunt. Vanaf dat moment wordt communicatie tussen services in de toepassing niet versleuteld. Communicatie met andere Azure PaaS-services en de serviceruntime vindt echter plaats via TLS.

U kunt ervoor kiezen om end-to-end TLS-communicatie te implementeren via Azure Spring Apps. Houd rekening met de compromissen. Er kan een negatief effect zijn op latentie en bewerkingen.

Gegevens die onderweg zijn, moeten worden gecontroleerd op beveiligingsproblemen. Web Application Firewall is geïntegreerd met Application Gateway en inspecteert het verkeer dat OWASP-beveiligingsproblemen blokkeert. U kunt Web Application Firewall configureren voor het detecteren, bewaken en vastleggen van bedreigingswaarschuwingen. U kunt de service ook instellen om inbraak en aanvallen te blokkeren die door de regels zijn gedetecteerd.

DDoS-bescherming

DDoS (Distributed Denial of Service) kan een systeem uitschakelen door het te overbelasten met aanvragen. Basis-DDoS-beveiliging wordt ingeschakeld op infrastructuurniveau voor alle Azure-services om zich te beschermen tegen dergelijke aanvallen. Overweeg een upgrade uit te voeren naar de Azure DDoS Protection-service om te profiteren van functies zoals bewaking, waarschuwingen, de mogelijkheid om drempelwaarden voor de toepassing in te stellen. Zie veelgestelde vragen over Azure DDoS Protection Service voor meer informatie.

Geheimenbeheer

Voor de Zero Trust-beveiligingsbenadering van Microsoft moeten geheimen, certificaten en referenties worden opgeslagen in een beveiligde kluis. De aanbevolen service is Azure Key Vault.

Er zijn alternatieve manieren om geheimen op te slaan, afhankelijk van de Azure-service en -intentie. Deze architectuur implementeert de volgende benadering:

Strategieën voor kostenoptimalisatie

Vanwege de aard van gedistribueerd systeemontwerp is infrastructuursprawl een realiteit. Deze realiteit resulteert in onverwachte en onbeheersbare kosten. Azure Spring Apps is gebouwd met behulp van onderdelen die worden geschaald om te voldoen aan de vraag en de kosten te optimaliseren. De basis van deze architectuur is de AKS (Azure Kubernetes Service). De service is ontworpen om de complexiteit en operationele overhead van het beheren van Kubernetes te verminderen en omvat efficiëntie in de operationele kosten van het cluster.

U kunt verschillende toepassingen en toepassingstypen implementeren in één exemplaar van Azure Spring Apps. De service biedt ondersteuning voor automatisch schalen van toepassingen die worden geactiveerd door metrische gegevens of schema's die het gebruik en de kostenefficiëntie kunnen verbeteren.

U kunt Application Insights en Azure Monitor ook gebruiken om de operationele kosten te verlagen. Met de zichtbaarheid van de uitgebreide logboekregistratieoplossing kunt u automatisering implementeren om de onderdelen van het systeem in realtime te schalen. U kunt logboekgegevens ook analyseren om inefficiëntie in de toepassingscode weer te geven die u kunt aanpakken om de totale kosten en prestaties van het systeem te verbeteren.

Scenario-implementatie

Een implementatie voor deze referentiearchitectuur is beschikbaar op Azure Spring Apps Landing Zone Accelerator op GitHub. De implementatie maakt gebruik van Terraform-sjablonen.

De artefacten in deze opslagplaats bieden een basis die u kunt aanpassen voor uw omgeving. De implementatie maakt een hubnetwerk met gedeelde resources, zoals Azure Firewall, voor illustratieve doeleinden. Deze groepering kan worden toegewezen aan afzonderlijke abonnementen voor landingszones om workload- en platformfuncties gescheiden te houden.

Volg de stapsgewijze instructies om de architectuur te implementeren.

VMware-ondersteuning met de Enterprise-laag

Als u beheerde VMware Tanzu-ondersteuning® voor uw live-implementatie wilt, kunt u overwegen om een upgrade uit te voeren naar de Azure Spring Apps Enterprise-laag. Het VMware Tanzu-serviceregister® is geïntegreerd voor Azure Spring Apps, waarmee servicedetectie en -registratie mogelijk is.

Voor gatewayroutering kunt u overschakelen naar VMware Spring Cloud Gateway. Het biedt een functieset die verificatie en autorisatie, tolerantiefuncties en frequentiebeperking omvat.

In de Enterprise-laag maakt Application Configuration Service voor Tanzu® het beheer mogelijk van Kubernetes-systeemeigen ConfigMap-resources die zijn ingevuld op basis van eigenschappen die zijn gedefinieerd in een of meer Git-opslagplaatsen.

Er worden andere VMware-services ondersteund in deze laag. Zie enterprise-laag in Azure Marketplace voor meer informatie.

De referentie-implementatie ondersteunt Azure Spring Apps Enterprise SKU als implementatieoptie. In deze optie zijn er enkele wijzigingen in de architectuur. Het maakt gebruik van een exemplaar van een flexibele Azure Database for PostgreSQL-server die is geïmplementeerd met Azure Virtual Network-integratie en Azure Cache voor Redis met een privé-eindpunt. De voorbeeldtoepassing is de Fitness Store-app.

Volgende stappen

Raadpleeg de volgende artikelen voor productdocumentatie over de Azure-services die in deze architectuur worden gebruikt:

Zie de volgende artikelen voor andere implementatiescenario's: