Freigeben über


Migrieren von Spring Cloud-Anwendungen zu Azure Container Apps

In diesem Handbuch wird beschrieben, was Sie beachten sollten, wenn Sie eine vorhandene Spring Cloud-Anwendung migrieren möchten, die auf Azure Container Apps ausgeführt werden soll.

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 auf Azure Kubernetes Service (Anleitung geplant)
  • Migrieren ausführbarer JAR-Anwendungen zu Azure Virtual Machines (Anleitung 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. Flüchtiger Speicher kann temporäre Daten lesen und schreiben und ist in einem laufenden Container oder Replikat verfügbar. Azure Datei bietet permanenten Speicher und kann für mehrere Container freigegeben werden. Weitere Informationen finden Sie unter Use storage mounts 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 erwägen, statische Inhalte nach Azure Blob Storage zu übertragen und Azure CDN für blitzschnelle Downloads weltweit hinzuzufügen. Weitere Informationen finden Sie unter Static website hosting in Azure Storage and Quickstart: Integrieren eines Azure storage Kontos in Azure CDN.

Dynamisch veröffentlichter statischer Inhalt

Wenn Ihre Anwendung statische Inhalte unterstützt, unabhängig davon, ob sie von der Anwendung selbst hochgeladen oder generiert wird, die nach der Erstellung unverändert bleibt, können Sie Azure Blob Storage und Azure CDN integrieren. Sie können auch eine Azure-Funktion verwenden, um Uploads zu verwalten und CDN-Aktualisierungen bei Bedarf auszulösen. Wir haben eine Beispielimplementierung für Ihre Verwendung bei Uploading und CDN-Preloading statischer Inhalte mit Azure Functions bereitgestellt.

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. Sie müssen beispielsweise die Verwendung von / oder \ in Dateisystempfaden durch File.Separator oder Paths.get ersetzen, wenn Ihre Anwendung auf Windows ausgeführt wird.

Wechseln zu einer unterstützten Plattform

Wenn Sie Ihre Dockerfile-Datei manuell erstellen und containerisierte Anwendung für Azure Container Apps bereitstellen, übernehmen Sie die vollständige Kontrolle über Ihre Bereitstellung, einschließlich JRE/JDK-Versionen.

Für die Bereitstellung von Artefakten bietet Azure Container Apps auch bestimmte Versionen von Java (8, 11, 17 und 21) sowie spezifische Versionen von Spring Boot- und Spring Cloud-Komponenten. Um die Kompatibilität zu gewährleisten, migrieren Sie Ihre Anwendung zuerst zu einer der unterstützten Versionen von Java in der aktuellen Umgebung, und fahren Sie dann mit den verbleibenden Migrationsschritten fort. 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.

Um Ihre aktuelle Java-Version zu erhalten, melden Sie sich bei Ihrem Produktionsserver an, und führen Sie den folgenden Befehl aus:

java -version

Unterstützte Versionen von Java, Spring Boot und Spring Cloud sowie Anweisungen zum Aktualisieren finden Sie unter Java unter Azure Container Apps Übersicht.

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

In Maven-Projekten befindet sich die Spring-Boot-Version typischerweise 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

In Gradle-Projekten wird sich die Spring Boot-Version typischerweise im plugins Abschnitt als Version des org.springframework.boot Plugins befinden.

plugins {
  id 'org.springframework.boot' version '3.3.3'
  id 'io.spring.dependency-management' version '1.1.6'
  id 'java'
}

Folgen Sie allen Anwendungen, die Spring Boot-Versionen vor 3.x verwenden, dem Migrationshandbuch für Spring Boot 2.0 oder spring Boot 3.0 , um sie auf eine unterstützte Spring Boot-Version zu aktualisieren. 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 in der Regel in der spring-cloud.version Eigenschaft 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" .

Identifizierung von APM-Agenten (Application Performance Management, Anwendungsleistungsmanagement)

Ermitteln Sie alle Application Performance Management-Agents, die von Ihren Anwendungen verwendet werden. Azure Container-Apps bieten 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 keine APM integriert haben, sollten Sie Azure Application Insights verwenden. Weitere Informationen finden Sie im Abschnitt "Migration ".

Inventar externer 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 " in einer Datei, die in der Regel "application.properties" oder "application.yml" genannt wird.
  • 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 einer Datei "application.properties ":

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 einer Application.yaml-Datei :

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

Identifizieren Sie den zu verwendenden Broker oder Broker, indem Sie im Buildmanifest (in der Regel eine pom.xml - oder build.gradle-Datei ) nach den relevanten Abhängigkeiten suchen.

Beispielsweise würde eine Spring Boot-Anwendung mit ActiveMQ in der Regel diese Abhängigkeit in der pom.xml Datei 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 einer Build.gradle-Datei :

    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. In Spring Cloud-Anwendungen können Sie sie in der Regel in den Dateien application.properties und application.yml im Anwendungsverzeichnis oder im Spring Cloud Config Server-Repository finden.

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 einer Datei "application.properties ":

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 zum Spring Boot Messaging.

Nachfolgend finden Sie ein IBM MQ-Beispiel aus einer Datei "application.yaml ":

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 Dokumentation zu Spring Data Redis .

Bestimmen Sie, ob Sitzungsdaten über Spring Session zwischengespeichert werden, indem Sie nach der jeweiligen Konfiguration suchen (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:

Ü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. Um die Konfiguration für solche Ressourcen zu untersuchen, verwenden Sie die TAS-CLI (Cloud Foundry), um die VCAP_SERVICES Variable 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 VCAP_SERVICES Variable auf Konfigurationseinstellungen externer Dienste, die an die Anwendung gebunden sind. Weitere Informationen finden Sie in der TAS-Dokumentation (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 Produktionsumgebungen auf geheime Zeichenfolgen und Kennwörter. In einer Spring Cloud-Anwendung können Sie in der Regel solche Zeichenfolgen in den application.properties oder application.yml Datei in einzelnen Diensten oder im Spring Cloud Config Server-Repository finden.

Inventurzertifikate

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 zum Speichern und Zugreifen auf geheime Schlüssel verwenden, identifizieren Sie den sicherungsbasierten geheimen Speicher , z. B. 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, identifizieren Sie, wo die Konfiguration gespeichert ist. Diese Einstellung finden Sie in der Regel in der Datei "bootstrap.yml" oder " bootstrap.properties " oder manchmal 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. In der Spring Cloud Config Server-Dokumentation finden Sie Informationen zu anderen Backends wie relationalen Datenbanken (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 diese Clients, um Spring Cloud OpenFeign vor der Migration zu verwenden.

Migration

Entfernen eingeschränkter Konfigurationen

Die Azure Container Apps-Umgebung bietet verwaltete 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 Konfiguration des Spring Boot 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 des 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 Sie eine verwaltete Azure Container Apps-Umgebung und Apps

Stellen Sie eine Azure Container Apps-App in Ihrem Azure-Abonnement in einer vorhandenen verwalteten Umgebung bereit, oder erstellen Sie für jeden Dienst, 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 Quickstart: Bereitstellen Ihrer ersten Container-App mithilfe des Azure Portals.

Vorbereiten des Spring Cloud Config-Servers

Konfigurieren Sie den Config-Server in den Azure Container Apps für die Spring-Komponente. Weitere Informationen finden Sie unter Configure-Einstellungen für die Config Server for Spring-Komponente in Azure Container Apps.

Hinweis

Wenn sich Ihr aktuelles Spring Cloud Config-Repository im lokalen Dateisystem oder lokal befindet, müssen Sie zuerst Ihre Konfigurationsdateien in ein cloudbasiertes Repository migrieren oder replizieren, z. B. GitHub, Azure Repos oder BitBucket.

Sicherstellen der Konsolenprotokollierung und Konfigurieren von Diagnoseeinstellungen

Konfigurieren Sie Ihre Protokollierung so, dass alle Ausgaben an die Konsole und nicht in Dateien weitergeleitet werden.

Nachdem eine Anwendung für Azure Container Apps bereitgestellt wurde, können Sie die Protokollierungsoptionen in Ihrer Container-Apps-Umgebung konfigurieren, um ein oder mehrere Ziele der Protokolle zu definieren. Diese Ziele können Azure Monitor Log Analytics, Azure Event Hub oder sogar andere Überwachungslösungen von Drittanbietern umfassen. Sie haben auch die Möglichkeit, Protokolldaten zu deaktivieren und Protokolle nur zur Laufzeit anzuzeigen. Ausführliche Konfigurationsanweisungen finden Sie unter Protokollspeicher- 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 Use storage mounts in Azure Container Apps.

Migrieren von Geheimschlüsseln in Spring Cloud Vault zu Azure KeyVault

Sie können geheime Schlüssel direkt über Spring in Anwendungen einfügen, indem Sie den Azure KeyVault Spring Boot Starter verwenden. Weitere Informationen finden Sie unter How to use the Spring Boot Starter for Azure Key Vault.

Hinweis

Für die Migration müssen gegebenenfalls einige Secrets umbenannt werden. Aktualisieren Sie Ihren Anwendungscode entsprechend.

Migrieren aller Zertifikate zu Key Vault

Azure Container-Apps unterstützen die sichere Kommunikation zwischen Apps. Ihre Anwendung muss den Prozess zum Aufbau einer sicheren Kommunikation nicht verwalten. Sie können das private Zertifikat auf Azure Container Apps hochladen oder ein kostenloses verwaltetes Zertifikat verwenden, das von Azure Container Apps bereitgestellt wird. Die Verwendung von Azure Key Vault zum Verwalten von Zertifikaten ist ein empfohlener Ansatz. Weitere Informationen finden Sie unter Certificates 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 connection string, sollten sicher behandelt werden. Sie können es entweder als geheimer Schlüssel angeben oder auf einen geheimen Schlüssel verweisen, der 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.
  • Wenn der Identitätsanbieter eine lokale Active Directory-Umgebung ist, sollten Sie eine Hybrididentitäts-Lösung mit Microsoft Entra ID implementieren. Anleitungen finden Sie in der Hybrididentitätsdokumentation.
  • Wenn der Identitätsanbieter eine andere lokale Lösung ist, z. B. PingFederate, lesen Sie die Benutzerdefinierte Installation von Microsoft Entra Connect Dokumentation, um die Föderation mit Microsoft Entra ID zu konfigurieren. Alternativ können Sie Spring Security verwenden, 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 Einstellungen für den Eureka-Server für die Spring-Komponente in Azure Container Apps konfigurieren. Ändern Sie dann alle Anwendungsclients, um den Spring Client Load Balancer zu verwenden. Mit dem Spring Client Load Balancer kann der Client Adressen aller laufenden Instanzen der Anwendung abrufen und eine funktionierende Instanz finden, wenn eine andere Instanz beschädigt ist oder nicht mehr reagiert. Weitere Informationen finden Sie unter Spring Tips: Spring Cloud Load Balancer im Spring Blog.

  • Anstatt Ihre Anwendung öffentlich zu machen, sollten Sie eine Spring Cloud Gateway-Instanz hinzufügen. Spring Cloud Gateway stellt einen einzelnen Endpunkt für alle Anwendungen bereit, 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 Configure-Einstellungen für die Config Server for Spring-Komponente in Azure Container Apps. Migrieren Sie dann Ihre Konfiguration mit den folgenden Schritten:

    1. Erstellen Sie im Verzeichnis "src/main/resources " der Anwendung eine bootstrap.yml Datei mit folgendem Inhalt:

        spring:
          application:
            name: <your-application-name>
      
    2. Erstellen Sie im Git-Konfigurations-Repository eine <your-application-name>.yml Datei, wobei your-application-name mit dem vorherigen Schritt identisch ist. Verschieben Sie die Einstellungen aus application.yml Datei in "src/main/resources " in die neue Datei, die Sie erstellt haben. Wenn sich die Einstellungen zuvor in einer EIGENSCHAFTENdatei befunden haben, wurden sie zuerst in YAML konvertiert. Für diese Konvertierung finden Sie Onlinetools oder IntelliJ-Plug-Ins.

    3. Erstellen Sie eine application.yml Datei im obigen Verzeichnis. Sie können diese Datei verwenden, um Einstellungen und Ressourcen zu definieren, die in der Azure Container Apps Umgebung für alle Anwendungen freigegeben sind. Diese Einstellungen umfassen in der Regel u. a. Datenquellen, Protokollierungseinstellungen und die Konfiguration des Spring Boot-Aktors.

    4. Übertragen und schieben Sie diese Änderungen ins Git-Repository.

    5. 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 Configure the Spring Boot Admin component in Azure Container Apps.

  • Fügen Sie ggf. eine Bereitstellungspipeline für automatische, konsistente Bereitstellungen hinzu. Anweisungen sind für Azure Pipelines und für GitHub Actions verfügbar.

  • Betrachten Sie die Verwendung von Container-App-Revisionen, Revisionslabels und Gewichtungen des eingehenden Datenverkehrs, um eine Blau-Grün-Bereitstellung zu aktivieren. Dadurch können Sie Codeänderungen in der Produktion testen, bevor sie für einige oder alle Ihrer Endbenutzer verfügbar gemacht werden. Weitere Informationen finden Sie unter Blue-Green Deployment in Azure Container Apps.

  • Erwägen Sie das Hinzufügen von Dienstbindungen, 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 JVM-Kernmetriken für Ihre Anwendungen. Weitere Informationen finden Sie unter Java Metriken für Java Apps in Azure Container Apps.

  • Erwägen Sie, Azure Monitor-Warnungsregeln und Aktionsgruppen hinzuzufügen, um abweichende Bedingungen schnell zu erkennen und zu beheben. Weitere Informationen finden Sie unter Warnmeldungen in Azure Container Apps einrichten.

  • 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 Reliability in Azure Container Apps.

  • Erwägen Sie, Azure Container Apps vor allgemeinen Exploits und Sicherheitsrisiken zu schützen, indem Sie Web Application Firewall auf dem Anwendungsgateway verwenden. Weitere Informationen finden Sie unter Schützen Azure Container-Apps mit Web Application Firewall mit dem Anwendungsgateway.

  • 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 (clientseitige load balancer)
    Spring Cloud Hystrix Spring Cloud Circuit Breaker + Resilience4J
    Spring Cloud Netflix Turbine Mikrometer + Prometheus