Freigeben über

Migrieren von JBoss-EAP-Anwendungen zu Azure Red Hat OpenShift

  • Artikel

Diese Anleitung beschreibt, was Sie beachten sollten, wenn Sie eine bestehende JBoss EAP-Anwendung migrieren möchten, um sie auf Azure Red Hat OpenShift auszuführen.

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.

Stellen Sie sicher, dass das Ziel das richtige Ziel für Ihre Migration ist

Der erste Schritt für eine erfolgreiche Migration einer JBoss EAP-Anwendung zu Azure ist die Auswahl des am besten geeigneten Ziels für die Migration. JBoss EAP lässt sich gut auf Azure Virtual Machines (VMs) oder Azure Red Hat OpenShift ausführen.

Das VM-Ziel ist die einfachste Wahl, da es einer on-premises Bereitstellung am nächsten kommt. Die Verwaltung und Bereitstellung virtueller Maschinen erfolgt analog zu der on-premises. Die Wahl von VMs bietet Ihnen die Möglichkeit, die Modernisierung aufzuschieben.

Red Hat OpenShift vereint getestete und bewährte Dienste, um die Reibungsverluste beim Entwickeln, Modernisieren, Bereitstellen, Ausführen und Verwalten von Anwendungen zu verringern. Azure Red Hat OpenShift ist auf Kubernetes erstellt. Azure Red Hat OpenShift bietet eine konsistente Erfahrung in der Public Cloud, on-premises, Hybrid Cloud oder Edge-Architektur.

Wenn die Minimierung von Änderungen der wichtigste Faktor für Ihre Migrationsbemühungen ist, sollten Sie eine VM-basierte Migration in Betracht ziehen. In diesem Fall siehe Migrieren Sie JBoss EAP-Anwendungen zu JBoss EAP auf Azure VMs. Wenn Sie es tolerieren können, dass Ihre Anwendung innerhalb von Red Hat OpenShift ausgeführt wird, um die Runtime-Kosten zu senken, ziehen Sie eine Migration zu Azure auf Basis von Red Hat OpenShift in Betracht. In diesem Fall fahren Sie fort mit Migrieren Sie JBoss EAP-Anwendungen zu JBoss EAP auf Azure Red Hat OpenShift. Um die Unterschiede zwischen JBoss EAP und JBoss EAP für OpenShift zu verstehen, siehe Vergleich: JBoss EAP und JBoss EAP für OpenShift.

Bestimmen Sie, ob das vorgefertigte Angebot auf dem Azure Marketplace ein guter Ausgangspunkt ist

Entscheiden Sie zunächst, dass Azure Red Hat OpenShift das geeignete Ziel für die Bereitstellung ist. Entscheiden Sie dann, ob das vorgefertigte Azure Marketplace-Angebot ein guter Ausgangspunkt ist oder nicht. Beachten Sie die folgenden Punkte über das vorgefertigte Azure Marketplace-Angebot:

  • Red Hat und Microsoft haben dieses Angebot erstellt, um eine schnelle Bereitstellung von JBoss EAP auf Azure Red Hat OpenShift zu ermöglichen.
  • Im Großen und Ganzen automatisiert das Angebot die folgenden Schritte für Sie.
    • Installieren Sie den EAP Operator auf Azure Red Hat OpenShift.
    • Erstellen Sie ein Image der Anwendung mit der Vorlage eap-s2i-build. Weitere Informationen über Source-to-image (S2I) finden Sie unter Verwendung von OpenJDK 11 source-to-image für OpenShift.
    • Stellen Sie die Java-Anwendung mithilfe des EAP-Operators bereit. Weitere Informationen finden Sie unter Red Hat in der Referenzdokumentation für EAP Operator.

Wenn Sie nicht das vorgefertigte Angebot des Azure Marketplace nutzen, müssen Sie lernen, den EAP Operator direkt zu verwenden. Die Beherrschung des Operators liegt außerhalb des Bereichs dieses Artikels. Die vollständige Dokumentation für den EAP Operator finden Sie unter Red Hat.

Der Rest dieses Abschnitts enthält einige Überlegungen zu der Entscheidung, ob Sie das vorgefertigte Angebot des Azure Marketplace nutzen oder den Operator direkt verwenden sollen.

Ermitteln, ob die JBoss EAP-Version kompatibel ist

Ihre vorhandene JBoss EAP-Version muss eine der vom Operator unterstützten Versionen sein. Weitere Informationen finden Sie unter Versionskompatibilität und Support in der Dokumentation von Red Hat.

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 von dem von Ihnen gewählten Migrationspfad. Ein detaillierter Bestand an Serverkapazitäten ist nicht nur für die folgenden Aspekte von Vorteil.

  • Als Anleitung für die Auswahl der Größe der VMs in Ihrem Knoten-Pool.
  • Um zu verstehen, wie viel Arbeitsspeicher vom Container genutzt werden soll.
  • Um zu wissen, wie viele CPU-Anteile der Container benötigt.

Es ist möglich, die Größe von Knoten Pools in Azure Red Hat OpenShift zu ändern. Weitere Informationen finden Sie unter Resizing a cluster--Microsoft Azure in der Red Hat-Dokumentation.

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. JBoss EAP, 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. Achten Sie darauf, Konfigurationsdateien wie custom-config.xml oder jboss-web.xml in Ihren Anwendungen zu überprüfen. 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.

Sobald Sie über einen soliden Bestand an Secrets verfügen, konsultieren Sie die EAP Operator Dokumentation zu Secrets. Weitere Informationen finden Sie unter Erstellen eines Secrets in der Dokumentation von Red Hat.

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>

Sobald Sie über einen soliden Bestand an Zertifikaten verfügen, können Sie diese in Azure Red Hat OpenShift konfigurieren. Weitere Informationen finden Sie unter TLS-Konfiguration in OpenShift Container Platform(replace) in der Red Hat-Dokumentation.

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

Alle Migrationspfade für JBoss EAP zu Azure Red Hat OpenShift erfordern eine bestimmte Java-Version, die für jeden Pfad unterschiedlich ist. Sie müssen sicherstellen, dass Ihre Anwendung mit dieser unterstützten Version korrekt ausgeführt werden kann.

Hinweis

Diese Überprüfung ist besonders wichtig, wenn Ihr aktueller Server auf einem nicht unterstützten JDK (z. B. Oracle JDK oder IBM OpenJ9) ausgeführt 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. 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 unter Datasource Management in der Red Hat-Dokumentation. Andere JNDI-bezogene Ressourcen, wie z. B. ActiveMQ Artemis Message Broker, müssen möglicherweise migriert oder neu konfiguriert werden. Weitere Informationen zur Konfiguration von ActiveMQ Artemis finden Sie unter Konfiguration von Nachrichten in der Red Hat-Dokumentation.

Ermitteln, ob die Sitzungsreplikation verwendet wird

Wenn Ihre Anwendung auf die Replikation von Sitzungen angewiesen ist, mit oder ohne Infinispan, haben Sie drei Möglichkeiten:

  • Infinispan funktioniert gut in virtuellen Maschinen von Azure, aber wenn Sie ein Profil verwenden, das Hochverfügbarkeits-Funktionalitäten bietet, sollten Sie die JGroups-Konfiguration beachten. Stellen Sie fest, ob Ihr System in einer verwalteten Domäne oder als eigenständiger Server betrieben wird.
    • Wenn Sie sich in einer verwalteten Domäne befinden, kümmern sich die Profile ha oder full-ha um JGroups.
    • Wenn Sie sich in einem Standalone-Server befinden, befassen sich die Konfigurationsdateien standalone-ha.xml oder standalone-full-ha.xml mit JGroups.
    • Microsoft Azure unterstützt keine JGroups-Erkennungsprotokolle, die auf UDP-Multicast basieren. Weitere Informationen finden Sie unter Verwenden von JBoss EAP Hochverfügbarkeit in Microsoft Azure in der Red Hat Dokumentation.
  • 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.

Für alle diese Optionen sollten Sie wissen, wie JBoss EAP die Replikation des HTTP Session Status durchführt. Weitere Informationen finden Sie unter Über HTTP Session Replikation in der Red Hat Dokumentation.

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 über JDBC-Treiber in JBoss EAP finden Sie unter Datasource Management in der Red Hat-Dokumentation.

Ermitteln Sie, ob JBoss EAP angepasst wurde

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

  • Wurden die Startskripts geändert? Zu diesen Skripten gehören host, eap_env, standalone und domain.
  • Werden an JVM spezifische Parameter übergeben?
  • Werden dem Klassenpfad des Servers JAR-Dateien hinzugefügt?

Diese Anpassungen müssen im Image des Containers, der auf Azure Red Hat OpenShift ausgeführt wird, festgehalten werden. Weitere Informationen finden Sie unter Konfiguration des JBoss EAP for OpenShift Image für Ihre Java-Anwendung in der Red Hat Dokumentation.

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 Topics verwendet, sollten Sie diese auf einen extern gehosteten JMS-Server migrieren. Azure Service Bus und das Advanced Message Queuing Protocol können bei Verwendung von JMS Teil einer gut geeigneten 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.

Weitere Informationen finden Sie unter Konfiguration von Messaging in der Red Hat-Dokumentation.

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.

Sie können diese Bibliotheken mit denselben Techniken behandeln, die im Abschnitt Bestimmen, ob JBoss EAP angepasst wurde beschrieben wurden.

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.

Azure Red Hat OpenShift wird unter OpenShift 4 ausgeführt und verwendet Red Hat Enterprise Linux CoreOS (RHCOS) als Betriebssystem für alle Knoten der Steuerungsebene sowie für alle Workerknoten. Jeder Betriebssystem-spezifische Code muss mit RHCOS kompatibel sein.

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, stellen Sie sicher, dass Sie deren 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.

Konto für Lastenausgleichsanforderungen

Der beste Weg, um Load-Balancing zu berücksichtigen, ist die Verwendung der App Gateway Integration. Weitere Informationen finden Sie unter Was ist Azure Application Gateway?

Migration

Die Schritte in diesem Abschnitt gehen davon aus, dass Sie sich nach Ihrer Analyse für das vorgefertigte Azure Marketplace-Angebot entschieden haben.

Bereitstellen des Angebots

Um das Angebot im Azure-Portal zu öffnen, siehe JBoss EAP auf Azure Red Hat OpenShift. Wählen Sie Erstellen und folgen Sie dann den Anweisungen im Angebot.

Migrieren Ihrer Anwendungen

Das Angebot unterstützt den Source-to-Image (S2I)-Prozess zum Erstellen und Ausführen einer Java-Anwendung auf dem JBoss EAP for OpenShift Image. Red Hat bietet ein Beispiel, das zeigt, wie Sie dies manuell durchführen können, wenn Sie die Bereitstellung später selbst vornehmen möchten. Weitere Informationen finden Sie unter Kapitel 2. Erstellen und Ausführen einer Java-Anwendung auf dem JBoss EAP für OpenShift Image in der Dokumentation von Red Hat.

Nach der Migration

Nachdem Sie die Migrationsziele erreicht haben, die Sie unter Vor der Migration definiert haben, führen Sie einige End-to-End-Akzeptanztests durch. Hiermit soll sichergestellt werden, dass alles wie gewünscht funktioniert. Informationen zu möglichen Verbesserungen nach der Migration finden Sie in den folgenden Artikeln: