Migrieren von WebSphere-Anwendungen zu Azure Kubernetes Service (AKS)

  • Artikel

Diese Anleitung beschreibt, was Sie beachten sollten, wenn Sie einen bestehenden WebSphere Application Server (WAS) Workload zu IBM WebSphere Liberty oder Open Liberty auf Azure Kubernetes Service (AKS) migrieren 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.

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

Der erste Schritt für eine erfolgreiche Migration einer WAS-Anwendung zu Azure ist die Auswahl des am besten geeigneten Ziels für die Migration.

WAS lässt sich traditionell gut auf Azure Virtual Machines ausführen. Das Ziel der virtuellen Maschine (VM) 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.

Eine weitere Möglichkeit ist die Migration zu Containern, indem Sie WAS traditionelles Workload in Anwendungscontainer umwandeln. Sie können das Container-Ziel auf Azure Kubernetes Service (AKS) und Azure Red Hat OpenShift ausführen. Der Kompromiss für diese Erleichterung sind die wirtschaftlichen Kosten.

Allgemein gesprochen sind die Kosten pro Minute bei einer VM-basierten Lösung höher als bei Containern. Eine Container-basierte Lösung ist zwar kostengünstiger auszuführen, aber Sie müssen Ihre Anwendung so einschränken, dass sie in die Anforderungen der Plattform für die Orchestrierung von Containern passt.

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 Migration von WebSphere-Anwendungen zu Azure Virtual Machines.

Wenn Sie es tolerieren können, dass Ihre Anwendung in Containern ausgeführt wird, um die Laufzeitkosten zu senken, ziehen Sie eine AKS-basierte oder Azure Red Hat OpenShift-basierte Migration in Betracht.

Für die AKS-basierte Migration können Sie mit dem kostenlosen Tier beginnen. Sie erhalten kostenloses Cluster-Management und zahlen nur für die virtuellen Maschinen, den zugehörigen Storage und die verbrauchten Networking-Ressourcen. In diesem Fall siehe Migrieren Sie WebSphere Anwendungen zu Azure Kubernetes Service.

Bei der auf Red Hat OpenShift basierenden Migration zu Azure fallen für Anwendungsknoten zusätzlich zu den Datenverarbeitungskosten und den Infrastrukturkosten weitere Kosten für die OpenShift-Lizenzkomponente an. Diese Kosten werden auf der Grundlage der Anzahl der Anwendungsknoten und des Instanztyps berechnet. Nutzen Sie On-demand-Preise oder reservierte Instanzen, je nachdem, was den Anforderungen Ihres Workloads und Ihres Unternehmens am besten entspricht. In diesem Fall siehe Websphere-Anwendungen auf Azure Red Hat OpenShift migrieren.

Die Anleitungen in der Azure Red Hat OpenShift-Dokumentation decken einige Aspekte ab, die für die Migration relevant sind. Die vollständige Liste der Anleitungen finden Sie in der Azure Red Hat OpenShift-Dokumentation.

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

Nachdem Sie entschieden haben, dass AKS das geeignete Ziel für die Bereitstellung ist, müssen Sie akzeptieren, dass der IBM WebSphere Liberty Operator oder Open Liberty Operator (der Operator) die einzige Möglichkeit ist, Liberty auf Kubernetes auszuführen. Nachdem Sie diese Tatsache akzeptiert haben, müssen Sie entscheiden, ob das vorgefertigte Azure Marketplace-Angebot ein guter Ausgangspunkt ist oder nicht. Hier sind einige Dinge, die Sie bei dem vorgefertigten Azure Marketplace-Angebot beachten sollten:

  • IBM und Microsoft haben dieses Angebot erstellt, um Ihnen die Möglichkeit zu bieten, Liberty schnell auf AKS bereitzustellen. Dieses Konzept wird im folgenden Inhalt ausführlicher erläutert.
  • Im Großen und Ganzen automatisiert das Angebot die folgenden Schritte für Sie.
    • Nehmen Sie, falls gewünscht, ein bestehendes Image einer Anwendung.
    • Stellen Sie einen AKS-Cluster und eine Azure Container Registry (ACR)-Instanz bereit, falls gewünscht.
    • Installieren und konfigurieren Sie den IBM WebSphere Liberty Operator oder Open Liberty Operator auf AKS.
    • Verwenden Sie den Operator, um das Ganze auszuführen. Der Operator stellt containerisierte Liberty-Anwendungen in AKS bereit und verwaltet sie. Die Referenzdokumentation finden Sie unter IBM WebSphere Liberty operator und Open Liberty operator.

Wenn Sie nicht das vorgefertigte Azure Marketplace-Angebot nutzen, müssen Sie lernen, den Operator direkt zu verwenden. Die Beherrschung des Operators liegt außerhalb des Bereichs dieses Artikels. Die vollständige Dokumentation für den Operator finden Sie unter IBM WebSphere Liberty operator und Open Liberty operator.

Nachdem Sie nun die verschiedenen Möglichkeiten zur Handhabung von Liberty auf AKS kennengelernt haben, können Sie besser entscheiden, ob Sie das vorgefertigte Angebot des Azure Marketplace nutzen oder es selbst mit Hilfe des Operators direkt tun möchten.

Bestimmen Sie, ob die Liberty-Version kompatibel ist

Sie benötigen den Open Liberty Operator oder den WebSphere Liberty Operator, um Anwendungen auf Kubernetes-basierten Clustern bereitzustellen und zu verwalten. Vergewissern Sie sich, dass Ihre vorhandene Liberty-Version zu den von dem Operator unterstützten Versionen gehört. Die Versionen von Open Liberty werden in GitHub OpenLiberty/open-liberty gepflegt. IBM verwaltet die Versionen von IBM WebSphere Application Server Liberty. Weitere Informationen finden Sie unter WebSphere Application Server Liberty.

Das vorgefertigte Azure Marketplace-Angebot bietet Ihnen die Möglichkeit, Ihre Anwendungs-Images aus der öffentlichen Registrierung auszuwählen, und unterstützt somit implizit alle Versionen.

Feststellen, ob eine Lizenz erforderlich ist

Für IBM WebSphere Liberty müssen Sie die Bedingungen der Lizenzvereinbarung akzeptieren, die der Version des IBM Programms im Anwendungscontainer entspricht. Die für dieses IBM Programm geltende Lizenzvereinbarung finden Sie unter Lizenzinformationen für WebSphere Liberty Operator anzeigen. Weitere Informationen finden Sie unter Ausführen von WebSphere Liberty auf Microsoft Azure.

Wenn es sich bei Ihrer Produktedition um eine andere als die Standardversion von IBM WebSphere Application Server (Base) handelt, muss .spec.license.edition value Ihre Produktversion angeben. Andere verfügbare Werte sind IBM WebSphere Application Server Liberty Core und IBM WebSphere Application Server Network Deployment. Das vorgefertigte Angebot des Azure Marketplace lässt die Auswahl der unterstützten Produkt Edition zu.

Bestandsunterschiede mit IBM Migration Tools

Um Ihre Anwendungen auf WebSphere Application Server Liberty oder Open Liberty umzustellen, müssen Sie Ihre Migration planen, Ihre Anwendungen analysieren und Ihren Quellcode aktualisieren. IBM stellt Migrationstools zur Verfügung, mit denen Sie die Unterschiede zwischen Ihrer aktuellen Umgebung und den Technologien in Ihrer neuen Liberty-Umgebung ermitteln können, wie z. B. Java EE 7 oder Java EE 8 und Java SE 8 oder Java SE 11. Weitere Informationen finden Sie unter Migration von Anwendungen zu Liberty.

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. Dies ist beispielsweise hilfreich beim Auswählen der Größe von VMs in Ihrem Knotenpool, der Speichermenge für den Container und der Anzahl von benötigten CPU-Freigaben für den Container.

Es ist möglich, die Größe von Knotenpools in AKS zu ändern. Weitere Informationen finden Sie unter Ändern der Größe von Knotenpools in Azure Kubernetes Service (AKS).

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 wie z. B. WAS befinden sich diese Secrets in vielen verschiedenen Konfigurationsdateien und Stores. Überprüfen Sie alle Eigenschaften und Konfigurationsdateien auf den Produktionsservern auf Geheimnisse und Kennwörter. Unter Umständen finden Sie in Ihrer Anwendung auch Konfigurationsdateien mit Kennwörtern oder Anmeldeinformationen. WAS speichert die Konfigurationsdaten in mehreren Dokumenten in einer kaskadierenden Hierarchie von Verzeichnissen. Die meisten Konfigurationsdokumente haben XML-Inhalte. Weitere Informationen finden Sie unter Konfigurationsdokumente und Azure Key Vault-Grundkonzepte.

Nachdem Sie einen soliden Bestand an Secrets haben, konsultieren Sie die Operator-Dokumentation zu Secrets. Weitere Informationen finden Sie in den folgenden Artikeln:

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>

Nachdem Sie über einen soliden Bestand an Zertifikaten verfügen, konfigurieren Sie diese mit Hilfe der folgenden Artikel:

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

Die Verwendung von Liberty erfordert eine bestimmte Version von Java. Sie müssen also sicherstellen, dass Ihre Anwendung mit dieser unterstützten Version korrekt ausgeführt wird.

Die Runtime von WebSphere Application Server Liberty hat spezifische Anforderungen an die Mindeststufe der Java Runtime Environment (JRE). Weitere Informationen finden Sie unter Java-Versionsabhängigkeiten für Funktionen.

Open Liberty erfordert eine Java SE Runtime. Es kann entweder mit einer Java Runtime Environment (JRE) oder einer Java SE Entwicklung Kit (JDK) Distribution ausgeführt werden. Weitere Informationen finden Sie unter Unterstützte Java SE-Versionen.

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 WebSphere Data Sources in der IBM-Dokumentation. 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 Verwendung von JMS-Ressourcen.

Wenn Sie das vorgefertigte Angebot des Azure Marketplace verwenden, ist die Menge der JNDI-Ressourcen, die Sie bei der Bereitstellung anpassen können, auf die im Angebot unterstützten Ressourcen beschränkt. Für WebSphere Liberty auf AKS können Sie ein Objekt im standardmäßigen Java Naming and Directory Interface (JNDI) Namespace verfügbar machen. Weitere Informationen finden Sie unter Entwickeln mit dem JNDI Standard Namespace in einer Liberty Funktion. Für Open Liberty, siehe Java Naming and Directory Interface.

Profilkonfiguration überprüfen

Die wichtigste Konfigurationseinheit in WAS ist das Profil. Als solches enthält die Datei resources.xml eine Fülle von Konfigurationen, die Sie bei der Migration sorgfältig berücksichtigen müssen. Die Datei enthält Verweise auf andere XML-Dateien, die in Unterverzeichnissen gespeichert sind. Weitere Informationen finden Sie unter Verwaltung von Profilen auf verteilten und IBM i-Betriebssystemen.

Innerhalb Ihrer Anwendung

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

Sie müssen diese Anpassungen in dem Container-Image erfassen, das AKS ausführt. Wenn Sie das vorgefertigte Angebot des Azure Marketplace verwenden, lassen sich solche Anpassungen am besten vornehmen, indem Sie ein angepasstes Container-Image erstellen und es in einer öffentlichen Registrierung zur Verfügung stellen, auf die Sie dann bei der Bereitstellung verweisen.

Wenn Sie eine WebSphere Application Server Network Deployment-Zelle verwenden, wird jedes Cluster-Mitglied in einer Installation des herkömmlichen WAS ausgeführt. Liberty ist ein schlankes Profil von WebSphere Application Server. Es ist ein flexibles und dynamisches Profil von WAS, das es dem WAS-Server ermöglicht, nur die erforderlichen angepassten Funktionen bereitzustellen, anstatt eine große Menge an verfügbaren Java EE-Komponenten bereitzustellen.

Ermitteln, ob die Sitzungsreplikation verwendet wird

Wenn Ihre Anwendung auf die Replikation von Sitzungen angewiesen ist, haben Sie folgende Möglichkeiten:

  • Für HTTP-Sitzungen können Sie je nach Ebene der Sitzungsverwaltung einen Cache oder eine Datenbank verwenden, um Sitzungsdaten zu sammeln.
  • Für Verteilte Sitzungen können Sie die Sitzungen in einer Datenbank speichern, indem Sie die Sitzungspersistenz der Datenbank verwenden.
  • Bei Dynamischem Cache können Sie die Sitzungsdaten im Cache oder in einer Datenbank verwalten.
  • Sie können Ihre Anwendung so refactorieren, dass eine Datenbank für die Sitzungsverwaltung verwendet wird.
  • Sie können Ihre Anwendung so refactorieren, dass die Sitzung in den Azure Redis Dienst ausgelagert wird. Weitere Informationen finden Sie unter Azure Cache for Redis.

Für alle diese Optionen sollten Sie wissen, wie Liberty die Replikation des HTTP Session Status durchführt. Die folgenden Dokumente helfen Ihnen zu verstehen, wie Sie HTTP-Sitzungen in Liberty verwalten können:

Das vorgefertigte Azure Marketplace-Angebot unterstützt die Sitzungsaffinität über den Ingress-Controller des Application Gateway. Wenn Sie das Angebot bereitstellen, wählen Sie Cookie-basierte Affinität aktivieren.

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 WAS finden Sie unter Verwendung von JDBC-Treibern mit WebSphere Application Server.

Die JDBC-Konfiguration ist eine zentrale Serverkonfiguration in Liberty. Weitere Informationen finden Sie unter JDBC-Treiber.

Das vorgefertigte Angebot auf dem Azure Marketplace bietet nur begrenzten Support für Datenbanken. Sie können die Konfiguration in den Anwendungsimages vornehmen und das Image verwenden, wenn Sie das Angebot bereitstellen.

Ermitteln, ob WAS angepasst wurde

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

  • Wurden die Startskripts geändert? Zu diesen Skripten gehören wsadmin, AdminControl, AdminConfig, AdminApp und AdminTask.
  • Werden an JVM spezifische Parameter übergeben?
  • Werden dem Klassenpfad des Servers JAR-Dateien hinzugefügt?
  • Wurden Einrichtungen auf Betriebssystemlevel wie z. B. systemd verwendet, damit WAS-Komponenten nach einem Server-Neustart automatisch gestartet werden?

Abhängig von den Antworten auf diese Fragen müssen Sie Migrationsüberlegungen anstellen.

Sie müssen diese Anpassungen in dem Container-Image erfassen, das AKS ausführt. Wenn Sie das vorgefertigte Angebot des Azure Marketplace verwenden, lassen sich solche Anpassungen am besten vornehmen, indem Sie ein angepasstes Container-Image erstellen und es in einer öffentlichen Registrierung zur Verfügung stellen, auf die Sie dann bei der Bereitstellung verweisen.

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, müssen Sie diese auf einen extern gehosteten JMS-Server migrieren. Eine Strategie für diejenigen, die JMS verwenden, ist die Verwendung von Azure Service Bus und dem Advanced Message Queuing Protocol. Weitere Informationen finden Sie unter Verwenden von Java Message Service 1.1 mit Azure Service Bus Standard und AMQP 1.0.

Wenn Sie persistente JMS Stores konfiguriert haben, müssen Sie deren Konfiguration erfassen und nach der Migration anwenden.

Wenn Sie IBM MQ verwenden, können Sie diese Software zu Azure Virtual Machines migrieren und sie so verwenden, wie sie ist.

Microsoft bietet eine Lösung zur Integration von IBM MQ mit Logic Apps. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit einem IBM MQ-Server über einen Workflow in Azure Logic Apps.

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 handhaben, die in Zugriff auf APIs von Drittanbietern aus einer Java EE-Anwendung beschrieben sind.

Ermitteln, ob OSGi-Pakete verwendet werden

Wenn Sie OSGi-Bundles verwendet haben, die dem WAS hinzugefügt wurden, müssen Sie die entsprechenden JAR-Dateien direkt zu Ihrer Webanwendung hinzufügen.

Sie können die Bundles in das Image aufnehmen, das dem vorgefertigten Azure Marketplace-Angebot beigefügt ist. Weitere Informationen finden Sie unter Konfiguration von Bibliotheken für OSGi-Anwendungen.

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.

Liberty auf AKS wird auf Linux x86_64 ausgeführt. Jeder betriebssystemspezifische Code muss mit Linux kompatibel sein. Um zu erfahren, wie Sie spezifische Informationen zum Betriebssystem ermitteln können, folgen Sie den Schritten im Abschnitt Bestimmen, ob die Liberty-Version kompatibel ist.

Stellen Sie fest, ob IBM Integration Bus verwendet wird

Wenn Ihre Anwendung IBM Integration Bus verwendet, müssen Sie erfassen, wie IBM Integration Bus konfiguriert ist. Weitere Informationen finden Sie unter IBM Integration Bus-Dokumentation.

IBM Integration Bus wird im vorgefertigten Azure Marketplace-Angebot nicht direkt unterstützt. Um die Funktion zu aktivieren, folgen Sie den Anweisungen in Aktivierung der JMS-Anwendung auf Liberty zur Verbindung mit dem Service Integration Bus in der IBM-Dokumentation.

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, ibm-application-bnd.xmi und ibm-application-ext.xmi untersuchen und deren Konfigurationen erfassen. Weitere Informationen finden Sie unter Erstellung des Enterprise Archive (EAR)-Pakets auf WebSphere.

Das vorgefertigte Azure Marketplace-Angebot bietet Ihnen die Möglichkeit, ein vorhandenes Container Image zu verwenden. Sie können die Anwendung entsprechend Ihren geschäftlichen Anforderungen vorbereiten.

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.

Ermitteln, ob und wie das Dateisystem verwendet wird

Kubernetes arbeitet mit Dateisystemen mit persistenten Volumes (PV). Das Einbinden von persistenten Volumes wird im vorgefertigten Azure Marketplace-Angebot nicht unterstützt. Um verschiedene Storage-Optionen zu aktivieren, folgen Sie den Anweisungen unter Speicheroptionen für Anwendungen in Azure Kubernetes Services.

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 Storage und Schnellstart: 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.

Ermitteln der Netzwerktopologie

Das aktuelle Angebot auf dem Azure Marketplace ist ein Ausgangspunkt für Ihre Migration. Wenn das Angebot die Aspekte Ihrer Architektur, die Sie migrieren müssen, nicht abdeckt, müssen Sie die Netzwerktopologie Ihrer bestehenden Bereitstellung erfassen. Anschließend müssen Sie diese Topologie in Azure reproduzieren, auch nachdem Sie das Basisangebot mit einer der Lösungsvorlagen eingerichtet haben.

Die Netzwerktopologie ist ein umfangreiches Thema, aber die folgenden Referenzen können Ihnen bei Ihren Migrationsbemühungen eine gewisse Richtung geben:

Konto für die Verwendung von JCA-Adaptern und Ressourcenadaptern

Wenn Ihre vorhandene Anwendung JCA-Adapter oder Ressourcenadapter zum Herstellen einer Verbindung mit anderen Unternehmenssystemen verwendet, stellen Sie sicher, dass Sie die Konfiguration für diese Artefakte auf den Liberty-Server anwenden, der auf Azure Kubernetes Service (AKS) ausgeführt wird. Weitere Informationen finden Sie unter Übersicht über die JCA-Konfigurationselemente und Java Konnektor-Architektur.

Bestimmen Sie, ob Clustering verwendet wird

Der Operator verwaltet das Clustering für alle möglichen Arten, den WAS Workload auf AKS auszuführen.

EJB-Clustering überprüfen

Wenn Ihre Anwendung lokale Enterprise Java Beans (EJB) verwendet, müssen Sie diese möglicherweise auf eine geclusterte EJB migrieren. Weitere Informationen finden Sie unter Entwicklung von EJB-Anwendungen auf Liberty.

Konto für Lastenausgleichsanforderungen

Die beste Möglichkeit, Load-Balancing zu berücksichtigen, ist die Verwendung der App Gateway-Integration, die durch das integrierte Angebot des Azure Marketplace bereitgestellt wird.

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 IBM WebSphere Liberty und Open Liberty auf Azure Kubernetes Service. Wählen Sie Erstellen und verwenden Sie dann die Informationen, die Sie in den vorangegangenen Schritten gesammelt haben, um die Felder des Angebots auszufüllen.

Berücksichtigen von Keystores

Sie müssen die Migration der von Ihrer Anwendung verwendeten SSL/TLS KeyStores berücksichtigen. Weitere Informationen finden Sie unter Konfigurieren von Keystores.

Verbinden der JMS-Quellen

Nachdem Sie die Datenbanken verbunden haben, können Sie JMS konfigurieren, indem Sie den Anweisungen unter Übersicht über die JCA-Konfigurationselemente in der IBM Dokumentation folgen.

Berücksichtigen der Protokollierung

Sie können nicht in der Cloud arbeiten, ohne die Protokollierung zu beherrschen. Der Operator bietet verschiedene Ansätze für die Überwachung. Weitere Informationen finden Sie unter Überwachung der Liberty Server Runtime Umgebung. Wenn Sie die Verwendung von Elastic Stack bevorzugen, bietet Azure umfangreichen Support für Elastic. Ausführliche Informationen finden Sie unter Was ist die Integration von Elastic mit Azure? Sie können das Wissen in diesen beiden Ressourcen kombinieren, um eine für Azure optimierte Protokollierungslösung für Liberty auf AKS zu erhalten.

Migrieren Ihrer Anwendungen

Unabhängig davon, ob Sie sich dafür entschieden haben, ein Image der Anwendung zum Zeitpunkt der Bereitstellung bereitzustellen, müssen Sie die Anwendung über CI/CD aktualisieren. In der IBM Dokumentation finden Sie ein Beispiel, das zeigt, wie Sie diese Aktualisierung durchführen. Weitere Informationen finden Sie unter Bereitstellen von Anwendungen in Liberty.

Konfigurieren von Tests

Sie müssen alle In-Container-Tests gegen Anwendungen so konfigurieren, dass sie Zugriff auf die neuen in Azure ausgeführten Server haben. Wie bei den CI/CD-Problemen müssen Sie auch hier sicherstellen, dass die notwendigen Netzwerksicherheitsregeln Ihren Tests die Möglichkeit bieten, auf die in Azure bereitgestellten Anwendungen zuzugreifen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

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. In den folgenden Artikeln finden Sie Informationen zu Verbesserungen nach der Migration: