Workloads mit WebLogic Deployment Tooling migrieren

Stellen Sie alle Ressourcen und Anwendungen in einer durch Provisioning bereitgestellten Domain gleichzeitig und nicht einzeln bereit.

Mit WebLogic Deploy Tooling (WLDT) können Sie die Quelldomainmodelldatei aktualisieren, um die verschiedenen Anwendungen und Ressourcen auf die Server der neuen Domain auszurichten und Datenbankverbindungen zu aktualisieren, damit sie mit den in Oracle Cloud Infrastructure migrierten Datenbanken übereinstimmen.

Beachten Sie Folgendes, bevor Sie beginnen:

Der für das Oracle WebLogic Server for Oracle Cloud Infrastructure-Image erstellte Domainname ist das Präfix, das Sie beim Provisioning mit dem hinzugefügten Suffix _domain angegeben haben. Beispiel: test_domain.
Managed Server-Namen folgen dem Muster <prefix>_server_<index>. Beispiel: test_server_1, test_server_2, test_server_n, wobei n die Anzahl der bereitgestellten Knoten ist.
Der Administrator-Server hat den Namen <prefix>_adminserver, z. B. test__adminserver.
Wenn Sie WebLogic Enterprise Edition durch Provisioning bereitgestellt haben, wird ein Cluster mit dem Namen <prefix>_cluster bereitgestellt, das alle Managed Server enthält.
Sie benötigen die Verbindungszeichenfolge für die Datenbank, die Sie zuvor erstellt haben.
Wenn Anwendungsdateien sich unter der Ordnerstruktur von ORACLE_HOME befinden, werden sie nicht von WebLogic Deploy Tooling verarbeitet und müssen manuell verschoben werden. Alternativ können Sie Anwendungsdateien in einer ZIP-Datei mit der Ordnerstruktur wie wlsdeploy/applications/<app.ear> in ein Package integrieren und den SourcePath in denselben Pfad ändern, sodass WebLogic Deploy Tooling im Standardordner auf dem Ziel bereitgestellt wird.

Als der richtige WebLogic-Benutzer (normalerweise oracle) und mit einem ordnungsgemäß konfigurierten JAVA_HOME installieren Sie WebLogic Deploy Tooling (WLDT) in der Quelldomain.

# install weblogic-deploy-tooling
# Check for the latest version at:
# https://github.com/oracle/weblogic-deploy-tooling/releases/
WLSDT_VERSION=1.7.0
echo $JAVA_HOME
# download and unzip the package
wget -qO- https://github.com/oracle/weblogic-deploy-tooling/releases/download/weblogic-deploy-tooling-${WLSDT_VERSION}/weblogic-deploy.zip | $JAVA_HOME/bin/jar xv
# make the scripts executable
chmod +x weblogic-deploy/bin/*.sh

Ermitteln Sie die Quelldomain.

-domain_type entspricht standardmäßig WLS und kann daher bei einer WLS-Domain ausgelassen werden. Bei -domain_type JRF filtert der Discovery-Befehl alle JRF-Komponenten heraus, die vom Marketplace-Image bei einer JRF-Domain erneut bereitgestellt werden. Die Verwendung von JRF ist ein geeigneter Standard für das Erkennen aller Domains.

In diesem Beispiel wird source für die Dateien .yaml, .zip und .properties verwendet. Sie können einen beliebigen gültigen Dateinamen verwenden.

# path to the parent of the wlserver folder (for example /u01/app/oracle/middleware/)
MW_HOME=
# path to the domain folder (i.e. <domain root>/<domain_name>)
DOMAIN_HOME=

weblogic-deploy/bin/discoverDomain.sh \
    -oracle_home $MW_HOME \
    -domain_home $DOMAIN_HOME \
    -archive_file source.zip \
    -model_file source.yaml \
    -variable_file source.properties \
    -domain_type JRF

# even if the domain is not JRF, using JRF domain type will only filter out domain libraries. If they don’t exist, this will not affect the output.

Verschieben Sie die Dateien auf den Administrator-Server in der Zielumgebung.

SOURCE_IP=<IP of the source WLS server>
ADMIN_SERVER_IP=<IP of the cloud Administrator server>
scp <source_user>@${SOURCE_IP}:~/source.* opc@${ADMIN_SERVER_IP}:~/

# change ownership of the files from opc to oracle 
# and move the file to the oracle user home
ssh opc@${ADMIN_SERVER_IP}
sudo chown oracle:oracle source.*
sudo mv source.* /home/oracle/
# switch to the oracle user
sudo su – oracle

Installieren Sie WebLogic Deploy Tooling auf dem WLS-Administratorserver auf Oracle Cloud Infrastructure.

# As the oracle user, install weblogic-deploy-tooling
WLSDT_VERSION=1.7.0
wget -qO- https://github.com/oracle/weblogic-deploy-tooling/releases/download/weblogic-deploy-tooling-${WLSDT_VERSION}/weblogic-deploy.zip | $JAVA_HOME/bin/jar xv

# make the scripts executable
chmod +x weblogic-deploy/bin/*.sh

Bearbeiten Sie die Quelldomainmodelldatei, damit sie mit der Zieldomaintopologie übereinstimmt.
- source.yaml: Modelldatei, die die Domain, ihre Topologie (Server, Cluster usw.), Ressourcen und Anwendungs-Deployments beschreibt.
- source.zip: enthält die Anwendungsdateien.
- source.properties: Enthält die Platzhalter für Zugangsdaten, die nicht portiert werden können.
Hinweis:
Beim Bearbeiten der Yaml-Datei dürfen keine Leerzeichen, keine Registerkarten oder Parsingvorgänge verwendet werden. Beachten Sie außerdem, dass die Einrückung in YAML eine Verschachtelung darstellt. Wenn Sie also einen Schlüssel der obersten Ebene entfernen, müssen Sie alle verschachtelten Elemente unter dem Schlüssel bis zum nächsten Schlüssel auf derselben Ebene entfernen.
1. Bearbeiten Sie die Datei .yaml, um nur die Abschnittsressourcen und appDeployments beizubehalten.
  - Entfernen Sie den gesamten domainInfo-Abschnitt.
  - Entfernen Sie den gesamten topology-Abschnitt.
  - WebLogic Server Enterprise Edition: Bearbeiten Sie für jede Anwendung, die unter resources, JDBCSystemResource und dann appDeployment verschachtelt ist, den Schlüssel Target, damit er mit dem Clusternamen in Oracle Cloud Infrastructure übereinstimmt, wobei der Clustername <domain_prefix>_cluster ist, z. B. ee_cluster.
  - WebLogic Server Standard Edition: Bearbeiten Sie für jede Anwendung, die unter resources, JDBCSystemResource und appDeployment verschachtelt ist, den Schlüssel Target, damit er der Liste der Managed Server-Namen auf Oracle Cloud Infrastructure entspricht, die die Anwendung mit dem Muster <domain_prefix>_server_<id> als Ziel definieren soll. Trennen Sie Listeneinträge durch ein Komma, und schließen Sie die Liste in einfache oder doppelte Anführungszeichen ein. Beispiel: 'se_server_0,se_server_1,se_server_3'
2. Bearbeiten Sie die URLs der Datenquellen unter jedem JDBCDriverParams-Schlüssel.
  Die URL muss dem Muster entsprechen:
```
'jdbc:oracle:thin:@//<hostname>:<port>/<your_pdb_name>.<subdomain_name>'
```
  Wobei hostname, port und subdomain_name aus der Datenbank-Verbindungszeichenfolge stammen und your_pdb_name der Name der PDB ist, die Ihre Datenbank hostet (nicht der CDB-Root-Name).
  - Einzelne Knotenverbindungs-Zeichenfolge: <hostname>:<port>/<cdb_root_name>.<db_subnet_domain_name>
  - Mehrfachknoten-Verbindungszeichenfolge: <hostname>-scan:<port>/<cdb_root_name>.<db_subnet_domain_name>
  Verwenden Sie eine der beiden Formen, wenn die Datenbank nur aus einem Knoten besteht. Es wird jedoch empfohlen, dass Sie die Komponente -scan aufnehmen, um ein ordnungsgemäßes Discovery sicherzustellen und zukünftige Skalierung zu unterstützen.
3. StagingMode-Schlüssel hinzufügen, falls fehlt
  
  Stellen Sie für jede Anwendung unter appDeployments sicher, dass der StagingMode-Schlüssel auf stage festgelegt ist, oder fügen Sie ihn hinzu, wenn er nicht vorhanden ist. Diese Einstellung stellt die Dateien automatisch auf den anderen als Ziel definierten Managed Servern oder Managed Servern des Clusters bereit. Ohne diese Einstellung müssen Sie die Datei manuell auf jedem Server bereitstellen.
4. Bearbeiten Sie die Datei source.properties, und aktualisieren Sie das Kennwort oder die Kennwörter der JDBC-Verbindung für die migrierte Datenbank oder Datenbank.
Führen Sie das WebLogic Deploy Tooling updateDomain-Skript aus, um die Domain zu aktualisieren.
```
# make sure the needed variables are set:
echo $DOMAIN_HOME
echo $MW_HOME

# run WebLogic Deploy Tooling updateDomain script in online mode
weblogic-deploy/bin/updateDomain.sh \
-oracle_home $MW_HOME \
-domain_home $DOMAIN_HOME \
-model_file source.yaml \
-variable_file source.properties \
-archive_file source.zip \
-admin_url t3://$(hostname -i):9071

# domain deployed before 05/19/2020 may need to use port 7001
```
Hinweise zu diesem Beispiel:
- -domain_type wird hier nicht verwendet, da es sich um ein Update handelt. Die Verwendung der Option -domain_type JRF (selbst bei einer JRF-Domain) führt zu Aktualisierungsproblemen bei WLDT für Onlineupdates.
- Das Protokoll -admin_url erfordert das t3-Protokoll mit der lokalen privaten IP-Adresse des Administratorservers, wie mit dem Befehl hostname -i extrahiert. HTTP oder HTTPS über die öffentliche IP funktioniert nicht.
- Durch die Angabe von -admin_url in diesem Befehl wird sichergestellt, dass die Domain online aktualisiert wird. Nicht alle Domains können online aktualisiert werden, es sei denn, die Topologie wird geändert (dies ist nicht der Fall hier), sie sollte jedoch für die meisten Domains verwendet werden.
- Wenn Sie online aktualisieren, können Sie die Anwendungen und Ressourcen bereitstellen, ohne die Server neu zu starten. Wenn Sie ein Update offline durchführen, entfernen Sie die Option -admin_url, und stoppen und starten Sie den WebLogic-Server mit den Skripten stopWebLogic.sh und startWebLogic.sh neu. Verwenden Sie startWeblogic.sh &!, um den Befehl an den Hintergrund zu senden und dessen Eigentümer zu entfernen, damit das Terminal beendet wird.
- Wenn Sie die Aktualisierung offline durchführen, müssen Sie den Server zweimal stoppen und neu starten, damit das StagingMode=stage-Flag wirksam wird. Beim ersten Neustart wird die Konfiguration aktualisiert, und der zweite Neustart aktiviert das StagingMode-Deployment.