Eseguire la migrazione dei carichi di lavoro mediante WebLogic Deploy Tooling

Distribuire tutte le risorse e le applicazioni in un dominio di cui è stato eseguito il provisioning contemporaneamente anziché singolarmente.

Quando si utilizza WLDT (WebLogic Deploy Tooling), il file del modello di dominio di origine viene aggiornato in modo da definire come destinazione le varie applicazioni e le risorse nei server del nuovo dominio e aggiornare le connessioni al database per la corrispondenza con i database migrati in Oracle Cloud Infrastructure.

Prima di iniziare, considerare quanto segue:

Il nome di dominio creato per l'immagine di Oracle WebLogic Server for Oracle Cloud Infrastructure è il prefisso fornito durante l'assegnazione ruoli con il suffisso aggiunto _domain, ad esempio test_domain.
I nomi dei server gestiti seguono il pattern <prefix>_server_<index>, ad esempio test_server_1, test_server_2, test_server_n, dove n è il numero di nodi di cui è stato eseguito il provisioning.
Il server dell'amministratore è denominato <prefix>_adminserver, ad esempio test__adminserver.
Se è stato eseguito il provisioning di WebLogic Enterprise Edition, viene eseguito il provisioning di un cluster denominato <prefix>_cluster che include tutti i server gestiti.
È necessaria la stringa di connessione per il database creato in precedenza.
Se i file dell'applicazione si trovano nella struttura della cartella ORACLE_HOME, non verranno selezionati da WebLogic Deploy Tooling e devono essere spostati manualmente. In alternativa, è possibile raggruppare i file dell'applicazione in un file zip con la struttura della cartella simile a wlsdeploy/applications/<app.ear> e impostare SourcePath sullo stesso percorso in modo che WebLogic Deploy Tooling distribuirà nella cartella predefinita sulla destinazione.

Come utente WebLogic appropriato (in genere oracle) e con un JAVA_HOME configurato correttamente, installare WLDT (WebLogic Deploy Tooling) nel dominio di origine.

# 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

Trova il dominio di origine.

-domain_type assume il valore predefinito di WLS, pertanto può essere omesso per un dominio WLS. Quando il parametro -domain_type JRF, il comando di ricerca automatica filtra tutti i componenti JRF di cui viene eseguito il nuovo provisioning dall'immagine del marketplace nel caso di un dominio JRF. L'uso di JRF rappresenta un valore predefinito valido per la ricerca automatica di tutti i domini.

Questo esempio utilizza source per i file .yaml, .zip e .properties. È possibile utilizzare qualsiasi nome file valido.

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

Spostare i file sul server dell'amministratore nell'ambiente di destinazione.

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

Installare lo strumento di distribuzione WebLogic nel server dell'amministratore WLS su 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

Modificare il file modello del dominio di origine in modo che corrisponda alla topologia del dominio di destinazione.
- source.yaml: file di modello che descrive il dominio, la relativa topologia (server, cluster e così via), le risorse e le distribuzioni delle applicazioni.
- source.zip: contiene i file dell'applicazione.
- source.properties: contiene i segnaposti per le credenziali che non è possibile portarle.
Nota:
Durante la modifica del file yaml, assicurarsi di utilizzare spazi, non schede o analisi non riusciranno. Tenere inoltre presente che in YAML, l'indentazione rappresenta la nidificazione, pertanto quando si rimuove una chiave di livello superiore, è necessario rimuovere tutti gli elementi nidificati sotto la chiave fino alla chiave successiva nello stesso livello.
1. Modificare il file .yaml per mantenere solo le risorse delle sezioni e appDeployments.
  - Rimuovere l'intera sezione domainInfo.
  - Rimuovere l'intera sezione topology.
  - WebLogic Server Enterprise Edition: per ogni applicazione nidificata in resources, JDBCSystemResource, quindi appDeployment, modificare la chiave Target in modo che corrisponda al nome del cluster in Oracle Cloud Infrastructure in cui il nome del cluster è <domain_prefix>_cluster, ad esempio ee_cluster.
  - WebLogic Server Standard Edition: per ogni applicazione nidificata in resources, JDBCSystemResource, quindi appDeployment, modificare la chiave Target in modo che corrisponda alla lista dei nomi dei server gestiti in Oracle Cloud Infrastructure che l'applicazione deve utilizzare il pattern <domain_prefix>_server_<id>. Separare le voci degli elenchi con una virgola e racchiudere l'elenco tra virgolette singole o doppie. Ad esempio, 'se_server_0,se_server_1,se_server_3'
2. Modificare gli URL delle origini dati in ogni chiave di JDBCDriverParams.
  L'URL deve seguire il pattern:
```
'jdbc:oracle:thin:@//<hostname>:<port>/<your_pdb_name>.<subdomain_name>'
```
  Dove hostname, port e subdomain_name provengono dalla stringa di connessione al database e your_pdb_name è il nome del PDB che ospita il database (non il nome della radice CDB).
  - Stringa di connessione a nodo singolo: <hostname>:<port>/<cdb_root_name>.<db_subnet_domain_name>
  - Stringa di connessione a più nodi: <hostname>-scan:<port>/<cdb_root_name>.<db_subnet_domain_name>
  Utilizzare uno dei due form se il database è composto da un solo nodo, ma si consiglia di includere il componente -scan per assicurare la ricerca automatica appropriata e il supporto della scala futura.
3. Aggiungere la chiave StagingMode se mancante
  
  Per ogni applicazione in appDeployments, assicurarsi che la chiave StagingMode sia impostata su stage oppure aggiungerla se non è presente. Questa impostazione distribuisce automaticamente i file negli altri server gestiti o server gestiti di destinazione del cluster. Senza questa impostazione, è necessario distribuire manualmente il file su ogni server.
4. Modificare il file source.properties e aggiornare la password di connessione JDBC o le password per il database di cui è stata eseguita la migrazione.
Eseguire lo script WebLogic Deploy Tooling updateDomain per aggiornare il dominio.
```
# 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
```
Note sull'esempio:
- -domain_type non viene utilizzato in questo caso perché si tratta di un aggiornamento. L'uso dell'opzione -domain_type JRF (anche per un dominio JRF) causa problemi di aggiornamento con WLDT per gli aggiornamenti in linea.
- -admin_url richiede il protocollo t3 con l'IP privato locale del server dell'amministratore estratto dal comando hostname -i. Il protocollo HTTP o HTTPS tramite l'IP pubblico non funziona.
- La specifica di -admin_url in questo comando assicura che il dominio venga aggiornato in linea. Non tutti i domini possono essere aggiornati in linea, ma a meno che non si modifichi la topologia (che non si tratti di maiuscole e minuscole), deve essere utilizzata per la maggior parte dei domini.
- L'aggiornamento in linea consente di distribuire le applicazioni e le risorse senza riavviare i server. Se si esegue l'aggiornamento non in linea, rimuovere l'opzione -admin_url, quindi arrestare e riavviare il server WebLogic utilizzando gli script stopWebLogic.sh e startWebLogic.sh. Utilizzare startWeblogic.sh &! per inviare il comando in background ed eliminarlo, in modo da lasciarlo definitivamente.
- Se si esegue l'aggiornamento non in linea, è necessario arrestare e riavviare il server due volte affinché il flag StagingMode=stage diventi effettivo. Il primo riavvio aggiorna la configurazione e il secondo riavvio abilita la distribuzione di StagingMode.