Migrieren von Spring Cloud-Anwendungen zu Azure Container Apps
In diesem Leitfaden erfahren Sie, worauf Sie achten müssen, wenn Sie eine vorhandene Spring Cloud-Anwendung für die Ausführung in Azure Container Apps migrieren möchten.
Vor der Migration
Führen Sie vor Beginn einer Migration die in den folgenden Abschnitten beschriebenen Schritte zur Bewertung und Bestandsermittlung aus, um eine erfolgreiche Migration zu gewährleisten.
Falls Sie keine dieser Voraussetzungen für die Migration erfüllen können, sehen Sie sich die folgenden Begleithandbücher an:
- Migrieren ausführbarer JAR-Anwendungen zu Containern in Azure Kubernetes Service (Leitfaden geplant)
- Migrieren ausführbarer JAR-Anwendungen zu Azure Virtual Machines (Leitfaden geplant)
Untersuchen der Anwendungskomponenten
Ermitteln, ob und wie das Dateisystem verwendet wird
Suchen Sie nach Fällen, in denen Ihre Dienste Daten in das lokale Dateisystem schreiben bzw. Daten daraus lesen. Ermitteln Sie, wo kurzlebige/temporäre Dateien geschrieben und gelesen und wo langlebige Dateien geschrieben und gelesen werden.
Azure Container Apps bietet mehrere Arten von Speicher. Kurzlebiger Speicher kann temporäre Daten lesen und schreiben und für einen ausgeführten Container oder ein Replikat verfügbar sein. Azure File bietet permanenten Speicher und kann für mehrere Container freigegeben werden. Weitere Informationen finden Sie unter Verwenden von Speichereinbindungen in Azure Container Apps.
Schreibgeschützter statischer Inhalt
Falls Ihre Anwendung derzeit statische Inhalte bereitstellt, benötigen Sie dafür einen anderen Speicherort. Sie könnten beispielsweise erwägen, statische Inhalte in Azure Blob Storage zu verschieben und Azure CDN hinzuzufügen, um global eine sehr hohe Downloadgeschwindigkeit zu erzielen. Weitere Informationen finden Sie unter Hosten von statischen Websites in Azure Storage und Schnellstart: Integrieren eines Azure-Speicherkontos in Azure CDN.
Dynamisch veröffentlichter statischer Inhalt
Wenn Ihre Anwendung statische Inhalte unterstützt, die hochgeladen oder von der Anwendung selbst generiert wurden und nach ihrer Erstellung unverändert bleiben, können Sie Azure Blob Storage und Azure CDN integrieren. Sie können auch eine Azure-Funktion verwenden, um Uploads zu verwalten und bei Bedarf CDN-Aktualisierungen auszulösen. Eine entsprechende Beispielimplementierung finden Sie unter Hochladen und CDN-Vorabladen von statischem Inhalt mit Azure Functions.
Ermitteln, ob Dienste betriebssystemspezifischen Code enthalten
Wenn Ihre Anwendung Code mit Abhängigkeiten vom Hostbetriebssystem enthält, müssen Sie ihn umgestalten, um diese Abhängigkeiten zu beseitigen. Beispielsweise müssen Sie möglicherweise die Verwendung von /
oder \
in Dateisystempfaden durch File.Separator
oder Paths.get
ersetzen, wenn Ihre Anwendung unter Windows ausgeführt wird.
Wechseln zu einer unterstützten Plattform
Wenn Sie Ihre Dockerfile-Datei manuell erstellen und eine containerisierte Anwendung in Azure Container Apps bereitstellen, übernehmen Sie die vollständige Kontrolle über Ihre Bereitstellung, einschließlich der JRE-/JDK-Versionen.
Für die Bereitstellung von Artefakten bietet Azure Container Apps auch bestimmte Versionen von Java (8, 11, 17 und 21) sowie bestimmte Versionen von Spring Boot- und Spring Cloud-Komponenten. Migrieren Sie zur Sicherstellung der Kompatibilität Ihre Anwendung zunächst zu einer der unterstützten Versionen von Java in der aktuellen Umgebung, und führen Sie anschließend die restlichen Schritte zur Migration aus. Achten Sie darauf, dass Sie die sich ergebende Konfiguration umfassend testen. Verwenden Sie für diese Tests das neueste stabile Release Ihrer Linux-Distribution.
Hinweis
Diese Überprüfung ist besonders wichtig, wenn Ihr aktueller Server auf einem nicht unterstützten JDK (z. B. Oracle JDK oder IBM OpenJ9) ausgeführt wird.
Melden Sie sich an Ihrem Produktionsserver an, und führen Sie den folgenden Befehl aus, um Ihre aktuelle Java-Version zu ermitteln:
java -version
Unterstützte Versionen von Java, Spring Boot und Spring Cloud sowie Anweisungen zum Aktualisieren finden Sie unter Übersicht zu Java in Azure Container Apps.
Ermitteln von Spring Boot-Versionen
Überprüfen Sie die Abhängigkeiten der einzelnen Anwendungen, die migriert werden, um ihre Spring Boot-Version zu bestimmen.
Maven
Bei Maven-Projekten befindet sich die Spring Boot-Version in der Regel im <parent>
-Element der POM-Datei:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.3.3</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
Gradle
Bei Gradle-Projekten befindet sich die Spring Boot-Version in der Regel im Abschnitt plugins
als Version des Plug-Ins org.springframework.boot
:
plugins {
id 'org.springframework.boot' version '3.3.3'
id 'io.spring.dependency-management' version '1.1.6'
id 'java'
}
Befolgen Sie für alle Anwendungen, die Spring Boot-Versionen vor 3.x verwenden, den Spring Boot 2.0-Migrationsleitfaden oder den Spring Boot 3.0-Migrationsleitfaden, um eine Aktualisierung der Anwendungen auf eine unterstützte Spring Boot-Version vorzunehmen. Unterstützte Versionen finden Sie in der Spring Cloud-Dokumentation.
Ermitteln von Spring Cloud-Versionen
Überprüfen Sie die Abhängigkeiten der einzelnen Anwendungen, die Sie migrieren möchten, um jeweils die Version der verwendeten Spring Cloud-Komponenten zu ermitteln.
Maven
In Maven-Projekten wird die Spring Cloud-Version üblicherweise in der Eigenschaft spring-cloud.version
festgelegt:
<properties>
<spring-cloud.version>2023.0.2</spring-cloud.version>
</properties>
Gradle
In Gradle-Projekten wird die Spring Cloud-Version üblicherweise im Block mit den zusätzlichen Eigenschaften festgelegt:
ext {
set('springCloudVersion', "2023.0.2")
}
Alle Anwendungen müssen so aktualisiert werden, dass sie unterstützte Versionen von Spring Cloud verwenden. Unterstützte Versionen finden Sie in der Spring Cloud-Dokumentation.
Ermitteln von Protokollaggregationslösungen
Ermitteln Sie alle Protokollaggregationslösungen, die ggf. von den zu migrierenden Anwendungen verwendet werden. Sie müssen Diagnoseeinstellungen in der Migration konfigurieren, um protokollierte Ereignisse für die Nutzung verfügbar zu machen. Weitere Informationen finden Sie im Abschnitt Sicherstellen der Konsolenprotokollierung und Konfigurieren von Diagnoseeinstellungen.
Ermitteln von APM-Agents (Application Performance Management, Anwendungsleistungsverwaltung)
Ermitteln Sie alle Application Performance Management-Agents, die von Ihren Anwendungen verwendet werden. Azure Containers Apps bietet keine integrierte Unterstützung für die APM-Integration. Sie müssen Ihr Containerimage vorbereiten oder das APM-Tool direkt in Ihren Code integrieren. Wenn Sie die Leistung Ihrer Anwendung messen möchten, aber noch kein APM integriert haben, können Sie die Verwendung von Azure Application Insights in Betracht ziehen. Weitere Informationen finden Sie im Abschnitt Migration.
Bestand: Externe Ressourcen
Identifizieren Sie externe Ressourcen, z. B. Datenquellen, JMS-Nachrichtenbroker und URLs anderer Dienste. Bei Spring Cloud-Anwendungen befindet sich die Konfiguration für solche Ressourcen in der Regel an einem der folgenden Orte:
- Im Ordner src/main/resources (üblicherweise in einer Datei namens application.properties oder application.yml)
- In dem Spring Cloud Config Server-Repository, das im vorherigen Schritt ermittelt wurde.
Datenbanken
Bei einer Spring Boot-Anwendung erscheinen Verbindungszeichenfolgen in der Regel in Konfigurationsdateien, wenn sie von einer externen Datenbank abhängt. Hier ist ein Beispiel aus der Datei application.properties angegeben:
spring.datasource.url=jdbc:mysql://localhost:3306/mysql_db
spring.datasource.username=dbuser
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
Hier ist ein Beispiel aus der Datei application.yaml angegeben:
spring:
data:
mongodb:
uri: mongodb://mongouser:deepsecret@mongoserver.contoso.com:27017
Weitere mögliche Konfigurationsszenarien finden Sie in der Dokumentation zu Spring Data:
JMS-Nachrichtenbroker
Ermitteln Sie die verwendeten Broker, indem Sie sich im Buildmanifest (in der Regel eine Datei vom Typ pom.xml oder build.gradle) die relevanten Abhängigkeiten ansehen.
Bei einer Spring Boot-Anwendung, die ActiveMQ verwendet, ist diese Abhängigkeit beispielsweise in der Datei pom.xml enthalten:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-activemq</artifactId>
</dependency>
Bei Spring Boot-Anwendungen, für die kommerzielle Broker genutzt werden, sind Abhängigkeiten meist direkt in den JMS-Treiberbibliotheken der Broker enthalten. Hier ist ein Beispiel aus der Datei build.gradle angegeben:
dependencies {
...
compile("com.ibm.mq:com.ibm.mq.allclient:9.4.0.5")
...
}
Nachdem Sie den oder die verwendeten Broker ermittelt haben, können Sie nach den entsprechenden Einstellungen suchen. Bei Spring Cloud-Anwendungen befinden sich diese in der Regel im Anwendungsverzeichnis in den Dateien application.properties und application.yml oder im Spring Cloud Config-Server-Repository.
Hinweis
Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden, der verfügbar ist. Der in diesem Verfahren beschriebene Authentifizierungsfluss, z. B. für Datenbanken, Caches, Nachrichten oder KI-Dienste, erfordert ein sehr hohes Vertrauen in die Anwendung und trägt Risiken, die in anderen Flüssen nicht vorhanden sind. Verwenden Sie diesen Fluss nur, wenn sicherere Optionen wie verwaltete Identitäten für kennwortlose oder schlüssellose Verbindungen nicht geeignet sind. Bei Vorgängen des lokalen Computers bevorzugen Sie Benutzeridentitäten für kennwortlose oder schlüssellose Verbindungen.
Hier ist ein ActiveMQ-Beispiel aus der Datei application.properties angegeben:
spring.activemq.brokerurl=broker:(tcp://localhost:61616,network:static:tcp://remotehost:61616)?persistent=false&useJmx=true
spring.activemq.user=admin
spring.activemq.password=<password>
Weitere Informationen zur ActiveMQ-Konfiguration finden Sie in der Dokumentation zu Spring Boot-Messaging.
Hier ist ein IBM MQ-Beispiel aus der Datei application.yaml angegeben:
ibm:
mq:
queueManager: qm1
channel: dev.ORDERS
connName: localhost(14)
user: admin
password: <password>
Weitere Informationen zur IBM MQ-Konfiguration finden Sie in der Dokumentation zu IBM MQ Spring-Komponenten.
Identifizieren von externen Caches
Ermitteln Sie alle verwendeten externen Caches. Redis wird häufig über Spring Data Redis verwendet. Informationen zur Konfiguration finden Sie in der Spring Data Redis-Dokumentation.
Ermitteln Sie, ob Sitzungsdaten über Spring Session zwischengespeichert werden. Suchen Sie dazu nach der entsprechenden Konfiguration (in Java oder XML).
Identitätsanbieter
Ermitteln Sie alle Identitätsanbieter und alle Spring Cloud-Anwendungen, für die eine Authentifizierung und/oder Autorisierung erforderlich ist. Informationen zum Konfigurieren von Identitätsanbietern finden Sie in den folgenden Ressourcen:
- Informationen zur OAuth2-Konfiguration finden Sie in der Schnellstartanleitung für Spring Cloud Security.
- Informationen zur Auth0-Spring Security-Konfiguration finden Sie in der Auth0-Spring Security-Dokumentation.
- Informationen zur PingFederate-Spring Security-Konfiguration finden Sie in der Auth0-PingFederate-Anleitung.
Über VMware Tanzu Application Service (TAS) (vormals Pivotal Cloud Foundry) konfigurierte Ressourcen
Bei Anwendungen, die mit TAS verwaltet werden, werden externe Ressourcen (einschließlich der weiter oben beschriebenen) häufig über TAS-Dienstbindungen konfiguriert. Verwenden Sie zum Untersuchen der Konfiguration solcher Ressourcen die TAS-Befehlszeilenschnittstelle (Cloud Foundry), um die Variable VCAP_SERVICES
für die Anwendung anzuzeigen.
# Log into TAS, if needed (enter credentials when prompted)
cf login -a <API endpoint>
# Set the organization and space containing the application, if not already selected during login.
cf target org <organization name>
cf target space <space name>
# Display variables for the application
cf env <Application Name>
Überprüfen Sie die Variable VCAP_SERVICES
auf Konfigurationseinstellungen von externen Diensten, die an die Anwendung gebunden sind. Weitere Informationen finden Sie in der Dokumentation zu TAS (Cloud Foundry).
Alle anderen externen Ressourcen
Es würde den Rahmen dieses Leitfadens sprengen, jede mögliche externe Abhängigkeit zu dokumentieren. Vergewissern Sie sich daher nach der Migration, dass alle externen Abhängigkeiten Ihrer Anwendung abgedeckt wurden.
Ermitteln des Bestands an Konfigurationsquellen und Geheimnissen
Ermitteln des Bestands an Kennwörtern und sicheren Zeichenfolgen
Überprüfen Sie alle Eigenschaften und Konfigurationsdateien sowie alle Umgebungsvariablen in den Produktionsbereitstellungen auf Secret-Zeichenfolgen und Kennwörter. Bei einer Spring Cloud-Anwendung befinden sich solche Zeichenfolgen in der Regel in der Datei application.properties oder application.yml individueller Services oder im Spring Cloud Config Server-Repository.
Inventarisieren von Zertifikaten
Dokumentieren Sie alle Zertifikate, die für öffentliche SSL-Endpunkte oder für die Kommunikation mit Back-End-Datenbanken und anderen Systemen verwendet werden. Sie können alle Zertifikate auf den Produktionsservern anzeigen, indem Sie den folgenden Befehl ausführen:
keytool -list -v -keystore <path to keystore>
Ermitteln, ob Spring Cloud Vault verwendet wird
Wenn Sie Spring Cloud Vault verwenden, um Geheimnisse zu speichern und darauf zuzugreifen, ermitteln Sie den zugrunde liegenden Geheimnisspeicher (HashiCorp Vault oder CredHub). Ermitteln Sie anschließend alle vom Anwendungscode verwendeten Geheimnisse.
Suchen der Konfigurationsserverquelle
Wenn Ihre Anwendung einen Spring Cloud Config-Server verwendet, ermitteln Sie den Speicherort der Konfiguration. Diese Einstellung befindet sich üblicherweise in der Datei bootstrap.yml oder bootstrap.properties, manchmal aber auch in der Datei application.yml oder application.properties. Die Einstellung sieht wie im folgenden Beispiel aus:
spring.cloud.config.server.git.uri: file://${user.home}/spring-cloud-config-repo
Als zugrunde liegender Datenspeicher von Spring Cloud Config Server wird zwar meist „git“ verwendet, es kann jedoch auch eines der anderen möglichen Back-Ends verwendet werden, wie weiter oben gezeigt. Konsultiern Sie die Spring Cloud Config Server-Dokumentation für Informationen zu anderen Back-Ends wie etwa Relational Database (JDBC), SVN und dem lokalen Dateisystem.
Untersuchen der Bereitstellungsarchitektur
Dokumentieren der Hardwareanforderungen für die einzelnen Dienste
Dokumentieren Sie für jeden der Spring Cloud-Dienste (mit Ausnahme des Konfigurationsservers, der Registrierung und des Gateways) die folgenden Informationen:
- Anzahl ausgeführter Instanzen
- Anzahl zugewiesener CPUs für die jeweilige Instanz
- Zugewiesener Arbeitsspeicher für die jeweilige Instanz
Dokumentieren von Georeplikation/Verteilung
Ermitteln Sie, ob die Spring Cloud-Anwendungen derzeit auf mehrere Regionen oder Rechenzentren verteilt sind. Dokumentieren Sie die Betriebszeitanforderungen/SLA für die zu migrierenden Anwendungen.
Ermitteln von Clients, von denen die Dienstregistrierung umgangen wird
Ermitteln Sie alle Clientanwendungen, die einen der zu migrierenden Dienste aufrufen, ohne die Spring Cloud-Dienstregistrierung zu verwenden. Aufrufe dieser Art sind nach der Migration nicht mehr möglich. Aktualisieren Sie solche Clients vor der Migration für die Verwendung von Spring Cloud OpenFeign.
Migration
Entfernen eingeschränkter Konfigurationen
Die Azure Container Apps-Umgebung bietet verwalteten Eureka Server, Spring Cloud Config Server und Admin. Wenn eine Anwendung an die Java-Komponente gebunden ist, fügt Azure Container Apps verwandte Eigenschaften als Systemumgebungsvariablen ein. Gemäß dem Design der externalisierten Spring Boot-Konfiguration werden Anwendungseigenschaften, die in Ihrem Code definiert oder in Artefakten verpackt sind, von Systemumgebungsvariablen überschrieben.
Wenn Sie eine der folgenden Eigenschaften über ein Befehlszeilenargument, eine Java-Systemeigenschaft oder die Umgebungsvariable eines Containers festlegen, müssen Sie sie entfernen, um Konflikte und unerwartetes Verhalten zu vermeiden:
SPRING_CLOUD_CONFIG_COMPONENT_URI
SPRING_CLOUD_CONFIG_URI
SPRING_CONFIG_IMPORT
eureka.client.fetch-registry
eureka.client.service-url.defaultZone
eureka.instance.prefer-ip-address
eureka.client.register-with-eureka
SPRING_BOOT_ADMIN_CLIENT_INSTANCE_PREFER-IP
SPRING_BOOT_ADMIN_CLIENT_URL
Erstellen einer verwalteten Azure Container Apps-Umgebung und von Apps
Stellen Sie eine Azure Container Apps-App in Ihrem Azure-Abonnement in einer vorhandenen verwalteten Umgebung bereit, oder erstellen Sie für jeden Service, den Sie migrieren, eine neue. Sie müssen keine Apps erstellen, die als Spring Cloud-Registry- und Konfigurationsserver ausgeführt werden. Weitere Informationen finden Sie unter Schnellstart: Bereitstellen Ihrer ersten Container-App über das Azure-Portal.
Vorbereiten des Spring Cloud Config-Servers
Konfigurieren Sie den Config-Server in Ihrer Azure Container Apps for Spring-Komponente. Weitere Informationen finden Sie unter Konfigurieren von Einstellungen für die Config Server für Spring-Komponente in Azure Container Apps.
Hinweis
Sollte sich Ihr derzeitiges Spring Cloud Config-Repository im lokalen Dateisystem oder in der lokalen Umgebung befinden, müssen Sie Ihre Konfigurationsdateien zunächst zu einem Repository in einer Cloud (beispielsweise GitHub, Azure Repos oder BitBucket) migrieren bzw. dort replizieren.
Sicherstellen der Konsolenprotokollierung und Konfigurieren von Diagnoseeinstellungen
Konfigurieren Sie Ihre Protokollierung so, dass alle Ausgaben an die Konsole und nicht in Dateien weitergeleitet werden.
Nach Bereitstellung einer Anwendung in Azure Container Apps können Sie die Protokollierungsoptionen in Ihrer Container Apps-Umgebung konfigurieren, um ein oder mehrere Ziele der Protokolle zu definieren. Zu diesen Zielen können Azure Monitor Log Analytics, Azure Event Hub oder sogar andere Überwachungslösungen von Drittanbietern gehören. Sie haben auch die Möglichkeit, Protokolldaten zu deaktivieren und Protokolle nur zur Laufzeit anzuzeigen. Ausführliche Konfigurationsanweisungen finden Sie unter Protokollspeicherungs- und Überwachungsoptionen in Azure Container Apps.
Konfigurieren von persistentem Speicher
Wenn ein Teil Ihrer Anwendung Daten aus dem lokalen Dateisystem liest oder in das lokale Dateisystem schreibt, müssen Sie beständigen Speicher konfigurieren, um das lokale Dateisystem zu ersetzen. Sie können den Pfad zum Einbinden im Container über die App-Einstellungen angeben und mit dem Pfad abgleichen, den Ihre App verwendet. Weitere Informationen finden Sie unter Verwenden von Speichereinbindungen in Azure Container Apps.
Migrieren von Spring Cloud Vault-Geheimnissen zu Azure Key Vault
Mithilfe von Spring Boot Starter für Azure Key Vault können Geheimnisse über Spring direkt in Anwendungen eingefügt werden. Weitere Informationen finden Sie unter Verwenden von Spring Boot Starter für Azure Key Vault.
Hinweis
Für die Migration müssen ggf. einige Secrets umbenannt werden. Aktualisieren Sie Ihren Anwendungscode entsprechend.
Migrieren aller Zertifikate zu Key Vault
Azure Containers Apps unterstützt eine sichere Kommunikation zwischen Apps. Ihre Anwendung muss den Prozess zum Aufbau einer sicheren Kommunikation nicht verwalten. Sie können das private Zertifikat in Azure Container Apps hochladen oder ein kostenloses verwaltetes Zertifikat verwenden, das von Azure Container Apps bereitgestellt wird. Eine empfohlene Vorgehensweise besteht darin, Zertifikate mithilfe von Azure Key Vault zu verwalten. Weitere Informationen hierzu finden Sie unter Zertifikate in Azure Container Apps.
Konfigurieren von Application Performance Management (APM)-Integrationen
Wenn Sie bereits APM-bezogene Variablen innerhalb des Containers konfiguriert haben, müssen Sie lediglich sicherstellen, dass die Verbindung mit der Ziel-APM-Plattform hergestellt werden kann. Wenn die APM-Konfiguration auf Umgebungsvariablen aus dem Container verweist, müssen Sie die Laufzeitumgebungsvariablen für Azure Container Apps entsprechend festlegen. Vertrauliche Informationen, z. B. die Verbindungszeichenfolge, sollten in sicherer Weise behandelt werden. Sie können sie entweder als Secret angeben oder auf ein Secret verweisen, das in Azure Key Vault gespeichert ist.
Konfigurieren dienstspezifischer Geheimnisse und externalisierter Einstellungen
Konfigurationseinstellungen können den einzelnen Containern als Umgebungsvariablen hinzugefügt werden. Alle Änderungen in den Variablen erstellen eine neue Version für die vorhandene App. Secrets sind Schlüssel-Wert-Paare und bleiben für alle Überarbeitungen gültig.
Migrieren und Aktivieren des Identitätsanbieters
Sollte für Spring Cloud-Anwendungen eine Authentifizierung oder Autorisierung erforderlich sein, stellen Sie anhand der folgenden Richtlinien sicher, dass sie für den Zugriff auf den Identitätsanbieter konfiguriert sind:
- Wenn der Identitätsanbieter Microsoft Entra ID ist, sollten keine Änderungen erforderlich sein.
- Handelt es sich bei dem Identitätsanbieter um eine lokale Active Directory-Gesamtstruktur, empfiehlt sich ggf. die Implementierung einer Hybrididentitätslösung mit Microsoft Entra ID. Entsprechende Informationen finden Sie in der Dokumentation zur Hybrididentität.
- Wenn es sich bei dem Identitätsanbieter um eine andere lokale Lösung (beispielsweise PingFederate) handelt, erfahren Sie im Thema Benutzerdefinierte Installation von Microsoft Entra Connect, wie Sie einen Verbund mit Microsoft Entra ID konfigurieren. Alternativ können Sie Spring Security nutzen, um Ihren Identitätsanbieter über OAuth2/OpenID Connect oder SAML zu verwenden.
Aktualisieren von Clientanwendungen
Aktualisieren Sie die Konfiguration aller Clientanwendungen, um die veröffentlichten Azure Container Apps-Endpunkte für migrierte Anwendungen zu verwenden.
Nach der Migration
Nachdem Sie die Migration abgeschlossen haben, überprüfen Sie, ob Ihre Anwendung erwartungsgemäß funktioniert. Mithilfe der folgenden Empfehlungen können Sie Ihre Anwendung anschließend cloudnativer gestalten.
Ziehen Sie in Erwägung, die Anwendung für die Verwendung der Spring Cloud-Registrierung zu aktivieren. Dank dieser Komponente kann Ihre Anwendung von anderen bereitgestellten Spring-Anwendungen und -Clients dynamisch erkannt werden. Weitere Informationen finden Sie unter Konfigurieren von Einstellungen für die Eureka Server für Spring-Komponente in Azure Container Apps. Ändern Sie dann alle Anwendungsclients so, dass sie den Spring Client Load Balancer verwenden. Mit dem Spring Client Load Balancer kann der Client die Adressen aller ausgeführten Instanzen der Anwendung abrufen und eine funktionierende Instanz finden, wenn eine andere Instanz beschädigt wird oder nicht mehr reagiert. Weitere Informationen finden Sie unter Spring Tips: Spring Cloud Load Balancer im Spring Blog.
Anstatt Ihre Anwendung öffentlich zu machen, können Sie wahlweise auch eine Spring Cloud Gateway-Instanz hinzufügen. Spring Cloud Gateway stellt einen einzelnen Endpunkt für alle Anwendungen zur Verfügung, die in Ihrer Azure Container Apps-Umgebung bereitgestellt werden. Wenn bereits ein Spring Cloud Gateway bereitgestellt wurde, stellen Sie sicher, dass eine Routingregel für die Weiterleitung von Datenverkehr an die neu bereitgestellte Anwendung konfiguriert ist.
Fügen Sie gegebenenfalls einen Spring Cloud-Konfigurationsserver hinzu, um die Konfiguration für alle Ihre Spring Cloud-Anwendungen zentral zu verwalten und eine zentrale Versionskontrolle durchzuführen. Erstellen Sie zunächst ein Git-Repository, um die Konfiguration zu speichern, und konfigurieren Sie die App-Instanz dann für die Verwendung dieser Konfiguration. Weitere Informationen finden Sie unter Konfigurieren von Einstellungen für die Config Server für Spring-Komponente in Azure Container Apps. Migrieren Sie dann Ihre Konfiguration mit den folgenden Schritten:
Erstellen Sie im Verzeichnis src/main/resources der Anwendung die Datei bootstrap.yml mit den folgenden Inhalten:
spring: application: name: <your-application-name>
Erstellen Sie im Git-Konfigurationsrepository die Datei <Name-Ihrer-Anwendung>.yml mit demselben Namen für
your-application-name
wie im vorherigen Schritt. Verschieben Sie die Einstellungen aus der Datei application.yml in src/main/resources in die neu erstellte Datei. Wenn die Einstellungen zuvor in einer PROPERTIES-Datei gespeichert waren, müssen sie zunächst in YAML konvertiert werden. Für diese Konvertierung finden Sie Onlinetools oder IntelliJ-Plug-Ins.Erstellen Sie im obigen Verzeichnis die Datei application.yml. Sie können diese Datei verwenden, um Einstellungen und Ressourcen zu definieren, die für alle Anwendungen in der Azure Container Apps-Umgebung freigegeben werden. Diese Einstellungen umfassen in der Regel u. a. Datenquellen, Protokollierungseinstellungen und die Konfiguration des Spring Boot-Aktors.
Commiten und pushen Sie diese Änderungen in das Git-Repository.
Entfernen Sie die Datei application.properties oder application.yml aus der Anwendung.
Fügen Sie gegebenenfalls die verwaltete Komponente Admin für Spring hinzu, um eine Verwaltungsschnittstelle für Spring Boot-Webanwendungen zu aktivieren, die Aktuatorendpunkte verfügbar machen. Weitere Informationen finden Sie unter Konfigurieren der Komponente „Spring Boot Admin“ in Azure Container Apps.
Fügen Sie ggf. eine Bereitstellungspipeline für automatische, konsistente Bereitstellungen hinzu. Es sind Anweisungen für Azure Pipelines und GitHub Actions verfügbar.
Ziehen Sie die Verwendung von Container App-Revisionen, Revisionsbezeichnungen und Gewichtungen für eingehenden Datenverkehr in Betracht, um eine Blau-Grün-Bereitstellung zu ermöglichen. So können Sie Codeänderungen in der Produktion testen, bevor sie für einige oder alle Ihre Endbenutzer verfügbar gemacht werden. Weitere Informationen finden Sie unter Blau-Grün-Bereitstellung in Azure Container Apps.
Fügen Sie ggf. Dienstbindungen hinzu, um Ihre Anwendung mit unterstützten Azure-Datenbanken zu verbinden. Bei Verwendung dieser Dienstbindungen müssten für Ihre Spring Cloud-Anwendungen keine Verbindungsinformationen mehr angegeben werden (auch keine Anmeldeinformationen).
Erwägen Sie die Aktivierung des Java-Entwicklungsstapels zum Sammeln von wichtigen JVM-Metriken für Ihre Anwendungen. Weitere Informationen finden Sie unter Java-Metriken für Java-Apps in Azure Container Apps.
Fügen Sie zur schnellen Erkennung und Behandlung von Anomalien ggf. Azure Monitor-Warnungsregeln und -Aktionsgruppen hinzu. Weitere Informationen finden Sie unter Einrichten von Warnungen in Azure Container Apps.
Erwägen Sie, Ihre App über die Zonen in der Region zu replizieren, indem Sie Azure Container Apps-Zonenredundanz aktivieren. Für den Datenverkehr erfolgt ein Lastenausgleich, und bei einem Zonenausfall wird der Datenverkehr automatisch an Replikate weitergeleitet. Weitere Informationen zu redundanten Einstellungen finden Sie unter Einblick in Azure Container Apps.
Erwägen Sie, Azure Container Apps durch Verwendung von Web Application Firewall in Application Gateway vor häufigen Exploits und Schwachstellen zu schützen. Weitere Informationen finden Sie unter Schützen von Azure Container Apps mit Web Application Firewall in Application Gateway.
Falls von Ihren Anwendungen alte Spring Cloud-Netflix-Komponenten verwendet werden, empfiehlt es sich gegebenenfalls, diese durch aktuelle Alternativen zu ersetzen (vgl. die folgende Tabelle):
Vorversion Aktuell Spring Cloud Eureka Spring Cloud Service Registry Spring Cloud Netflix Zuul Spring Cloud Gateway Spring Cloud Netflix Archaius Spring Cloud-Konfigurationsserver Spring Cloud Netflix Ribbon Spring Cloud Load Balancer (clientseitiger Lastenausgleich) Spring Cloud Hystrix Spring Cloud Circuit Breaker + Resilience4J Spring Cloud Netflix Turbine Micrometer + Prometheus