Migrieren von WebLogic Server-Anwendungen zu Azure Kubernetes Service

  • Artikel

In diesem Handbuch wird beschrieben, was Sie beachten sollten, wenn Sie eine vorhandene WebLogic Server (WLS)-Anwendung migrieren möchten, die auf Azure Kubernetes Service (AKS) 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 WLS-Anwendung zu Azure ist die Auswahl des am besten geeigneten Migrationsziels. WLS wird gut auf virtuellen Azure-Computern (VMs) oder Azure Kubernetes Service (AKS) 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 sehr dem, was Sie lokal haben. 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 AKS höher. Während eine AKS-basierte Lösung weniger ausgeführt werden kann, müssen Sie ihre Anwendung auf die Anforderungen von AKS 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 WebLogic-Anwendungen zu virtuellen Azure-Computern. Wenn Sie die Konvertierung Ihrer Anwendung in Kubernetes tolerieren können, um die Laufzeitkosten zu reduzieren, sollten Sie eine AKS-basierte Migration in Betracht ziehen. Fahren Sie in diesem Fall mit der Migration von WebLogic Server-Anwendungen zu Azure Kubernetes Service fort.

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

Nachdem Sie entschieden haben, dass AKS das entsprechende Bereitstellungsziel ist, müssen Sie akzeptieren, dass der Oracle WLS Kubernetes-Operator (der Operator) die einzige Möglichkeit ist, WLS 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.

  • Oracle und Microsoft haben dieses Angebot erstellt, um Ihnen die schnelle Bereitstellung von WLS auf AKS mithilfe des Modells in Image do Standard Home Source Type zu ermöglichen. Dieses Konzept wird weiter unten in diesem Artikel ausführlicher erläutert.
  • Auf hoher Ebene automatisiert das Angebot die folgenden Schritte für Sie.
    • Nehmen Sie bei Bedarf eine vorhandene WAR- oder EAR-Bereitstellung.
    • Schließen Sie ihn in einen Container mit dem WebLogic Image Tool (WIT) um. Weitere Informationen finden Sie unter WebLogic Image Tool in der Oracle-Dokumentation.
    • Installieren und konfigurieren Sie den WebLogic Kubernetes-Operator auf AKS.
    • Verwenden Sie den Operator, um das Ganze auszuführen. Der Operator ruft WebLogic Deploy Tooling (WDT) auf, um WebLogic-Umgebungen stand up zu stehen, und führt do Standard Lebenszyklusvorgänge auf einer wiederholbaren Weise basierend auf einem Metadatenmodell aus. Weitere Informationen finden Sie in der Oracle-Dokumentation unter WebLogic Deploy Tooling .
  • Obwohl das vorgefertigte Angebot zahlreiche Azure-Dienstintegrationen wie App-Gateway, Elastic Logging, Datenbankintegration und vieles mehr bietet, macht es viele vereinfachende Annahmen. Diese Annahmen machen das Angebot nicht so flexibel wie Mastering und Nutzung des Betreibers selbst.

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 WLS Kubernetes Operator steht bei Oracle zur Verfügung.

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.

Zunächst müssen Sie das Konzept der WLS "do Standard" verstehen. Eine Do Standard ist eine logisch verwandte Gruppe von WLS-Ressourcen. Die kanonische Definition von WLS do Standard finden Sie in der Oracle-Dokumentation. Wenn Sie WLS auf AKS ausführen, müssen Sie entscheiden, wie AKS damit umgeht Standard s. Die verschiedenen Auswahlmöglichkeiten werden als "do Standard Home Source Type" bezeichnet. Der WLS Kubernetes-Operator unterstützt drei Auswahlmöglichkeiten des Startquellentyps Standard. Das vorgefertigte Azure Marketplace-Angebot verwendet die erste in dieser Tabelle.

Do Standard Startquelltyp Beschreibung Positive Aspekte Negative Aspekte
Modell in Bild WLS und Anwendungen befinden sich im Containerimage, und alles andere wird außerhalb dieses Images gespeichert. Unterstützt durch vorgefertigtes Angebot. Als offizielle Stichprobe dokumentiert; siehe Oracle. Die meisten verwenden WDT. Die meisten "cloudnativ" Option. Einfachste CI/CD-Integration. Größte Lernkurve.
Do Standard in PV Die Do Standard befindet sich auf einem kubernetes persistenten Volume. Konzeptionell ähnlich der Ausführung auf virtuellen Computern. Sie können die WLS-Konsole verwenden, um Änderungen vorzunehmen, und diese Änderungen bleiben über AKS-Podneustarts bestehen. Als offizielle Stichprobe dokumentiert; siehe Oracle. Einige Herausforderungen im Zusammenhang mit NFS müssen abgemildert werden. Weitere Informationen finden Sie unter Oracle. Dieser Ansatz ist die geringste "cloudnativ"-Technik; der Zustand befindet sich vollständig außerhalb des AKS-Clusters.
Do Standard in Image Die Do Standard befindet sich in einem Containerimage. Anwendungen sind in einem Containerimage enthalten, das im Do Standard Image überlagert ist. Mehr "cloudnativ" als Do Standard in PV. Einfacher für CI/CD. WLS-Konsole kann nicht verwendet werden. Muss weitere Containerimages Standard enthalten.

Wichtig

Wenn Sie "Do Standard" im PV-Quelltyp auswählen, empfehlen wir DRINGEND NFS anstelle von SMB. NFS entwickelte sich aus dem UNIX-Betriebssystem und anderen Varianten wie GNU/Linux. Aus diesem Grund ist es bei der Verwendung von NFS mit Containertechnologien wie Docker weniger wahrscheinlich, Probleme mit gleichzeitigen Lesevorgängen und Dateisperrungen zu haben.

Achten Sie darauf, NFS v4.1 zu aktivieren. Versionen unter v4.1 haben Probleme.

Die Operatordokumentation enthält auch eine nützliche Tabelle, die die verschiedenen Optionen vergleicht. Weitere Informationen finden Sie unter Auswählen einer Do Standard Home Source Type.

Um ein Gefühl für das vorgefertigte Azure Marketplace-Angebot zu erhalten, lesen Sie die Schnellstartanleitung: Bereitstellen von WebLogic Server auf Azure Kubernetes Service mit dem Azure-Portal. Die Referenzdokumentation zum vorgefertigten Azure Marketplace-Angebot finden Sie unter Oracle.

Um ein Gefühl für die direkte Nutzung des Operators zu erhalten, probieren Sie die Beispiele in der Operatordokumentation aus.

Nachdem Sie nun mit den verschiedenen Möglichkeiten für die Behandlung von WLS Standard s auf AKS eingeführt wurden, können Sie besser auswählen, ob Sie das vordefinierte Azure Marketplace-Angebot verwenden oder es selbst mit dem Betreiber direkt erledigen möchten.

Ermitteln, ob die WebLogic-Version kompatibel ist

Die vorhandene WLS-Version muss eine der vom Operator unterstützten Versionen sein. Oracle Standard enthält diese Versionen in der Oracle Container Registry (OCR). Führen Sie die folgenden Schritte aus, um die Liste der unterstützten Versionen anzuzeigen.

  1. Besuchen Sie die Oracle Container Registry-Website, und melden Sie sich an. Weitere Informationen finden Sie unter https://container-registry.oracle.com/.
  2. Wenn Sie über eine Supportberechtigung verfügen, wählen Sie Middleware aus, und suchen Sie dann nach weblogic_cpu. Wählen Sie weblogic_cpu aus.
  3. Wenn Sie keine Supportberechtigung von Oracle haben, wählen Sie Middleware aus, und suchen Sie dann nach Weblogic. Wählen Sie "weblogic" aus.

Hinweis

