Freigeben über

Migrieren von WebSphere-Anwendungen zu JBoss EAP unter Azure App Service

  • Artikel

Diese Anleitung beschreibt, was Sie beachten sollten, wenn Sie eine bestehende WebSphere 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.

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

Überprüfen Sie alle Eigenschaften und Konfigurationsdateien auf den Produktionsservern oder Servern auf Geheimnisse 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. Zu diesen Dateien können bei Spring Boot-Anwendungen die Dateien application.properties oder application.yml gehören.

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

Bestand: JNDI-Ressourcen

Inventarisieren Sie alle JNDI-Ressourcen. Einige Ressourcen, wie z. B. JMS Message Broker, müssen möglicherweise migriert oder neu konfiguriert werden.

Innerhalb Ihrer Anwendung

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

Stellen Sie fest, ob Datenbanken verwendet werden

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

  • Der Name der Datenquelle.
  • Die Konfiguration des Verbindungspools.
  • Den Speicherort der JDBC-Treiber JAR-Datei.

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 WebSphere Shared Modules oder von Ihrem Code 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.

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.

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, können Sie Azure Storage in Ihr App Service Dateisystem einbinden. Weitere Informationen finden Sie unter Azure Storage als lokale Freigabe im App Service einbinden.

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

Wenn Ihre Anwendung WebSphere-spezifische APIs verwendet, müssen Sie ein Refactoring durchführen, damit Ihre Anwendung diese APIs NICHT verwendet. 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 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 die Java EE-Anwendungsclientfunktion verwendet wird

Falls Sie über Clientanwendungen verfügen, die mit der Java EE-Anwendungsclientfunktion 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 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 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.

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 WebSphere gebunden ist, müssen Sie ein Refactoring Ihrer Anwendung durchführen, um die Abhängigkeit vom JCA-Konnektor zu entfernen. Wenn der JCA Konnektor verwendet werden kann, müssen Sie die JARs zum Klassenpfad des Servers hinzufügen. Außerdem müssen Sie die erforderlichen Konfigurationsdateien am richtigen Speicherort in den Verzeichnissen des JBoss EAP-Servers 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 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.

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 gepackt ist, sollten Sie die Dateien application.xml und ibm-application-bnd.xml untersuchen und ihre Konfigurationen erfassen.

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 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 unter Dateien 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 in Einrichten und Konfigurieren einer Tomcat-, JBoss- oder Java SE-App in Azure App Service.

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 Key Vault-Referenzen als App-Einstellungen in Azure App Service und Azure Functions.

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 Datendienste zu migrieren, folgen Sie den Schritten im Abschnitt Konfigurieren von Datendiensten für eine Tomcat-, JBoss- oder Java SE-App in Azure App Service.

Migrieren Sie alle zusätzlichen Server-Level-Klassenpfad-Abhängigkeiten. Weitere Informationen finden Sie unter Konfigurieren von Datendiensten für eine Tomcat-, JBoss- oder Java SE-App in Azure App Service.

Migrieren Sie alle zusätzlichen freigegebenen JDNI-Ressourcen auf Serverebene. Weitere Informationen finden Sie unter Konfigurieren von Datendiensten für eine Tomcat-, JBoss- oder Java SE-App in Azure App Service.

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

Empfehlungen