Azure Spring Apps integrerat med landningszoner

Den här referensarkitekturen distribuerar Azure Spring Apps-baslinjearkitekturen i Azure-landningszoner.

I det här scenariot förväntar sig din organisation att arbetsbelastningen använder federerade resurser som hanteras av centrala team (plattform) Centraliserade hanteringsexempel, inklusive nätverk för lokal anslutning, hantering av identitetsåtkomst och principer. Den här vägledningen förutsätter att organisationen har antagit Azure-landningszoner för att tillämpa konsekvent styrning och spara kostnader för flera arbetsbelastningar.

Designvalen som görs i den här arkitekturen beskrivs i de viktigaste tekniska designområdena för den här acceleratorn. Mer information finns i Accelerator för Azure Spring Apps-landningszoner.

Arkitektur

Följande diagram visar arkitekturen för den här metoden:

Vanliga användningsområden för den här arkitekturen inkluderar:

• Privata program: Interna program som distribueras i hybridmolnmiljöer.
• Offentliga program: Externt riktade program.

Dessa användningsfall är liknande förutom konfigurationen av säkerhets- och nätverkstrafikregler.

Komponenter

I följande avsnitt beskrivs komponenterna i den här arkitekturen. Komponenterna delas upp enligt ägarskapets ansvarsområden för att hjälpa dig att identifiera vad du ska dela med organisationens plattformsteam. Produktdokumentation om Azure-tjänster finns i avsnittet Relaterade resurser .

Teamägda programresurser

Ditt team ansvarar för att skapa och underhålla följande resurser.

• Azure Spring Apps Standard är värd för dina Java Spring Boot-program i Azure.

• Azure Application Gateway Standard_v2 är den omvända proxyn som dirigerar inkommande webbtrafik till Azure Spring Apps. Den här SKU:n har integrerad Azure Web Application Firewall som inspekterar trafik för OWASP-säkerhetsrisker (Open Web Application Security Project).

• Azure Virtual Machines fungerar som en hoppruta för hanteringsåtgärder.

• Azure Database for MySQL lagrar programdata.

• Azure Key Vault lagrar hemligheter och konfigurationer, till exempel en anslutningssträng till databasen.

• Log Analytics är en funktion i Azure Monitor som även kallas Azure Monitor-loggar. Log Analytics är övervakningsmottagaren som lagrar loggar och mått från programmet och Azure-tjänsterna.

• Azure Application Insights används som ett APM-verktyg (Application Performance Management) för att samla in alla programövervakningsdata och lagra dem direkt i Log Analytics.

Plattformsteamägda resurser

Den här arkitekturen förutsätter att följande resurser redan finns. De centrala teamen i organisationen äger och underhåller dessa resurser. Ditt program är beroende av dessa tjänster för att minska driftkostnaderna och optimera kostnaderna.

• Azure Firewall inspekterar och begränsar utgående trafik.

• Azure Bastion ger säker åtkomst till hopprutan för hantering.

• Azure ExpressRoute tillhandahåller privata anslutningar från lokal till Azure-infrastruktur.

• Azure DNS tillhandahåller namnmatchning mellan platser.

• Azure VPN Gateway ansluter programmet till fjärranslutna team i ditt lokala nätverk.

Programöverväganden

Referensimplementeringen innehåller ett exempelprogram som illustrerar ett typiskt mikrotjänstprogram som finns i en Azure Spring Apps-instans. Följande avsnitt innehåller information om det värdbaserade programmet. Mer information finns i PetClinic Store-exempel.

Tjänsteidentifiering

I ett mikrotjänstmönster måste tjänstregisterfunktionen stödjas för routning av användarbegäranden och kommunikation från tjänst till tjänst.

Tjänsterna ska kunna kommunicera med andra tjänster. När nya instanser skapas läggs de till i registret så att de kan identifieras dynamiskt. I den här arkitekturen är Managed Spring Cloud Service Registry (OSS) aktiverat för Azure Spring Apps. Den här tjänsten har ett register med live-appinstanser, möjliggör belastningsutjämning på klientsidan och frikopplar tjänstleverantörer från klienter utan att förlita sig på en DNS(Domain Name Service).

Azure Spring Apps-instansen implementerar gateway-routningsmönstret , som ger en enda startpunkt för extern trafik. Gatewayen dirigerar inkommande begäranden till de aktiva tjänstinstanser som finns i registret. I den här designen implementeras mönstret med en implementering med öppen källkod av Spring Cloud Gateway. Den erbjuder en funktionsuppsättning som innehåller autentisering och auktorisering, återhämtningsfunktioner och hastighetsbegränsning.

Konfigurationsserver

För mikrotjänster måste konfigurationsdata separeras från koden. I den här arkitekturen möjliggör Azure Spring Apps Config Server hantering av resurser via en anslutningsbar lagringsplats som stöder lokal lagring och Git-lagringsplatser.

Redundans

Du kan använda tillgänglighetszoner när du skapar en Azure Spring Apps-instans.

Med den här funktionen distribuerar Azure Spring Apps automatiskt grundläggande resurser över logiska delar av den underliggande Azure-infrastrukturen. Den här distributionen ger en högre tillgänglighetsnivå och skyddar mot maskinvarufel eller planerade underhållshändelser.

Zonredundans säkerställer att underliggande noder för virtuella datorer (VM) fördelas jämnt över alla tillgänglighetszoner. Zonredundans garanterar dock inte ens distribution av appinstanser. Om en appinstans misslyckas på grund av att dess lokaliserade zon slutar fungera skapar Azure Spring Apps en ny appinstans för den här appen på en nod i en annan tillgänglighetszon.

Om du aktiverar din egen resurs i Azure Spring Apps, till exempel din egen beständiga lagring, aktiverar du zonredundans för resursen. Mer information finns i Så här aktiverar du din egen beständiga lagring i Azure Spring Apps.

Tillgänglighetszoner stöds inte i alla regioner. Information om vilka regioner som stöder tillgänglighetszoner finns i Azure-regioner med stöd för tillgänglighetszoner.

Skalbarhet

Azure Spring Apps tillhandahåller autoskalningsfunktioner som gör det möjligt för appar att skala baserat på måtttrösklar eller under en viss tidsperiod. Automatisk skalning rekommenderas när appar behöver skalas upp eller skalas ut som svar på föränderlig efterfrågan.

Azure Spring Apps stöder även skalning av dina program manuellt genom att justera antalet processorer, minne/GB per instans och appinstans. Den här typen av skalning är lämplig för engångsskalningsaktivitet som du kanske vill utföra för vissa appar. Justera värdena för att uppfylla programmets skalningsbehov och se till att inställningarna ligger inom de maximala gränserna för varje attribut.

Nätverksöverväganden

I den här designen är arbetsbelastningen beroende av resurser som ägs av plattformsteamet för åtkomst till lokala resurser, kontroll av utgående trafik och så vidare. Mer information finns i Accelerator för Azure Spring Apps-landningszon: Nätverkstopologi och anslutning.

Nätverkstopologi

Plattformsteamet bestämmer nätverkstopologin. En hub-spoke-topologi antas i den här arkitekturen.

Virtuellt hubbnätverk

Anslutningsprenumerationen innehåller ett virtuellt hubbnätverk som delas av hela organisationen. Nätverket innehåller nätverksresurser som ägs och underhålls av plattformsteamet. Följande plattformsteamresurser finns i omfånget för den här arkitekturen:

• Azure Firewall styr utgående trafik till Internet.
• Azure Bastion skyddar åtkomsten till hopprutan för hantering.

Virtuellt ekernätverk

Programlandningszonen har minst ett fördefinierat virtuellt nätverk som är peer-kopplat till hubbnätverket. Du äger resurserna i det här nätverket, till exempel lastbalanseraren som dirigerar och skyddar inkommande HTTP/s-anslutningar till Azure Spring Apps från Internet.

Det företablerade virtuella nätverket och peerings måste kunna stödja den förväntade tillväxten av arbetsbelastningen. Beräkna storleken på det virtuella nätverket och utvärdera kraven med plattformsteamet regelbundet. Mer information finns i Krav för virtuellt nätverk.

VNet-inmatning och underinmatning

Azure Spring Apps distribueras till nätverket via VNET-inmatningsprocessen . Den här processen isolerar programmet från Internet, system i privata nätverk, andra Azure-tjänster och till och med tjänstkörningen. Inkommande och utgående trafik från programmet tillåts eller nekas baserat på nätverksregler.

Isolering uppnås via undernät. Du ansvarar för att allokera undernät i det virtuella ekernätverket. Azure Spring Apps kräver två dedikerade undernät för tjänstkörningen och för Java Spring Boot-program.

Undernäten måste vara dedikerade till en enda Azure Spring Apps-instans. Flera instanser kan inte dela samma undernät.

Minsta storlek för varje undernät är /28. Den faktiska storleken beror på antalet programinstanser som Azure Spring Apps kan stödja. Mer information finns i Använda mindre undernätsintervall.

Nätverkskontroller

Azure Application Gateway med brandväggen för webbaserade program begränsar inkommande trafik till det virtuella ekernätverket från Internet. Brandväggsregler för webbaserade program tillåter eller nekar HTTP/s-anslutningar.

Trafiken i nätverket styrs med hjälp av nätverkssäkerhetsgrupper (NSG:er) i undernät. NSG:er filtrerar trafik enligt de konfigurerade IP-adresserna och portarna. I den här designen placeras NSG:er på alla undernät. Azure Bastion-undernätet tillåter HTTPS-trafik från Internet, gatewaytjänster, lastbalanserare och det virtuella nätverket. Endast RDP- och SSH-kommunikation till de virtuella nätverken tillåts från undernätet.

Privata länkar används för att styra anslutningen mellan Azure Spring Apps och andra Azure-tjänster, till exempel åtkomst till nyckelvalvet och databasen. De privata slutpunkterna placeras i ett separat undernät.

DNS-poster för programvärdar ska lagras i Azure Privat DNS för att säkerställa fortsatt tillgänglighet under ett geografiskt fel.

Även om anslutningsprenumerationen har privata DNS-zoner skapar du egna Azure Privat DNS-zoner för att stödja de tjänster som nås av privata slutpunkter.

Utgående trafik från det virtuella nätverket måste begränsas för att förhindra dataexfiltreringsattacker. Den här trafiken dirigeras via den centraliserade Azure Firewall (nästa hopp) som tillåter eller nekar flödet med hjälp av ett fullständigt kvalificerat domännamn (FQDN).

Identitets- och åtkomsthantering

Arbetsbelastningens identitetsimplementering måste överensstämma med organisationens metodtips för att säkerställa att programmet inte bryter mot organisationens säkerhets- eller styrningsgränser. Mer information finns i Accelerator för Azure Spring Apps-landningszon: Identitets- och åtkomsthantering.

Microsoft Entra-ID rekommenderas för autentisering av användare och tjänster som interagerar med Azure Spring Apps-instansen.

Den rekommenderade metoden är att aktivera Microsoft Entra-hanterade identiteter för Azure-resurser för programmet så att appen kan autentiseras själv till andra tjänster. I den här arkitekturen används systemtilldelade hanterade identiteter för enkel hantering.

För auktorisering använder du Azure Role Based Access Control (RBAC) genom att tillämpa principen om lägsta behörighet när behörighet beviljas.

Övervakningsöverväganden

Azure-landningszonens plattform tillhandahåller delade observerbarhetsresurser som en del av hanteringsprenumerationerna. Etablering av dina egna övervakningsresurser rekommenderas dock för att förenkla den övergripande hanteringen av arbetsbelastningen. Mer information finns i Accelerator för Azure Spring Apps-landningszon: Övervaka åtgärder.

Den här arkitekturen skapar följande resurser:

• Azure Application Insights är APM-lösningen (Application Performance Monitoring) och är helt integrerad i tjänsten via en Java-agent. Den här agenten ger insyn i alla distribuerade program och beroenden utan att kräva extra kod.
• Azure Log Analytics-arbetsytan är den enhetliga mottagaren för alla loggar och mått som samlas in från Azure-tjänster och programmet.

Konfigurera Azure Spring Apps-instansen för att skicka diagnostikloggar från programmet till den etablerade Log Analytics-arbetsytan. Mer information finns i Övervaka program från slutpunkt till slutpunkt.

Samla in loggar och mått för andra Azure-tjänster. Startdiagnostiken är aktiverad för hopprutan, så du kan samla in händelser när den virtuella datorn startas.

Konfigurera diagnostikinställningar för att skicka resursloggar för alla andra Azure-resurser till en Log Analytics-arbetsyta. Resursloggar samlas inte in förrän de dirigeras till ett mål. Varje Azure-resurs kräver en egen diagnostikinställning.

Datakorrelation från flera arbetsytor