Erwerben Sie eine Supportberechtigung von Oracle, bevor Sie in die Produktionsumgebung wechseln. Andernfalls, sind Ihre ausgeführten Images nicht sicher und erhalten keine Patches zur Beseitigung kritischer Sicherheitsfehler. Weitere Informationen zu den kritischen Patchupdates von Oracle finden Sie unter Kritische Patchupdates, Sicherheitswarnungen und Bulletins.

Mit dem vorgefertigten Azure Marketplace-Angebot können Sie die WLS-Images aus OCR und Azure Container Registry (ACR) auswählen und somit implizit alle verfügbaren Versionen von OCR unterstützen. Wenn Sie das Angebot leiten, ein Bild von ACR abzurufen, stellen Sie sicher, dass es von einer der unterstützten Versionen abgeleitet ist, die in OCR aufgeführt sind.

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, z. B. WebLogic Server, 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. Sehen Sie in der Datei weblogic.xml in Ihren WARs nach. 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 Geheimnissen verfügen, wenden Sie sich an die Betreiberdokumentation zu Geheimnissen. Weitere Informationen finden Sie unter Geheimnisse.

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 direkt mit dem vorgefertigten Azure Marketplace-Angebot installieren. Weitere Informationen finden Sie unter TLS/SSL-Konfiguration. Wenn Sie den Operator direkt verwenden, lesen Sie externe Zertifikate des Aktualisierungsoperators.

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

Für alle Migrationspfade für WebLogic zu Azure wird eine bestimmte Java-Version benötigt, die für jeden Pfad variiert. Sie müssen überprüfen, ob Ihre Anwendung mit dieser unterstützten Version richtig 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

Hinweis

Bei der Migration zu WLS auf virtuellen Azure-Computern werden die Anforderungen für die spezifischen Java-Versionen von der vorinstallierten Java-Version auf den virtuellen Computern bestimmt. Bei der Migration zu WLS auf AKS wird die spezifische Java-Version durch das ausgewählte Containerimage bestimmt. Es gibt eine Vielzahl von Auswahlmöglichkeiten, aber alle verwenden oracle JDK.

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 Oracle-Dokumentation unter WebLogic Server-Datenquellen. 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 Oracle WebLogic Server 12.2.1.4.0.

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. Suchen Sie in der Angebotsdokumentation nach JNDI. Wenn Sie den Operator direkt verwenden, können die JDNI-Ressourcen abhängig von Ihrer ausgewählten Do-Methode definiert werden Standard Startquelltyp. Für Do Standard in PV können Sie sie auf die übliche Weise festlegen, mit WLST oder mit der Administratorkonsole. Informationen zu Do Standard in Image oder Model in Image finden Sie unter Typische Außerkraftsetzungen.

Untersuchen der Domänenkonfiguration

Die Hauptkonfigurationseinheit in WebLogic Server ist die Domäne. Daher enthält die Datei config.xml viele Konfigurationsinformationen, die Sie bei der Migration sorgfältig berücksichtigen müssen. Die Datei enthält Verweise auf zusätzliche XML-Dateien, die in Unterverzeichnissen gespeichert sind. Oracle rät dazu, wie gewohnt die Verwaltungskonsole zu verwenden, um die verwaltbaren Objekte und Dienste von WebLogic Server zu konfigurieren, und WebLogic Server die Verwaltung der Datei config.xml zu überlassen. Weitere Informationen finden Sie unter Domänenkonfigurationsdateien.

Innerhalb Ihrer Anwendung

Untersuchen Sie die Datei WEB-INF/weblogic.xml bzw. WEB-INF/web.xml.

Das vorgefertigte Azure Marketplace-Angebot erstellt automatisch eine Do Standard Ressource. Wenn Sie den Operator direkt verwenden, können Sie die Vorgehensweise vollständig anpassen Standard dargestellt wird. Vollständige Informationen finden Sie unter Do Standard Ressource.

Ermitteln, ob die Sitzungsreplikation verwendet wird

Wenn für Ihre Anwendung die Sitzungsreplikation benötigt wird, haben Sie drei Optionen (mit oder ohne Oracle Coherence*Web):

  • Coherence*Web kann auf den virtuellen Azure-Computern neben WebLogic Server ausgeführt werden, aber Sie müssen diese Option manuell konfigurieren, nachdem Sie das Angebot bereitgestellt haben. Falls Sie Coherence allein nutzen, können Sie die Anwendung auch auf einem virtuellen Azure-Computer ausführen, aber Sie müssen diese Option nach der Bereitstellung des Angebots manuell konfigurieren.
  • 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.

Bei all diesen Optionen ist es ratsam, sich damit vertraut zu machen, wie von WebLogic die Replikation des HTTP-Sitzungsstatus durchgeführt wird. Weitere Informationen finden Sie in der Oracle-Dokumentation unter Replikation des HTTP-Sitzungsstatus.

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. Suchen Sie in der Dokumentation nach cookiebasierter Affinität für das Angebot.

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 JDBC-Treibern in WebLogic finden Sie unter Verwenden von JDBC-Treibern mit einem WebLogic-Server.

Das vorgefertigte Azure Marketplace-Angebot bietet Unterstützung für die beliebtesten Datenbanken. Weitere Informationen finden Sie unter "Datenbank". Für Do Standard in PV können Sie sie auf die übliche Weise festlegen, mit WLST oder mit der Administratorkonsole. Informationen zu Do Standard in Image oder Model in Image finden Sie unter Typische Außerkraftsetzungen.

Ermitteln, ob WebLogic angepasst wurde

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

  • Wurden die Startskripts geändert? Zu diesen Skripts gehören setDomainEnv, commEnv, startWebLogic und stopWebLogic.
  • Werden an JVM spezifische Parameter übergeben?
  • Werden dem Klassenpfad des Servers JAR-Dateien hinzugefügt?

Sie müssen diese Anpassungen im Containerimage erfassen, das von AKS ausgeführt wird. Für das vorgefertigte Azure Marketplace-Angebot werden solche Anpassungen am besten behandelt, indem ein benutzerdefiniertes Containerimage erstellt und in der Azure-Containerregistrierung verfügbar ist und dann zur Bereitstellungszeit auf diese Registrierung verweist. Weitere Informationen finden Sie unter "Bildauswahl". Wenn Sie den Operator direkt verwenden, lesen Sie JVM-Speicher- und Java-Optionsumgebungsvariablen.

Ermitteln, ob die Verwaltung per REST verwendet wird

Wenn der Lebenszyklus Ihrer Anwendung die Nutzung der Verwaltung per REST (Management over REST) umfasst, müssen Sie erfassen, welche Ports zum Zugreifen auf die REST-API verwendet werden. Darüber hinaus müssen Sie ermitteln, wie sie authentifiziert und verfügbar gemacht werden. Nach der Migration müssen Sie sicherstellen, dass die gleichen Ports und Authentifizierungsmechanismen verfügbar gemacht werden, damit Ihr Anwendungslebenszyklus auf ähnliche Weise wie vor der Migration ablaufen kann. Weitere Informationen finden Sie unter Verwalten von Oracle WebLogic Server mit RESTful-Verwaltungsdiensten.

Die einzige do Standard Home Source Type, wo es sinnvoll ist, die Verwaltung über REST weiterhin zu nutzen, ist Do Standard in PV. Es ist möglich, sie mit den anderen do Standard Home Source-Typen zu verwenden, aber vorgenommene Änderungen sind kurzlebig und bleiben nicht über Pod-Neustarts hinweg bestehen.

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 nutzt, müssen Sie diese 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.

Bei Verwendung von Oracle Message Broker können Sie diese Software zu virtuellen Azure-Computern migrieren und unverändert verwenden.

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.

Diese Bibliotheken können mit den gleichen Techniken wie in "Bestimmen" beschrieben werden, ob WebLogic angepasst wurde.

Ermitteln, ob OSGi-Pakete verwendet werden

Wenn Sie dem WebLogic-Server hinzugefügte OSGi-Pakete verwendet haben, müssen Sie die entsprechenden JAR-Dateien direkt Ihrer Webanwendung hinzufügen.

Sie können sie in das war- oder EAR-Angebot einschließen, das dem vorgefertigten Azure Marketplace-Angebot bereitgestellt wird, oder den Betreiber direkt verwenden.

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.

WLS auf AKS wird unter Oracle Linux ausgeführt. Jeder betriebssystemspezifische Code muss mit Oracle Linux kompatibel sein. Um zu erfahren, wie Sie bestimmte Betriebssysteminformationen ermitteln, führen Sie die Schritte unter "Ermitteln" aus, ob die WebLogic-Version kompatibel ist.

Ermitteln, ob Oracle Service Bus verwendet wird

Wenn Ihre Anwendung Oracle Service Bus (OSB) verwendet, müssen Sie erfassen, wie OSB konfiguriert ist. Weitere Informationen finden Sie unter Informationen zur Installation von Oracle Service Bus.

OSB wird im vorgefertigten Azure Marketplace-Angebot nicht direkt unterstützt. Wenn Sie OSB verwenden müssen, müssen Sie den Operator direkt verwenden.

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

Ist Ihre Anwendung als EAR-Datei gepackt, sehen Sie sich unbedingt die Dateien application.xml und weblogic-application.xml an, und erfassen Sie deren Konfigurationen.

Das vorgefertigte Azure Marketplace-Angebot unterstützt WARs und EARs. Der Einsatz des Operators unterstützt auch WARs und EARs direkt.

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 das WebLogic-Skriptingtool (WLST) verwendet wird

Wenn Sie derzeit das WLST für die Bereitstellung verwenden, müssen Sie sich mit den Vorgängen von WLST auseinandersetzen. Werden im Rahmen der Bereitstellung (Laufzeit-)Parameter Ihrer Anwendung vom WLST geändert, müssen Sie sicherstellen, dass dieses Verhalten auch beim Testen der Anwendung nach der Migration funktioniert.

Der einzige do Standard Home Source-Typ, der mit der Verwendung von WLST kompatibel ist, ist Do Standard in PV. Weitere Informationen finden Sie unter Do Standard Home on a PV.

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 und bei direkter Verwendung des Operators unterstützt. Wenn Sie Do Standard in PV verwenden, ist das Dateisystem ein zentraler Aspekt der Konfiguration.

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. Falls durch das Angebot Bereiche Ihrer Architektur, die Sie migrieren müssen, nicht abgedeckt sind, müssen Sie die Netzwerktopologie Ihrer vorhandenen Bereitstellung erfassen und in Azure reproduzieren. Dies gilt auch, wenn Sie das grundlegende Angebot mit einer der Lösungsvorlagen in Anspruch genommen haben.

Dies ist ein sehr umfangreiches Thema, aber unter den folgenden Referenzthemen erhalten Sie einige Informationen zur Vorgehensweise bei der Migration:

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

Wenn Ihre Bereitstellung von Ressourcenadaptern abhängt, ist die am häufigsten unterstützte Option "Do Standard Home on a PV.

Konto für die Verwendung von benutzerdefinierten Sicherheitsanbietern und JAAS

Stellen Sie bei Verwendung von JAAS durch Ihre Anwendung sicher, dass die Konfiguration der Sicherheitsanbieter ordnungsgemäß migriert wird. Weitere Informationen finden Sie in der Oracle-Dokumentation unter Informationen zum Konfigurieren von WebLogic-Sicherheitsanbietern.

Wenn Ihre Bereitstellung Sicherheitsanbieter nutzt, ist die am häufigsten unterstützte Option "Do Standard Home on a PV.

Ermitteln, ob das WebLogic-Clustering genutzt wird

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

Überprüfen des EJB-Clusterings

