Migrieren von WebLogic Server-Anwendungen zu JBoss EAP auf Azure-App Dienst

  • Artikel

In diesem Handbuch wird beschrieben, was Sie beachten sollten, wenn Sie eine vorhandene WebLogic Server-Anwendung migrieren möchten, die auf Azure-App Dienst mit JBoss EAP 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.

Wenn Sie diese Anforderungen vor der Migration nicht erfüllen können, lesen Sie stattdessen den Begleitmigrationsleitfaden zum Migrieren Ihrer Anwendungen zu virtuellen Computern: Migrieren von WebLogic Server-Anwendungen zu virtuellen Azure-Computern

Inventarisieren der Serverkapazität

Dokumentieren Sie die Hardware (Arbeitsspeicher, CPU, Datenträger) der aktuellen Produktionsserver und die durchschnittliche und maximale Anzahl von Anforderungen und die Ressourcennutzung. Sie benötigen diese Informationen unabhängig vom gewählten Migrationspfad. Es ist beispielsweise hilfreich, die Auswahl des App-Serviceplans zu unterstützen.

Die Liste der verfügbaren App Service Plan-Ebenen zeigt die Speicher-, CPU-Kerne, Speicher- und Preisinformationen an. Beachten Sie, dass JBoss EAP on App Service nur auf den Stufen Premium V3 und Isolated V2 App Service Plan verfügbar ist.

Bestand: Alle Geheimnisse

Vor der Einführung von „Configuration-as-a-Service“-Technologien, z. B. Azure Key Vault, gab es kein gut definiertes Konzept für „Geheimnisse“. Stattdessen haben Sie über viele unterschiedliche Konfigurationseinstellungen verfügt, die quasi als die nun verwendeten „Geheimnisse“ gedient haben. Bei App-Servern, z. B. WebLogic Server, sind diese Geheimnisse in vielen unterschiedlichen Konfigurationsdateien und -speichern enthalten. Überprüfen Sie alle Eigenschaften und Konfigurationsdateien auf den Produktionsservern auf Geheimnisse und Kennwörter. Sehen Sie in der Datei weblogic.xml in Ihren WARs nach. Unter Umständen finden Sie in Ihrer Anwendung auch Konfigurationsdateien mit Kennwörtern oder Anmeldeinformationen. Weitere Informationen finden Sie unter Grundlegende Konzepte von Azure Key Vault.

Inventarisieren aller Zertifikate

Dokumentieren Sie alle Zertifikate, die für öffentliche SSL-Endpunkte 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>

Bestand: JNDI-Ressourcen

Inventarisieren Sie alle JNDI-Ressourcen. Datenquellen, z. B. Datenbanken, können beispielsweise über einen zugeordneten JNDI-Namen verfügen, mit dem Instanzen von EntityManager von JPA korrekt an eine bestimmte Datenbank gebunden werden können. Weitere Informationen zu JNDI-Ressourcen und -Datenbanken finden Sie in der Oracle-Dokumentation unter WebLogic Server-Datenquellen. Für andere JNDI-bezogene Ressourcen, z. B. JMS-Nachrichtenbroker, ist ggf. eine Migration oder Neukonfiguration erforderlich. Weitere Informationen zur JMS-Konfiguration finden Sie unter Oracle WebLogic Server 12.2.1.4.0.

Untersuchen der Domänenkonfiguration

Die Hauptkonfigurationseinheit in WebLogic Server ist die Domäne. Daher enthält die Datei config.xml viele Konfigurationsinformationen, die Sie bei der Migration sorgfältig berücksichtigen müssen. Die Datei enthält Verweise auf zusätzliche XML-Dateien, die in Unterverzeichnissen gespeichert sind. Oracle rät dazu, wie gewohnt die Verwaltungskonsole zu verwenden, um die verwaltbaren Objekte und Dienste von WebLogic Server zu konfigurieren, und WebLogic Server die Verwaltung der Datei config.xml zu überlassen. Weitere Informationen finden Sie unter Domänenkonfigurationsdateien.

Innerhalb Ihrer Anwendung

Untersuchen Sie die Datei WEB-INF/weblogic.xml bzw. WEB-INF/web.xml.

Ermitteln, ob die Sitzungsreplikation verwendet wird

Wenn für Ihre Anwendung die Sitzungsreplikation benötigt wird, haben Sie zwei Optionen (mit oder ohne Oracle Coherence*Web):

  • Gestalten Sie Ihre Anwendung so um, dass eine Datenbank für die Sitzungsverwaltung verwendet wird.
  • Gestalten Sie Ihre Anwendung so um, dass die Sitzung für den Azure Redis-Dienst externalisiert wird. Weitere Informationen finden Sie unter Azure Cache for Redis.

