Migrieren von WebSphere-Anwendungen zu Azure Kubernetes Service

  • Artikel

In diesem Leitfaden wird beschrieben, was Sie beachten sollten, wenn Sie eine vorhandene 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 geeignete Ziel für Ihren Migrationsaufwand ist.

Der erste Schritt bei einer erfolgreichen Migration einer WAS-Anwendung zu Azure ist die Auswahl des am besten geeigneten Migrationsziels.

WAS traditionell gut auf virtuellen Azure-Computern ausgeführt wird. Das Ziel des virtuellen Computers (VM) ist die einfachste Wahl, da es einer lokalen Bereitstellung am ehesten ähnelt. Die Verwaltungs- und Bereitstellungsumgebung für virtuelle Computer entspricht dem, was Sie lokal haben.

Eine weitere Option besteht darin, zu Containern zu migrieren, indem sie DIE herkömmliche Arbeitsauslastung in Anwendungscontainer konvertieren. Sie können das Containerziel für Azure Kubernetes Service (AKS) und Azure Red Hat OpenShift ausführen. Der Kompromiss für diese Erleichterung ist die wirtschaftliche Kosten.

Im Allgemeinen ist die Kosten pro Minute für eine VM-basierte Lösung im Vergleich zu Containern höher. Während eine containerbasierte Lösung weniger ausgeführt werden kann, müssen Sie ihre Anwendung auf die Anforderungen der Container-Orchestrierungsplattform beschränken.

Wenn die Minimierung von Änderungen der wichtigste Faktor für Ihren Migrationsaufwand ist, sollten Sie eine VM-basierte Migration in Betracht ziehen. Informationen hierzu finden Sie unter Migrieren von WebSphere-Anwendungen zu virtuellen Azure-Computern.

Wenn Sie die Konvertierung Ihrer Anwendung in Containern tolerieren können, um die Laufzeitkosten zu reduzieren, sollten Sie eine AKS-basierte oder Azure Red Hat OpenShift-basierte Migration in Betracht ziehen.

Für die AKS-basierte Migration können Sie mit der Kostenlosen Stufe beginnen. Erhalten Sie kostenlose Clusterverwaltung und zahlen Sie nur für die virtuellen Computer, zugeordneten Speicher und Netzwerkressourcen, die verbraucht werden. Informationen hierzu finden Sie unter Migrieren von WebSphere-Anwendungen zu Azure Kubernetes Service.

Für die Azure Red Hat OpenShift-basierte Migration haben Anwendungsknoten zusätzlich zu den Compute- und Infrastrukturkosten weitere Kosten für die OpenShift-Lizenzkomponente. Diese Kosten werden basierend auf der Anzahl der Anwendungsknoten und des Instanztyps in Rechnung gestellt. Verwenden Sie On-Demand-Preise oder reservierte Instanzen, je nachdem, was die Anforderungen Ihrer Workload und Ihres Unternehmens am besten erfüllt. In diesem Fall finden Sie Informationen zum Migrieren von WebSphere-Anwendungen zu Azure Red Hat OpenShift.

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

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

Nachdem Sie entschieden haben, dass AKS das geeignete Bereitstellungsziel ist, müssen Sie akzeptieren, dass der IBM WebSphere Liberty-Operator oder der Open Liberty Operator (der Operator) die einzige Möglichkeit ist, Liberty auf Kubernetes auszuführen. Nachdem Sie diese Tatsache angenommen haben, müssen Sie entscheiden, ob das vorgefertigte Azure Marketplace-Angebot ein guter Ausgangspunkt ist. Hier sind einige Punkte, die Sie über das vorgefertigte Azure Marketplace-Angebot berücksichtigen sollten:

  • IBM und Microsoft haben dieses Angebot erstellt, damit Sie Liberty schnell auf AKS bereitstellen können. Dieses Konzept wird im folgenden Inhalt ausführlicher erläutert.
  • Auf hoher Ebene automatisiert das Angebot die folgenden Schritte für Sie.
    • Erstellen Sie bei Bedarf ein vorhandenes Anwendungsbild.
    • Stellen Sie bei Bedarf einen AKS-Cluster und eine Azure Container Registry (ACR)-Instanz bereit.
    • Installieren und konfigurieren Sie den IBM WebSphere Liberty-Operator oder den 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 das vorgefertigte Azure Marketplace-Angebot nicht verwenden, müssen Sie erfahren, wie Sie den Betreiber direkt verwenden. Die Mastering des Operators liegt außerhalb des Umfangs dieses Artikels. Die vollständige Dokumentation für den Betreiber ist bei IBM WebSphere Liberty Operator und Open Liberty Operator verfügbar.

