Migrieren von WebSphere-Anwendungen zu JBoss EAP für Azure-App-Dienst

  • Artikel

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

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

Überprüfen Sie alle Eigenschaften und Konfigurationsdateien auf dem Produktionsserver oder auf Servern auf geheime Schlüssel und Kennwörter. Überprüfen Sie ibm-web-bnd.xml in Ihren WAR-Dateien. Unter Umständen finden Sie in Ihrer Anwendung auch Konfigurationsdateien mit Kennwörtern oder Anmeldeinformationen. Diese Dateien können für Spring Boot-Anwendungen die Dateien application.properties oder application.yml enthalten.

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>

Ü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

Bestand: JNDI-Ressourcen

Inventarisieren Sie alle JNDI-Ressourcen. Einige Ressourcen, z. B. JMS-Nachrichtenbroker, erfordern möglicherweise eine Migration oder Neukonfiguration.

Innerhalb Ihrer Anwendung

Prüfen Sie die Datei "WEB-INF/ibm-web-bnd.xml " und/oder " WEB-INF/web.xml ".

Ermitteln, ob Datenbanken verwendet werden

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

  • Der Name der Datenquelle.
  • Die Konfiguration des Verbindungspools.
  • Der Speicherort der JAR-Datei des INSTALLATIONStreibers.

Ermitteln, 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 freigegebenen WebSphere-Modulen oder von Ihrem Anwendungscode verwendet werden. Es kann sein, dass für Sie einige bzw. alle folgenden Szenarien zutreffen.

Schreibgeschützter statischer Inhalt

Falls mit Ihrer Anwendung derzeit statischer Inhalt bereitgestellt wird, benötigen Sie dafür einen anderen Speicherort. 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. Weitere Informationen finden Sie unter Hosten von statischen Websites in Azure StorageundSchnellstart: Integrieren eines Azure-Speicherkontos in Azure CDN. Sie können den statischen Inhalt auch direkt in einer App im Azure Spring Apps Enterprise-Plan bereitstellen. Weitere Informationen finden Sie unter Bereitstellen statischer Webdateien.

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. Eine entsprechende Beispielimplementierung finden Sie unter Hochladen und CDN-Vorabladen von statischem Inhalt mit Azure Functions. Sie können den statischen Inhalt auch direkt in einer App im Azure Spring Apps Enterprise-Plan bereitstellen. Weitere Informationen finden Sie unter Bereitstellen statischer Webdateien.

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, können Sie Azure Storage in Ihr App Service-Dateisystem einbinden. Weitere Informationen finden Sie unter Bereitstellen von Inhalt aus Azure Storage in App Service unter Linux.

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 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, ob für Ihre Anwendung WebSphere-spezifische APIs verwendet werden

Wenn Ihre Anwendung WebSphere-spezifische APIs verwendet, müssen Sie Ihre Anwendung so umgestalten, dass sie NICHT verwendet werden. 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 für Ihre Anwendung Entity Beans oder CMP Beans im EJB 2.x-Format verwendet werden, müssen Sie Ihre Anwendung umgestalten, um diese Abhängigkeiten zu entfernen.

Ermitteln, ob das JavaEE-Anwendungsclient-Feature verwendet wird

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

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

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 WebSphere gebunden ist, müssen Sie ihre Anwendung umgestalten, um die Abhängigkeit vom JCA-Connector zu entfernen. Wenn der JCA-Connector verwendet werden kann, müssen Sie die JARs dem Serverklassenpfad hinzufügen. Außerdem müssen Sie die erforderlichen Konfigurationsdateien an der richtigen Stelle in den JBoss EAP-Serververzeichnissen ablegen, 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 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 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

Wenn Ihre Anwendung als EAR-Datei verpackt ist, überprüfen Sie unbedingt die Dateien "application.xml " und "ibm-application-bnd.xml ", und erfassen Sie ihre 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.

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 diesen App-Dienstplan.

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

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

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. Als Nächstes können Sie sich über unsere Empfehlungen informieren, mit denen Sie Ihre Anwendung cloudnativer gestalten können.

Empfehlungen