Copy a WebLogic Server Instance

For a non-JRF instance, you can clone to copy the binaries and data from the original instance, and then use the load balancer and IDCS in the cloned instance. In this setup, the cloned instance would have the same topology as the original instance.

Note:

Currently, in this method, cloning for an instance with JRF database is not supported.

Topics:

Clone a non-JRF Instance

Complete the following steps:

In this procedure:

Original instance is the instance you want to clone.
Cloning instance is the instance you will create to clone the original instance.

Create a non-JRF domain. This is the Cloning instance. See Create a Basic Domain.

Note:
If the source instance uses IDCS, the IDCS configuration steps assume that the new instance was created with the Enable Authentication Using Identity Cloud Service option selected.
Complete the following steps if you have created an instance by using the Identity Cloud Service:
1. Open the /u01/data/domains/idcss_domain/config/config.xml file and make a note of the idcs:client-id value.
2. Take a backup of the following to the /tmp location:
```
/u01/data/cloudgate_config
```
Detach the block volumes that were created in the cloning instance.
1. Stop the Domain. See Start and Stop a Domain.
2. Remove the mount volume:
  sudo umount <mount>
  
  Where <mount> is /u01/data or /u01/app.
3. From the navigation menu, click Compute. Under the Compute group, click Instances.
4. From the Compartment drop-down list, select the compartment in which your instance is created.
5. Click the instance you created.
6. In the instance page, under Resources, click Attached Block Volume.
7. Against the block volume that was created when creating the domain, click the menu icon and then click Detach.
  The Detach Block Volume dialog box is displayed. It provides information about your volume and the iSCSI commands you will need. The commands are ready to use with the appropriate information included.
  
  Copy these commands.
8. Click Continue Detachment.
9. Access the node and then run the iSCSI commands that you copied in step 3e.
10. Repeat step 3e through step 3g for all the other block volumes that were created when creating the domain.
Clone both the middleware and data block volumes of the Original instance. See Cloning a Volume.

Note:
Follow the next steps, to first attach the middleware volume and then attach the data block volume to the Cloning instance. This sequence ensures that the mountVolume.sh script works as desired, which you will be running later in this procedure.
To the Cloning instance, attach the middleware volume that your cloned in step 4.
1. In the instance page, under Resources, click Attached Block Volume > Attach Block Volume.
2. In the Attach Block Volume page, select the compartment where you cloned the block volume earlier.
3. Click the drop-down and select the block volume you clone earlier.
4. Select the Attachment Type as ISCSI.
5. Click Attach.
  An Attach Block Volume message appears.
6. Click Close.
To the Cloning instance, attach the data block volume that your cloned in step 4.
1. In the instance page, under Resources, click Attached Block Volume > Attach Block Volume.
2. In the Attach Block Volume page, select the compartment where you cloned the block volume earlier.
3. Click the drop-down and select the block volume you clone earlier.
4. Select the Attachment Type as ISCSI.
5. Click Attach.
  An Attach Block Volume message appears.
6. Click Close.
Run the following script:
```
/opt/scripts/cloning/mountVolume.sh -m <cloned-middleware-volume-name> -d <cloned-data-volume-name>
```
This script runs the iSCSI commands to attach both the middleware and data volumes. Also, the script updates the UUID entries of both the volumes in /etc/fstab, which ensures that the mount is persistent across reboot.
Update the metadata on each node by using update_metadata.py script, which is located at /opt/scripts/utils/:
We need to update the metadata for reboot to work correctly. This also starts the node manager and administration server automatically after every restart. There are 5 domain related values in metadata that need to be updated for reboot to work.
```
python3 /tmp/update_metadata.py -k wls_domain_name -v <resource_prefix>_domain python3 /tmp/update_metadata.py -k wls_machine_name -v <resource_prefix>_machine_ python3 /tmp/update_metadata.py -k wls_cluster_name -v <resource_prefix>_cluster python3 /tmp/update_metadata.py -k wls_admin_server_name -v <resource_prefix>_adminserver python3 /tmp/update_metadata.py -k wls_ms_server_name -v <resource_prefix>_server_
```
The script updates one value at time. Also, for every command, it creates the backup of previous setup under /opt/scripts/utils/metadata_backup_<timestamp>.txt.

Note:
After the restart works as desired, you can delete these backed up files.
Run the following update_hostname.sh script, which is located at /opt/scripts/cloning:
```
./update_hostname.sh <FQDN-of-source-instance>
```
For example: ./update_hostname.sh source12c-wls-0.subnet1fd5ed7.idcsvcn.oraclevcn.com
This updates the hostname to the cloned hostname in the nodemanager.properties and config.xml files. It also updates the startup.properties file to reflect the correct admin url.
If the Demo Identity certificates have the incorrect host name, then, as the oracle user, run the following command on each VM in the Oracle WebLogic Server for OCI instance:
```
sudo su - oracle /opt/scripts/cloning/generate_demo_certs.sh
```
If you are using the CustomIdentityAndCustomTrust keystore for SSL configuration in the WebLogic Server domain, and you have not placed the keystore in a location under the data volume (/u01/data), then, as the oracle user, you will need to copy the keystore to the compute instance (VM).
Reboot the instance.

This will automatically first start the node manager and then start the administration server.
Repeat step 2 through step 10 on all the nodes.

You have now cloned the WebLogic Server Instance. Continue with the next steps to configure the load balancer and IDCS.

Caution:
If you are not using IDCS, then do not continue with the next steps.
Access the IDCS console and copy the idcs:client-secret value:
1. Access the IDCS console.
2. From the left navigation, Click Applications.
3. Search for the confidential application that is used by the Authentication Provider for the instance. It will have the instance name and the word confidential in it.
4. Select the application, and then click Configuration.
5. Under General Information, click Show Secret against Client Secret.
  The Client Secret information is displayed.
6. Copy the Client Secret value.
In the WebLogic console, update the idcs:client-id and idcs:client-secret.
1. Access the WebLogic console of the clone instance. See Access the WebLogic Server Administration Console.
2. Under Domain Structure, click Security Realms.
3. In the Summary of Security Realms page, select myrealm > Providers.
4. Click IDCSIntegrator > Provider Specific.
5. In the left navigation, under Change Center, click Lock & Edit.
6. In the Provider Specific page, enter the values for Client Id, Client Secret, and Confirm Client Secret.
  Where,
  - Client Id : is the client ID that you made a note of in step 2a.
  - Client Secret or Confirm Client Secret: is the Client Secret that you copied in step 12.
7. Click Save.
8. In the left navigation, under Change Center, click Release Configuration.
In the cloned instance, restore the backup of /u01/data/cloudgate_config from the /tmp to /u01/data location.
This is the backup which you performed in step 2b.

Restart the container.

sudo systemctl status appgateway.service sudo systemctl start appgateway.service sudo podman ps -a sudo systemctl status appgateway.service sudo /opt/scripts/idcs/run_cloudgate.sh

Verify if nginx is redirecting traffic to WebLogic server through port 9999:

ip=$(hostname -i) cloudgate_url=${ip}:9999 curl -v ${cloudgate_url} curl -s -o /dev/null -w “%{http_code}\n” ${cloudgate_url}

Repeat step 14 through step 16 on all nodes.

Note:
Here you will use the load balancer of the cloned instance. So, there is no update required to the load balancer.
Verify if you can access sample app. See Access the Sample Application.

After every reboot, manually start the appgateway:

sudo systemctl start appgateway sudo podman ps -a ip=$(hostname -i) cloudgate_url=${ip}:9999 curl -v ${cloudgate_url} curl -v ${cloudgate_url}/sample-app

You have successfully cloned the instance.

Access the respective WebLogic console to verify the updates you performed to the instance. See Access the WebLogic Server Administration Console.

After you verified the updates you performed to the instance, delete the block volumes that you detach in step 6. See Deleting a Volume.

Scale Out the Cloned Instance

You can scale out the instance that you cloned.

Note:

If you have updated the WebLogic Server password, then create a version of the Secret and update the metadata scripts to use the new Secret. See To update a secret's contents to create a new secret version under Managing Secrets in the Oracle Cloud Infrastructure documentation.

To scale out the cloned instance, edit the node count variable for the stack and complete the required steps:

Sign in to the Oracle Cloud Infrastructure Console.
Click the navigation menu , select Developer Services. Under the Resource Manager group, click Stacks.
Select the Compartment that contains your stack.
Click the name of your stack.
Click Variables.
Click Edit Variables.
Edit WebLogic Server Node Count to the increase the number of compute instances.
Select Do Not Update Domain Configuration for Scale Out.
Click Next.
Click Save Changes.
The apply job is run to update the stack.
Periodically monitor the progress of the Apply job until it is finished.
Click Outputs.
Locate WebLogic_Instances, and verify the number of compute instances in the updated stack.
Update the metadata on each node by using update_metadata.py script, which is located at /opt/scripts/utils/:
We need to update the metadata for reboot to work correctly. This also starts the node manager and administrator server automatically after every restart. There are 5 domain related values in metadata that need to be updated for reboot to work.
```
python3 /tmp/update_metadata.py -k wls_domain_name -v <resource_prefix>_domain python3 /tmp/update_metadata.py -k wls_machine_name -v <resource_prefix>_machine_ python3 /tmp/update_metadata.py -k wls_cluster_name -v <resource_prefix>_cluster python3 /tmp/update_metadata.py -k wls_admin_server_name -v <resource_prefix>_adminserver python3 /tmp/update_metadata.py -k wls_ms_server_name -v <resource_prefix>_server_
```
The script updates one value at time. Also, for every command, it creates the backup of previous setup under /opt/scripts/utils/metadata_backup_<timestamp>.txt.

Note:
After the restart works as desired, you can delete these backed up files.

Run the manual scale out by running extend domain scripts on the added instance.

Note:

You must change WLST_PROPERTIES for a custom SSL set up, to avoid SSL handshake errors.

For example, if you are using Custom Identity and Custom Trust, then weblogic.security.TrustKeyStore=CustomTrust, weblogic.security.CustomTrustKeyStoreFileName, and weblogic.security.CustomTrustKeyStoreType need to be set.

Run the following command:

export WLST_PROPERTIES="-Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.2 -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.TrustKeyStore=DemoTrust -Djava.security.egd=file:///dev/urandom -Dweblogic.ssl.JSSEEnabled=true -Dweblogic.security.SSL.enableJSSE=true -Dwlst.offline.log=/u01/logs/wlst_extend_domain.log"

Run the following extend domain script for WebLogic Server:

/opt/scripts/decryptStrings.sh 1 | /u01/app/oracle/middleware/oracle_common/common/bin/wlst.sh -skipWLSModuleScanning /opt/scripts/extend_12c_domain.py

Access the respective WebLogic console to verify the updates you performed to the instances. See Access the WebLogic Server Administration Console.