Nachdem Sie nun mit den verschiedenen Möglichkeiten zur Handhabung von Liberty auf AKS eingeführt wurden, können Sie besser auswählen, ob Sie das vorgefertigte Azure Marketplace-Angebot verwenden oder es selbst mit dem Betreiber selbst erledigen möchten.

Ermitteln, 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. Stellen Sie sicher, dass Ihre vorhandene Liberty-Version eine der vom Operator unterstützten Versionen ist. Versionen von Open Liberty werden in GitHub OpenLiberty/open-liberty Standard tained. IBM Standard versionen von IBM WebSphere Application Server Liberty. Weitere Informationen finden Sie unter WebSphere Application Server Liberty.

Mit dem vorgefertigten Azure Marketplace-Angebot können Sie Ihre Anwendungsimages aus der öffentlichen Registrierung auswählen und somit alle Versionen implizit unterstützen.

Ermitteln, ob eine Lizenz erforderlich ist

Für IBM WebSphere Liberty müssen Sie die Bedingungen für den Lizenzvertrag akzeptieren, der der Version des IBM-Programms im Anwendungscontainer entspricht. Informationen zum Lizenzvertrag für dieses IBM-Programm finden Sie unter Anzeigen von Lizenzinformationen für den WebSphere Liberty-Operator. Weitere Informationen finden Sie unter Running WebSphere Liberty in Microsoft Azure.

Wenn Ihre Produktedition etwas anderes als der Standard-IBM WebSphere Application Server (Basis) ist, muss die .spec.license.edition value Produktedition angegeben werden. Weitere verfügbare Werte sind IBM WebSphere Application Server Liberty Core und IBM WebSphere Application Server Network Deployment. Mit dem vorgefertigten Azure Marketplace-Angebot können Sie die unterstützte Produktedition auswählen.

Bestandsaufnahmesunterschiede mithilfe von IBM-Migrationstools

Um Ihre Anwendungen in WebSphere Application Server Liberty oder Open Liberty zu verschieben, müssen Sie Ihre Migration planen, Ihre Anwendungen analysieren und Ihren Quellcode aktualisieren. IBM bietet Migrationstools, mit denen Alle Unterschiede zwischen Ihrer aktuellen Umgebung und den Technologien in Ihrer neuen Liberty-Umgebung wie Java EE 7 oder Java EE 8 und Java SE 8 oder Java SE 11 identifiziert werden können. Weitere Informationen finden Sie unter Migrieren 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. Es ist beispielsweise hilfreich, die Auswahl der Größe der virtuellen Computer in Ihrem Knotenpool, die Menge des vom Container verwendeten Arbeitsspeichers und die Anzahl der CPU-Freigaben des Containers zu unterstützen.

Es ist möglich, die Größe von Knotenpools in AKS zu ändern. Informationen dazu finden Sie unter Ändern der Größe von Knotenpools in Azure Kubernetes Service (AKS).To learn how, see Resize node pools 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 WAS befinden sich diese geheimen Schlüssel in vielen verschiedenen Konfigurationsdateien und Konfigurationsspeichern. Ü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 Konfigurationsdaten in mehreren Dokumenten in einer kaskadierenden Hierarchie von Verzeichnissen. Die meisten Konfigurationsdokumente weisen XML-Inhalte auf. Weitere Informationen finden Sie unter Konfigurationsdokumente und grundlegende Konzepte von Azure Key Vault.

Nachdem Sie über ein solides Inventar von Geheimnissen verfügen, wenden Sie sich an die Betreiberdokumentation zu Geheimnissen. 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 mithilfe der folgenden Artikel:

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

Die Verwendung von Liberty erfordert eine bestimmte Version von Java, daher müssen Sie bestätigen, dass Ihre Anwendung ordnungsgemäß mit dieser unterstützten Version ausgeführt wird.

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

Open Liberty erfordert eine Java SE-Laufzeit. Sie kann entweder mit einer Java Runtime Environment (JRE) oder einer Java SE Development Kit (JDK)-Verteilung ausgeführt werden. Weitere Informationen finden Sie in unterstützten 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 in der IBM-Dokumentation unter WebSphere Data Sources . 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 Verwenden von JMS-Ressourcen.

Wenn Sie das vordefinierte Azure Marketplace-Angebot verwenden, ist die Gruppe der JNDI-Ressourcen, die Sie zur Bereitstellungszeit anpassen können, auf das beschränkt, was das Angebot unterstützt. 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 Developing with the JNDI default namespace in a Liberty feature. Informationen zu Open Liberty finden Sie unter Java Naming and Directory Interface.

Überprüfen Der Profilkonfiguration

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

Innerhalb Ihrer Anwendung

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

Sie müssen diese Anpassungen im Containerimage erfassen, das von AKS ausgeführt wird. Wenn Sie das vorgefertigte Azure Marketplace-Angebot verwenden, werden solche Anpassungen am besten behandelt, indem sie ein benutzerdefiniertes Containerimage erstellen und in einer öffentlichen Registrierung verfügbar machen und dann zur Bereitstellungszeit auf diese Registrierung verweisen.

Wenn Sie eine WebSphere Application Server Network Deployment Cell verwenden, wird jedes Clustermitglied in einer Installation herkömmlicher WAS ausgeführt. Liberty ist ein einfaches Profil von WebSphere Application Server. Es ist ein flexibles und dynamisches Profil von WAS, das es dem WAS-Server ermöglicht, nur erforderliche benutzerdefinierte Features bereitzustellen, anstatt eine große Menge verfügbarer Java EE-Komponenten bereitzustellen.

Ermitteln, ob die Sitzungsreplikation verwendet wird

Wenn Ihre Anwendung auf der Sitzungsreplikation basiert, haben Sie die folgenden Optionen:

  • Bei HTTP-Sitzungen können Sie gemäß sitzungsverwaltungsebene den Cache oder eine Datenbank verwenden, um Sitzungsdaten zu sammeln.
  • Bei verteilten Sitzungen können Sie Sitzungen in einer Datenbank mithilfe der Persistenz der Datenbanksitzung speichern.
  • Für den dynamischen Cache können Sie Sitzungsdaten im Cache oder in einer Datenbank verwalten.
  • Sie können Ihre Anwendung so umgestalten, dass sie eine Datenbank für die Sitzungsverwaltung verwendet.
  • Sie können Ihre Anwendung umgestalten, um die Sitzung in Azure Redis Service zu externalisieren. Weitere Informationen finden Sie unter Azure Cache for Redis.

Für alle diese Optionen ist es ratsam, zu meistern, wie Liberty die HTTP-Sitzungsstatusreplikation durchführt. Die folgenden Dokumente helfen Ihnen zu verstehen, wie HTTP-Sitzungen in Liberty verwaltet werden:

