Freigeben über

Migrieren von WebLogic Server-Anwendungen zu Azure Kubernetes Service (AKS)

  • Artikel

Diese Anleitung beschreibt, was Sie beachten sollten, wenn Sie eine bestehende WebLogic Server (WLS)-Anwendung auf Azure Kubernetes Services (AKS) ausführen 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 WLS-Anwendung zu Azure ist die Auswahl des am besten geeigneten Ziels für die Migration. WLS lässt sich gut auf Azure Virtual Machines (VMs) oder Azure Kubernetes Service (AKS) ausführen. Das VM-Ziel ist die einfachste Wahl, da es einer on-premises Bereitstellung am nächsten kommt. Die Verwaltung und Bereitstellung virtueller Maschinen erfolgt ganz analog zu dem, was Sie on-premises haben. Der Kompromiss für diese Erleichterung sind die wirtschaftlichen Kosten. Allgemein gesprochen sind die Kosten pro Minute für eine VM-basierte Lösung höher als für AKS. Eine AKS-basierte Lösung kostet zwar weniger beim Ausführen, aber Sie müssen Ihre Anwendung so einschränken, dass sie in die Anforderungen von AKS passt. Wenn die Minimierung von Änderungen der wichtigste Faktor für Ihre Migrationsbemühungen ist, sollten Sie eine VM-basierte Migration in Betracht ziehen. Lesen Sie in diesem Fall WebLogic-Anwendungen auf Azure Virtual Machines migrieren. Wenn Sie tolerieren können, dass Ihre Anwendung innerhalb von Kubernetes ausgeführt wird, um die Laufzeitkosten zu senken, sollten Sie eine AKS-basierte Migration in Betracht ziehen. In diesem Fall fahren Sie fort mit WebLogic Server-Anwendungen zu Azure Kubernetes Service migrieren.

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

Sobald Sie entschieden haben, dass AKS das geeignete Ziel für die Bereitstellung ist, müssen Sie akzeptieren, dass der Oracle WLS Kubernetes Operator (der Operator) die einzige Möglichkeit ist, WLS in 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.

  • Oracle und Microsoft haben dieses Angebot erstellt, um Ihnen die Möglichkeit zu geben, WLS auf AKS mit dem Modell in Image Domain Home Source Type schnell bereitzustellen. Dieses Konzept wird weiter unten in diesem Artikel ausführlicher erläutert.
  • Im Großen und Ganzen automatisiert das Angebot die folgenden Schritte für Sie.
    • Verwenden Sie eine vorhandene WAR- oder EAR-Bereitstellung, falls gewünscht.
    • Verpacken Sie sie mit dem WebLogic Image Tool (WIT) in einen Container. 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 das WebLogic Deploy Tooling (WDT) auf, um WebLogic-Umgebungen einzurichten und die Lebenszyklusvorgänge einer Domäne auf der Grundlage eines Metadatenmodells in wiederholbarer Weise durchzuführen. Weitere Informationen finden Sie unter WebLogic Deploy Tooling in der Dokumentation von Oracle.
  • Das vorgefertigte Angebot bietet zwar zahlreiche Azure Services-Integrationen, wie z. B. App Gateway, Elastic Logging, Datenbankintegration und mehr, geht aber von vielen vereinfachenden Annahmen aus. Diese Annahmen machen das Angebot nicht so flexibel wie die eigenständige Verwendung und Anwendung des Operators.

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 WLS Kubernetes Operator finden Sie unter Oracle.

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

Entscheiden Sie, ob Sie das vorgefertigte Azure Marketplace-Angebot nutzen möchten

Zunächst müssen Sie das Konzept der WLS-„Domäne“ verstehen. Eine Domäne ist eine logisch zusammenhängende Gruppe von WLS-Ressourcen. Die kanonische Definition der WLS-Domäne finden Sie in der Oracle-Dokumentation. Um WLS auf AKS auszuführen, müssen Sie sich entscheiden, wie AKS mit Domänen umgeht. Die verschiedenen Auswahlmöglichkeiten werden als „Domain Home Source Type“ bezeichnet. Der WLS Kubernetes Operator unterstützt drei verschiedene Domain Home Source-Typen. Das vorgefertigte Angebot auf dem Azure Marketplace verwendet die erste in dieser Tabelle.

Domain Home Source Type Beschreibung Positive Aspekte Negative Aspekte
Modell in Image WLS und Anwendungen befinden sich im Container-Image, alles andere wird außerhalb dieses Images gehalten. Unterstützt durch vorgefertigte Angebote. Dokumentiert als offizielles Beispiel; siehe Oracle. Nutzt am stärksten WDT. Die „cloudnativste“ Option. Einfachste CI/CD-Integration. Größte Lernkurve.
Domain in PV. Die Domäne befindet sich auf einem persistenten Kubernetes-Volume. Konzeptionell ähnlich wie das Ausführen in VMs. Sie können die WLS-Konsole verwenden, um Änderungen vorzunehmen, und diese Änderungen bleiben über Neustarts von AKS-Pods hinweg bestehen. Dokumentiert als offizielles Beispiel; siehe Oracle. Einige Herausforderungen im Zusammenhang mit NFS müssen gemeistert werden. Weitere Informationen finden Sie unter Oracle. Dieser Ansatz ist die am wenigsten „cloudnative“ Technik; der Status befindet sich vollständig außerhalb des AKS-Clusters.
Domain in Image Die Domäne befindet sich in einem Container-Image. Die Anwendungen sind in einem Container Image enthalten, das dem Image der Domäne überlagert ist. Eher „cloudnativ“ als Domain in PV. Einfacher für CI/CD. Sie können die WLS-Konsole nicht verwenden. Sie müssen mehr Container-Images pflegen.

Wichtig

Wenn Sie sich für den Quelltyp Domain in PV entscheiden, empfehlen wir dringend NFS anstelle von SMB. NFS hat sich aus dem UNIX-Betriebssystem und anderen Varianten wie z. B. GNU/Linux entwickelt. Aus diesem Grund ist es bei der Verwendung von NFS mit Container-Technologien wie z. B. Docker weniger wahrscheinlich, dass es bei gleichzeitigen Lesevorgängen und Dateisperren zu Problemen kommt.

Achten Sie darauf, NFS v4.1 zu aktivieren. Bei niedrigeren Versionen als v4.1 treten Probleme auf.

Die Dokumentation des Operators enthält auch eine nützliche Tabelle, in der die verschiedenen Vorgänge verglichen werden. Weitere Informationen finden Sie unter Domain Home Source Type auswählen.

Um ein Gefühl für das vorgefertigte Azure Marketplace-Angebot zu bekommen, siehe Schnellstart: Bereitstellung von WebLogic Server auf Azure Kubernetes Service über das Azure-Portal. Die Referenzdokumentation für das vorgefertigte Azure Marketplace-Angebot finden Sie unter Oracle.

Um ein Gefühl für die direkte Verwendung des Operators zu bekommen, probieren Sie die Beispiele in der Operator-Dokumentation aus.

Nachdem Sie nun die verschiedenen Möglichkeiten zur Verwaltung von WLS-Domänen auf Azure kennengelernt haben, können Sie besser entscheiden, ob Sie das vorgefertigte Azure Marketplace-Angebot nutzen oder es selbst mit dem Operator direkt tun möchten.

Ermitteln, ob die WebLogic-Version kompatibel ist

Ihre vorhandene WLS-Version muss eine der Versionen sein, die vom Operator unterstützt werden. Oracle verwaltet diese Versionen in der Oracle Container Registry (OCR). Gehen Sie wie folgt vor, um die Liste der unterstützten Versionen einzusehen.

  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 eine Support-Berechtigung haben, wählen Sie Middleware und suchen Sie dann nach weblogic_cpu. Wählen Sie weblogic_cpu.
  3. Wenn Sie keine Support-Berechtigung von Oracle haben, wählen Sie Middleware und suchen Sie dann nach weblogic. Wählen Sie weblogic.

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 Patch-Updates von Oracle finden Sie unter Kritische Patch-Updates, Sicherheitswarnungen und Bulletins.

Das vorgefertigte Azure Marketplace-Angebot lässt die Auswahl der WL-Images aus OCR und Azure Container Registry (ACR) zu und unterstützt damit implizit alle aus OCR verfügbaren Versionen. Wenn Sie das Angebot anweisen, ein Image aus ACR zu beziehen, stellen Sie sicher, dass es von einer der unterstützten Versionen stammt, 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. 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, 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 einen soliden Bestand an Secrets verfügen, konsultieren Sie die Operator-Dokumentation zu Secrets. 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 diese direkt mit dem vorgefertigten Angebot des Azure Marketplace installieren. Weitere Informationen finden Sie unter TLS/SSL-Konfiguration. Wenn Sie den Vorgang direkt mit dem Operator durchführen, lesen Sie Aktualisierung externer Zertifikate des Operators.

Ü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

Wenn Sie zu WLS auf Azure Virtual Machines migrieren, werden die Anforderungen für die spezifischen Java-Versionen durch das vorinstallierte Java auf den virtuellen Maschinen bestimmt. Bei der Migration zu WLS auf AKS wird die spezifische Java-Version durch das gewählte Container-Image bestimmt. Es gibt eine Vielzahl von Möglichkeiten, aber alle verwenden das 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 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. Suchen Sie nach JNDI in der Angebotsdokumentation. Wenn Sie den Operator direkt verwenden, können Sie die JDNI-Ressourcen je nach dem von Ihnen gewählten Domain Home Source Type definieren. Für Domain in PV können Sie sie auf die übliche Weise festlegen, mit WLST oder mit der Admin-Konsole. Für Domain in Image oder Modell in Image lesen Sie bitte Typische Überlagerungen.

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 Domänen-Ressource. Wenn Sie den Operator direkt verwenden, können Sie vollständig anpassen, wie Ihre Domäne dargestellt wird. Vollständige Informationen finden Sie unter Domänen-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 vordefinierte Azure Marketplace-Angebot unterstützt die Sitzungsaffinität über den Application Gateway-Eingangscontroller. Die auf Cookies basierende Affinität ist standardmäßig aktiviert. Um diese zu deaktivieren, können Sie Auf Cookies basierende Affinität deaktivieren auswählen. Suchen Sie in der Dokumentation für das Angebot nach „Auf Cookies basierende Affinität“.

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 meisten gängigen Datenbanken. Weitere Informationen finden Sie unter Datenbank. Für Domain in PV können Sie sie auf die übliche Weise festlegen, mit WLST oder mit der Admin-Konsole. Für Domain in Image oder Modell in Image lesen Sie bitte Typische Überlagerungen.

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 in dem von AKS ausgeführten Container-Image erfassen. Für das vorgefertigte Azure Marketplace-Angebot lassen sich solche Anpassungen am besten vornehmen, indem Sie ein angepasstes Container-Image erstellen und es in der Azure Container Registry verfügbar machen und dann bei der Bereitstellung auf diese Registrierung verweisen. Weitere Informationen finden Sie unter Image-Auswahl. 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.

Der einzige Domain Home Source Type, bei dem es Sinn ergibt, weiterhin die Verwaltung über REST zu verwenden, ist Domain in PV. Sie können es auch mit den anderen Domain Home Source Types verwenden, aber die vorgenommenen Änderungen sind temporär 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 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 1.1 mit Azure Service Bus Standard und AMQP 1.0.

Wenn beständige JMS-Speicher konfiguriert wurden, müssen Sie die zugehörige Konfiguration erfassen und nach dem Migrationsvorgang anwenden.

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 denselben Techniken verwendet werden, wie in Bestimmen, ob WebLogic angepasst wurde beschrieben.

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 die WAR oder EAR einbinden, die dem vorgefertigten Azure Marketplace-Angebot beigefügt ist, oder den Vorgang 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 möglicherweise die Verwendung von / oder \ in Dateisystempfaden durch File.Separator oder Paths.get ersetzen, wenn Ihre Anwendung unter Windows ausgeführt wird.

WLS auf AKS wird auf Oracle Linux ausgeführt. Jeder betriebssystemspezifische Code muss mit Oracle Linux kompatibel sein. Um zu erfahren, wie Sie spezifische Informationen zum Betriebssystem ermitteln können, folgen Sie den Schritten unter Bestimmen, 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 Angebot des Azure Marketplace 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. Die direkte Verwendung des Operators unterstützt auch WARs und EARs.

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 Domain Home Source Type, der mit der Verwendung von WLST kompatibel ist, ist Domain in PV. Weitere Informationen finden Sie unter Domain home on a PV.

Ermitteln, ob und wie das Dateisystem verwendet wird

Kubernetes arbeitet mit Dateisystemen mit persistenten Volumes (PV). Das Einbinden von persistenten Volumes wird im vorgefertigten Angebot des Azure Marketplace und bei direkter Verwendung des Operators unterstützt. Wenn Sie Domain 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 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. 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 sich Ihre Bereitstellung auf Ressourcenadapter stützt, ist die am meisten unterstützte Option Domain 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 sich Ihre Bereitstellung auf Sicherheitsanbieter stützt, ist die am meisten unterstützte Option Domain home on a PV.

Ermitteln, ob das WebLogic-Clustering genutzt wird

Der Operator übernimmt das Clustering für alle Möglichkeiten zur Ausführung von WLS auf AKS.

EJB-Clustering überprüfen

Wenn Ihre Anwendung lokale EJB verwendet, müssen Sie diese auf geclusterte EJB migrieren. Weitere Informationen finden Sie unter Geclusterte versus lokale EJB.

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. Weitere Informationen finden Sie unter Tutorial: Migration eines WebLogic Server Clusters zu Azure mit Azure Application Gateway als Load-Balancer.

Ermitteln, ob die Java EE-Anwendungsclientfunktion verwendet wird

Wenn Ihre Bereitstellung auf Java EE-Anwendungsclients angewiesen ist, verwenden Sie am besten direkt den Operator. Weitere Informationen finden Sie unter Externe Clients.

Bestimmen, ob mehrere Container-Images erforderlich sind

Eine WebLogic Server-Domäne kann mehrere Cluster enthalten. So kann beispielsweise eine mehrschichtige Anwendung in einer einzigen Domäne dargestellt werden, aber zwei Cluster enthalten, z. B. „Frontend“ und „Backend“. Es ist sinnvoll, das Frontend aktualisieren zu können, ohne das Backend zu aktualisieren, und umgekehrt. Mit dem Domain Home Source Type Modell in Image wird jedoch die gesamte Domäne in einem Container-Image dargestellt. Um diesem Anwendungsfall gerecht zu werden, müssen Sie die Cluster in ihre eigenen Domänen aufteilen, die jeweils über ein eigenes Container-Image verfügen. Der Operator kann mehrere Domänen in mehreren Namespaces verwalten. Weitere Informationen finden Sie unter Strategie zur Auswahl eines Domänen-Namespaces

Die Adaption mehrerer Domänen kann zu T3-Zugriffsproblemen zwischen den Domänen führen. Um diese Probleme zu lösen, aktivieren Sie einen angepassten Channel wie in Bestimmen, ob die Aktivierung des Zugriffs auf unbekannte Hosts erforderlich ist beschrieben.

Stellen Sie fest, ob die Aktivierung des Zugriffs auf unbekannte Hosts erforderlich ist

Für die folgenden Anforderungen müssen Sie möglicherweise den Zugriff auf unbekannte Hosts aktivieren, indem Sie einen Patch auf WebLogic anwenden:

  • Zulassen des T3-Zugriffs von externen Clients außerhalb von AKS auf WLS-Cluster in AKS über einen angepassten Kanal.
  • Zulassen des T3-Zugriffs zwischen verschiedenen WLS-Domänen in AKS über einen angepassten Kanal.

Für die Details des Patches folgen Sie der Anleitung in Wie Sie die Patch-Suche in My Oracle Support(MOS) verwenden und suchen Sie nach Patch 30656708.

Nachdem der Patch eingespielt wurde, siehe Zugriff auf unbekannte Hosts aktivieren.

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

Migrieren der Domänen

Nachdem Sie das Angebot bereitgestellt haben, geben Sie die Domäne aus, indem Sie die folgenden Schritte ausführen.

Wenn Sie die Seite Bereitstellung läuft verlassen haben, zeigen Ihnen die folgenden Schritte, wie Sie zu dieser Seite zurückkehren. Wenn Sie sich immer noch auf der Seite befinden, auf der Ihre Bereitstellung ist abgeschlossen 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 die Option Bereitstellungen, um eine geordnete Liste der Bereitstellungen für diese Ressourcengruppe anzuzeigen, wobei die jüngste zuerst angezeigt wird.

  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: Azure-Portal mit der Liste der Ressourcengruppenbereitstellungen

  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 uns die Möglichkeit bieten, die Domäne zu inspizieren und mit dem Operator zu interagieren. Die anderen Werte in den Ausgaben werden in der WebLogic auf AKS-Benutzeranleitung ausführlich erklärt.

  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 kubectl wie in Verbinden mit dem Cluster beschrieben verwenden.

  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. Dieser Befehl gibt die Ressource der Domäne als YAML-Datei aus.

  8. Jetzt, da Sie die YAML-Datei der Domäne der aktuellen Bereitstellung haben, können Sie das Wissen aus Deploying domain resource YAML files anwenden und diese Anleitung lesen, um weitere Hinweise zur Migration der Domänen zu erhalten. Diese Anleitung muss zwar an die Kubernetes-Arbeitsweise angepasst werden, ist aber dennoch nützlich 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 nicht in der Cloud arbeiten, ohne die Protokollierung zu beherrschen. Der Operator bietet Beispiele für die Verwendung von Elasticsearch und Kibana. Weitere Informationen finden Sie unter der Dokumentation des Operators. Azure bietet hervorragenden Support für Elastic. Ausführliche Informationen finden Sie unter Was ist die Integration von Elastic in Azure?. Sie können das Wissen aus diesen beiden Ressourcen kombinieren, um eine für Azure optimierte Protokollierungslösung für WLS auf AKS zu erhalten.

Migrieren Ihrer Anwendungen

Unabhängig davon, ob Sie sich dafür entschieden haben, bei der Bereitstellung eine WAR- oder EAR-Datei bereitzustellen, müssen Sie die Anwendung über CI/CD aktualisieren. In der Operator-Dokumentation finden Sie ein Beispiel, das zeigt, wie Sie diese Aktualisierung durchführen. Weitere Informationen finden Sie unter Update 3. Die anderen Update-Beispiele sind für die Migration relevant und es lohnt sich, sie zu entdecken.

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. Eine Anleitung zu einigen möglichen Verbesserungen nach der Migration finden Sie in den folgenden Empfehlungen: