Migrieren von Spring Boot-Anwendungen zu Azure Container Apps

In diesem Handbuch wird beschrieben, was Sie beachten sollten, wenn Sie eine vorhandene Spring Boot-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

Bestimmung des lokalen Status

In PaaS-Umgebungen ist es nicht gewährleistet, dass die Anwendung zu einem beliebigen Zeitpunkt genau ein Mal ausgeführt wird. Auch wenn Sie eine Anwendung so konfigurieren, dass Sie in einer einzelnen Instanz ausgeführt wird, kann in den folgenden Fällen eine doppelte Instanz erstellt werden:

• Die Anwendung muss aufgrund eines Fehlers oder eines Systemupdates auf einen physischen Host verschoben werden.
• Die Anwendung wird aktualisiert.

In jedem dieser Fälle läuft die ursprüngliche Instanz weiter, bis die neue Instanz vollständig gestartet ist. Dieses Muster kann die folgenden potenziell erheblichen Auswirkungen auf Ihre Anwendung haben:

• Kein Singleton kann garantiert als wirklich einzigartig angesehen werden.
• Alle Daten, die nicht in einem externen Speicher persistent gespeichert wurden, gehen wahrscheinlich schneller verloren als auf einem einzelnen physischen Server oder einer VM.

Stellen Sie vor der Migration zu Azure Container Apps sicher, dass Ihr Code keinen lokalen Zustand enthält, der nicht verloren gehen oder dupliziert werden darf. Wenn ein lokaler Zustand vorhanden ist, ändern Sie den Code so, dass dieser Zustand außerhalb der Anwendung gespeichert wird. Für die Cloud bereite Anwendungen speichern den Anwendungsstatus in der Regel beispielsweise an folgenden Speicherorten:

• Azure Cache for Redis
• Azure Cosmos DB
• Eine andere externe Datenbank, z. B. Azure SQL, Azure Database for MySQL oder Azure Database for PostgreSQL.
• Azure Storage zum Speichern unstrukturierter Daten oder sogar serialisierter Objekte.

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.

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, ob für Ihre Anwendung geplante Aufträge benötigt werden

Ephemerale Anwendung wie Unix-Cron-Aufträge oder kurzlebige Anwendungen, die auf Spring Batch Framework basieren, sollten als Auftrag auf Azure Container Apps ausgeführt werden. Weitere Informationen finden Sie unter Jobs in Azure Container Apps. Wenn Ihre Anwendung eine lang andauernde Anwendung ist und regelmäßig Aufgaben mit einem Planungsframework wie Quarz oder Spring Batch ausführt, können Azure Container Apps diese Anwendung hosten. Die Anwendung muss die Skalierung jedoch entsprechend handhaben, um Wettlaufsituationen zu vermeiden, bei denen dieselben Anwendungsinstanzen während einer Erweiterung der Kapazität oder eines Rolling Upgrades mehr als einmal pro geplantem Zeitraum ausgeführt werden.

Inventarisieren Sie alle geplanten Aufgaben, die auf Produktionsservern ausgeführt werden, innerhalb oder außerhalb Ihres Anwendungscodes.

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 den Spring Boot- und Spring Cloud-Versionen.

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. In Spring Boot-Anwendungen finden Sie in der Regel die Konfiguration für solche Ressourcen im Ordner "src/main/resources ", in einer Datei, die normalerweise als application.properties oder application.yml bezeichnet wird.

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:

• JPA-Repositorys
• JDBC Repositories
• Cassandra Repositorys
• MongoDB-Repositorys

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 Boot-Anwendungen können Sie sie in der Regel in den Dateien "application.properties " und application.yml im Anwendungsverzeichnis finden.

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

Identifizieren Sie alle Identitätsanbieter, die von Ihrer Anwendung verwendet werden. Informationen zum Konfigurieren von Identitätsanbietern finden Sie in den folgenden Artikeln:

• Informationen zur OAuth2-Konfiguration finden Sie in der Spring Security-Referenz.
• Die Auth0 Spring Security-Konfiguration finden Sie in der Auth0 Spring Security-Dokumentation.
• Informationen zur Konfiguration von PingFederate Spring Security finden Sie in den Auth0 PingFederate-Anweisungen.

Identifizieren von Clients, die einen nicht standardmäßigen Port verwenden

mit Azure Container Apps können Sie den Port entsprechend Ihrer Azure Container Apps Ressourcenkonfiguration verfügbar machen. Beispielsweise lauscht eine Spring Boot-Anwendung standardmäßig auf den Port von 8080, kann aber bei Bedarf mit server.port oder Umgebungsvariable SERVER_PORT festgelegt werden.

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 der Produktionsumgebung auf sensible Zeichenfolgen und Kennwörter. In einer Spring Boot-Anwendung können Sie in der Regel solche Zeichenfolgen in der Datei "application.properties" oder application.yml 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>

Untersuchen der Bereitstellungsarchitektur

Dokumentieren der Hardwareanforderungen für die einzelnen Dienste

Dokumentieren Sie die folgenden Informationen für Ihre Spring Boot-Anwendung:

• 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 Boot-Anwendungsinstanzen derzeit auf mehrere Regionen oder Rechenzentren verteilt sind. Dokumentieren Sie die Betriebszeitanforderungen/SLA für die zu migrierenden Anwendungen.

Migration

Erstellen einer Azure Container Apps Umgebung und Bereitstellen von Apps

Stellen Sie eine Azure Container Apps Instanz in Ihrem Azure-Abonnement bereit. Ihre sichere Hostingumgebung wird gleichzeitig erstellt. Weitere Informationen finden Sie unter Quickstart: Bereitstellen Ihrer ersten Container-App mithilfe des Azure Portals.

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 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

Ob Ihre App aus einem Containerimage oder aus Code bereitgestellt wird, Azure Container Apps beeinträchtigt ihr Image oder Code nicht. Daher hängt die Integration Ihrer Anwendung mit einem APM-Tool von Ihren eigenen Präferenzen und Ihrer Implementierung ab.

Wenn Ihre Anwendung keine unterstützte APM verwendet, ist Azure Application Insights eine Option. Weitere Informationen finden Sie unter Using Azure Monitor Application Insights with Spring Boot.

Bereitstellen der Anwendung

Stellen Sie alle migrierten Microservices bereit (nicht einschließlich Spring Cloud Config Server und Spring Cloud Service Registry), wie in Deploy Azure Container Apps mit dem Befehl az containerapp up beschrieben.

Konfigurieren dienstspezifischer Geheimnisse und externalisierter Einstellungen

Konfigurationseinstellungen können den einzelnen Anwendungen als Umgebungsvariablen hinzugefügt werden. Sie können diese Variablen als manuelle Einträge oder als Verweise auf Geheimnisse festlegen. Weitere Informationen zur Konfiguration finden Sie unter Manage-Umgebungsvariablen für Azure Container Apps.

Migrieren und Aktivieren des Identitätsanbieters

Sollte für Spring Cloud-Anwendungen eine Authentifizierung oder Autorisierung erforderlich sein, stellen Sie 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. Weitere Informationen finden Sie in der Dokumentation zur Hybrid-Identität.
• 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.

Verfügbarmachen der Anwendung

Standardmäßig kann über eine Anwendungs-URL auf eine Anwendung zugegriffen werden, die für Azure Container Apps bereitgestellt wird. Wenn Ihre App im Kontext einer verwalteten Umgebung mit einem eigenen virtuellen Netzwerk bereitgestellt wird, müssen Sie die Zugriffsebene der App ermitteln, um den öffentlichen Eingang oder nur den Eingang aus Ihrem virtuellen Netzwerk zuzulassen. Weitere Informationen finden Sie unter Networking in Azure Container Apps Umgebung.

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.