Das vorgefertigte Azure Marketplace-Angebot unterstützt die Sitzungsaffinität über den Anwendungsgateway-Eingangscontroller. Wählen Sie bei der Bereitstellung des Angebots die Option "Cookiebasierte Affinität aktivieren" aus.

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 WAS finden Sie unter VERWENDUNG VON DRIVER Drivers mit WebSphere Application Server.

DIE KONFIGURATION DES SERVERS ist eine Kernserverkonfiguration in Liberty. Weitere Informationen finden Sie unter DRIVER DRIVER.

Das vorgefertigte Azure Marketplace-Angebot bietet eingeschränkten Support für Datenbanken. Sie können die Konfiguration in den Anwendungsimages behandeln 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 Skripts gehören wsadmin, AdminControl, AdminConfig, AdminApp und AdminTask.
  • Werden an JVM spezifische Parameter übergeben?
  • Werden dem Klassenpfad des Servers JAR-Dateien hinzugefügt?
  • Wurden Anlagen auf Betriebssystemebene verwendet, um systemd zu bewirken, dass WAS-Komponenten nach einem Serverneustart automatisch gestartet werden?

Je nach Antworten auf diese Fragen müssen Sie Überlegungen zur Migration berücksichtigen.

Sie müssen diese Anpassungen im Containerimage erfassen, das von AKS ausgeführt wird. Wenn Sie das vorgefertigte Azure Marketplace-Angebot verwenden, werden solche Anpassungen am besten behandelt, indem sie ein benutzerdefiniertes Containerimage erstellen und in einer öffentlichen Registrierung verfügbar machen und dann zur Bereitstellungszeit auf diese Registrierung 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 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, müssen Sie sie zu einem extern gehosteten JMS-Server migrieren. Eine Strategie für diejenigen, die JMS verwenden, ist die Verwendung von Azure Service Bus und das Advanced Message Queuing-Protokoll. Weitere Informationen finden Sie unter Verwenden von Java Message Service (JMS) mit Azure Service Bus und AMQP 1.0.

Wenn Sie beständige JMS-Speicher konfiguriert haben, müssen Sie deren Konfiguration erfassen und nach der Migration anwenden.

Wenn Sie IBM MQ verwenden, können Sie diese Software auf virtuelle Azure-Computer migrieren und wie sie verwenden.

Microsoft verfügt über eine Lösung zur Integration von IBM MQ in 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 den gleichen Techniken behandeln, wie unter "Zugreifen auf Drittanbieter-APIs aus einer Java EE-Anwendung" beschrieben.

Ermitteln, ob OSGi-Pakete verwendet werden

Wenn Sie OSGi-Bündel 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 Bündel in das Image einschließen, das dem vorgefertigten Azure Marketplace-Angebot bereitgestellt wird. Weitere Informationen finden Sie unter Konfigurieren 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 ggf. alle Vorkommen von / oder \ in Dateisystempfaden durch File.Separator oder Paths.get ersetzen.

Liberty auf AKS läuft unter Linux x86_64. Jeder betriebssystemspezifische Code muss mit Linux kompatibel sein. Wenn Sie erfahren möchten, wie Sie bestimmte Betriebssysteminformationen ermitteln, führen Sie die Schritte im Abschnitt "Ermitteln, ob die Liberty-Version kompatibel ist" aus.

Ermitteln, 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 in der Dokumentation zu IBM Integration Bus.

IBM Integration Bus wird im vorgefertigten Azure Marketplace-Angebot nicht direkt unterstützt. Um das Feature zu aktivieren, befolgen Sie die Anweisungen unter Aktivieren der JMS-Anwendung auf Liberty, um eine Verbindung mit dem Serviceintegrationsbus in der IBM-Dokumentation herzustellen.

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", "ibm-application-bnd.xmi" und "ibm-application-ext.xmi ", und erfassen Sie ihre Konfigurationen. Weitere Informationen finden Sie unter Building the Enterprise Archive (EAR) package on WebSphere.

Mit dem vorgefertigten Azure Marketplace-Angebot können Sie ein vorhandenes Containerimage 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 beschäftigt sich mit Dateisystemen mit persistenten Volumes (PV). Das Einbinden persistenter Volumes wird im vorgefertigten Azure Marketplace-Angebot nicht unterstützt. Um verschiedene Speicheroptionen zu aktivieren, befolgen Sie die Anweisungen unter "Speicheroptionen für Anwendungen in Azure Kubernetes Service".

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.

Ermitteln der Netzwerktopologie

Die aktuelle Gruppe von Azure Marketplace-Angeboten ist ein Ausgangspunkt für Ihre Migration. Wenn das Angebot keine Aspekte Ihrer Architektur abdeckt, die Sie migrieren müssen, müssen Sie die Netzwerktopologie Ihrer vorhandenen 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 breites Thema, aber die folgenden Verweise können Ihren Migrationsbemühungen eine Richtung geben:

Berücksichtigen der 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 AKS ausgeführt wird. Weitere Informationen finden Sie unter Übersicht über JCA-Konfigurationselemente und Java Verbinden or-Architektur.

Ermitteln, ob Clustering verwendet wird

Der Operator behandelt clustering für alle möglichen Arten der Ausführung von WAS-Workload auf AKS.

Überprüfen des EJB-Clusterings

Wenn Ihre Anwendung lokale Enterprise Java Beans (EJB) verwendet, müssen Sie sie möglicherweise zu einem gruppierten EJB migrieren. Weitere Informationen finden Sie unter Developing EJB applications on Liberty.

Konto für Lastenausgleichsanforderungen

Die beste Möglichkeit zum Berücksichtigen des Lastenausgleichs ist die Verwendung der App-Gateway-Integration, die vom integrierten Azure Marketplace-Angebot bereitgestellt wird.

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

Um das Angebot im Azure-Portal zu öffnen, lesen Sie IBM WebSphere Liberty und Open Liberty auf Azure Kubernetes Service. Wählen Sie "Erstellen" aus, und verwenden Sie dann die informationen, die Sie in den vorherigen Schritten gesammelt haben, um die Felder des Angebots auszufüllen.

Berücksichtigen von Keystores

Sie müssen die Migration aller 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 die Anweisungen unter "Overview of JCA configuration elements " in der IBM-Dokumentation befolgen.

Berücksichtigen der Protokollierung

Sie können keine Cloud ohne Masterprotokollierung ausführen. Der Operator bietet verschiedene Ansätze für die Überwachung. Weitere Informationen finden Sie unter Monitoring the Liberty server runtime environment. Wenn Sie die Verwendung von Elastic Stack bevorzugen, bietet Azure eine hervorragende Unterstützung für Elastic. Ausführliche Informationen finden Sie unter Was ist die elastic Integration in Azure? Sie können das Wissen in diesen beiden Ressourcen kombinieren, um eine azure-optimierte Protokollierungslösung für Liberty auf AKS zu erreichen.

Migrieren Ihrer Anwendungen

Unabhängig davon, ob Sie zur Bereitstellungszeit ein Anwendungsimage bereitstellen möchten, müssen Sie die Anwendung über CI/CD aktualisieren. Die IBM-Dokumentation enthält ein Beispiel, das zeigt, wie dieses Update ausgeführt wird. Weitere Informationen finden Sie unter Bereitstellen von Anwendungen in Liberty.

Konfigurieren von Tests

Sie müssen alle In-Container-Tests für Anwendungen konfigurieren, um auf die neuen Server zuzugreifen, die in Azure ausgeführt werden. Wie bei den CI/CD-Bedenken müssen Sie sicherstellen, dass die erforderlichen Netzwerksicherheitsregeln Ihren Tests den Zugriff auf die in Azure bereitgestellten Anwendungen ermöglichen. 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. Die folgenden Artikel enthalten Informationen zu Verbesserungen nach der Migration: