Migrate Workloads Using WebLogic Deploy Tooling

Deploy all resources and applications on a provisioned domain at one time rather than individually.

Using WebLogic Deploy Tooling (WLDT), you will update the source domain model file to target the various applications and resources to the new domain’s servers and update database connections to match databases migrated to Oracle Cloud Infrastructure.

Before you begin, note the following:

The domain name created for the Oracle WebLogic Server for Oracle Cloud Infrastructure image is the prefix you supplied during provisioning with the added suffix _domain, for example test_domain.
Managed server names follow the pattern <prefix>_server_<index> for example test_server_1, test_server_2, test_server_n where n is the number of nodes provisioned.
The Administrator server is named <prefix>_adminserver, for example test__adminserver.
If you provisioned WebLogic Enterprise Edition, a cluster named <prefix>_cluster is provisioned that includes all the managed servers.
You will need the connection string for the database you created earlier.
If application files are under the ORACLE_HOME folder structure, they will not be picked up by WebLogic Deploy Tooling, and must be moved manually. Alternatively, you can package application files in a zip file with the folder structure similar to wlsdeploy/applications/<app.ear> and change the SourcePath to the same path so WebLogic Deploy Tooling will deploy in the default folder on the target.

As the proper WebLogic user (typically oracle), and with a properly configured JAVA_HOME, install WebLogic Deploy Tooling (WLDT) in the source domain.

# 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

Discover the source domain.

-domain_type defaults to WLS, so it can be omitted for a WLS domain. When -domain_type JRF, the discovery command filters out all the JRF components, which are re-provisioned by the marketplace image in the case of a JRF domain. Using JRF is a good default for discovery of all domains.

This example uses source for the .yaml, .zip, and .properties files. You can use any valid file name.

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

Move the files to the Administrator server on the target environment.

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

Install WebLogic Deploy Tooling on the WLS Administrator server on 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

Edit the source domain model file to match the target domain topology.
- source.yaml: model file that describes the domain, its topology (servers, clusters and so on), resources, and application deployments.
- source.zip: contains the application files.
- source.properties: contains the placeholders for credentials that cannot be ported.
Note:
When editing the yaml file, make sure to use spaces, not tabs or parsing will fail. Also note that in YAML, indentation represents nesting, so when removing a top-level key, you should remove everything nested under the key up to the next key at the same level.
1. Edit the .yaml file to keep only the sections resources and appDeployments.
  - Remove the entire domainInfo section.
  - Remove the entire topology section.
  - WebLogic Server Enterprise Edition: For each application nested under resources, then JDBCSystemResource, and then appDeployment, edit the Target key to match the cluster name on Oracle Cloud Infrastructure where cluster name is <domain_prefix>_cluster, for example ee_cluster.
  - WebLogic Server Standard Edition: For each application nested under resources, then JDBCSystemResource, and then appDeployment, edit the Target key to match the list of managed server names on Oracle Cloud Infrastructure that the application should target using the pattern, <domain_prefix>_server_<id>. Separate list entries by a comma and enclose the list with single or double quotation marks. For example 'se_server_0,se_server_1,se_server_3'
2. Edit the URLs of the data sources under each JDBCDriverParams key.
  The URL should follow the pattern:
```
'jdbc:oracle:thin:@//<hostname>:<port>/<your_pdb_name>.<subdomain_name>'
```
  Where hostname, port and subdomain_name are from the database connection string, and your_pdb_name is the name of the PDB hosting your database (not the CDB root name).
  - Single node connection string: <hostname>:<port>/<cdb_root_name>.<db_subnet_domain_name>
  - Multiple node connection string: <hostname>-scan:<port>/<cdb_root_name>.<db_subnet_domain_name>
  Use either form if the database consists only of one node, however we recommend that you include the -scan component to insure proper discovery and to support future scaling.
3. Add the StagingMode key if missing
  
  For each application under appDeployments, make sure the StagingMode key is set to stage or add it if it is not present. This setting automatically deploys the files on the other targeted managed servers or managed servers of the cluster. Without this setting, you must manually deploy the file to each server.
4. Edit the source.properties file and update the JDBC connection password or passwords for the database or database that you migrated.
Run the WebLogic Deploy Tooling updateDomain script to update the domain.
```
# 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
```
Notes about this example:
- The -domain_type is not used here as it is an update only. Using the -domain_type JRF option (even for a JRF domain) causes update issues with WLDT for online updates.
- The -admin_url requires the t3 protocol with the Administrator server local private IP as extracted by the hostname -i command. HTTP or HTTPS through the public IP do not work.
- Providing the -admin_url in this command ensures that the domain is updated online. Not all domains can be updated online, but unless the topology is modified (which is not the case here), it should work for most domains.
- Updating online allows you to deploy the applications and resources without restarting the servers. If you perform update offline, remove the -admin_url option, and then stop and restart WebLogic server using the stopWebLogic.sh and startWebLogic.sh scripts. Use startWeblogic.sh &! to send the command to the background and disown it, so it survives terminal exit.
- If you perform the update offline, you must stop and restart the server twice for the StagingMode=stage flag to take effect. The first restart updates the configuration and the second restart enables the StagingMode deployment.