Loggar och mått som genereras av arbetsbelastningen och dess infrastrukturkomponenter sparas på arbetsbelastningens Log Analytics-arbetsyta. Loggar och mått som genereras av centraliserade tjänster som Active Directory och Azure Firewall sparas dock på en central Log Analytics-arbetsyta som hanteras av plattformsteam. Korrelering av data från olika mottagare kan leda till komplexitet.

Tänk dig ett scenario med ett användarflöde där arbetsbelastningen har beroenden för de centraliserade tjänsterna. En del av data kan samlas in på arbetsbelastningsnivå och exporteras till den centrala Log Analytics-arbetsytan där den korreleras med plattformsloggar.

Andra poster kan dock bara finnas på arbetsbelastningens arbetsyta på grund av problem som datavolym, formatkompatibilitet eller säkerhetsbegränsningar. Oinkorrigerade loggposter som finns på två eller flera arbetsytor för ett enda användarflöde kan göra det svårare att felsöka vissa problem. Dessa ytterligare komplexiteter kräver att teamen arbetar tillsammans för att felsöka programincidenter.

För att hjälpa till med den här typen av samarbete kan du bekanta dig med de procedurer som har konfigurerats av din organisation. När en säkerhetsincident inträffar kan administratörer på arbetsbelastningsnivå bli ombedda att granska sina systemloggar efter tecken på skadlig aktivitet eller tillhandahålla kopior av sina loggar till incidenthanterare för ytterligare analys. När arbetsbelastningsadministratörer felsöker programproblem kan de behöva hjälp från plattformsadministratörer för att korrelera loggposter från företagsnätverk, säkerhet eller andra plattformstjänster.

Hälsotillståndsavsökningar

Azure Application Gateway använder hälsoavsökningar för att säkerställa att inkommande trafik dirigeras till dynamiska serverdelsinstanser. Azure Spring Apps-beredskap, liveness och startavsökningar rekommenderas. Om det uppstår ett fel kan dessa avsökningar hjälpa till med en korrekt avslutning. Mer information finns i Konfigurera hälsoavsökningar.

Säkerhetsfrågor

De centraliserade teamen tillhandahåller nätverks- och identitetskontroller som en del av plattformen. Arbetsbelastningen bör dock ha säkerhetsfunktioner för att minska attackytan. Mer information finns i Accelerator för Azure Spring Apps-landningszon: Säkerhet.

Vilande data

Vilande data ska krypteras. Själva programmet är tillståndslöst. Alla data sparas i en extern databas, där den här arkitekturen använder Azure Database for MySQL. Den här tjänsten krypterar data, inklusive säkerhetskopior och temporära filer som skapas när frågor körs.

Data under överföring

Data under överföring ska krypteras. Trafiken mellan användarens webbläsare och Azure Application Gateway måste krypteras för att säkerställa att data förblir oförändrade under överföringen. I den här arkitekturen accepterar Azure Application Gateway endast HTTPS-trafik och förhandlar om TLS-handskakning. Den här kontrollen tillämpas via NSG-regler i Application Gateway-undernätet. TLS-certifikatet läses in direkt under distributionen.

Trafik från Application Gateway till Azure Spring Apps-instansen krypteras igen för att säkerställa att endast säker trafik når programmet. Azure Spring Apps-tjänstens körning tar emot den trafiken och fungerar som TLS-avslutningspunkt. Från och med då krypteras inte kommunikation mellan tjänster i programmet. Kommunikationen med andra Azure PaaS-tjänster och tjänstkörningen sker dock via TLS.

Du kan välja att implementera TLS-kommunikation från slutpunkt till slutpunkt via Azure Spring Apps. Tänk på kompromisserna. Det kan finnas en negativ effekt på svarstid och åtgärder.

Data under överföring bör inspekteras för säkerhetsrisker. Brandväggen för webbaserade program är integrerad med Application Gateway och inspekterar trafik som blockerar OWASP-sårbarheter ytterligare. Du kan konfigurera brandväggen för webbaserade program för att identifiera, övervaka och logga hotaviseringar. Eller så kan du konfigurera tjänsten för att blockera intrång och attacker som identifieras av reglerna.

DDoS-skydd

DDoS (Distributed Denial of Service) kan ta bort ett system genom att överbelasta det med begäranden. Grundläggande DDoS-skydd är aktiverat på infrastrukturnivå för alla Azure-tjänster för att skydda mot sådana attacker. Överväg att uppgradera till Azure DDoS Protection-tjänsten för att dra nytta av funktioner som övervakning, aviseringar, tröskelvärden för möjligheten att ange tröskelvärden för programmet. Mer information finns i Vanliga frågor och svar om Azure DDoS Protection Service.

Hemlighetshantering

Microsofts Nolltillit säkerhetsmetod kräver att hemligheter, certifikat och autentiseringsuppgifter lagras i ett säkert valv. Den rekommenderade tjänsten är Azure Key Vault.

Det finns alternativa sätt att lagra hemligheter beroende på Azure-tjänsten och avsikten. Den här arkitekturen implementerar följande metod:

• Certifikat läses in under distributionen.
• Anslutningen till MySQL implementeras med hjälp av Service Anslut or.

Strategier för kostnadsoptimering

På grund av den distribuerade systemdesignens natur är infrastrukturutbredning en verklighet. Denna verklighet resulterar i oväntade och okontrollerbara kostnader. Azure Spring Apps skapas med hjälp av komponenter som skalas för att möta efterfrågan och optimera kostnaderna. Grunden för den här arkitekturen är Azure Kubernetes Service (AKS). Tjänsten är utformad för att minska komplexiteten och driftkostnaderna för att hantera Kubernetes och inkluderar effektivitetsvinster i klustrets driftskostnader.

Du kan distribuera olika program och programtyper till en enda instans av Azure Spring Apps. Tjänsten stöder automatisk skalning av program som utlöses av mått eller scheman som kan förbättra användningen och kostnadseffektiviteten.

Du kan också använda Application Insights och Azure Monitor för att sänka driftskostnaderna. Med den synlighet som tillhandahålls av den omfattande loggningslösningen kan du implementera automatisering för att skala systemets komponenter i realtid. Du kan också analysera loggdata för att visa ineffektivitet i programkoden som du kan åtgärda för att förbättra systemets totala kostnad och prestanda.

Scenariodistribution

En distribution för den här referensarkitekturen finns på Azure Spring Apps Landing Zone Accelerator på GitHub. Distributionen använder Terraform-mallar.

Artefakterna på den här lagringsplatsen ger en grund som du kan anpassa för din miljö. Implementeringen skapar ett hubbnätverk med delade resurser, till exempel Azure Firewall i illustrativa syften. Den här gruppering kan mappas till separata prenumerationer för landningszoner för att hålla arbetsbelastnings- och plattformsfunktionerna åtskilda.

Om du vill distribuera arkitekturen följer du de stegvisa anvisningarna.

VMware-stöd med Enterprise-nivån

Om du vill ha stöd för hanterad VMware Tanzu® för din livedistribution kan du överväga att uppgradera till Azure Spring Apps Enterprise-nivån. VMware Tanzu® Service Registry är integrerat för Azure Spring Apps, vilket möjliggör identifiering och registrering av tjänster.

För gatewayroutning kan du växla till VMware Spring Cloud Gateway. Den erbjuder en funktionsuppsättning som innehåller autentisering och auktorisering, återhämtningsfunktioner och hastighetsbegränsning.

På Enterprise-nivån möjliggör Programkonfigurationstjänsten för Tanzu® hantering av Kubernetes-inbyggda ConfigMap-resurser som fylls i från egenskaper som definierats i en eller flera Git-lagringsplatser.

Det finns andra VMware-tjänster som stöds på den här nivån. Mer information finns i Enterprise-nivån på Azure Marketplace.

Referensimplementeringen stöder Azure Spring Apps Enterprise SKU som distributionsalternativ. I det här alternativet finns det vissa arkitekturändringar. Den använder en instans av en flexibel Azure Database for PostgreSQL-server som distribuerats med Azure Virtual Network-integrering och Azure Cache for Redis med privat slutpunkt. Exempelprogrammet är Fitness Store-appen.

Nästa steg

• Granska designområdena för Azure Spring Apps-acceleratorn för landningszoner.

Relaterade resurser

Produktdokumentation om De Azure-tjänster som används i den här arkitekturen finns i följande artiklar:

• Azure Spring Apps Enterprise
• Azure Application Gateway v2
• Azure Database for MySQL
• Azure Key Vault
• Azure Virtual Network
• Routningstabeller

Andra implementeringsscenarier finns i följande artiklar:

• Distribuera Azure Spring Apps till flera regioner
• Exponera Azure Spring Apps via en omvänd proxy