Freigeben über

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

  • Artikel

Diese Anleitung beschreibt, was Sie beachten sollten, wenn Sie eine bestehende WebLogic Server Anwendung mit JBoss EAP auf Azure App Service ausführen 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.

Wenn Sie eine dieser Voraussetzungen vor der Migration nicht erfüllen können, lesen Sie stattdessen die Anleitung zur Migration Ihrer Anwendungen auf virtuelle Maschinen: Migrieren Sie WebLogic Server-Anwendungen auf Azure Virtual Machines

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 zum Beispiel nützlich, um die Anleitung zur Auswahl des App Service-Plans zu nutzen.

Die Liste der verfügbaren Tiers des App Service-Plans zeigt die Informationen zu Speicher, CPU-Kernen, Storage und Preisen. Beachten Sie, dass JBoss EAP on App Service nur auf den Ebenen Premium V3 und Isolated V2 des App Service-Plans 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 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 1.1 mit Azure Service Bus Standard 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 möglicherweise die Verwendung von / oder \ in Dateisystempfaden durch File.Separator oder Paths.get ersetzen, wenn Ihre Anwendung unter Windows ausgeführt wird.

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 auf 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 derzeit WLST für die Bereitstellung verwenden, müssen Sie bewerten, was es tut. Wenn WLST als Element der Bereitstellung irgendwelche (Laufzeit-)Parameter Ihrer Anwendung ä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 als die oben genannten Änderungen vornimmt, haben Sie während der Migration zusätzliche Arbeit zu erledigen.

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

Wenn Ihre Anwendung WebLogic-spezifische APIs verwendet, müssen Sie ein Refactoring durchführen, um diese NICHT zu verwenden. 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 Sie beim Entfernen und Refactoring dieser Abhängigkeiten unterstützen.

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

Wenn Ihre Anwendung Entity Beans oder CMP Beans im Stil von EJB 2.x verwendet, müssen Sie ein Refactoring durchführen, um diese NICHT zu verwenden.

Ermitteln, ob die Java EE-Anwendungsclientfunktion verwendet wird

Wenn Sie Client-Anwendungen haben, die sich über die Funktion Java EE Application Client mit Ihrer (Server-)Anwendung verbinden, müssen Sie sowohl Ihre Client-Anwendungen als auch Ihre (Server-)Anwendung für die Verwendung von HTTP-APIs refaktorisieren.

Ermitteln, ob ein Bereitstellungsplan verwendet wurde

Wenn für die Bereitstellung ein Plan verwendet wurde, müssen Sie bewerten, was der Plan für die Bereitstellung 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-Timer verwendet, müssen Sie validieren, dass der Code für den EJB-Timer von jeder JBoss EAP Instanz unabhängig ausgelöst werden kann. Diese Validierung ist erforderlich, da bei einer horizontalen Skalierung Ihres App Service jeder EJB Timer auf seiner eigenen JBoss EAP Instanz ausgelöst wird.

Überprüfen Sie, 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 gemeinsamen WebLogic-Modulen oder von Ihrem Code 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 bereitstellt, ist ein alternativer Speicherort für diese statischen Inhalte erforderlich. Sie können beispielsweise erwägen, statischen Inhalt in Azure Blob Storage zu verschieben und Azure CDN hinzuzufügen, um global eine sehr hohe Downloadgeschwindigkeit zu erzielen.

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 Sie bereitgestellt.

Dynamischer oder interner Inhalt

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

Ermitteln, ob JCA-Connectors genutzt werden

Wenn Ihre Anwendung JCA-Konnektoren verwendet, müssen Sie überprüfen, ob der JCA-Konnektor auf JBoss EAP verwendet werden kann. Wenn die JCA-Implementierung an WebLogic gebunden ist, müssen Sie Ihre Anwendung so refactorieren, dass der JCA-Konnektor NICHT verwendet wird. Wenn er verwendet werden kann, müssen Sie die JARs zum Server-Klassenpfad hinzufügen und die erforderlichen Konfigurationsdateien am richtigen Speicherort in den Verzeichnissen des JBoss EAP-Servers ablegen, damit er verfügbar ist.

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 die RA ordnungsgemäß funktioniert, müssen Sie die JARs zum Server-Klassenpfad der App Service Instanz hinzufügen und die erforderlichen Konfigurationsdateien am richtigen Speicherort in den JBoss EAP Serververzeichnissen ablegen, damit sie verfügbar ist.