Wenn Ihre Anwendung lokale EJB verwendet, müssen Sie sie zu gruppierten EJB migrieren. Weitere Informationen finden Sie unter Clustered versus local EJB.

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. Weitere Informationen finden Sie im Lernprogramm: Migrieren eines WebLogic Server-Clusters zu Azure mit Azure-App lizenzierungsgateway als Lastenausgleichsmodul.

Ermitteln, ob die Java EE-Anwendungsclientfunktion verwendet wird

Wenn Ihre Bereitstellung auf Java EE-Anwendungsclients basiert, empfiehlt es sich, den Operator direkt zu verwenden. Weitere Informationen finden Sie unter "Externe Clients".

Ermitteln, ob mehrere Containerimages erforderlich sind

Ein WebLogic Server-Do Standard kann mehrere Cluster enthalten. Beispielsweise kann eine mehrstufige Anwendung in einer einzigen Do dargestellt werden Standard, aber zwei Cluster haben, sagen "frontend" und "Back-End". Es ist nützlich, das Frontend zu aktualisieren, ohne das Back-End zu aktualisieren und umgekehrt. Mit dem Modell in Image do Standard Home Source Type wird jedoch der gesamte Do Standard in einem Containerimage dargestellt. Um diesen Anwendungsfall zu berücksichtigen, müssen Sie die Cluster in ihre eigenen Aufgaben unterteilen Standard mit jeweils einem eigenen Containerimage. Der Operator kann mehrere Do Standard s in mehreren Namespaces verwalten. Weitere Informationen finden Sie unter Auswählen einer Do Standard Namespaceauswahlstrategie

Durch die Übernahme mehrerer Do Standard können T3-Zugriffsprobleme zwischen do Standard s auftreten. Um diese Probleme zu beheben, aktivieren Sie einen benutzerdefinierten Kanal, wie unter " Ermitteln" beschrieben, ob ein unbekannter Hostzugriff erforderlich ist.

Ermitteln, ob das Aktivieren des unbekannten Hostzugriffs erforderlich ist

Möglicherweise müssen Sie den unbekannten Hostzugriff aktivieren, indem Sie einen Patch auf WebLogic für die folgenden Szenarien anwenden:

  • Zulassen des T3-Zugriffs von externen Clients außerhalb von AKS auf WLS-Cluster in AKS über einen benutzerdefinierten Kanal.
  • T3-Zugriff zwischen verschiedenen WLS ermöglichen Standard s in AKS über einen benutzerdefinierten Kanal.

Für die Details des Patches befolgen Sie die Anleitungen in how to Use the Patch Search in My Oracle Support(MOS), und suchen Sie nach Patch 30656708.

Nachdem der Patch angewendet wurde, lesen Sie das Aktivieren des unbekannten Hostzugriffs.

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 in der Azure-Portal finden Sie unter https://aka.ms/wlsaks. Wählen Sie "Erstellen" aus, und folgen Sie dann den Anweisungen in der Dokumentation für das Angebot. Verwenden Sie die informationen, die Sie in den vorherigen Schritten gesammelt haben, um die Felder des Angebots auszufüllen.

Migrieren der Domänen

Nachdem Sie das Angebot bereitgestellt haben, geben Sie die Aktion aus Standard indem Sie die folgenden Schritte ausführen.

