Before You Begin

Understand Service Requirements

You require access to several services in order to use Oracle WebLogic Server for OCI.

Identity and Access Management (IAM)
Compute, Network, Block Storage
Vault, Key, Secret
Resource Manager
Load Balancing (optional)
Database (optional)
Tagging (optional)

Check the service limits for these components in your Oracle Cloud Infrastructure tenancy and, if necessary, request a service limit increase.

In Oracle Cloud Infrastructure Vault (formerly known as Key Management), a standard vault is hosted on a hardware security module (HSM) partition with multiple tenants, and uses a more cost-efficient, key-based metric for billing purposes. A virtual private vault provides greater isolation and performance by allocating a dedicated partition on an HSM. Each type of vault has a separate service limit in your Oracle Cloud Infrastructure tenancy. The limit for secrets spans all vaults.

See:

Service Limits in the Oracle Cloud Infrastructure documentation
Oracle Cloud Infrastructure Vault FAQ

Create a Compartment

Create compartments for your Oracle WebLogic Server for OCI resources, or use existing compartments.

This task is typically performed by an administrator.

When you create a domain with Oracle WebLogic Server for OCI, by default the compute instances, networks, and load balancer are all created within a single compartment. You can, however, choose to use two compartments, one compartment just for the compute instances (WebLogic Server and bastion nodes), and another compartment for all the network resources that are created for the domain (including load balancer, virtual cloud network, subnets, route tables, gateways, and network security groups or security lists).

See Managing Compartments in the Oracle Cloud Infrastructure documentation.

Create Policies

Access to Oracle Cloud Infrastructure is controlled through policies.

There are two major groupings of policies that are required by Oracle WebLogic Server for OCI:

User Group Policies

Oracle WebLogic Server for OCI runs terraform scripts on behalf of the user who is running the OCI stack. Therefore, when running the stack you must have certain OCI policies set up to create the required OCI resources.

Required Policies

Unless you are an OCI administrator for a tenancy, the following policies must be set up for the OCI Identity Group that you are a member of. You must set up these user group policies prior to creating a Oracle WebLogic Server for OCI instance.

In the following listed policies:

MyGroup is the group name of the user who will create the OCI stack.
MyCompartment and MySecretCompartment is name of the compartment in which the resources will be created or updated.

Table 1-3 Required User Group Policies

Policy	Description	Policy Location
`Allow group MyGroup to inspect instance-image in compartment MyCompartment`	To use the WebLogic custom images from Marketplace	Stack Compartment
`Allow group MyGroup to use app-catalog-listing in compartment MyCompartment`	To use the Marketplace applications	Stack Compartment
`Allow group MyGroup to manage instance-family in compartment MyCompartment`	To create Compute Instances	Stack Compartment
`Allow group MyGroup to manage volume-family in compartment MyCompartment`	To create Block Volumes	Stack Compartment
`Allow group MyGroup to manage orm-family in compartment MyCompartment`	To create stacks	Stack Compartment
`Allow group MyGroup to inspect secrets in compartment MySecretCompartment`	To display the list of secrets in the UI	Secret Compartment
`Allow group MyGroup to inspect limits in tenancy`	To determine if resources are available in various compartments	Root Compartment
`Allow group MyGroup to inspect tenancies in tenancy`	To locate the home region for the tenancy	Root Compartment
`Allow group MyGroup to use virtual-network-family in compartment MyNetworkCompartment`	To set the networking configuration when creating compute instances.	Network Compartment

Stack Selection Policies

Unless you are an OCI administrator for your tenancy, there are user group policies that must be set up based on the selections that you make in the Oracle Cloud Infrastructure console or the OCI CLI.

The following table list the policies required for specific selections you intend to make.

In the following listed policies:

MyGroup is the group name of the user who will create the OCI stack.
MyCompartment, MyNetworkCompartment, and MyDBCompartment is name of the compartment in which the resources will be created or updated.

Table 1-4 User Group Policies Based on Stack Selection

Selection	Policy	Description	Policy Location
Network Create a new VCN Create a New Subnet	`Allow group MyGroup to manage virtual-network-family in compartment MyNetworkCompartment`	To create VCNs and subnets	Network Compartment
Load Balancer Add a Load Balancer Enable Authentication Using Identity Cloud Service	`Allow group MyGroup to manage load-balancers in compartment MyNetworkCompartment`	To create a load balancer	Network Compartment
Enable Application Performance Monitoring	`Allow group MyGroup to read metrics in compartment MyCompartment where target.metrics.namespace='oracle_apm_monitoring'`	To view and retrieve monitoring metrics	APM Domain Compartment
Enable Application Performance Monitoring	`Allow group MyGroup to read apm-domains in compartment MyAPMDomainCompartment`	To list the APM domains in the UI and to identify the compartment associated with the selected APM domain.	APM Domain Compartment
Enable Exporting Logs to OCI Logging Service	`Allow group MyGroup to manage log-groups in compartment MyCompartment`	To create log groups	Stack Compartment
	`Allow group MyGroup to use log-content in compartment MyCompartment`	To view the logs	Stack Compartment
	`Allow group MyGroup to manage unified-configuration in compartment MyCompartment`	To provision agent configurations	Stack Compartment
Enable Autoscaling	`Allow group MyGroup to read objectstorage-namespaces in tenancy`	To read objectstorage namespace for tenancy	Root Compartment
	`Allow group MyGroup to manage repos in tenancy`	To create repository and push images to repository	Root Compartment (this can be moved to compartment if we use repos from compartment)
	`Allow group MyGroup to manage functions-family in compartment id MyCompartmentOCID`	To deploy and manage OCI Functions and function application	Stack Compartment
	`Allow group MyGroup to manage ons-subscriptions in compartment id MyCompartmentOCID`	To create and manage topic subscriptions	Stack Compartment
	`Allow group MyGroup to manage ons-topics in compartment id MyCompartmentOCID`	To create and manage topics	Stack Compartment
	`Allow group MyGroup to manage alarms in compartment id MyCompartmentOCID`	To create and manage Alarms	Stack Compartment
	`Allow group MyGroup to manage cloudevents-rules in compartment id MyCompartmentOCID`	To create cloud event rules	Stack Compartment
	`Allow group MyGroup to use cloud-shell in tenancy`	Required for deleting autoscaling resources before stack deletion	Root Compartment
OCI Policies	`Allow group MyGroup to manage dynamic-groups in tenancy`	To create dynamic groups. See Dynamic Group Policies.	Root Compartment
OCI Policies	`Allow group MyGroup to manage policies in tenancy`	To create policies in the root compartment	Root Compartment
Use Resource Manager Private Endpoint	`Allow group MyGroup to manage orm-family in compartment MyNetworkCompartment`	To create private endpoints	Network Compartment
Use Resource Manager Private Endpoint	`Allow group MyGroup to manage virtual-network-family in compartment MyNetworkCompartment`	To create private endpoints	Network Compartment
Provision with JRF and Autonomous Transaction Database Processing	`Allow group MyGroup to inspect autonomous-transaction-processing-family in compartment MyDBCompartment`	To display the list of available Autonomous Databases	DB Compartment
Provision with JRF and Database System	`Allow group MyGroup to inspect database-family in compartment MyDBCompartment`	To display the list of databases available	DB Compartment
Provision with JRF and Database System	`Allow group MyGroup to manage virtual-network-family in compartment MyDBCompartment`	To create a security list to allow ingress from WebLogic Server	DB Compartment
Add File System Storage	`Allow group MyGroup to manage mount-targets in compartment MyCompartment`	To create mount target and associate a file system with an existing mount target	Mount Target Compartment
	`Allow group MyGroup to manage file-systems in compartment MyCompartment`	To create a shared file system	FSS Compartment
	`Allow group MyGroup to manage export-sets in compartment MyCompartment`	To create export-sets	FSS Compartment
Add File System Storage and Existing File System	`Allow group MyGroup to read mount-targets in compartment MyCompartment`	To read existing mount targets for mounting existing FSS	Mount target Compartment
Add File System Storage and Existing Mount target	`Allow group MyGroup to use mount-targets in compartment MyCompartment`	To read existing mount targets for mounting new FSS	Mount Target Compartment
	`Allow group MyGroup to manage file-systems in compartment MyCompartment`	To create a shared file system	FSS Compartment
	`Allow group MyGroup to manage export-sets in compartment MyCompartment`	To create FSS export-sets for mount target	FSS Compartment

Dynamic Group Policies

When Oracle WebLogic Server for OCI starts up a Compute instance, certain scripts make OCI API calls. The Compute instances are granted the privileges by defining an Oracle Cloud Infrastructure dynamic group that includes the Compute instance and assigning that dynamic group to a set of policies. You can choose to create these policies prior to creating the OCI stack or you can choose to let the stack creation terraform scripts create these policies for you by selecting the OCI Policies option.

If you want the Oracle WebLogic Server for OCI stack to create the dynamic groups and policies for you, then be sure to have your OCI administrator construct the following user group policies:

Table 1-5 Dynamic Group Policies

Policy	Description	Policy Location
`Allow group MyGroup to manage dynamic-groups in tenancy`	To create dynamic groups	Root Compartment
`Allow group MyGroup to manage policies in tenancy`	To create policies in the root compartment	Root Compartment
`Allow group MyGroup to manage tag-namespaces in tenancy`	To create defined tags in tenancy for a stack (used for dynamic group-based policy setup)	Root Compartment

Create a Dynamic Group

If you choose to create the policies prior to stack creation your OCI administrator must create the OCI dynamic group and the OCI policies.

To create a dynamic group, complete the following steps:

Access the Oracle Cloud Infrastructure console.
From the navigation menu, select Identity & Security. Under the Identity group, click Compartments.
Locate the compartment you plan to use for the compute instances. Then in the OCID column, copy the compartment's OCID.

An OCID value looks similar to this: ocid1.compartment.oc1..alongstringoflettersandnumbers123.
Click Dynamic Groups.
Click Create Dynamic Group.
Enter a Name and Description.
For Rule 1, create a rule that includes all instances in the named compartment as members of this group.

instance.compartment.id = 'WLS_Compartment_OCID'

Provide the OCID for the compartment you copied in step 3.

Note:
If domains can be created in more than one compartment, click Rule Builder to select Any of the following and then use separate lines to add each compartment OCID.
Click Create Dynamic Group.

If you choose to create the policies yourself, prior to stack creation, your OCI administrator must create the OCI dynamic group and the OCI policies.

Required policies

The following table lists the required policies (if the OCI Policies option is not selected):

Table 1-6 Required policies (if the OCI Policies option is not selected)

Policy	Description	Policy Location
`Allow dynamic-group MyInstancesPrincipalGroup to manage instance-family in compartment MyCompartment`	To add volumes to Compute instances	Stack Compartment
`Allow dynamic-group MyInstancesPrincipalGroup to manage volume-attachments in compartment MyCompartment`	To attach volumes to Compute instances	Stack Compartment
`Allow dynamic-group MyInstancesPrincipalGroup to inspect volumes in compartment MyCompartment`	To look up volumes, so that, they can be added and attached	Stack Compartment
`Allow dynamic-group MyInstancesPrincipalGroup to manage volumes in compartment MyCompartment`	For future Cloning options to delete unneeded volumes	Stack Compartment
`Allow dynamic-group MyInstancesPrincipalGroup use osms-managed-instances in compartment MyCompartment`	To use the OS Management Service (OSMS)	Stack Compartment
`Allow dynamic-group MyInstancesPrincipalGroup to read instance-family in compartment MyCompartment`	Required by the OSMS agent	Stack Compartment
`Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in tenancy where target.secret.id = '<OCID_of_wls_password_secret>'`	To set up the WLS domain administrator user	Root Compartment

Stack selection policies

The following tables lists the policies that are based on stack selection, if the OCI Policies option is not selected:

Table 1-7 Policies based on stack selection if the OCI Policies option is not selected

Selection	Policy	Description	Policy Location
Network Create a new VCN Create a New Subnet	`Allow dynamic-group MyInstancesPrincipalGroup to manage virtual-network-family in compartment MyNetworkCompartment`	To read VCN information like CIDR, and so on, for VCN validation	Network Compartment
Load Balancer Add a Load Balancer Enable Authentication Using Identity Cloud Service	`Allow dynamic-group MyInstancesPrincipalGroup to manage load-balancers in compartment MyNetworkCompartment`	To add load balancer backends	Network Compartment
Enable Authentication Using Identity Cloud Service	`Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in tenancy where target.secret.id = '<OCID_idcs_password_secret>'`	To set the correct Client secret for the IDCS confidential application that will be created	Secret Compartment
Provision with JRF and Autonomous Transaction Database Processing	`Allow dynamic-group MyInstancesPrincipalGroup to use autonomous-transaction-processing-family in compartment MyDBCompartment`	To get the wallet from an Autonomous Database so RCU data sources can be set up	DB Compartment
	`Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in tenancy where target.secret.id = '<OCID_of_db_password_secret>'`	To get the ADMIN user required to run RCU	Root Compartment
Provision with JRF and Database System	`Allow dynamic-group MyInstancesPrincipalGroup to inspect database-family in compartment MyDBCompartment`	To display the list of databases available	DB Compartment
Provision with JRF and Database System	`Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in tenancy where target.secret.id = '<OCID_of_db_password_secret>'`	To get the user with sysdba role required to run RCU	Root Compartment
Configure Observability and Enable Exporting Logs to OCI Logging Service	`Allow dynamic-group MyInstancesPrincipalGroup to use logging-family in compartment MyCompartment`	To associate WLS logs with OCI Logging Service	Stack Compartment
Enable Autoscaling	`Allow dynamic-group MyInstancesPrincipalGroup to use tag-namespaces in tenancy`	To use the tag the OCI functions	Root Compartment
	`Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in tenancy where target.secret.id = '<ocid_of_auth_token_secret>'`	To read secret to access OCI repository	Root Compartment
	`Allow dynamic-group MyInstancesPrincipalGroup to use repos in tenancy`	To create repository for OCI functions	Root Compartment
	`Allow dynamic-group MyInstancesPrincipalGroup to manage functions-family in compartment MyCompartment`	To create OCI functions	Stack Compartment
	`Allow dynamic-group MyInstancesPrincipalGroup to manage ons-subscriptions in compartment MyCompartment`	To create topic subscriptions	Stack Compartment

For information about removing secrets and policies, see About Deleting Secrets and Policies.

Dynamic Group Policies for Autoscaling

The dynamic group must include the compartment in which functions are created and the type of resource is fnfunc.

Create the dynamic group and required policies using a script

If you choose to create the policies prior to stack creation, then your OCI administrator must create the OCI dynamic group that includes the compartment that will contain the OCI Function application and functions.

To create a dynamic group for autoscaling, complete the following steps:

Create the script.
1. Create a file with name: create_autoscaling_policies.py
2. Go to Script File to Create Policies for Autoscaling Functions Post Provisioning.
3. Copy and paste the script to the create_autoscaling_policies.py file.
4. Save the file.
Run the following command from cloud shell:

Note:
Ensure you have tenancy administrator privilege.
```
python3 create_autoscaling_policies.py <OCID_of_the_stack>
```
To run the script in a non-home region, run the following command:
```
python3 create_autoscaling_policies.py <OCID_of_the_stack> --region <non-home_region>
```
Note:
The script uses the stack's OCID and creates function's dynamic group and policy with permissions for the function's dynamic group. It verifies if the stack has create_policies set to false, in which case it returns an error that policies would be automatically created via stack. However, you can use the --force option to override and create dynamic group and policies when create_policies == true.

Create the dynamic group and required policies through the OCI console

If you do not want to use the script, then to create the dynamic group for the function, add the following dynamic group entry:

ALL {resource.type = 'fnfunc', resource.compartment.id='ocid_for_stack_compartment'}

If you choose to create the policies yourself prior to stack creation and select autoscaling for your stack, your OCI administrator must create the OCI autoscaling policies.

Required policies

The following table lists the required policies (if the OCI Policies option is not selected):

Table 1-8 Required policies (if the OCI Policies option is not selected)

Policy	Description	Policy Location
`Allow dynamic-group FunctionDynamicGroup to inspect tenancies in tenancy`	For scaling functions to read `objectstorage` namespace for tenancy	Root Compartment
`Allow dynamic-group FunctionDynamicGroup to inspect limits in tenancy`	For scaling functions to determine if resources can be created in Network and Stack Compartment	Root Compartment
`Allow dynamic-group FunctionDynamicGroup to manage repos in tenancy`	For scaling functions to perform reapply during scaling	Root Compartment
`Allow dynamic-group FunctionDynamicGroup to use tag-namespaces in tenancy`	For scaling functions to use tags for the resource that might be created during reapply	Root Compartment
`Allow dynamic-group FunctionDynamicGroup to manage instance-family in compartment MyCompartment`	For scaling functions to create new instances during scale out	Root Compartment
`Allow dynamic-group FunctionDynamicGroup to manage policies in tenancy`	For scaling functions to update or add policies based on stack configuration changes	Root Compartment
`Allow dynamic-group FunctionDynamicGroup to inspect dynamic-groups in tenancy`	For scaling OCI functions to inspect dynamic groups during stack reapply	Root Compartment
`Allow dynamic-group FunctionDynamicGroup to use app-catalog-listing in compartment MyCompartment`	For scaling OCI functions to scale a stack created using Marketplace Listing	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to manage orm-family in compartment MyCompartment`	For scaling OCI functions to scale a stack by executing ORM stack apply	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to manage orm-family in compartment MyNetworkCompartment`	For scaling OCI functions to create resource manager private endpoint	Network Compartment
`Allow dynamic-group FunctionDynamicGroup to manage volume-family in compartment MyCompartment`	For scaling OCI functions to create volumes for new scaled out instances	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to manage virtual-network-family in compartment MyCompartment`	For scaling OCI functions for VCN CIDR validations	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to manage load-balancers in compartment MyNetworkCompartment`	For scaling OCI functions to add or remove load balancers and update backend set	Network Compartment
`Allow dynamic-group FunctionDynamicGroup to read metrics in compartment MyAPMDomainCompartment`	For scaling OCI functions to have permission to perform re-apply on the stack	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to use instance-agent-command-execution-family in compartment MyCompartment`	For scaling OCI functions to perform re-apply on the stack for scaling event	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to manage functions-family in compartment MyCompartment`	For scaling OCI functions to have permission to perform re-apply on the stack	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to read secret-bundles in tenancy where target.secret.id ='<ocir auth token>'`	For scaling OCI functions to have permission to read secret for repository	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to manage instance-agent-command-family in compartment MyCompartment`	To scaling OCI functions to perform re-apply on the stack for scaling event	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to use apm-domains in compartment MyAPMDomainCompartment`	To scaling OCI functions to perform re-apply on the stack for scaling event	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to manage alarms in compartment MyCompartment`	To scaling OCI functions to have permission to perform re-apply on the stack	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to manage cloudevents-rules in compartment MyCompartment`	For scaling OCI functions to have permission to perform re-apply on the stack	Stack Compartment
`Allow dynamic-group FunctionDynamicGroup to manage ons-topics in compartment MyCompartment`	For scaling OCI functions to have permission to perform re-apply on the stack	Stack Compartment

Stack selection policies

The following table lists the autoscaling policies that are based on stack selection (if the OCI Policies option is not selected):

Table 1-9 Policies based on stack selection (if the OCI Policies option is not selected)

Selection	Policy	Description	Policy Location
Provision with JRF and Autonomous Transaction Database Processing	`Allow dynamic-group FunctionDynamicGroup to inspect autonomous-transaction-processing-family in compartment MyDBCompartment`	To get the wallet from an Autonomous Database, so that RCU data sources can be set up	DB Compartment
Provision with JRF and Database System	`Allow dynamic-group FunctionDynamicGroup to inspect database-family in compartment MyDBCompartment`	To run some validations based on DB data sources	DB Compartment
Configure Observability and Enable Exporting Logs to OCI Logging Service	`Allow dynamic-group FunctionDynamicGroup to manage log-groups in compartment MyCompartment`	To create log group	Stack Compartment
	`Allow dynamic-group FunctionDynamicGroup to use log-content in compartment MyCompartment`	To view the logs	Stack Compartment
	`Allow dynamic-group FunctionDynamicGroup to manage unified-configuration in compartment`	To provision agent configurations	Stack Compartment

Create an Encryption Key

An encryption key allows you to encrypt the contents of secrets required for Oracle WebLogic Server for OCI.

Oracle WebLogic Server for OCI can use one or more keys in Oracle Cloud Infrastructure Vault to decrypt the secrets for a single domain.

Use Oracle Cloud Infrastructure Vault to create a vault and encryption key, or use an existing vault and key. Oracle WebLogic Server for OCI supports keys in standard vaults and virtual private vaults. See Managing Keys in the Oracle Cloud Infrastructure documentation.

Create Secrets for Passwords

Use secrets in Oracle Cloud Infrastructure Vault to store the passwords that you need to create a domain with Oracle WebLogic Server for OCI.

You must provide secrets for these passwords:

Administrator password for the new domain
Administrator password for an existing database, if you are creating a domain that includes the Java Required Files (JRF) components
Client secret for an existing confidential application, if you are creating a domain that uses Oracle Identity Cloud Service for authentication

You must use Oracle Cloud Infrastructure Vault to create your secrets. When you create a domain using Oracle WebLogic Server for OCI, you'll be asked to provide the OCID values of the secrets.

To create a secret and copy the OCID:

Access the Oracle Cloud Infrastructure console.
Navigate to the vault that contains your encryption key.
Click Secrets, and then click Create Secret.
Enter a name to identify the secret.
Select your encryption key.
The key is used to encrypt the secret contents while they are imported to the vault.
In Secret Contents, specify the password you want to store in this secret.
Ensure the password meets the criteria for which it will be used (for example, the WebLogic Server administrator password requires that it starts with an alphabet, is between 8 and 30 characters long, contains at least one numeric, and optionally, any number of the special characters: '$', '#', and '_'. For example, Ach1z0#d.).
Passwords entered in plain-text are base64-encoded before they are sent to Oracle WebLogic Server for OCI.
Click Create Secret.
When the secret is created, click the name.
Copy the OCID for the secret.
Repeat steps 2 through 9 to create the remaining secrets you need.

See Managing Secrets in the Oracle Cloud Infrastructure documentation.

For information about removing secrets and policies, see About Deleting Secrets and Policies.

Create an SSH Key

Create a secure shell (SSH) key pair so that you can access the compute instances in your Oracle WebLogic Server domains.

A key pair consists of a public key and a corresponding private key. When you create a domain using Oracle WebLogic Server for OCI, you specify the public key. You then access the compute instances from an SSH client using the private key.

On a UNIX or UNIX-like platform, use the ssh-keygen utility. For example:

ssh-keygen -b 2048 -t rsa -f mykey
cat mykey.pub

On a Windows platform, you can use the PuTTY Key Generator utility. See Creating a Key Pair in the Oracle Cloud Infrastructure documentation.

Create a Virtual Cloud Network

Oracle WebLogic Server for OCI can create a Virtual Cloud Network (VCN) in Oracle Cloud Infrastructure for a new Oracle WebLogic Server domain, or you can create your own VCN before creating a domain.

A VCN includes one or more subnets, route tables, gateways, DHCP options, and network security groups or security lists.

By default subnets are public. Any compute instances assigned to a private subnet cannot be directly accessed from outside of Oracle Cloud.

If you create a VCN before creating a domain, then the VCN must meet the following requirements:

The VCN must use DNS for hostnames.
If you plan to use a public subnet for the bastion or load balancer, then the VCN must include an Internet Gateway.
If you plan to create a public subnet in the VCN before creating a domain, then the VCN must include a route table that directs traffic to the Internet Gateway.
When you create DHCP options, it is recommended to select the DNS type as Internet and VCN Resolver. If your network configuration demands you to select Custom Resolver, then add Oracle DNS Server IP 169.254.169.254 as the last DNS server entry.

If you plan to use a private subnet for the Oracle WebLogic Server compute instances, then the VCN must meet these additional requirements:

The VCN for the bastion must have a route table that directs traffic to the Internet Gateway.
The VCN must include a service gateway or a Network Address Translation (NAT) gateway, to provide access to other cloud services. For a service gateway, select the option All <Region> Services In Oracle Services Network.
If you want to create the private subnet before creating a domain, then the VCN must also include a route table that directs traffic to the service gateway or the NAT gateway. For a service gateway route rule, select the option All <Region> Services In Oracle Services Network. If you intend to have your WebLogic Domain authenticate users from an enterprise application, formerly known as using Oracle Identity Cloud Service (IDCS) in WLS for OCI, you must use a NAT gateway.
If you use a private subnet for a WebLogic domain, which requires access to the internet, then the VCN must also include a route table that directs traffic to access the NAT gateway.

If you use an existing VCN for a domain, and also choose for Oracle WebLogic Server for OCI to create new subnets for the domain, then Oracle WebLogic Server for OCI will also create the required route tables in the VCN.

If you use an existing VCN and existing subnets in Oracle WebLogic Server for OCI, you can certify the existing network setup using helper scripts. See Validate Existing Network.

See these topics in the Oracle Cloud Infrastructure documentation:

Create a Private Endpoint

Oracle WebLogic Server for OCI can create private endpoints in Oracle Cloud Infrastructure that allows you to check the status of the resources in your domain. You can also create your own private endpoints before creating a domain.

See Managing Private Endpoints in Oracle Cloud Infrastructure documentation.

Create a Network Security Group

Oracle WebLogic Server for OCI can create network security groups (NSGs) in Oracle Cloud Infrastructure for a new Oracle WebLogic Server domain, or you can create your own NSGs before creating a domain.

In Oracle WebLogic Server for OCI, you can use NSGs for your compute instances, load balancer, bastion instance, and file storage.

For an NSG security rule's source (for ingress rules) or destination (for egress rules), you can specify an NSG ID instead of a CIDR. This means you can easily write security rules to control traffic between two NSGs in the same VCN, or traffic within a single NSG.

You can create one NSG for each type of resource; each resource will have it's own set of security rules.

If you want to use an existing NSG for your resources, the NSGs must include specific security rules. The following table lists the security rules for the NSGs:

Table 1-10 Network Security Group Rules

NSG	Rule Type	Protocol	Source	Target	Destination Ports	Description
Bastion	Stateful Ingress	TCP	0.0.0.0/0		22	SSH access
Bastion	Stateful Egress	All		0.0.0.0/0	All	Egress to everything
Load Balancer	Stateful Ingress	TCP	0.0.0.0/0		443	Application traffic using HTTPS
Load Balancer	Stateful Egress	All		0.0.0.0/0	All	Egress to everything
WebLogic Administration Server	Stateful Ingress	TCP	Bastion NSG OCID		7001, 7002	Administration Server ports
WebLogic Managed Server	Stateful Ingress	TCP	Admin network, or load balancer NSG OCID		7003, 7004	Managed Server ports
WebLogic Managed Server	Stateful Ingress	TCP	Bastion NSG OCID		22	SSH access
WebLogic Managed Server	Stateful Ingress	TCP	Load balancer NSG OCID		9999 or custom redirect port	App Gateway in Oracle Identity Cloud Service
WebLogic Managed Server	Stateful Ingress	All	WebLogic Managed Server NSG OCID		All	All ports among server
WebLogic Managed Server	Stateful Egress	TCP		Database network CIDR	1521 or custom DB port	Database for JRF-enabled domain
WebLogic Managed Server	Stateful Egress	All		0.0.0.0/0	All	Egress to everything
Mount Target	Stateful Ingress	TCP	VCN CIDR		2048-2050	File system integration
Mount Target	Stateful Ingress	TCP	VCN CIDR		111	File system integration
Mount Target	Stateful Ingress	UDP	VCN CIDR		111	File system integration
Mount Target	Stateful Ingress	UDP	VCN CIDR		2048	File system integration
Mount Target	Stateful Egress	TCP	VCN CIDR		2048-2050	File system integration
Mount Target	Stateful Egress	TCP	VCN CIDR		111	File system integration
Mount Target	Stateful Egress	UDP	VCN CIDR		111	File system integration

If you use existing subnets and existing network security groups during stack creation, you can create the NSGs using a script.

To use the script, create a file named, create_nsg, and copy and paste the script in create_nsg.sh to this create_nsg file.

Then run the following commands:

#Set execute permission to the create_nsg.sh file. 
chmod +x create_nsg.sh
./create_nsg.sh -w <WLS_Subnet_OCID> -l <Load_Balancer_Subnet_OCID> -b <Bastion_Subnet_OCID> -f <File_System_Storage_Subnet_OCID> -d <Database_Subnet_OCID>

This script creates NSGs and adds the security rules to the NSGs, for compute instances, load balancer, bastion instance, file system, and database subnet.

See Network Security Groups in the Oracle Cloud Infrastructure documentation.

Create a Private Subnet for the Oracle WebLogic Server Nodes

Oracle WebLogic Server for OCI can create a subnet in Oracle Cloud Infrastructure for a new Oracle WebLogic Server domain, or you can create your own subnet before creating a domain.

A subnet is a component of a Virtual Cloud Network (VCN). When you create a domain with Oracle WebLogic Server for OCI, the Oracle WebLogic Server compute instances are assigned to a subnet.

By default subnets span an entire region in Oracle Cloud Infrastructure.

Oracle WebLogic Server for OCI supports both regional and AD-scoped subnets.

If you assign a private subnet to the domain, the nodes cannot be directly accessed from outside of Oracle Cloud. Oracle WebLogic Server for OCI can create a bastion node on a public subnet, which you can use to administer the nodes that comprise your domain.

If you assign a private subnet that needs access to the public internet, you must include a route table that directs traffic to the NAT gateway.

If you want to use an existing subnet for the Oracle WebLogic Server nodes when creating a domain, the subnet must meet the following requirements:

The subnet must use DNS for hostnames.
The subnet must have a security list that enables inbound access to the SSH port (22) and to the administration server ports (by default, 7001 and 7002).
Alternatively, if you want to use network security groups (NSGs), the VCN of the subnet must have a network security group that enables inbound access to the SSH port (22) and to the administration server ports (by default, 7001 and 7002)
The subnet must have a security list that enables inbound access to the managed server ports (by default, 7003 and 7004).
Alternatively, if you want to use network security groups, the VCN of the subnet must have a network security group that enables inbound access to the managed server ports (by default, 7003 and 7004) on the subnet you plan to use for WebLogic Server.

If you are using a load balancer, the security list's source or the NSG's source should be restricted to the subnets that you plan to use for the load balancer.
If you are creating a domain that uses Oracle Identity Cloud Service to authenticate application users, the subnet must have a security list that enables inbound access to the listen port for the App Gateway in Oracle Identity Cloud Service (by default, 9999).
If you are creating a domain with the Java Required Files (JRF) components, the subnet must have a security list that enables outbound access to the database port (1521 by default) on the database subnet.
If you are creating a domain with the JRF components, and the database is on a different VCN, then the subnet must have a security list that enables outbound access to port 53 (both TCP and UDP) on the subnet that you plan to create for DNS. The subnet must also be associated with the default DHCP option for the VCN (Default DHCP Options for <vcn_name>). The subnet cannot use a custom DNS resolver.

If you use an existing subnet, you can specify the subnet compartment that is different than the VCN compartment.

If you use an existing subnet, you can certify the existing network setup using helper scripts. See Validate Existing Network.

The following diagram illustrations the default destination ports.

Figure 1-6 Default Destination Ports

The following table summarizes the security list requirements for an existing subnet. However, if you use network security groups, refer the Network Security Rules table in Create a Network Security Group.

Note:

If you change the default ports when creating a domain, then open the related ports accordingly.

Table 1-11 Security List Rules

Rule Type	Source CIDR and Protocol	Default Destination Ports	Description
Stateful Ingress	Bastion network, TCP	22	SSH access
Stateful Ingress	Bastion network, TCP	7001, 7002	Administration Server ports
Stateful Ingress	Weblogic subnet, CIDR	22	Administration server ports
Stateful Ingress	Weblogic subnet, CIDR	9071	Used for provisioning and scaling
Stateful Ingress	Weblogic subnet, CIDR	5556	Used for accessing node manager
Stateful Ingress	Your admin network, or your load balancer subnet, TCP	7003, 7004	Managed Server ports
Stateful Ingress	Your load balancer subnet, TCP	9999 or custom redirect port	App Gateway in Oracle Identity Cloud Service
Stateful Ingress	Your database network, TCP	1521 or custom DB port	Database for JRF-enabled domain
Stateful Ingress	DNS subnet, TCP	53	JRF-enabled domain and database is on a different VCN
Stateful Ingress	DNS subnet, UDP	53	JRF-enabled domain and database is on a different VCN
Stateful Ingress	Mount target subnet, TCP	2048-2050	File system integration
Stateful Ingress	Mount target subnet, TCP	111	File system integration
Stateful Ingress	Mount target subnet, UDP	111	File system integration
Stateful Ingress	Mount target subnet, UDP	2048	File system integration
Stateful Egress	Mount target subnet, TCP	2048-2050	File system integration
Stateful Egress	Mount target subnet, TCP	111	File system integration
Stateful Egress	Mount target subnet, UDP	111	File system integration

See VCNs and Subnets in the Oracle Cloud Infrastructure documentation.

Configure the Load Balancer

Oracle WebLogic Server for OCI can create a load balancer in Oracle Cloud Infrastructure that is used to distribute traffic across the servers in your domain, or you can use your own load balancer for the domain.

Note:

If you use your own load balancer, create it in the Network compartment, not the Stack compartment.
The following instructions assume that you want to use TLS (SSL) on the load balancer and terminate TLS (SSL) at the load balancer.
- If you are not using TLS (SSL), then you should not add the Rule Set and the Certificate Resource that are mentioned as part of the instructions.
- If you are not terminating TLS (SSL) at the load balancer, you should ensure the following:
  - Do not add the Rule Set.
  - Change the port to the HTTPS port used by the managed servers to 7004 or the HTTPS port that matches with the managed server HTTPS port of the backend set.
  - Add the TLS (SSL) certificates required to access the managed server over HTTPS. See Adding a Load Balancer Certificate.

If you use an existing load balancer, then you must configure the load balancer as follows:

Create a backend set

Specify the load balancing and the health check policy for the backend set.

Note:

When you create a backend set, do not add backends for the backend set.

In the Oracle Cloud Infrastructure Console, from the navigation menu , click Networking, and then click Load Balancers.
Click the name of the load balancer.
Under Resources, click Backend Sets.
Click Create Backend Set.
Enter a name for the backend set.
From Traffic Distribution Policy, select Weighted Round Robin.
From Session Persistence, select Enable load balancer cookie persistence.
Specify the following properties for Health Check:
- Protocol: HTTP
- Port: 7003
  The default port is 7003. You must specify the port that matches with managed server port of the backend set.
- Interval in MS: 30000
- Timeout in MS: 3000
- Number of retries: 3
- Status code: 404
- URL Path (URI): /
- Response body regex: .*
Click Create Backend Set.

Create a rule set

Specify the rule sets for the load balancer.

In the Oracle Cloud Infrastructure Console, from the navigation menu , click Networking, and then click Load Balancers.
Select the Compartment in which the network resources for your domain were created.
Click the name of the load balancer.
Click Rule sets.
Click Create rule set.
For Name, enter SSLHeaders.
Click Specify request header rules.
Specify the following header parameters:
- Action: Add Request Header
- Header: is_ssl
- Value: ssl
Click Another request header rule.
Specify the following header parameters:
- Action: Add Request Header
- Header: WL-Proxy-SSL
- Value: true
Click Create, and then click Close.

Create a listener

Specify the listener properties for the load balancer.

In the Oracle Cloud Infrastructure Console, from the navigation menu , click Networking, and then click Load Balancers.
Click the name of the load balancer.
Under Resources, click Listeners.
Click Create Listener.
Enter a Name for the listener.
Select the HTTPS Protocol.
For Port, enter 443.
For Certificate Resource, select Load Balancer Managed Certificate, if not already selected, and then select the Certificate Name that you imported for the certificate resource.
Select the backend set that you created for the load balancer. See Create a backend set.
Click Create Listener.
After the listener is created, edit it to add the Rule Set you created earlier. See Create a rule set.
In the Edit listener page, in the Rule sets section, select the rule set SSLHeaders from the drop-down list.
Click Save changes, and then click Close.

Add the routing policy

Specify the routing policy for the load balancer.

In the Oracle Cloud Infrastructure Console, from the navigation menu , click Networking, and then click Load Balancers.
Click the name of the load balancer.
Under Resources, click Routing policies.
Click Routing Policy.
Enter a name for the routing policy.
Specify the following conditions for the rule:
- When the following conditions are met…: If All Match
- Condition Type: Path
- Operator: Is
- URL String: /myPath
Select the backend set that you created for the load balancer. See Create a backend set.
Click Next.
In the Change Order column, corresponding to the rule, click the down arrow to see a summary of the conditions and actions set in a rule.
Click Reorder to move a rule up or down in the policy order.
When the routing policy rules are created and in the right order, click Create Routing Policy.

See the following topics in Oracle Cloud Infrastructure documentation:

Create a Subnet for the Load Balancer

Oracle WebLogic Server for OCI can create subnets in Oracle Cloud Infrastructure for the load balancer that is used to access an Oracle WebLogic Server domain, or you can create your own subnets before creating a domain.

A subnet is a component of a Virtual Cloud Network (VCN). When you create a domain with a load balancer using Oracle WebLogic Server for OCI, the load balancer is assigned a subnet.

By default subnets span an entire region in Oracle Cloud Infrastructure.

To ensure high availability for a load balancer, you must assign it either one regional subnet, or two AD-scoped subnets.

If you want to use an existing subnet for the load balancer, the subnet must meet the following requirements:

The subnet must use DNS for hostnames.
The subnet must be public.
The subnet must have a security list that enables inbound access to ports 80 and 443.
Alternatively, if you want to use network security groups (NSGs), the VCN of the subnet must have a network security group that enables inbound access to ports 80 and 443.
The subnet must have a security list that enables outbound access to the managed server ports (by default, 7003 and 7004) on the subnet that you plan to use for Oracle WebLogic Server.
Alternatively, if you want to use network security groups, the VCN of the subnet must have a network security group that enables outbound access to the managed server ports (by default, 7003 and 7004) on the subnet that you plan to use for Oracle WebLogic Server.

If you use an existing subnet, you can specify the subnet compartment that is different than the VCN compartment.

If you use an existing subnet, you can certify the existing network setup using helper scripts. See Validate Existing Network.

See VCNs and Subnets in the Oracle Cloud Infrastructure documentation.

Create a Subnet for the Bastion Node

Oracle WebLogic Server for OCI can create a public subnet in Oracle Cloud Infrastructure for the bastion node that is used to access a private Oracle WebLogic Server domain, or you can create your own subnet before creating a domain.

A subnet is a component of a Virtual Cloud Network (VCN). When you create a domain in Oracle WebLogic Server for OCI, you can assign the Oracle WebLogic Server compute instances to a public subnet or a private subnet. If you assign a private subnet, then the compute instances can not be directly accessed from outside of Oracle Cloud. Oracle WebLogic Server for OCI can create a bastion compute instance on a public subnet, and from this bastion you can administer the Oracle WebLogic Server compute instances.

Note:

Configuring a bastion is optional.

If you do not configure a bastion, no status is returned for provisioning. You must check the status of provisioning by connecting to each compute instance and confirm that the /u01/provStartMarker file exists with details found in the file /u01/logs/provisioning.log file. See Configure a Bastion.

By default subnets span an entire region in Oracle Cloud Infrastructure.

Oracle WebLogic Server for OCI supports both regional and AD-scoped subnets.

If you want to use an existing subnet for the bastion node when creating a domain, then the subnet must meet the following requirements:

The subnet must use DNS for hostnames.
The subnet must be public.
The subnet's route table must have an Internet Gateway rule
The subnet must have a security list that enables inbound access to the SSH port (22).
Alternatively, if you want to use network security groups (NSGs), the VCN of the subnet must have a network security group that enables inbound access to the SSH port (22).
The subnet must have a security list that enables outbound access to the SSH port (22) on the subnet that you plan to use for Oracle WebLogic Server.
Alternatively, if you want to use network security groups, the VCN of the subnet must have a network security group that enables outbound access to the SSH port (22) on the subnet that you plan to use for Oracle WebLogic Server.

If you use an existing subnet, the subnet is created in the subnet compartment that is different than the VCN compartment.

If you use an existing subnet, you can certify the existing network setup using helper scripts. See Validate Existing Network.

See VCNs and Subnets in the Oracle Cloud Infrastructure documentation.

Create a Subnet for the Mount Target

Oracle WebLogic Server for OCI can create subnets in Oracle Cloud Infrastructure for the mount target that is used to access an Oracle WebLogic Server domain, or you can create your own subnets before creating a domain.

A subnet is a component of a Virtual Cloud Network (VCN). When you create a domain with a mount target using Oracle WebLogic Server for OCI, the mount target is assigned a subnet.

By default subnets span an entire region in Oracle Cloud Infrastructure.

If you want to use an existing subnet for the mount target, the subnet must meet the following requirements:

The subnet must use DNS for hostnames.
The subnet must be public.
The subnet must have a security list that enables inbound access to ports 111 and 2048.
Alternatively, if you want to use network security group (NSGs), the VCN of the subnet must have a network security group that enables inbound access to ports 111 and 2048.
The subnet must have a security list that enables outbound access to the SSH port 111 on the subnet that you plan to use for Oracle WebLogic Server.
Alternatively, if you want to use network security group (NSGs), the VCN of the subnet must have a network security group that enables outbound access to the SSH port 111 on the subnet that you plan to use for Oracle WebLogic Server.

If you use an existing subnet, you can specify the subnet compartment that is different than the VCN compartment.

If you use an existing subnet, you can certify the existing network setup using helper scripts. See Validate Existing Network.

See VCNs and Subnets in the Oracle Cloud Infrastructure documentation.

Create a Database

Before creating an Oracle WebLogic Server domain that includes the Java Required Files (JRF) components, you must create a database in Oracle Cloud Infrastructure.

Note:

You cannot create an Oracle WebLogic Server domain that includes the Java Required Files (JRF) components for Oracle WebLogic Server 14.1.1.0 as this version does not support JRF.

A JRF-enabled domain supports the Oracle Application Development Framework (ADF). When you create a domain with Oracle WebLogic Server for OCI and associate it with an existing database, Oracle WebLogic Server for OCI does the following:

Provisions the schemas to support the JRF components in the selected database
Provisions data sources in the domain that provide connectivity to the selected database
Deploys the JRF components and libraries to the domain

Oracle WebLogic Server for OCI also provides a tool to delete the JRF schemas for a specific domain from the database.

Choose one of these database options:

Oracle Autonomous Database
- Create an autonomous database using either the dedicated or shared infrastructure option. You can also create a Free-Tier autonomous database.
- See Creating an Autonomous Database in the Oracle Cloud Infrastructure documentation.
Note:
Oracle Autonomous Database provides a private endpoint configuration which can be created in subnet within a VCN, by using listen port 1522.
Oracle Cloud Infrastructure Database
- Create bare metal, virtual machine (VM), and Exadata DB systems. For a 1-node VM DB system, note that you can use the fast provisioning option to create the database. Oracle WebLogic Server for OCI supports using Logical Volume Manager as the storage management software for a 1-node VM DB system.
- For Oracle WebLogic Server 12.2.1.4.0, you can also specify a database connection string. This database connection string can be used only with existing VCN. To know the database connection string details, see Database Connect String for Database Version and Type in Configure Database Parameters and VCN Peering.
- See Creating Bare Metal and Virtual Machine DB Systems or Managing Exadata DB Systems in the Oracle Cloud Infrastructure documentation.

The database must allow your domain to access its listen port (1521 by default):

Oracle Autonomous Database - Update your access control list (ACL), if necessary.
Oracle Cloud Infrastructure Database - by default, Oracle WebLogic Server for OCI creates a security list on the database's VCN that allows the WebLogic Server subnet to access the database. Alternatively, you can manually update the security lists in the database's VCN, or update the network security group that is assigned to the database. If you use database connection string, security list is not created to access the database. You must ensure that the ports are open to access the database.

To create a JRF-enabled domain with Oracle WebLogic Server for OCI, you need the following information about the database:

Administrator credentials
Pluggable database (PDB) name (only for Oracle Cloud Infrastructure Database running Oracle Database 12c or later)

If your database and domain are in different VCNs, then Oracle WebLogic Server for OCI configures local peering between the two VCNs. To support VCN peering, you must perform the following prerequisite tasks:

Create an local peering Gateway (LPG) in the database VCN.
Add a route to the current route table of the database subnet, to direct traffic to the CIDR of the WebLogic subnet to the LPG.
Open the database port to the WebLogic subnet CIDR.
If you use an existing VCN and existing subnet, or existing VCN and new subnets, you must add the default private view of the database VCN to the DNS resolver of the existing VCN. See Add a DNS view to the DNS Resolver.

You must also meet the following additional requirements to support VCN peering for the databases:

The CIDRs for the VCNs must not overlap. For example, you cannot create a domain in VCN 10.0.0.0/16 that uses a database in VCN 10.0.0.1/24.
The database subnet must be associated with the default DHCP option for the VCN (Default DHCP Options for <vcn_name>). The subnet cannot use a custom DNS resolver.

If you use Oracle Cloud Infrastructure Database with connection string, you must peer the VCNs manually before creating the stack if your database VCN is on a different VCN than the WebLogic Server VCN. See Manual VCN Peering.

The following table summarizes the security list requirements for an existing subnet that will use local VCN peering to communicate with the domain.

Rule Type	CIDR and Protocol	Destination Ports	Description
Stateful Ingress	WebLogic Server subnet, TCP	1521 or custom database port	Database access
Stateful Ingress	DNS subnet, TCP	53	Access to custom DNS resolver
Stateful Ingress	DNS subnet, UDP	53	Access to custom DNS resolver

Oracle WebLogic Server for OCI supports the same database versions and drivers as those for on-premise WebLogic Server installations. Refer to the following excel files (xls) at Oracle Fusion Middleware Supported System Configurations:

System Requirements and Supported Platforms for Oracle WebLogic Server 14c (14.1.1.0.0)
System Requirements and Supported Platforms for Oracle Fusion Middleware 12c (12.2.1.4.0)

Note:

From release 21.4.3 (December 9, 2021) onwards, you cannot provision a domain in Oracle Oracle WebLogic Server for OCI for Oracle WebLogic server versions 11g (10.3.6.0) and 12c (12.2.1.3) from the Marketplace.

Create a Confidential Application

Before creating an Oracle WebLogic Server domain that integrates with Oracle Identity Cloud Service, you must create a confidential application, and then identify its client ID and client secret.

This configuration is supported only for Oracle Cloud accounts that include Oracle Identity Cloud Service 19.2.1 or later.

When creating a new domain, Oracle WebLogic Server for OCI provisions an App Gateway and other security components in Oracle Identity Cloud Service. In order for Oracle WebLogic Server for OCI to perform these tasks, you must provide the following information:

Your Oracle Identity Cloud Service instance ID, which is also referred to as your tenant name. This ID is typically found in the URL you use to access the Oracle Identity Cloud Service console, and has the format idcs-<GUID>.
The client ID of a confidential application in Oracle Identity Cloud Service
The client secret of the confidential application. You must use Oracle Cloud Infrastructure Vault to create a secret to store the client secret. You will asked to provide the OCID of the secret in the vault. See Create Secrets for Passwords.

Create a confidential application for Oracle WebLogic Server for OCI, or use an existing one. You can use a single confidential application in Oracle Identity Cloud Service to create multiple domains.

From the Oracle Identity Cloud Service Console, click the navigation menu, and then select Applications.
Click Add.
Select Confidential Application.
Enter a Name, and then click Next.
Click Configure this application as a client now.
For Allowed Grant Types, select Client Credentials.
Below Grant the client access to Identity Cloud Service Admin APIs, click Add.
Select Identity Domain Administrator, and then click Add.
(Optional) For a WebLogic Server 12.2.1.4 domain only, add Cloud Gate App Role. You can add this role after you create your WebLogic Server domain but you may need to restart the domain.

Caution:
Add Cloud Gate App Role only if you need to open and log in to the Fusion Middleware Control Console from the Internet. While enabling this role means the Fusion Middleware Control Console is accessible from the Internet, it also means any application would be allowed to look up users.
Complete the Add Confidential Application wizard. Record the values of Client ID and Client Secret.
Select the check box for your application, click Activate, and then click OK.
In the Oracle Cloud Infrastructure console, create a secret in a vault to store the client secret of your confidential application.

See Add a Confidential Application in Administering Oracle Identity Cloud Service.

Create an Application Performance Monitoring Domain

Create an Application Performance Monitoring domain or use an existing Application Performance Monitoring domain.

When you create a domain with Oracle WebLogic Server for OCI, you can enable Application Performance Monitoring integration and provide the Application Performance Monitoring domain details. So, during provisioning, the Application Performance Monitoring Java agent is installed on each of the WebLogic compute instance. This agent records metrics and spans and sends them to the specified Application Performance Monitoring domain.

Metric-based autoscaling depends on the Application Performance Monitoring integration feature to be enabled during provisioning.

See Create an APM Domain in the Oracle Cloud Infrastructure documentation.

Note:

Application Performance Monitoring always free domain is not supported for autoscaling.

Create an Auth Token

In order for Oracle Cloud Infrastructure Registry to deploy autoscaling OCI Functions, you must provide an auth token.

Oracle WebLogic Server for OCI can access the registry as the same user that creates a stack, or as a different user. Every user in Oracle Cloud Infrastructure can be associated with up to two auth tokens. You can create a new auth token for a user with access to Oracle Cloud Infrastructure Registry, or use an existing auth token. When creating an auth token, be sure to copy the token string immediately. You can't retrieve it again later using the console.

See Managing User Credentials in the Oracle Cloud Infrastructure documentation.

Validate Existing Network Setup

You can use helper scripts from the Oracle Cloud Infrastructure Cloud shell to certify the existing network setup (existing VCN and existing WebLogic Server subnet) in Oracle WebLogic Server for OCI. See Using Cloud Shell in Oracle Cloud Infrastructure documentation.

The helper scripts perform the following validations and functions:

Validates if the service gateway or the NAT gateway is created for private subnets.
Validates if the database port is accessible from WebLogic Server subnets.
Validates if port number of the administration server is accessible to the SSH and T3 ports from managed servers.
Validates if internet gateway is created for public bastion and WebLogic Server subnets. This validation is optional and can be ignored for private or FastConnect network.
Checks if port 22 in WebLogic Server subnet is open for access to the CIDR of the bastion instance subnet or bastion host IP.
Checks if port 7003 in WebLogic Server subnet is open for access to the CIDR of the load balancer subnet.
Checks if port 443 in load balancer subnet is open for access to 0.0.0.0/0 IP address.
Checks if ports 111 (both TCP and UDP), 2048-2050 (TCP) and 2048 (UDP) in file system storage subnets are open for access.
Checks if the private subnet for the Oracle WebLogic Server compute instances using the service gateway route rule has All <Region> Services In Oracle Services Network as the destination.

You must install the following tools before you run the validation scripts:

OCI CLI 2.14.1 or later

See Install CLI.
jq 1.5 or later

See Download jq.
Bash 4.0 or later

See Upgrade Bash Version.

As these tools are installed in the Cloud Shell by default, it is recommended to run the validation scripts from the Cloud Shell. The scripts can be copied to Cloud Shell or any Linux terminal running bash 4 and above.

Validation scripts can be run prior to provisioning or post-provisioning.

Validation can be done post-provisioning if the network configuration changes causes the following issues:

Scale out fails on reapply. This occurs when ports 22 and 9071 are not open to access Weblogic Server subnet CIDR in Weblogic Server subnet.
Database connectivity fails. This occurs when the database port is not open to access Weblogic Server subnet CIDR in database subnet, or NAT gateway or service gateway for the WebLogic Server VCN is removed resulting in access failure to the Oracle Autonomous Database.

Using the Validation Script

You can run the helper scripts to perform validations for existing private subnets, existing public subnets, and network security groups.

You must run the commands on the validation script file to check the existing network setup. For example, in this case, let's create a file named, network_validation.sh, and then copy and paste the script in network_validation.sh to this network_validation.sh file.

Run the following commands on the validation script file, network_validation.sh:

Set execute permission to the network_validation.sh file.

chmod +x network_validation.sh

Based on the configuration, run the following commands using network_validation.sh script to validate the subnets or the network security groups (NSG) prior to provisioning:

Note:

Make sure that you perform the validations for the configurations as described in Validate Existing Network Setup.

WebLogic subnet:

./network_validation.sh -w <WLS_Subnet_OCID>

WebLogic NSG:

./network_validation.sh -w <WLS_Subnet_OCID> -a <OCID_of_NSG_for_Admin_Server> -m <OCID_of_NSG_for_Managed_Server>

Bastion subnet:

./network_validation.sh -w <WLS_Subnet_OCID> -b <Bastion_Subnet_OCID>

Existing Bastion Host IP:

./network_validation.sh -w <WLS_Subnet_OCID> -i <Bastion_Host_IP>

Bastion NSG:

./network_validation.sh -w <WLS_Subnet_OCID> -b <Bastion_Subnet_OCID> -a <OCID_of_NSG_for_Admin_Server> -m <OCID_of_NSG_for_Managed_Server> -n <OCID_of_NSG_for_Bastion_Host>

Existing Bastion Host IP with NSG:

./network_validation.sh -w <WLS_Subnet_OCID> -i <Bastion_Host_IP> -a <OCID_of_NSG_for_Admin_Server> -m <OCID_of_NSG_for_Managed_Server>

Load balancer subnet:

./network_validation.sh -w <WLS_Subnet_OCID> -u <Load_Balancer_Subnet1_OCID> -l <external_WLS_LB_Port>

If you use an availability domain-specific subnet, then you must provide the load balancer subnet 2.

./network_validation.sh -w <WLS_Subnet_OCID> -u <Load_Balancer_Subnet1_OCID> -v <Load_Balancer_Subnet2_OCID> -l <external_WLS_LB_Port>

If you use a public load balancer, then you must provide the load balancer source CIDR.

./network_validation.sh -w <WLS_Subnet_OCID> -u <Load_Balancer_Subnet1_OCID> -l <external_WLS_LB_Port> -j 0.0.0.0/0

Load balancer NSG:

./network_validation.sh -w <WLS_Subnet_OCID> -u <Load_Balancer_Subnet_OCID> -l <external_WLS_LB_Port> -a <OCID_of_NSG_for_Admin_Server> -m <OCID_of_NSG_for_Managed_Server> -e <OCID_of_NSG_for_Load_Balancer>

If you use a public load balancer, then you must provide the load balancer source CIDR.

./network_validation.sh -w <WLS_Subnet_OCID> -u <Load_Balancer_Subnet_OCID> -l <external_WLS_LB_Port> -j 0.0.0.0/0 -a <OCID_of_NSG_for_Admin_Server> -m <OCID_of_NSG_for_Managed_Server> -e <OCID_of_NSG_for_Load_Balancer>

File System Storage subnet:

./network_validation.sh -w <WLS_Subnet_OCID> -f <File_System_Storage_Subnet_OCID>

File System Storage NSG:

./network_validation.sh -w <WLS_Subnet_OCID> -a <OCID_of_NSG_for_Admin_Server> -m <OCID_of_NSG_for_Managed_Server> -e <OCID_of_NSG_for_File_System_Storage>

JRF domain with OCI Database system:

./network_validation.sh -w <WLS_Subnet_OCID> -d <OCI_DB_OCID> -p <OCI_DB_Port>

JRF domain with OCI Database system NSG:

./network_validation.sh -w <WLS_Subnet_OCID> -d <OCI_DB_OCID> -p <OCI_DB_Port> -a <OCID_of_NSG_for_Admin_Server> -m <OCID_of_NSG_for_Managed_Server>

JRF domain with an Autonomous Database:

./network_validation.sh -w <WLS_Subnet_OCID> -t <Autonomous_DB_OCID>

JRF domain with an Autonomous Database NSG:

./network_validation.sh -w <WLS_Subnet_OCID> -t <Autonomous_DB_OCID> -a <OCID_of_NSG_for_Admin_Server> -m <OCID_of_NSG_for_Managed_Server>

An example of network_validation.sh command to check the existing WebLogic Server subnet network setup for validating File System Storage subnet:

example_user@cloudshell:~ (us-phoenix-1)$ ./network_validation.sh -w <WLS_Subnet_OCID> -f <File_System_Storage_OCID> 
ERROR: Port 22 is not open for access by WLS Subnet CIDR [10.0.62.0/24] in WLS Subnet [<WLS_Subnet_OCID>]
ERROR: Port 9071 is not open for access by WLS Subnet CIDR [10.0.62.0/24] in WLS Subnet [<WLS_Subnet_OCID>]
WARNING: Exposing the WebLogic administrator port [7001] in the subnet [{<WLS_Subnet_OCID>}] to the internet [0.0.0.0/0] allows any user to access the WebLogic console, which is not a recommended practice. Ensure that only a specific CIDR range can access the WebLogic console.
WARNING: Exposing the WebLogic administrator port [7002] in the subnet [{<WLS_Subnet_OCID>}] to the internet [0.0.0.0/0] allows any user to access the WebLogic console, which is not a recommended practice. Ensure that only a specific CIDR range can access the WebLogic console.
ERROR: TCP Port [111] is not open in FSS Subnet [<WLS_Subnet_OCID>] for VCN CIDR [10.0.0.0/16]
ERROR: TCP Port [2048] is not open in FSS Subnet [<WLS_Subnet_OCID>] for VCN CIDR [10.0.0.0/16]
ERROR: TCP Port [2049] is not open in FSS Subnet [<WLS_Subnet_OCID>] for VCN CIDR [10.0.0.0/16]
ERROR: TCP Port [2050] is not open in FSS Subnet [<WLS_Subnet_OCID>] for VCN CIDR [10.0.0.0/16]
ERROR: UDP Port [111] is not open in FSS Subnet [<WLS_Subnet_OCID>] for VCN CIDR [10.0.0.0/16]
ERROR: UDP Port [2048] is not open in FSS Subnet [<WLS_Subnet_OCID>] for VCN CIDR [10.0.0.0/16]

An example of network_validation.sh command to check the existing WebLogic Server subnet network setup for validating File System Storage subnet and network security groups (NSG):

example_user@cloudshell:~ (us-phoenix-1)$ ./network_validation.sh -w <WLS_Subnet_OCID> -e <OCID_of_NSG_for_File_System_Storage> ERROR: Port 22 is not open for access by WLS Subnet CIDR [10.0.62.0/24] in WLS Subnet [ocid1.subnet.oc1.phx.aaaaaaaatcel2ytjhgyws7rbfpobfb4vvce636ffepci36xxb33ohj3hi6dq]
ERROR: Port 22 is not open for access by WLS Subnet CIDR [10.0.62.0/24] in WLS Subnet [<WLS_Subnet_OCID>]
ERROR: Port 9071 is not open for access by WLS Subnet CIDR [10.0.62.0/24] in WLS Subnet [<WLS_Subnet_OCID>]
WARNING: Exposing the WebLogic administrator port [7001] in the subnet [{<WLS_Subnet_OCID>}] to the internet [0.0.0.0/0] allows any user to access the WebLogic console, which is not a recommended practice. Ensure that only a specific CIDR range can access the WebLogic console.
WARNING: Exposing the WebLogic administrator port [7002] in the subnet [{<WLS_Subnet_OCID>}] to the internet [0.0.0.0/0] allows any user to access the WebLogic console, which is not a recommended practice. Ensure that only a specific CIDR range can access the WebLogic console.
ERROR: TCP Port [111] is not open in FSS NSG [<FSS_NSG_OCID>] for VCN CIDR [10.0.0.0/16]
ERROR: TCP Port [2048] is not open in FSS NSG [<FSS_NSG_OCID>] for VCN CIDR [10.0.0.0/16]
ERROR: TCP Port [2049] is not open in FSS NSG [<FSS_NSG_OCID>] for VCN CIDR [10.0.0.0/16]
ERROR: TCP Port [2050] is not open in FSS NSG [<FSS_NSG_OCID>] for VCN CIDR [10.0.0.0/16]
ERROR: UDP Port [111] is not open in FSS NSG [<FSS_NSG_OCID>] for VCN CIDR [10.0.0.0/16]