Feststellen, 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 Service ist skalierbar, aber wenn Sie die WebLogic Cluster API verwendet haben, müssen Sie Ihren Code refaktorisieren, um die Verwendung dieser API zu eliminieren.

Migration

Red Hat Migration Toolkit for Apps

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

Die Inhalte dieser Anleitung helfen Ihnen bei den anderen Komponenten der Migration, wie z.B. der Auswahl des richtigen App Service-Plan-Typs, der Externalisierung Ihres Sitzungsstatus und der Verwendung von Azure zur Verwaltung Ihrer EAP Instanzen anstelle der JBoss Management Schnittstelle.

Bereitstellen eines App Service-Plans

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

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 für jede WAR-Datei, die auf Ihrem JBoss EAP Server bereitgestellt wird, eine Web-App auf Ihrem App Service-Plan erstellen.

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 unter Konfigurieren Sie das Maven-Plugin im Abschnitt Quickstart: Erstellen Sie eine 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 unterDateien im App Service bereitstellen.

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 unter Java-Laufzeitoptionen festlegen im Abschnitt Java-App für Azure App Service konfigurieren.

Externalisierte Parameter migrieren

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

Startskripte migrieren

Wenn die ursprüngliche Anwendung ein angepasstes Startskript verwendet hat, müssen Sie es in ein 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 dasselbe Secret oder dieselben Secrets für mehrere Anwendungen verwenden möchten oder detailliertere Zugriffsrichtlinien und Funktionalitäten zur Überprüfung benötigen, verwenden Sie stattdessen Azure Key Vault-Referenzen. Weitere Informationen finden Sie unter Verwenden Sie KeyVault-Referenzen im Abschnitt Konfigurieren Sie eine Java App für Azure App Service.

Konfigurieren der benutzerdefinierten Domäne und der Nutzung von 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 für diese Domäne an Ihre App Service-Web-App binden. 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

Um Datenquellen zu migrieren, folgen Sie den Schritten im Abschnitt Konfigurieren Sie Datenquellen von Konfigurieren Sie eine Java App für Azure App Service.

Migrieren Sie alle zusätzlichen Server-Level-Klassenpfad-Abhängigkeiten, indem Sie die Anweisungen im Abschnitt JBoss EAP in Java App für Azure App Service konfigurieren befolgen.

Migrieren Sie alle zusätzlichen freigegebenen JDNI-Ressourcen auf Serverebene. Weitere Informationen finden Sie unter JBoss EAP im Abschnitt Java App für Azure App Service konfigurieren.

JCA-Konnektoren und JAAS-Module migrieren

Migrieren Sie alle JCA-Konnektoren und JAAS-Module, indem Sie die Anweisungen unter Module und Abhängigkeiten installieren befolgen.

Hinweis

Wenn Sie sich an die empfohlene Architektur mit einer WAR pro Anwendung halten, sollten Sie in Erwägung ziehen, die Server-Level-Klassenpfad-Bibliotheken und JNDI-Ressourcen in Ihre Anwendung zu migrieren. Dadurch werden die Governance der Komponenten und die Änderungsverwaltung erheblich vereinfacht. Wenn Sie mehr als eine WAR pro Anwendung bereitstellen möchten, sollten Sie sich eine unserer begleitenden Anleitungen ansehen, die wir am Anfang dieser Anleitung erwähnt haben.

Migrieren von geplanten Aufträgen

Zumindest sollten Sie Ihre geplanten Aufträge auf eine Azure VM verlagern, damit sie nicht mehr Bestandteil Ihrer Anwendung sind. Alternativ können Sie sie in ereignisbasiertes Java umwandeln, indem Sie Azure Services wie Azure Functions, SQL Database und Event Hubs nutzen.

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. Wenn Sie das getan haben, haben wir einige Empfehlungen für Sie, die Ihre Anwendung nativer in der Cloud machen können.

Empfehlungen