Wenn Sie die Seite "Bereitstellung " verlassen haben, zeigen ihnen die folgenden Schritte, wie Sie zu dieser Seite zurückkehren. Wenn Sie sich noch auf der Seite befinden, auf der die Bereitstellung angezeigt wird, können Sie mit Schritt 5 fortfahren.

  1. Wählen Sie oben links auf einer beliebigen Portalseite das Hamburger-Menü und dann Ressourcengruppen aus.

  2. Geben Sie in das Feld mit dem Text nach beliebigem Feld filtern die ersten Buchstaben der zuvor erstellten Ressourcengruppe ein. Wenn Sie der empfohlenen Konvention gefolgt sind, geben Sie Ihre Initialen ein und wählen Sie dann die entsprechende Ressourcengruppe aus.

  3. Wählen Sie im linken Navigationsbereich im Abschnitt Einstellungen Bereitstellungen aus, um eine sortierte Liste der Bereitstellungen für diese Ressourcengruppe mit der letzten anzuzeigen.

  4. Scrollen Sie zum ältesten Eintrag in dieser Liste. Dieser Eintrag entspricht der Bereitstellung, die Sie im vorherigen Abschnitt gestartet haben. Wählen Sie die älteste Bereitstellung aus, wie im folgenden Screenshot dargestellt.

    Screenshot of Azure portal showing the resource group deployments list.

  5. Wählen Sie im linken Panel Ausgaben aus. In dieser Liste werden die Ausgabewerte der Bereitstellung angezeigt. Die Ausgaben enthalten hilfreiche Informationen. Wir interessieren uns für die Ausgaben, die es uns ermöglichen, die Do Standard zu prüfen und mit dem Operator zu interagieren. Die anderen Werte in den Ausgaben werden im WebLogic on AKS User Guide ausführlich erläutert.

  6. Suchen Sie die Ausgabe mit dem Namen shellCmdtoConnectAks. Fügen Sie den Wert der Ausgabe in eine Bash-Shell ein, und führen Sie den Befehl aus. Mit diesem Befehl können Sie wie in Verbinden beschriebenen Befehl für den Cluster verwendenkubectl.

  7. Suchen Sie die Ausgabe mit dem Namen shellCmdtoOutputWlsDomainYaml. Fügen Sie den Wert der Ausgabe in eine Bash-Shell ein, und führen Sie den Befehl aus. Mit diesem Befehl wird die Do Standard ressource als YAML-Datei ausgegeben.

  8. Nachdem Sie nun über die do Standard YAML der aktuellen Bereitstellung verfügen, können Sie das Wissen in der Bereitstellung von YAML-Dateien anwenden Standard Ressourcen-YAML-Dateien und lesen Sie diesen Leitfaden, um weitere Hinweise zur Migration der Aufgaben zu erhalten Standard s. Diese Anleitung erfordert Anpassungen, um auf die Kubernetes-Art der Dinge anzuwenden, aber es ist immer noch nützlich, etwas zu wissen.

Berücksichtigen von Keystores

Sie müssen die Migration der SSL-Keystores berücksichtigen, die von Ihrer Anwendung verwendet werden. 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 in der WebLogic-Dokumentation die Anleitung unter Fusion Middleware: Verwalten von JMS-Ressourcen für Oracle WebLogic Server befolgen.

Berücksichtigen der Protokollierung

Sie können keine Cloud ohne Masterprotokollierung ausführen. Der Operator stellt Beispiele für die Verwendung von Elasticsearch und Kibana bereit. Weitere Informationen finden Sie in der Operatordokumentation. Azure bietet 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 azureoptimierte Protokollierungslösung für WLS auf AKS zu erreichen.

Migrieren Ihrer Anwendungen

Unabhängig davon, ob Sie sich entschieden haben, eine WAR- oder EAR-Datei zur Bereitstellungszeit bereitzustellen, müssen Sie die Anwendung über CI/CD aktualisieren. Die Operatordokumentation enthält ein Beispiel, das zeigt, wie Sie dieses Update ausführen. Weitere Informationen finden Sie unter Update 3. Die anderen Updatebeispiele sind für die Migration relevant und lohnt sich.

Testen

Alle containerinternen Tests von Anwendungen müssen so konfiguriert werden, dass auf die neuen Server zugegriffen wird, die in Azure ausgeführt werden. Wie bei CI/CD auch, müssen Sie sicherstellen, dass für Ihre Tests gemäß den erforderlichen Netzwerksicherheitsregeln der Zugriff auf die Anwendungen möglich ist, die in Azure bereitgestellt werden. 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. Anleitungen zu einigen potenziellen Verbesserungen nach der Migration finden Sie in den folgenden Empfehlungen: