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

  • Artikel

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

Stellen Sie sicher, dass das Ziel das geeignete Ziel für Ihren Migrationsaufwand ist.

Der erste Schritt bei einer erfolgreichen Migration einer JBoss EAP-Anwendung zu Azure ist die Auswahl des am besten geeigneten Migrationsziels. JBoss EAP wird gut auf virtuellen Azure-Computern (VMs) oder Azure Red Hat OpenShift ausgeführt.

Das VM-Ziel ist die einfachste Wahl, da sie am ehesten einer lokalen Bereitstellung ähnelt. Die Verwaltungs- und Bereitstellungsumgebung für virtuelle Computer entspricht dem, was Sie lokal haben. Wenn Sie VMs auswählen, können Sie die Modernisierung zurückstellen.

Red Hat OpenShift vereint getestete und vertrauenswürdige Dienste, um die Reibung der Entwicklung, Modernisierung, Bereitstellung, Ausführung und Verwaltung von Anwendungen zu reduzieren. Azure Red Hat OpenShift basiert auf Kubernetes. Azure Red Hat OpenShift bietet eine konsistente Erfahrung in der öffentlichen Cloud, lokal, hybriden Cloud oder Edgearchitektur.

Wenn die Minimierung von Änderungen der wichtigste Faktor für Ihren Migrationsaufwand ist, sollten Sie eine VM-basierte Migration in Betracht ziehen. In diesem Fall finden Sie informationen unter Migrieren von JBoss EAP-Anwendungen zu JBoss EAP auf Azure-VMs. Wenn Sie die Konvertierung Ihrer Anwendung in Red Hat OpenShift tolerieren können, um die Laufzeitkosten zu reduzieren, sollten Sie eine Azure Red Hat OpenShift-basierte Migration in Betracht ziehen. Fahren Sie in diesem Fall mit der Migration von JBoss EAP-Anwendungen zu JBoss EAP auf Azure Red Hat OpenShift fort. Informationen zu den Unterschieden zwischen JBoss EAP und JBoss EAP für OpenShift finden Sie im Vergleich: JBoss EAP und JBoss EAP für OpenShift.

Ermitteln, ob das vorgefertigte Azure Marketplace-Angebot ein guter Ausgangspunkt ist

Entscheiden Sie zunächst, dass Azure Red Hat OpenShift das entsprechende Bereitstellungsziel ist. Entscheiden Sie als Nächstes, ob das vorgefertigte Azure Marketplace-Angebot ein guter Ausgangspunkt ist. Beachten Sie die folgenden Punkte zum vorgefertigten Azure Marketplace-Angebot:

  • Red Hat und Microsoft haben dieses Angebot erstellt, um die schnelle Bereitstellung von JBoss EAP auf Azure Red Hat OpenShift zu ermöglichen.
  • Auf hoher Ebene automatisiert das Angebot die folgenden Schritte für Sie.
    • Installieren Sie den EAP-Operator auf Azure Red Hat OpenShift.
    • Erstellen Sie ein Anwendungsimage mithilfe einer eap-s2i-Buildvorlage. Weitere Informationen zu Source-to-Image (S2I) finden Sie unter Verwenden von OpenJDK 11 Source-to-Image für OpenShift.
    • Stellen Sie die Java-Anwendung mit dem EAP-Operator bereit. Weitere Informationen finden Sie in der Referenzdokumentation für den EAP-Operator bei Red Hat.

Wenn Sie das vorgefertigte Azure Marketplace-Angebot nicht verwenden, müssen Sie erfahren, wie Sie den EAP-Operator direkt verwenden. Die Mastering des Operators liegt außerhalb des Umfangs dieses Artikels. Die vollständige Dokumentation für den EAP-Operator ist unter Red Hat verfügbar.

Der Re Standard der dieses Abschnitts enthält einige Überlegungen zur Entscheidung, das vorgefertigte Azure Marketplace-Angebot zu verwenden oder den Betreiber direkt zu verwenden.

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 in der Dokumentation zu Red Hat unter Versionskompatibilität und Support .

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 von Ihnen ausgewählten Migrationspfad. Die folgenden Aspekte und vieles mehr profitieren von einer detaillierten Bestandsaufnahme der Serverkapazität.

  • Um die Auswahl der Größe der virtuellen Computer in Ihrem Knotenpool zu unterstützen.
  • Um zu verstehen, wie viel Arbeitsspeicher vom Container verwendet werden soll.
  • Um zu wissen, wie viele CPU-Freigaben für den Container benötigt werden.

Es ist möglich, die Größe von Knotenpools in Azure Red Hat OpenShift zu ändern. Weitere Informationen finden Sie in der Dokumentation zu Red Hat unter Ändern der Größe eines Clusters – Microsoft Azure .

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. Überprüfen Sie die Konfigurationsdateien wie custom-config.xml oder jboss-web.xml in Ihren Anwendungen. 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 ein solides Inventar von geheimen Schlüsseln verfügen, konsultieren Sie die Dokumentation des EAP-Betreibers zu geheimen Schlüsseln. Weitere Informationen finden Sie unter Erstellen eines geheimen Schlüssels in der Dokumentation zu 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 sie in Azure Red Hat OpenShift konfigurieren. Weitere Informationen finden Sie in der Red Hat-Dokumentation unter TLS-Konfiguration in openShift Container Platform(replace ).

Ü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 variiert. Sie müssen überprüfen, ob Ihre Anwendung mit dieser unterstützten Version ordnungsgemäß 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 in der Red Hat-Dokumentation unter "Datasource Management ". Andere JNDI-bezogene Ressourcen, z. B. ActiveMQ Artemis-Nachrichtenbroker, erfordern möglicherweise eine Migration oder Neukonfiguration. Weitere Informationen zur Konfiguration von ActiveMQ Artemis finden Sie in der Dokumentation zum Konfigurieren von Messaging in der Red Hat-Dokumentation.

Ermitteln, ob die Sitzungsreplikation verwendet wird

Wenn Ihre Anwendung auf der Sitzungsreplikation mit oder ohne Infinispan basiert, haben Sie drei Optionen:

  • Infinispan funktioniert gut auf virtuellen Azure-Computern. Wenn Sie jedoch ein Profil verwenden, das funktionen für hohe Verfügbarkeit bereitstellt, beachten Sie die JGroups-Konfiguration . Ermitteln Sie, ob Ihr System als verwalteter Vorgang ausgeführt wird Standard oder eigenständiger Server.
    • Wenn in einer verwalteten Do Standard werden die ha- oder full-ha-Profile mit JGroups behandelt.
    • Wenn sie sich auf einem eigenständigen Server befinden, werden die Konfigurationsdateien "standalone-ha.xml " oder "standalone-full-ha.xml " mit JGroups behandelt.
    • Microsoft Azure unterstützt keine JGroups-Ermittlungsprotokolle, die auf UDP-Multicast basieren. Weitere Informationen finden Sie unter Verwenden von JBoss EAP High Availability in Microsoft Azure in der Dokumentation zu Red Hat.
  • 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 ist es ratsam, zu beherrschen, wie JBoss EAP die HTTP-Sitzungsstatusreplikation durchführt. Weitere Informationen finden Sie in der Dokumentation zur HTTP-Sitzungsreplikation .

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 TREIBERN in JBoss EAP finden Sie in der Dokumentation zu Datasource Management in Red Hat.

Bestimmen, ob JBoss EAP angepasst wurde

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

  • Wurden die Startskripts geändert? Zu diesen Skripts gehören Host, eap_env, eigenständige Und do Standard.
  • Werden an JVM spezifische Parameter übergeben?
  • Werden dem Klassenpfad des Servers JAR-Dateien hinzugefügt?

Diese Anpassungen müssen im Containerimage erfasst werden, das auf Azure Red Hat OpenShift ausgeführt wird. Weitere Informationen finden Sie unter Configuring the JBoss EAP for OpenShift Image for Your Java Application in the Red Hat documentation.

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 verwendet, sollten Sie sie zu einem 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 (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.

Weitere Informationen finden Sie unter Konfigurieren von Messaging in der Dokumentation zu Red Hat.

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 den gleichen Techniken wie im Abschnitt "Bestimmen, ob JBoss EAP angepasst wurde" behandeln.

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.

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 betriebssystemspezifische 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 verpackt ist, müssen Sie 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.

Konto für Lastenausgleichsanforderungen

Die beste Möglichkeit zum Berücksichtigen des Lastenausgleichs ist die Verwendung der App-Gateway-Integration. Weitere Informationen finden Sie unter Was ist Azure Application Gateway?

Migration

Bei den Schritten in diesem Abschnitt wird davon ausgegangen, dass Ihre Analyse Sie dazu geführt hat, das vorgefertigte Azure Marketplace-Angebot zu verwenden.

Bereitstellen des Angebots

Informationen zum Öffnen des Angebots im Azure-Portal finden Sie unter JBoss EAP unter Azure Red Hat OpenShift. Wählen Sie "Erstellen" aus, 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 für OpenShift-Image. Red Hat hat ein Beispiel, das zeigt, wie Sie dies manuell tun können, wenn Sie später selbst bereitstellen möchten. Weitere Informationen finden Sie in Kapitel 2. Erstellen und Ausführen einer Java-Anwendung auf dem JBoss EAP für OpenShift Image in der Dokumentation zu 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: