Freigeben über

Migrieren von WebLogic Server-Anwendungen zu virtuellen Azure-Computern

  • Artikel

In diesem Leitfaden wird beschrieben, was Sie beachten sollten, wenn Sie eine vorhandene WebLogic-Anwendung für die Ausführung auf Azure Virtual Machines migrieren möchten. Eine Übersicht über die verfügbaren WebLogic Server-Lösungen im Azure Marketplace finden Sie unter Welche Lösungen gibt es, um Oracle WebLogic Server auf Azure Virtual Machines auszuführen?

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.

Definieren der Bedeutung von „Migration abgeschlossen“

Dieser Leitfaden und die entsprechenden Azure Marketplace-Angebote sind ein guter Ausgangspunkt für die Beschleunigung der Migration Ihrer WebLogic Server-Workloads für Azure. Es ist wichtig, den Umfang Ihres Migrationsablaufs zu definieren. Führen Sie beispielsweise einen strikten „Lift & Shift“-Vorgang aus Ihrer vorhandenen Infrastruktur auf Azure Virtual Machines durch? Wenn ja, kann es verlockend sein, während der Migration auch nach dem Motto „Lift & Improve“ vorzugehen.

Es ist aber besser, möglichst nah am „Lift & Shift“-Ansatz zu bleiben und die erforderlichen Änderungen vorzunehmen, die in diesem Leitfaden beschrieben werden. Definieren Sie, was genau mit „Migration abgeschlossen“ gemeint ist, damit Sie wissen, wann dieser Meilenstein erreicht ist. Nach dem Erreichen des Zustands „Migration abgeschlossen“ können Sie eine Momentaufnahme Ihrer virtuellen Computer erstellen. Dies ist unter Erstellen einer Momentaufnahme beschrieben. Nachdem Sie sich vergewissert haben, dass Sie von Ihrem Snapshot aus erfolgreich wiederherstellen können, können Sie die Verbesserungen vornehmen, ohne befürchten zu müssen, dass der bis dahin erzielte Migrationsfortschritt verloren geht.

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.

Ermitteln, ob die vordefinierten Azure Marketplace-Angebote ein guter Ausgangspunkt sind

Oracle und Microsoft haben sich zusammengetan, um eine Reihe von Azure-Lösungsvorlagen im Azure Marketplace festzulegen, die einen soliden Ausgangspunkt für die Migration zu Azure bieten. In der Dokumentation zur Oracle Fusion Middleware finden Sie eine Liste mit Angeboten. Wählen Sie ein Angebot aus, das für Ihre vorhandene Bereitstellung am besten geeignet ist. Die Liste der Angebote finden Sie im Übersichtsartikel Was ist Oracle WebLogic Server in Azure?

Wenn keines der vorhandenen Angebote ein guter Ausgangspunkt ist, müssen Sie die Bereitstellung von Hand mit den Ressourcen von Azure Virtual Machine reproduzieren. Eine schrittweise Anleitung finden Sie in Oracle WebLogic Server auf Azure Virtual Machines manuell installieren. Weitere Informationen finden Sie unter Was ist IaaS?

Ermitteln, ob die WebLogic-Version kompatibel ist

Ihre vorhandene WebLogic-Version muss mit der Version in den IaaS-Angeboten kompatibel sein. Um die Angebote für WebLogic Version 12.2.1.4 anzuzeigen, fragen Sie Azure Marketplace für Oracle WebLogic 12.2.1.4 ab. Wenn Ihre vorhandene WebLogic-Version mit dieser Version nicht kompatibel ist, müssen Sie die Bereitstellung mit Azure-IaaS-Ressourcen manuell reproduzieren. Weitere Informationen finden Sie in der Azure-Dokumentation.

Inventarisieren der Serverkapazität

Dokumentieren Sie die Hardware (Arbeitsspeicher, CPU, Datenträger) der aktuellen Produktionsserver sowie die durchschnittliche und maximale Anzahl von Anforderungen und die Ressourcennutzung. Diese Informationen beeinflussen die VM-Größe. Weitere Informationen finden Sie unter Größen für Clouddienste.

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.

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>

Ü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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

Ermitteln, ob und wie das Dateisystem verwendet wird

VM-Dateisysteme funktionieren in Bezug auf die Persistenz und das Starten und Herunterfahren genauso wie lokale Dateisysteme. Trotzdem ist es wichtig, dass Sie die Anforderungen Ihres Dateisystems kennen und sicherstellen, dass die virtuellen Computer über eine geeignete Speichergröße und Leistung verfügen.

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.

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

Verwendet Ihre vorhandene Anwendung JCA-Adapter und/oder Ressourcenadapter zum Herstellen einer Verbindung mit anderen Unternehmenssystemen, stellen Sie sicher, dass die Konfiguration für diese Artefakte auf den in Azure Virtual Machines ausgeführten WebLogic-Server angewendet werden. Weitere Informationen finden Sie unter Erstellen und Konfigurieren von Ressourcenadaptern.

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.

Ermitteln, ob das WebLogic-Clustering genutzt wird

Höchstwahrscheinlich haben Sie Ihre Anwendung auf mehreren WebLogic-Servern bereitgestellt, um Hochverfügbarkeit zu erzielen. Sie können diese Cluster direkt aus Ihrer lokalen Installation zu der in Azure Virtual Machines ausgeführten WebLogic-Instanz migrieren. Weitere Informationen finden Sie in der Oracle-Dokumentation unter Domänenkonfigurationsdateien.

Konto für Lastenausgleichsanforderungen

Der Lastenausgleich ist ein wesentlicher Bestandteil der Migration Ihres Oracle WebLogic Server-Clusters zu Azure. Die einfachste Lösung ist die Verwendung der integrierten Unterstützung für Azure Application Gateway, die im Azure Marketplace-Angebot für Oracle WebLogic Server-Cluster bereitgestellt wird. Ein Tutorial zu diesem Thema finden Sie unter Tutorial: Migration eines WebLogic Server Clusters zu Azure mit Azure Application Gateway als Load-Balancer.

Eine Zusammenfassung der Funktionen von Azure Application Gateway im Vergleich zu anderen Azure-Lastenausgleichslösungen finden Sie unter Übersicht über Lastenausgleichsoptionen in Azure.

Ermitteln, ob die Java EE-Anwendungsclientfunktion verwendet wird

Verwendet Ihre Anwendung die Java EE-Anwendungsclientfunktion, sollten Sie sie nach der Migration zu Azure Virtual Machines weiterhin unverändert verwenden können. Weitere Informationen finden Sie unter Verwenden von Java EE-Clientanwendungsmodulen.

Migration

Auswählen eines WebLogic-Angebots für Azure Virtual Machines

Die folgenden Angebote sind für WebLogic auf Azure Virtual Machines verfügbar.

Während der Bereitstellung eines Angebots werden Sie aufgefordert, die Größe der virtuellen Maschine für Ihre WebLogic Server-Knoten auszuwählen. Es ist wichtig, bei der Auswahl der VM-Größe alle Größenaspekte (Arbeitsspeicher, Prozessor, Datenträger) zu berücksichtigen. Weitere Informationen finden Sie in der Azure-Dokumentation zur Größenanpassung virtueller Computer.

WebLogic Server-Einzelknoten ohne Admin-Server

Bei diesem Angebot wird nur ein virtueller Computer erstellt, auf dem dann die Installation von WebLogic erfolgt, aber es werden keine Domänen konfiguriert. Dies ist nützlich für Szenarien, in denen Sie eine stark angepasste Domänenkonfiguration nutzen.

WebLogic Server-Einzelknoten mit Admin-Server

Bei diesem Angebot wird nur ein virtueller Computer bereitgestellt und WebLogic Server darauf installiert. Es wird eine Domäne erstellt und der Admin-Server gestartet.

WebLogic Server-Cluster mit „n“ Knoten

Bei diesem Angebot wird ein hoch verfügbarer Cluster mit WebLogic Server-VMs erstellt.

Dynamischer WebLogic Server-Cluster mit „n“ Knoten

Bei diesem Angebot wird ein hoch verfügbarer und skalierbarer dynamischer Cluster mit WebLogic Server-VMs erstellt.

Bereitstellen des Angebots

Befolgen Sie nach der Auswahl des Anfangsangebots die Anleitung in der entsprechenden Dokumentation, um das Angebot bereitzustellen. Achten Sie darauf, dass Sie den Domänennamen auswählen, der mit Ihrem vorhandenen Domänennamen übereinstimmt. Sie können auch das Domänenkennwort an Ihr vorhandenes Domänenkennwort anpassen.

Migrieren der Domänen

Nachdem Sie das Angebot bereitgestellt haben, können Sie die Domänenkonfiguration untersuchen und die Informationen zum Migrieren der Domänen in diesem Leitfaden verwenden.

Verbinden der Datenbanken

Nachdem Sie die Domänen migriert haben, können Sie die Datenbanken verbinden, indem Sie die Anleitung in der Dokumentation zum Angebot befolgen. Diese Anweisungen helfen Ihnen dabei, etwaige Datenbank Secrets und Zeichenfolgen zu berücksichtigen.

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. Weitere Informationen finden Sie unter Fusion Middleware Administering JMS Resources for Oracle WebLogic Server in der WebLogic Dokumentation.

Konto für Authentifizierung und Autorisierung

Die meisten Anwendungen verfügen über eine Art von Authentifizierung und Autorisierung. Wenn Sie LDAP zur Authentifizierung verwenden, können Sie Microsoft Entra Domain Services mit sicherem LDAP einrichten und LDAP-Verbindungen in WebLogic Server konfigurieren. Weitere Informationen finden Sie unter Erstellen und Konfigurieren einer von Microsoft Entra Domain Services verwalteten Domäne und Konfigurieren Sie sicheres LDAP für eine von Microsoft Entra Domain Services verwaltete Domäne.

Berücksichtigen der Protokollierung

Verwenden Sie die Integration mit Elastic auf Azure, die von den Lösungsvorlagen auf dem Oracle WebLogic Server Marketplace bereitgestellt wird. Dieser Ansatz ist der einfachste Weg, um die Protokollierung zu berücksichtigen. Die Liste der Angebote finden Sie im Übersichtsartikel Welche Lösungen gibt es, um Oracle WebLogic Server auf Azure Virtual Machines auszuführen? Vollständige Anleitungen zur Konfiguration von Elastic finden Sie in:

Wenn die Elastic-Integration nicht geeignet ist, sollten Sie die vorhandene Protokollierungskonfiguration bei der Migration der Domäne übernehmen. Weitere Informationen finden Sie unter Konfigurieren von „java.util.logging“-Protokollierungsebenen und Konfigurieren von Protokolldateien und Filtern von Protokollmeldungen für Oracle WebLogic Server in der Oracle-Dokumentation.

Migrieren Ihrer Anwendungen

Die verwendeten Verfahren zum Bereitstellen von Anwendungen über das Entwicklungsteam auf Test-, Staging- und Produktionsservern können von Fall zu Fall stark variieren. In einigen Fällen wird eine hoch entwickelte CI/CD-Plattform genutzt, die dazu führt, dass die Anwendungen auf dem WebLogic Server bereitgestellt werden. In anderen Fällen kann es sein, dass der Prozess manuell durchgeführt wird. Ein Vorteil der Verwendung von Azure Virtual Machines für die Migration von WebLogic-Anwendungen in die Cloud ist, dass Ihre bestehenden Prozesse weiterhin funktionieren.

Sie müssen die Netzwerksicherheitsgruppe konfigurieren, die das Angebot bereitstellt, um den Zugriff von Ihrer CI/CD Pipeline oder Ihrem manuellen Bereitstellungssystem aus zuzulassen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

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: