In Zielzonen integrierte Azure Spring Apps

Diese Referenzarchitektur stellt die Azur Spring Apps-Basisarchitektur in Azure-Zielzonen bereit.

In diesem Szenario erwartet Ihre Organisation, dass die Workload Verbundressourcen verwendet, die von zentralen Teams (Plattform) verwaltet werden. Die Beispiele für zentrale Verwaltung umfassen lokale Konnektivität, Identitätszugriffsverwaltung und Richtlinien. In diesem Leitfaden wird davon ausgegangen, dass die Organisation Azure-Zielzonen eingeführt hat, um konsistente Governance zu erreichen und Kosten für mehrere Workloads zu sparen.

Die in dieser Architektur getroffenen Designentscheidungen werden in den wichtigsten technischen Designbereichen behandelt. Weitere Informationen finden Sie in der Zielzone von Azure Spring Apps im Cloud Adoption Framework.

Aufbau

Die folgende Abbildung zeigt die Architektur für diesen Ansatz:

Typische Einsatzmöglichkeiten für diese Architektur sind:

• Private Anwendungen: Interne Anwendungen, die in Hybrid Cloud-Umgebungen bereitgestellt werden.
• Öffentliche Anwendungen: Nach außen gerichtete Anwendungen.

Diese Anwendungsfälle sind ähnlich, mit Ausnahme der Konfiguration von Sicherheits- und Netzwerkverkehrsregeln.

Komponenten

In den folgenden Abschnitten werden die Komponenten dieser Architektur beschrieben. Die Komponenten werden gemäß den Zuständigkeiten des jeweiligen Besitzes aufgeteilt, damit Sie ermitteln können, was Sie mit den Plattformteams der Organisation teilen müssen. Eine Produktdokumentation zu Azure-Diensten finden Sie im Abschnitt Zugehörige Ressourcen.

Ressourcen im Besitz des Anwendungsteams

Ihr Team ist für das Erstellen und Verwalten der folgenden Ressourcen verantwortlich.

• Azure Spring Apps Standard hostet Ihre Java Spring Boot-Anwendungen in Azure.

• Azure Application Gateway Standard_v2 ist der Reverseproxy, der eingehenden Webdatenverkehr an Azure Spring Apps weiterleitet. Diese SKU verfügt über eine integrierte Azure Web Application Firewall, die den Datenverkehr auf OWASP-Sicherheitsrisiken (Open Web Application Security Project) überprüft.

• Azure Virtual Machine fungiert als Jumpbox für Verwaltungsvorgänge.

• Azure Database for MySQL speichert Anwendungsdaten.

• Azure Key Vault speichert Geheimnisse und Konfigurationen, z. B. Verbindungszeichenfolgen für die Datenbank.

• Log Analytics ist ein Feature von Azure Monitor, das auch als Azure Monitor-Protokolle bezeichnet wird. Log Analytics ist die Überwachungssenke, in der Protokolle und Metriken aus der Anwendung und den Azure-Diensten gespeichert werden.

• Azure Application Insights wird als APM-Tool (Application Performance Management) zum Sammeln aller Anwendungsüberwachungsdaten und deren Speicherung in Log Analytics genutzt.

Ressourcen im Besitz des Plattformteams

Bei dieser Architektur wird davon ausgegangen, dass die folgenden Ressourcen bereits vorhanden sind. Die zentralen Teams der Organisation besitzen und verwalten diese Ressourcen. Ihre Anwendung ist von diesen Diensten abhängig, um den Betriebsaufwand zu reduzieren und die Kosten zu optimieren.

• Azure Firewall überprüft den ausgehenden Datenverkehr und schränkt ihn ein.

• Azure Bastion bietet sicheren Zugriff auf die Verwaltungsjumpbox.

• Azure ExpressRoute stellt private Konnektivität von der lokalen Infrastruktur zur Azure-Infrastruktur bereit.

• Azure DNS stellt eine standortübergreifende Namensauflösung bereit.

• Azure VPN Gateway verbindet die Anwendung mit Remoteteams in Ihrem lokalen Netzwerk.

Überlegungen zu Anwendungen

Die Referenzimplementierung enthält eine Beispielanwendung, die eine typische, in einer Azure Spring Apps-Instanz gehostete Microserviceanwendung veranschaulicht. Die folgenden Abschnitte enthalten weitere Informationen über die gehostete Anwendung. Weitere Informationen finden Sie im PetClinic-Beispiel.

Dienstermittlung

In einem Microservicemuster muss die Dienstregistrierungsfunktion für das Routing von Benutzeranforderungen und die Dienst-zu-Dienst-Kommunikation unterstützt werden.

Dienste sollten in der Lage sein, mit anderen Diensten zu kommunizieren. Wenn neue Instanzen erzeugt werden, werden sie der Registrierung hinzugefügt, um sie dynamisch erkennen zu können. In dieser Architektur ist die Managed Spring Cloud Service Registry (OSS) für Azure Spring Apps aktiviert. Dieser Dienst verwaltet eine Registrierung der Live-App-Instanzen, aktiviert den clientseitigen Lastenausgleich und entkoppelt die Dienstanbieter von den Clients, ohne dafür DNS (Domain Name Service) zu benötigen.

Die Azure Spring Apps-Instanz implementiert das Gatewayrouting-Muster, das einen zentralen Einstiegspunkt für externen Datenverkehr bereitstellt. Das Gateway leitet eingehende Anforderungen an die aktiven Dienstinstanzen weiter, die sich in der Registrierung befinden. In diesem Entwurf wird das Muster mit der Open-Source-Implementierung von Spring Cloud Gateway implementiert. Dies bietet einen Featuresatz, der Authentifizierung und Autorisierung, Resilienzfeatures und Ratenbegrenzung umfasst.

Konfigurationsserver

Für Microservices müssen Konfigurationsdaten vom Code getrennt werden. In dieser Architektur ermöglicht Azure Spring Apps Config Server die Verwaltung von Ressourcen über ein austauschbares Repository, das lokalen Speicher und Git-Repositorys unterstützt.

Redundanz

Sie können Verfügbarkeitszonen verwenden, wenn Sie eine Azure Spring Apps-Instanz erstellen.

Mit diesem Feature verteilt Azure Spring Apps automatisch grundlegende Ressourcen in logischen Abschnitten der zugrunde liegenden Azure-Infrastruktur. Diese Verteilung ermöglicht ein höheres Maß an Verfügbarkeit und schützt vor Hardwareausfällen oder bei geplanten Wartungsereignissen.

Zonenredundanz stellt sicher, dass zugrunde liegende VM-Knoten gleichmäßig über alle Verfügbarkeitszonen verteilt werden. Zonenredundanz garantiert aber keine gleichmäßige Verteilung von App-Instanzen. Wenn eine App-Instanz ausfällt, weil die ihr zugewiesene Zone ausfällt, erstellt Azure Spring Apps eine neue App-Instanz für diese App auf einem Knoten in einer anderen Verfügbarkeitszone.

Aktivieren Sie beim Aktivieren Ihrer eigenen Ressource in Azure Spring Apps (z. B. eines eigenen beständigen Speichers) die Zonenredundanz für die Ressource. Weitere Informationen finden Sie unter Aktivieren Ihres eigenen beständigen Speichers in Azure Spring Apps.

Verfügbarkeitszonen werden nicht in allen Regionen unterstützt. Eine Liste von Regionen, die Verfügbarkeitszonen unterstützen, finden Sie unter Azure-Regionen mit Unterstützung für Verfügbarkeitszonen.

Skalierbarkeit

Azure Spring Apps bietet standardmäßig Funktionen für die automatische Skalierung, die es Apps ermögliche, basierend auf Metrikschwellenwerten oder während eines bestimmten Zeitfensters skaliert zu werden. Die automatische Skalierung wird empfohlen, wenn Apps als Reaktion auf sich ändernde Nachfrage hoch- oder aufskaliert werden müssen.

Azure Spring Apps unterstützt auch die manuelle Skalierung Ihrer Anwendungen durch Anpassen der CPU, von Arbeitsspeicher/GB pro Instanz und der Anzahl von App-Instanzen. Diese Art der Skalierung eignet sich für einmalige Skalierungsaktivitäten, die Sie möglicherweise für bestimmte Apps ausführen möchten. Passen Sie die Werte an die Skalierungsanforderungen Ihrer Anwendung an, und stellen Sie sicher, dass Ihre Einstellungen innerhalb der maximalen Grenzwerte für jedes Attribut liegen.

Überlegungen zum Netzwerkbetrieb

In diesem Entwurf ist die Workload von Ressourcen abhängig, die sich im Besitz des Plattformteams befinden, um auf lokale Ressourcen zuzugreifen, den ausgehenden Datenverkehr zu steuern usw. Weitere Informationen finden Sie in der Azure Spring Apps-Zielzone: Netzwerktopologie und Konnektivität.

Netzwerktopologie

Das Plattformteam bestimmt die Netzwerktopologie. Die Hub-Spoke-Topologie wird in dieser Architektur verwendet.

Virtuelles Hubnetzwerk

Das Konnektivitätsabonnement enthält ein virtuelles Hubnetzwerk, das von der gesamten Organisation gemeinsam genutzt wird. Das Netzwerk enthält Netzwerkressourcen, deren Besitzer das Plattformteam ist und die von diesem verwaltet werden. Die folgenden Ressourcen des Plattformteams sind in dieser Architektur enthalten:

• Azure Firewall steuert den ausgehenden Datenverkehr ins Internet.
• Azure Bastion sichert den Zugriff auf die Verwaltungsjumpbox.

Virtuelles Spoke-Netzwerk

Die Anwendungszielzone verfügt über mindestens ein vorab bereitgestelltes virtuelles Netzwerk, das mit dem Hubnetzwerk verknüpft ist. Sie besitzen die Ressourcen in diesem Netzwerk, z. B. den Lastenausgleich, der eingehende HTTP/s-Verbindungen mit Azure Spring Apps aus dem Internet weiterleitet und schützt.

Das vorab bereitgestellte virtuelle Netzwerk und Peerings müssen in der Lage sein, das erwartete Wachstum der Workload zu unterstützen. Schätzen Sie regelmäßig in Zusammenarbeit mit dem Plattformteam die Größe des virtuellen Netzwerks, und bewerten Sie die Anforderungen. Weitere Informationen finden Sie unter Anforderungen für virtuelle Netzwerke.

VNET-Einschleusung und Subnetz

Azure Spring Apps wird über den Prozess der VNET-Einschleusung im Netzwerk bereitgestellt. Dieser Prozess isoliert die Anwendung vom Internet, Systemen in privaten Netzwerken, anderen Azure-Diensten und sogar der Dienstlaufzeit. Eingehender und ausgehender Datenverkehr von der Anwendung wird basierend auf Netzwerkregeln zugelassen oder verweigert.

Die Isolation wird durch Subnetze erzielt. Sie sind für die Zuweisung von Subnetzen im virtuellen Spokenetzwerk verantwortlich. Azure Spring Apps erfordert zwei dedizierte Subnetze für die Dienstlaufzeit und für Java Spring Boot-Anwendungen.

Die Subnetze müssen dediziert für eine einzelne Azure Spring Apps-Instanz sein. Mehrere Instanzen können nicht die gleichen Subnetze gemeinsam verwenden.

Die Mindestgröße jedes Subnetzes beträgt /28. Die tatsächliche Größe hängt von der Anzahl der Anwendungsinstanzen ab, die Azure Spring Apps unterstützen kann. Weitere Informationen finden Sie unter Verwenden kleinerer Subnetzbereiche.

Netzwerksteuerungen

Azure Application Gateway mit Web Application Firewall schränkt eingehenden Datenverkehr in das virtuelle Spoke-Netzwerk aus dem Internet ein. Web Application Firewall-Regeln lassen HTTP/s-Verbindungen zu oder verweigern sie.

Der Datenverkehr innerhalb des Netzwerks wird mithilfe von Netzwerksicherheitsgruppen (NSGs) in Subnetzen gesteuert. Netzwerksicherheitsgruppen filtern den Datenverkehr gemäß den konfigurierten IP-Adressen und Ports. In diesem Entwurf werden NSGs in allen Subnetzen platziert. Das Bastion-Subnetz lässt HTTPS-Datenverkehr aus dem Internet, von Gatewaydiensten, Lastenausgleichsmodulen und aus dem virtuellen Netzwerk zu. Nur RDP- und SSH-Kommunikation mit den virtuellen Netzwerken ist aus dem Subnetz zulässig.

Private Verbindungen werden verwendet, um die Konnektivität zwischen Azure Spring Apps und anderen Azure-Diensten zu steuern, z. B. den Zugriff auf den Schlüsseltresor und die Datenbank. Die privaten Endpunkte werden in einem separaten Subnetz platziert.

DNS-Einträge des Anwendungshosts sollten im privaten Azure-DNS gespeichert werden, um die fortgesetzte Verfügbarkeit während eines geografischen Ausfalls sicherzustellen.

Obwohl das Konnektivitätsabonnement über private DNS-Zonen verfügt, erstellen Sie Ihre eigenen privaten Azure-DNS-Zonen, um die Dienste zu unterstützen, auf die von privaten Endpunkten zugegriffen wird.

Ausgehender Datenverkehr aus dem virtuellen Netzwerk muss eingeschränkt werden, um Datenexfiltrationsangriffe zu verhindern. Dieser Datenverkehr wird über die zentralisierte Azure Firewall (nächster Hop) weitergeleitet, die den Flow mithilfe des vollqualifizierten Domänennamens (Fully Qualified Domain Name, FQDN) zulässt oder verweigert.

Identitäts- und Zugriffsverwaltung

Die Identitätsimplementierung der Workload muss mit den bewährten Methoden der Organisation übereinstimmen, um sicherzustellen, dass die Anwendung keine Sicherheits- oder Governancevorgaben der Organisation verletzt. Weitere Informationen finden Sie in der Azure Spring Apps-Zielzone: Identitäts- und Zugriffsverwaltung.

Microsoft Entra ID wird für die Authentifizierung von Benutzer*innen und Diensten empfohlen, die mit der Azure Spring Apps-Instanz interagieren.

Der empfohlene Ansatz besteht darin, verwaltete Microsoft Entra-Identitäten für Azure-Ressourcen für die Anwendung zu aktivieren, damit sich die App bei anderen Diensten selbst authentifizieren kann. In dieser Architektur werden systemseitig zugewiesene verwaltete Identitäten verwendet, um die Verwaltung zu vereinfachen.

Verwenden Sie für die Autorisierung die rollenbasierte Azure-Zugriffssteuerung (Role Based Access Control, RBAC), indem Sie beim Erteilen von Berechtigungen das Prinzip der geringsten Rechte anwenden.

Aspekte der Überwachung

Die Azure-Zielzonenplattform stellt freigegebene Einblickressourcen im Rahmen der Verwaltungsabonnements bereit. Die Bereitstellung eigener Überwachungsressourcen wird jedoch empfohlen, um die allgemeine Verwaltung der Workload zu vereinfachen. Weitere Informationen finden Sie in der Azure Spring Apps-Zielzone: Überwachen von Vorgängen.

Diese Architektur erstellt die folgenden Ressourcen:

• Die Überwachungslösung für die Anwendungsleistung (Application Performance Monitoring, APM) ist Azure Application Insights, und sie ist über einen Java-Agent vollständig in den Dienst integriert. Dieser Agent bietet Einblick in alle bereitgestellten Anwendungen und Abhängigkeiten, ohne dass zusätzlicher Code erforderlich ist.
• Der Azure Log Analytics-Arbeitsbereich ist die einheitliche Senke für alle Protokolle und Metriken, die von Azure-Diensten und der Anwendung erfasst werden.

Konfigurieren Sie die Azure Spring Apps-Instanz so, dass Diagnoseprotokolle von der Anwendung an den bereitgestellten Log Analytics-Arbeitsbereich gesendet werden. Weitere Informationen finden Sie unter End-to-End-Überwachung von Anwendungen.

Erfassen Sie Protokolle und Metriken für andere Azure-Dienste. Die Startdiagnose ist für die Jumpbox aktiviert, sodass Sie Ereignisse beim Starten des virtuellen Computers erfassen können.

Konfigurieren Sie Diagnoseeinstellungen, um Ressourcenprotokolle für alle anderen Azure-Ressourcen an einen Log Analytics-Arbeitsbereich zu senden. Ressourcenprotokolle werden erst gesammelt, wenn sie an ein Ziel weitergeleitet werden. Jede Azure-Ressource erfordert eine eigene Diagnoseeinstellung.

Datenkorrelation aus mehreren Arbeitsbereichen

Protokolle und Metriken, die von der Workload und ihren Infrastrukturkomponenten generiert werden, werden im Log Analytics-Arbeitsbereich der Workload gespeichert. Protokolle und Metriken, die von zentralisierten Diensten wie Active Directory und der Azure Firewall generiert werden, werden jedoch in einem zentralen Log Analytics-Arbeitsbereich gespeichert, der von Plattformteams verwaltet wird. Das Korrelieren von Daten aus verschiedenen Senken kann zu Komplexitäten führen.

Stellen Sie sich ein Szenario mit einem Benutzerflow vor, bei dem die Workload Abhängigkeiten von den zentralisierten Diensten aufweist. Ein Teil der Daten kann auf Workloadebene erfasst und in den zentralen Log Analytics-Arbeitsbereich exportiert werden, wo sie mit Plattformprotokollen korreliert werden.

Andere Einträge können jedoch aufgrund von Problemen wie Datenvolume, Formatinteroperabilität oder Sicherheitseinschränkungen nur im Arbeitsbereich der Workload vorhanden sein. Nicht korrelierte Protokolleinträge, die in zwei oder mehr Arbeitsbereichen für einen einzelnen Benutzerflow vorhanden sind, können die Behandlung bestimmter Probleme erschweren. Diese zusätzlichen Komplexitäten erfordern, dass die entsprechenden Teams zusammenarbeiten, um Anwendungsvorfälle zu behandeln.

Um bei dieser Art der Zusammenarbeit zu helfen, machen Sie sich mit den von Ihrer Organisation eingerichteten Verfahren vertraut. Wenn ein Sicherheitsvorfall auftritt, werden Administratoren auf Workloadebene möglicherweise aufgefordert, die Protokolle ihrer Systeme auf Anzeichen böswilliger Aktivitäten zu überprüfen oder Kopien ihrer Protokolle zur weiteren Analyse für Vorfallsbearbeiter bereitzustellen. Wenn Workloadadministratoren Anwendungsprobleme behandeln, benötigen sie möglicherweise Hilfe von Plattformadministratoren, um Protokolleinträge aus Unternehmensnetzwerken, Sicherheits- oder anderen Plattformdiensten zu korrelieren.

Integritätstests

Azure Application Gateway verwendet Integritätstests, um sicherzustellen, dass eingehender Datenverkehr an reaktionsfähige Back-End-Instanzen weitergeleitet wird. Azure Spring Apps-Tests für Bereitschaft, Livezustand und Start werden empfohlen. Wenn ein Fehler auftritt, können diese Tests bei der ordnungsgemäßen Beendigung helfen. Weitere Informationen finden Sie unter Konfigurieren von Integritätsüberprüfungen.

Sicherheitshinweise

Die zentralisierten Teams stellen Netzwerk- und Identitätskontrollen als Teil der Plattform bereit. Die Workload sollte jedoch über Sicherheitsfaktoren verfügen, um die Angriffsfläche zu verringern. Weitere Informationen finden Sie in der Azure Spring Apps-Zielzone: Sicherheit.

Ruhende Daten

Ruhende Daten sollten verschlüsselt werden. Die Anwendung selbst ist zustandslos. Alle Daten werden in einer externen Datenbank beibehalten, wobei in dieser Architektur Azure Database for MySQL verwendet wird. Dieser Dienst verschlüsselt die Daten wie Sicherungen und temporäre Dateien, die während der Ausführung von Abfragen erstellt wurden.

Daten während der Übertragung

In Übertragung begriffene Daten sollten verschlüsselt werden. Der Datenverkehr zwischen dem Browser des Benutzers und Azure Application Gateway muss verschlüsselt werden, um sicherzustellen, dass Daten während der Übertragung unverändert bleiben. In dieser Architektur akzeptiert Azure Application Gateway nur HTTPS-Datenverkehr und verhandelt den TLS-Handshake. Diese Überprüfung wird über NSG-Regeln im Application Gateway-Subnetz erzwungen. Das TLS-Zertifikat wird während der Bereitstellung direkt geladen.

Der Datenverkehr von Application Gateway zur Azure Spring Apps-Instanz wird erneut verschlüsselt, um sicherzustellen, dass nur sicherer Datenverkehr die Anwendung erreicht. Die Dienstlaufzeit von Azure Spring Apps empfängt diesen Datenverkehr und fungiert als TLS-Abschlusspunkt. Ab diesem Punkt wird die Kommunikation zwischen Diensten innerhalb der Anwendung nicht verschlüsselt. Die Kommunikation mit anderen Azure PaaS-Diensten und der Dienstlaufzeit erfolgt jedoch über TLS.

Sie können die End-to-End-TLS-Kommunikation über Azure Spring Apps implementieren. Berücksichtigen Sie die Vor- und Nachteile. Dies kann sich eventuell negativ auf Wartezeiten und Vorgänge auswirken.

Daten während der Übertragung sollten auf Sicherheitsrisiken überprüft werden. Web Application Firewall ist in Application Gateway integriert und untersucht OWASP-Sicherheitsrisiken, die Datenverkehr blockieren. Sie können Web Application Firewall konfigurieren, um Bedrohungswarnungen zu erkennen, zu überwachen und zu protokollieren. Sie können den Dienst auch so einrichten, dass Eindringversuche und Angriffe blockiert werden, die von den Regeln erkannt werden.

DDoS-Schutz

Ein Distributed Denial of Service-Angriff (DDoS) kann zu einem Ausfall des Systems führen, indem es mit Anforderungen überlastet wird. Der grundlegende DDoS-Schutz ist auf Infrastrukturebene für alle Azure-Dienste aktiviert, um vor solchen Angriffen zu schützen. Erwägen Sie ein Upgrade auf den Azure DDoS Protection-Dienst, um Features wie Überwachung, Warnungen und das Festlegen von Schwellenwerten für die Anwendung nutzen zu können. Weitere Informationen finden Sie in den häufig gestellten Fragen zum Azure DDoS Protection-Dienst.

Verwaltung von Geheimnissen

Der Zero Trust-Sicherheitsansatz von Microsoft erfordert, dass Geheimnisse, Zertifikate und Anmeldeinformationen in einem sicheren Tresor gespeichert werden. Azure Key Vault wird als Dienst empfohlen.

Je nach Azure-Dienst und Absicht gibt es alternative Möglichkeiten zum Speichern von Geheimnissen. Diese Architektur implementiert den folgenden Ansatz:

• Zertifikate werden während der Bereitstellung geladen.
• Die Verbindung mit MySQL wird mithilfe des Dienstconnectors implementiert.

Strategien zur Kostenoptimierung

Der Entwurf des verteilten Systems bringt die Ausdehnung der Infrastruktur mit sich. Dies führt zu unerwarteten und unkontrollierbaren Kosten. Azure Spring Apps basiert auf Komponenten, die sich skalieren lassen, um die Nachfrage zu erfüllen und die Kosten zu optimieren. Die Grundlage dieser Architektur ist der Azure Kubernetes Service (AKS). Der Dienst ist so konzipiert, dass die Komplexität und der betriebliche Aufwand bei der Verwaltung von Kubernetes reduziert werden. Dies umfasst auch die Effizienz der Betriebskosten des Clusters.

Sie können verschiedene Anwendungen und Anwendungstypen in einer einzelnen Instanz von Azure Spring Apps bereitstellen. Der Dienst unterstützt die automatische Skalierung von Anwendungen, die durch Metriken oder Zeitpläne ausgelöst werden, die die Auslastung und Kosteneffizienz verbessern.

Sie können auch Application Insights und Azure Monitor verwenden, um die Betriebskosten zu senken. Mit den von der umfassenden Protokollierungslösung gebotenen Einblicken können Sie Automatisierung implementieren, um die Komponenten des Systems in Echtzeit zu skalieren. Sie können Protokolldaten auch analysieren, um Ineffizienzen im Anwendungscode zu erkennen, die Sie zur Verbesserung der Gesamtkosten und der Leistung des Systems beseitigen können.

Szenariobereitstellung

Eine Bereitstellung für diese Referenzarchitektur ist im GitHub-Repository für Azure Spring Apps verfügbar. Die Bereitstellung verwendet Terraform-Vorlagen.

Die Artefakte in diesem Repository bilden eine Grundlage, die Sie für Ihre Umgebung anpassen können. Die Implementierung erstellt zu Veranschaulichungszwecken ein Hubnetzwerk mit freigegebenen Ressourcen wie Azure Firewall. Diese Gruppierung kann separaten Zielzonenabonnements zugeordnet werden, um Workload- und Plattformfunktionen voneinander zu trennen.

Befolgen Sie zum Bereitstellen der Architektur die Schritt-für-Schritt-Anweisungen.

VMware-Unterstützung im Enterprise-Tarif

Wenn Sie Support für verwaltete VMware Tanzu®-Komponenten für Ihre Livebereitstellungen benötigen, sollten Sie ein Upgrade auf den Enterprise-Tarif von Azure Spring Apps in Betracht ziehen. Die VMware Tanzu®-Dienstregistrierung ist für Azure Spring Apps integriert, was die Diensterkennung und -registrierung ermöglicht.

Für das Gatewayrouting können Sie zu VMware Spring Cloud Gateway wechseln. Dies bietet einen Featuresatz, der Authentifizierung und Autorisierung, Resilienzfeatures und Ratenbegrenzung umfasst.

Auf der Enterprise-Ebene ermöglicht der Anwendungskonfigurationsdienst für Tanzu® die Verwaltung von Kubernetes-nativen ConfigMap-Ressourcen, die aus Eigenschaften mit Daten aufgefüllt werden, die in mindestens einem Git-Repository definiert sind.

Auf dieser Ebene werden weitere VMware-Dienste unterstützt. Weitere Informationen finden Sie unter Enterprise-Tarif in Azure Marketplace.

Die Referenzimplementierung unterstützt die Azure Spring Apps Enterprise-SKU als Bereitstellungsoption. In dieser Option gibt es einige Architekturänderungen. Es wird eine Instanz von Azure Database for PostgreSQL – Flexible Server verwendet, die mit der Integration von Azure Virtual Network und Azure Cache for Redis mit privatem Endpunkt bereitgestellt wird. Die Beispielanwendung ist die Fitness Store-App.

Nächste Schritte

• Überprüfen Sie die Entwurfsbereiche der Azure Spring Apps-Angebotszone.

Zugehörige Ressourcen

Eine Produktdokumentation zu den in dieser Architektur verwendeten Azure-Diensten finden Sie in den folgenden Artikeln.

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

Weitere Implementierungsszenarien finden Sie in den folgenden Artikeln:

• Bereitstellen von Azure Spring Apps in mehreren Regionen
• Verfügbarmachen von Azure Spring Apps über einen Reverseproxy