Bei all diesen Optionen ist es ratsam, sich damit vertraut zu machen, wie von WebLogic die Replikation des HTTP-Sitzungsstatus durchgeführt wird. Weitere Informationen finden Sie in der Oracle-Dokumentation unter Replikation des HTTP-Sitzungsstatus.

Dokumentdatenquellen

Verwendet Ihre Anwendung Datenbanken, müssen Sie die folgenden Informationen erfassen:

  • Wie lautet der Name der Datenquelle?
  • Wie ist der Verbindungspool konfiguriert?
  • Wo ist die JAR-Datei mit den JDBC-Treibern zu finden?

Weitere Informationen zu JDBC-Treibern in WebLogic finden Sie unter Verwenden von JDBC-Treibern mit einem WebLogic-Server.

Ermitteln, ob WebLogic angepasst wurde

Ermitteln Sie, welche der folgenden Anpassungen vorgenommen wurden, und erfassen Sie sie.

  • Wurden die Startskripts geändert? Zu diesen Skripts gehören setDomainEnv, commEnv, startWebLogic und stopWebLogic.
  • Werden an JVM spezifische Parameter übergeben?
  • Werden dem Klassenpfad des Servers JAR-Dateien hinzugefügt?

Ermitteln, ob eine Verbindung mit der lokalen Umgebung erforderlich ist

Wenn Ihre Anwendung auf Ihre lokalen Dienste zugreifen muss, müssen Sie einen der Konnektivitätsdienste von Azure bereitstellen. Weitere Informationen finden Sie unter Auswählen einer Lösung zum Herstellen einer Verbindung zwischen einem lokalen Netzwerk und Azure. Alternativ müssen Sie Ihre Anwendung so umgestalten, dass öffentlich zugängliche APIs genutzt werden, die von Ihren lokalen Ressourcen verfügbar gemacht werden.

Ermitteln, ob JMS-Warteschlangen oder -Themen (Java Message Service) verwendet werden

Wenn Ihre Anwendung JMS-Warteschlangen oder -Themen nutzt, müssen diese zu einem extern gehosteten JMS-Server migriert werden. Azure Service Bus und das Advanced Message Queuing Protocol (AMQP) können bei Verwendung von JMS eine hervorragende Migrationsstrategie sein. Weitere Informationen finden Sie unter Verwenden von Java Message Service (JMS) mit Azure Service Bus und AMQP 1.0.

Wenn beständige JMS-Speicher konfiguriert wurden, müssen Sie die zugehörige Konfiguration erfassen und nach dem Migrationsvorgang anwenden.

Ermitteln Sie, ob Sie eigene benutzerdefinierte freigegebene Java EE-Bibliotheken verwenden

Wenn Sie das Features für freigegebene Java EE-Bibliotheken verwenden, haben Sie zwei Optionen:

  • Gestalten Sie Ihren Anwendungscode um, um alle Abhängigkeiten von Ihren Bibliotheken zu entfernen, und integrieren Sie die Funktionalität stattdessen direkt in Ihre Anwendung.
  • Fügen Sie die Bibliotheken zum Serverklassenpfad hinzu.

Ermitteln, ob OSGi-Pakete verwendet werden

Wenn Sie dem WebLogic-Server hinzugefügte OSGi-Pakete verwendet haben, müssen Sie die entsprechenden JAR-Dateien direkt Ihrer Webanwendung hinzufügen.

Ermitteln, ob Ihre Anwendung betriebssystemspezifischen Code enthält

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 ggf. alle Vorkommen von / oder \ in Dateisystempfaden durch File.Separator oder Paths.get ersetzen.

Ermitteln, ob Oracle Service Bus verwendet wird

Wenn Ihre Anwendung Oracle Service Bus (OSB) verwendet, müssen Sie erfassen, wie OSB konfiguriert ist. Weitere Informationen finden Sie unter Informationen zur Installation von Oracle Service Bus.

Ermitteln, ob Ihre Anwendung aus mehreren WAR-Dateien besteht

Besteht Ihre Anwendung aus mehreren WAR-Dateien, sollten Sie die einzelnen WAR-Dateien als separate Anwendungen behandeln und für jede Datei diese Anleitung ausführen.

Ermitteln, ob Ihre Anwendung als EAR-Datei gepackt ist

Ist Ihre Anwendung als EAR-Datei gepackt, sehen Sie sich unbedingt die Dateien application.xml und weblogic-application.xml an, und erfassen Sie deren Konfigurationen.

Ermitteln aller externen Prozesse und Daemons, die auf den Produktionsservern ausgeführt werden

Werden einige Ihrer Prozesse außerhalb des Anwendungsservers ausgeführt (z. B. die Überwachung von Daemons), müssen Sie sie beseitigen oder zu einem anderen Ort migrieren.

Überprüfen, ob die unterstützte Java-Version richtig funktioniert

JBoss EAP für Azure-App Service unterstützt Java 8 und 11. Sie müssen daher überprüfen, ob Ihre Anwendung mit dieser unterstützten Version richtig ausgeführt werden kann. Diese Überprüfung ist besonders wichtig, wenn für Ihren aktuellen Server ein nicht unterstütztes JDK (z. B. Oracle JDK oder IBM OpenJ9) verwendet 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

Ermitteln, ob für Ihre Anwendung geplante Aufträge benötigt werden

Für Azure App Service sollten geplante Aufträge, z. B. Quartz Scheduler-Aufgaben oder Unix-Cron-Aufträge, NICHT verwendet werden. Azure App Service hindert Sie nicht an der Bereitstellung einer Anwendung, die intern geplante Aufgaben enthält. Wenn Ihre Anwendung aber horizontal hochskaliert wird, wird derselbe geplante Auftrag unter Umständen mehrmals pro geplantem Zeitraum ausgeführt. Diese Situation kann unerwünschte Konsequenzen haben.

Erwägen Sie für die Ausführung von geplanten Aufträgen in Azure die Verwendung von Azure Functions mit einem Zeitgebertrigger. Weitere Informationen finden Sie unter Trigger mit Timer für Azure Functions. Hierbei ist es nicht erforderlich, den eigentlichen Auftragscode in eine Funktion zu migrieren. Für die Funktion kann einfach eine URL in Ihrer Anwendung aufgerufen werden, um den Auftrag auszulösen.

Hinweis

Zur Verhinderung einer missbräuchlichen Nutzung müssen Sie ggf. sicherstellen, dass für den Endpunkt zum Aufrufen des Auftrags Anmeldeinformationen benötigt werden. In diesem Fall müssen die Anmeldeinformationen von der Triggerfunktion bereitgestellt werden.

Ermitteln, ob das WebLogic-Skriptingtool (WLST) verwendet wird

Wenn Sie zurzeit WLST zum Ausführen der Bereitstellung verwenden, müssen Sie bewerten, was dies tut. Wenn WLST parameter Ihrer Anwendung im Rahmen der Bereitstellung (Laufzeit) ändert, müssen Sie sicherstellen, dass diese Parameter einer der folgenden Optionen entsprechen:

  • Sie werden als App-Einstellungen externalisiert.
  • Sie sind in Ihre Anwendung eingebettet.
  • Während der Bereitstellung wird die JBoss CLI genutzt.

Wenn WLST mehr tut als oben Erwähnung, haben Sie während der Migration einige zusätzliche Aufgaben.

Ermitteln, ob für Ihre Anwendung WebLogic-spezifische APIs verwendet werden

Wenn Ihre Anwendung WebLogic-spezifische APIs verwendet, müssen Sie Ihre Anwendung so umgestalten, dass sie NICHT verwendet werden. Wenn Sie beispielsweise eine Klasse verwendet haben, die in der Java-API-Referenz für Oracle WebLogic Server erwähnt wird, haben Sie in Ihrer Anwendung eine WebLogic-spezifische API genutzt. Das Red Hat Migration Toolkit für Apps kann beim Entfernen und Umgestalten dieser Abhängigkeiten helfen.

Ermitteln, ob für Ihre Anwendung Entity Beans oder CMP Beans im EJB 2.x-Format verwendet werden

Wenn Ihre Anwendung Entity Beans oder EJB 2.x-CmP-Bohnen verwendet, müssen Sie Ihre Anwendung umgestalten, um sie NICHT zu verwenden.

Ermitteln, ob die Java EE-Anwendungsclientfunktion verwendet wird

Wenn Sie über Clientanwendungen verfügen, die eine Verbindung mit Ihrer (Server)-Anwendung herstellen, indem Sie das Java EE-Anwendungsclient-Feature verwenden, müssen Sie sowohl Ihre Clientanwendungen als auch Ihre (Server)-Anwendung so umgestalten, dass HTTP-APIs verwendet werden.

Ermitteln, ob ein Bereitstellungsplan verwendet wurde

Wenn ein Bereitstellungsplan für die Bereitstellung verwendet wurde, müssen Sie bewerten, was der Bereitstellungsplan tut. Wenn es im Bereitstellungsplan um eine direkte Bereitstellung geht, können Sie Ihre Webanwendung ohne weitere Änderungen bereitstellen. Falls der Bereitstellungsplan komplexer ist, müssen Sie ermitteln, ob Sie die JBoss CLI nutzen können, um Ihre Anwendung im Rahmen der Bereitstellung richtig zu konfigurieren. Falls die Nutzung der JBoss CLI nicht möglich ist, müssen Sie Ihre Anwendung so umgestalten, dass kein Bereitstellungsplan mehr benötigt wird.

Ermitteln, ob EJB-Zeitgeber verwendet werden

Wenn Ihre Anwendung EJB-Zeitgeber verwendet, müssen Sie überprüfen, ob der EJB-Zeitgebercode von jeder JBoss-EAP-Instanz unabhängig voneinander ausgelöst werden kann. Diese Überprüfung ist erforderlich, da jeder EJB-Timer in seiner eigenen JBoss-EAP-Instanz ausgelöst wird, wenn Ihr App-Dienst horizontal skaliert wird.

Überprüfen, ob und wie das Dateisystem verwendet wird

Für jegliche Nutzung des Dateisystems auf dem Anwendungsserver sind erneute Konfigurationen oder in selteneren Fällen auch Architekturänderungen erforderlich. Das Dateisystem kann von webLogic freigegebenen Modulen oder von Ihrem Anwendungscode verwendet werden. Es kann sein, dass für Sie einige bzw. alle folgenden Szenarien zutreffen.

Schreibgeschützter statischer Inhalt

Wenn Ihre Anwendung derzeit statische Inhalte bedient, ist ein alternativer Speicherort für diesen statischen Inhalt erforderlich. Sie können das Verschieben statischer Inhalte in Azure Blob Storage und das Hinzufügen von Azure CDN für blitzschnelle Downloads in Betracht ziehen.

Dynamisch veröffentlichter statischer Inhalt

Wenn Ihre Anwendung statischen Inhalt zulässt, der von Ihrer Anwendung hochgeladen bzw. produziert wird, nach der Erstellung aber unveränderlich ist, können Sie Azure Blob Storage und Azure CDN wie oben beschrieben nutzen. Hierbei können Sie auch eine Azure-Funktion zum Verarbeiten von Uploads und der CDN-Aktualisierung verwenden. Wir haben eine Beispielimplementierung für Ihre Verwendung bereitgestellt.

Dynamischer oder interner Inhalt

Bei Dateien, die häufig von Ihrer Anwendung geschrieben und gelesen werden (z. B. temporäre Datendateien), oder statische Dateien, die nur für Ihre Anwendung sichtbar sind, kann Azure Storage in das App Service-Dateisystem eingebunden werden.

Ermitteln, ob JCA-Connectors genutzt werden

Wenn Ihre Anwendung JCA-Connectors verwendet, müssen Sie überprüfen, ob der JCA-Connector auf JBoss EAP verwendet werden kann. Wenn die JCA-Implementierung an WebLogic gebunden ist, müssen Sie Ihre Anwendung so umgestalten, dass sie NICHT den JCA-Connector verwendet. Wenn sie verwendet werden kann, müssen Sie die JARs zum Serverklassenpfad hinzufügen und die erforderlichen Konfigurationsdateien an den richtigen Speicherort in den JBoss EAP-Serververzeichnissen ablegen, damit sie verfügbar sind.

Ermitteln, ob Ihre Anwendung einen Ressourcenadapter verwendet

Wenn für Ihre Anwendung ein Ressourcenadapter (RA) benötigt wird, muss dieser mit JBoss EAP kompatibel sein. Ermitteln Sie, ob der RA für eine eigenständige Instanz von JBoss EAP richtig funktioniert, indem Sie ihn auf dem Server bereitstellen und entsprechend konfigurieren. Wenn der RA ordnungsgemäß funktioniert, müssen Sie die JARs dem Serverklassenpfad der App Service-Instanz hinzufügen und die erforderlichen Konfigurationsdateien an den richtigen Speicherort in den JBoss EAP-Serververzeichnissen einfügen, damit sie verfügbar sind.

Ermitteln, ob JAAS verwendet wird

Wenn Ihre Anwendung JAAS verwendet, müssen Sie erfassen, wie JAAS konfiguriert ist. Sofern hierfür eine Datenbank verwendet wird, können Sie sie in eine JAAS-Domäne unter JBoss EAP konvertieren. Falls es sich um eine benutzerdefinierte Implementierung handelt, müssen Sie überprüfen, ob sie unter JBoss EAP verwendet werden kann.

Ermitteln, ob das WebLogic-Clustering genutzt wird

Höchstwahrscheinlich haben Sie Ihre Anwendung auf mehreren WebLogic-Servern bereitgestellt, um Hochverfügbarkeit zu erzielen. Azure-App Dienst kann skaliert werden, aber wenn Sie die WebLogic Cluster-API verwendet haben, müssen Sie Ihren Code umgestalten, um die Verwendung dieser API zu beseitigen.

Migration

Red Hat Migration Toolkit für Apps

Das Red Hat Migration Toolkit for Applications ist eine kostenlose Erweiterung für Visual Studio Code. Diese Erweiterung analysiert Ihren Anwendungscode und Ihre Konfiguration, um Empfehlungen für die Migration Ihrer Jakarta EE-Anwendungen von anderen App-Servern zu JBoss EAP bereitzustellen, z. B. das Entfernen von Abhängigkeiten von proprietären APIs. Die Erweiterung enthält auch Empfehlungen, wenn Sie von der lokalen Bereitstellung zur Cloud migrieren. Weitere Informationen finden Sie in der Übersicht über das Migrations-Toolkit für Applikationen.

Der Inhalt dieses Leitfadens hilft Ihnen, die anderen Komponenten der Migrationsreise zu behandeln, z. B. die Auswahl des richtigen App Service Plan-Typs, das Externalisieren des Sitzungszustands und die Verwendung von Azure zum Verwalten Ihrer EAP-Instanzen anstelle der JBoss-Verwaltungsschnittstelle.

Bereitstellen eines App Service-Plans

Wählen Sie in der Liste der verfügbaren Servicepläne den Plan aus, dessen Spezifikationen die Spezifikationen der aktuellen Produktionshardware erfüllen oder überschreiten.

Hinweis

Wenn Sie die Ausführung von Staging- bzw. Canarybereitstellungen planen oder Bereitstellungsslots nutzen möchten, muss der App Service-Plan diese zusätzliche Kapazität enthalten. Wir empfehlen Ihnen die Verwendung eines Premium-Plans (oder höher) für Java-Anwendungen.

Erstellen Sie den App Service-Plan.

Erstellen und Bereitstellen von Web-Apps

Sie müssen eine Web App in Ihrem App Service Plan für jede WAR-Datei erstellen, die auf Ihrem JBoss EAP-Server bereitgestellt wird.

Hinweis

Es ist zwar möglich, für eine Web-App mehrere WAR-Dateien bereitzustellen, aber dies entspricht nicht der empfohlenen Vorgehensweise. Die Bereitstellung mehrerer WAR-Dateien für eine Web-App verhindert, dass jede Anwendung gemäß ihren jeweiligen Nutzungsanforderungen skaliert werden kann. Darüber hinaus wird hierdurch die Komplexität nachfolgender Bereitstellungspipelines erhöht. Wenn mehrere Anwendungen unter einer einzelnen URL verfügbar sein sollen, sollten Sie den Einsatz einer Routinglösung, z. B. Azure Application Gateway, erwägen.

Maven-Anwendungen

Wenn Ihre Anwendung über eine Maven-POM-Datei erstellt wurde, sollten Sie das Web-App-Plug-In für Maven verwenden, um die Web-App zu erstellen und Ihre Anwendung bereitzustellen. Weitere Informationen finden Sie im Abschnitt "Konfigurieren des Maven-Plug-Ins" in der Schnellstartanleitung: Erstellen einer Java-App auf Azure-App Service.

Nicht auf Maven basierende Anwendungen

Falls Sie das Maven-Plug-In nicht verwenden können, müssen Sie die Web-App über andere Mechanismen bereitstellen, z. B.:

Nachdem Sie die Web-App erstellt haben, verwenden Sie einen der verfügbaren Bereitstellungsmechanismen, um Ihre Anwendung bereitzustellen. Weitere Informationen finden Sie unterBereitstellen von Dateien in App Service.

Migrieren von JVM-Runtimeoptionen

Wenn für Ihre Anwendung bestimmte Runtimeoptionen benötigt werden, sollten Sie zum Angeben den am besten geeigneten Mechanismus verwenden. Weitere Informationen finden Sie im Abschnitt "Java-Laufzeitoptionen festlegen" von "Konfigurieren einer Java-App für Azure-App Service".

Migrieren von externalisierten Parametern

Wenn Sie externe Parameter verwenden müssen, müssen Sie sie als App-Einstellungen festlegen. Weitere Informationen finden Sie unter Konfigurieren von App-Einstellungen.

Migrieren von Startskripts

Wenn die ursprüngliche Anwendung ein benutzerdefiniertes Startskript verwendet hat, müssen Sie es zu einem Bash-Skript migrieren. Weitere Informationen finden Sie unter Anpassen der Anwendungsserverkonfiguration.

Einfügen von Geheimnissen

Verwenden Sie die Anwendungseinstellungen, um die spezifischen Geheimnisse für Ihre Anwendung zu speichern. Wenn Sie beabsichtigen, denselben geheimen Schlüssel oder geheime Schlüssel zwischen mehreren Anwendungen zu verwenden, oder Sie präzise Zugriffsrichtlinien und Überwachungsfunktionen benötigen, verwenden Sie stattdessen Azure Key Vault-Verweise. Weitere Informationen finden Sie im Abschnitt "Use KeyVault References" unter "Configure a Java app for Azure-App Service".

Konfigurieren von benutzerdefinierten Aufgaben Standard und SSL

Wenn Ihre Anwendung in einer benutzerdefinierten Domäne sichtbar ist, müssen Sie Ihre Webanwendung zuordnen. Weitere Informationen finden Sie unter Tutorial: Zuordnen eines vorhandenen benutzerdefinierten DNS-Namens zu Azure App Service.

Anschließend müssen Sie das TLS/SSL-Zertifikat dafür binden Standard an Ihre App Service Web App. Weitere Informationen finden Sie unter Schützen eines benutzerdefinierten DNS-Namens mit einer TLS/SSL-Bindung in Azure App Service.

Migrieren von Datenquellen, Bibliotheken und JNDI-Ressourcen

Führen Sie zum Migrieren von Datenquellen die Schritte im Abschnitt "Datenquellen konfigurieren" unter "Konfigurieren einer Java-App für Azure-App Dienst" aus.

Migrieren Sie alle zusätzlichen Klassenpfadabhängigkeiten auf Serverebene, indem Sie den Anweisungen im Abschnitt "JBoss EAP" von Configure a Java app for Azure-App Service folgen.

Migrieren Sie alle zusätzlichen JDNI-Ressourcen auf Serverebene. Weitere Informationen finden Sie im Abschnitt "JBoss EAP" von "Configure a Java app for Azure-App Service".

Migrieren von JCA-Connectors und JAAS-Modulen

Migrieren Sie alle JCA-Connectors und JAAS-Module, indem Sie die Anweisungen unter Installieren von Modulen und Abhängigkeiten befolgen.

Hinweis

Wenn Sie der empfohlenen Architektur eines WAR pro Anwendung folgen, sollten Sie die Migration von Klassenpfadbibliotheken auf Serverebene und JNDI-Ressourcen in Ihre Anwendung in Betracht ziehen. Dies wird die Komponentengovernance und die Änderungsverwaltung erheblich vereinfachen. Wenn Sie mehrere WAR pro Anwendung bereitstellen möchten, sollten Sie einen unserer Begleithandbücher lesen, die am Anfang dieses Handbuchs Erwähnung.

Migrieren von geplanten Aufträgen

Sie sollten Ihre geplanten Aufträge mindestens auf einen virtuellen Azure-Computer verschieben, damit sie nicht mehr Teil Ihrer Anwendung sind. Alternativ können Sie sie mithilfe von Azure-Diensten wie Azure Functions, SQL-Datenbank und Event Hubs in ereignisgesteuertem Java modernisieren.

Neustarten und Durchführen des Buildüberprüfungstests

Abschließend müssen Sie Ihre Web-App neu starten, um alle Konfigurationsänderungen anzuwenden. Vergewissern Sie sich nach Abschluss des Neustarts, dass Ihre Anwendung korrekt ausgeführt wird.

Nach der Migration

Nachdem Sie Ihre Anwendung nun zu Azure App Service migriert haben, sollten Sie sich vergewissern, dass sie wie erwartet funktioniert. Nachdem Sie dies getan haben, haben wir einige Empfehlungen für Sie, die Ihre Anwendung cloudnativ machen können.

Empfehlungen