Before You Begin with Oracle WebLogic Server for OCI

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, security lists, route tables and gateways).

See Managing Compartments in the Oracle Cloud Infrastructure documentation.

Create Compartment Policies

If you are not an Oracle Cloud Infrastructure administrator, you must be given management access to resources in the compartment in which you want to create a domain using Oracle WebLogic Server for OCI.

Access to Oracle Cloud Infrastructure resources in a compartment is controlled through policies. This task is typically performed by the Oracle Cloud Infrastructure administrator.

The Oracle Cloud Infrastructure user who is not an administrator must have access to Marketplace applications, as well as management access to Resource Manager stacks and jobs, compute instances, and block storage volumes. If you want Oracle WebLogic Server for OCI to create resources for a domain like networks and load balancers, management access for these resources must also be provided.

A sample policy is shown below:

Allow group MyGroup to use app-catalog-listing in compartment MyCompartment
Allow group MyGroup to manage instance-family in compartment MyCompartment
Allow group MyGroup to manage virtual-network-family in compartment MyCompartment
Allow group MyGroup to manage volume-family in compartment MyCompartment
Allow group MyGroup to manage load-balancers in compartment MyCompartment
Allow group MyGroup to manage orm-family in compartment MyCompartment
Allow group MyGroup to read metrics in compartment MyCompartment
Allow group MyGroup to inspect limits in tenancy

If you need to allow a user who is not an administrator to be able to create secrets with the passwords required during provisioning, ensure you grant manage access to the vaults, keys, and secret-family. For example:

Allow group MyGroup to manage vaults in compartment MyCompartment
Allow group MyGroup to manage keys in compartment MyCompartment
Allow group MyGroup to manage secret-family in compartment MyCompartment

If you need to allow a user who is not an administrator to use the secrets created by administrator, ensure you grant the following policy. For example:

Allow group MyGroup to inspect secrets in compartment id <Compartment OCID>

If you use a separate compartment for network resources, ensure you set up the appropriate policy for the network compartment. For example:

Allow group MyGroup to manage virtual-network-family in compartment MyNetworkCompartment
Allow group MyGroup to manage load-balancers in compartment MyNetworkCompartment

If you intend to create a domain that includes the Java Required Files (JRF) components, then you must be able to list databases in the compartment that contains your database, and to create network resources in the same compartment. For example:

Allow group MyGroup to inspect autonomous-transaction-processing-family in compartment MyDBCompartment
Allow group MyGroup to inspect database-family in compartment MyDBCompartment
Allow group MyGroup to manage virtual-network-family in compartment MyDBCompartment

If you need to allow a user who is not an administrator to be able to create file storage for instances in the same compartment as the WebLogic VCN compartment, ensure you grant manage access. For example:

Allow group MyGroup to manage mount-targets in compartment MyCompartment
Allow group MyGroup to manage file-systems in compartment MyCompartment
Allow group MyGroup to manage export-sets in compartment MyCompartment

If you need to allow a user who is not an administrator to be able to create file storage for instances in a separate compartment and mount target resources, ensure you grant manage access. For example:

Allow group MyGroup to manage mount-targets in compartment myFSSCompartment
Allow group MyGroup to manage file-systems in compartment myFSSCompartment
Allow group MyGroup to manage export-sets in compartment myFSSCompartment

See Common Policies in the Oracle Cloud Infrastructure documentation.

Create Root Policies

You must be an Oracle Cloud Infrastructure administrator, or be granted specific root-level permissions, in order to create domains using Oracle WebLogic Server for OCI.

Identity and Access Management (IAM) policies let you control what type of access a group of users has and to which specific resources. Most IAM policies are set at the compartment level, while some are set at the tenancy (root) level:

View tenancies
Use vault keys and secrets
Inspect tag namespaces and apply defined tags from those namespaces to cloud resources
Create dynamic groups
Create root-level policies

The following sample root policy grants other relevant permissions to a group of users who are not administrators:

Allow group MyGroup to inspect tenancies in tenancy
Allow group MyGroup to manage tag-namespaces in tenancy

See these topics in the Oracle Cloud Infrastructure documentation:

Create Dynamic Groups and Policies

When you create a domain, by default the OCI Policies check box is selected and Oracle WebLogic Server for OCI creates the dynamic groups and policies.

The following policies are required when OCI Policies check box is selected:

Allow group MyGroup to manage dynamic-groups in tenancy
Allow group MyGroup to manage policies in tenancy

If you do not belong to a group that has the policies listed above, then you need to clear the OCI Policies check box and create a dynamic group and the required polices.

These tasks are typically performed by any user that belongs to a group that has the policies listed above or a tenancy administrator:

Create a Dynamic Group

If you are not an administrator, ask them to create a dynamic group in Oracle Cloud Infrastructure whose members are the compute instances that Oracle WebLogic Server for OCI will create for a domain.

During stack creation for a domain, Oracle WebLogic Server for OCI creates compute instances in a compartment you select. This compartment's OCID must be listed in a dynamic group before users who are not administrators can create resources for the domain in the specified compartment.

One or more compartments can be listed in a dynamic group.

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.

See Managing Dynamic Groups in the Oracle Cloud Infrastructure documentation.

Create Policies for the Dynamic Group

If you are not an administrator, ask them to create policies that permit your dynamic group to access relevant services when you create a domain using Oracle WebLogic Server for OCI.

If you are an administrator, by default Oracle WebLogic Server for OCI creates these policies when you create a domain.

When you create a domain, compute instances in Oracle WebLogic Server for OCI need to access Oracle Cloud Infrastructure Vault secrets. If a load balancer is enabled, access to network resources is required. If you're creating a domain that includes the Java Required Files (JRF) components, depending on the database strategy you select, the instances will also need access to the Oracle Autonomous Database wallet, or the Oracle Cloud Infrastructure Database (DB System) and network resources.

The following sample policy grants the relevant vault, key, and secret permissions to a dynamic group:

Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in tenancy where target.secret.id = '<OCID_of_wls_password_secret>'
Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in tenancy where target.secret.id = '<OCID_of_db_password_secret>'
Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in tenancy where target.secret.id = '<OCID_idcs_password_secret>'

The following sample policy grants the relevant network and database permissions to a dynamic group:

Allow dynamic-group MyInstancesPrincipalGroup to manage instance-family in compartment MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to manage volume-attachments in compartment MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to inspect volumes in compartment MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to use volumes in compartment MyCompartment where any { request.operation = 'AttachVolume', request.operation = 'DetachVolume'}
Allow dynamic-group MyInstancesPrincipalGroup to manage virtual-network-family in compartment MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to manage load-balancers in compartment MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to use autonomous-transaction-processing-family in compartment MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to inspect database-family in compartment MyCompartment

The following sample policy grants the OS Management service:

Allow dynamic-group MyInstancesPrincipalGroup use osms-managed-instances in compartment MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to read instance-family in compartment MyCompartment

The following sample policy grants the relevant logging permissions to a dynamic group:

Allow dynamic-group MyInstancesPrincipalGroup to use logging-family in compartment MyCompartment

See these topics in the Oracle Cloud Infrastructure documentation:

Create Dynamic Groups and Policies for Observability

When you create a domain, by default the OCI Policies check box is selected and Oracle WebLogic Server for OCI creates the dynamic groups and policies for functions in the stack compartment.

The following policies are required when OCI Policies check box is selected:

Allow group MyGroup to manage dynamic-groups in tenancy
Allow group MyGroup to manage policies in tenancy

If you do not belong to a group that has the policies listed above, then you need to clear the OCI Policies check box and create a dynamic group and the required polices.

These tasks are typically performed by any user that belongs to a group that has the policies listed above or a tenancy administrator:

When OCI Policies check box is not selected when creating a domain, you can use the following script to create function's dynamic group and policies after creating the domain:

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.

The following dynamic group and policies are created by the create_autoscaling_policies.py script. If you plan to not use the script, you can manually create the dynamic group and policies.

Dynamic Group for OCI Function

When you create a domain with metric-based autoscaling a dynamic group is created for OCI functions service. This is required for the OCI function to be able to create an Apply job and to update the stack variables.

Group identifying all functions are in the specified compartment. All the OCI functions for the stack are tagged with the following parameters:

tagnamespace is the default tag namespace of the Oracle WebLogic Server for OCI service, which is created in terraform when you create a domain.
tagkey is the wlsociserviceprefix.
tagvalue is the service prefix of Oracle WebLogic Server for OCI stack.

ALL {resource.type = 'fnfunc', resource.compartment.id = '<stack compartment ocid>', tag.<tagnamespace>.<tagkey>.value='<tagvalue>'}

This dynamic group groups all OCI functions in the stack compartment that are assigned the tag.<WLS-OCI service default tag namespace>.wlsociserviceprefix tagkey with value of service_name of your Oracle WebLogic Server for OCI stack.

Dynamic Group Policies for OCI Function

Allow dynamic-group FunctionDynamicGroup to inspect tenancies in tenancy
Allow dynamic-group FunctionDynamicGroup to inspect limits in tenancy
Allow dynamic-group FunctionDynamicGroup to manage volume-family in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage instance-family in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to use app-catalog-listing in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage virtual-network-family in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage load-balancers in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage orm-family in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to read metrics in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage repos in tenancy
Allow dynamic-group FunctionDynamicGroup to manage functions-family in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to use ons-topics in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to use instance-agent-command-family in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage alarms in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage log-groups in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage unified-configuration in compartment id MyCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to inspect dynamic-groups in tenancy
Allow dynamic-group FunctionDynamicGroup to manage policies in tenancy
Allow dynamic-group FunctionDynamicGroup to use tag-namespaces in tenancy
Allow dynamic-group FunctionDynamicGroup to use apm-domain in compartment id MyAPMDomainCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to inspect autonomous-transaction-processing-family in compartment id MyATPDBCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to inspect database-family in compartment id MyOCIDBCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to inspect autonomous-transaction-processing-family in compartment id MyATPAppDBCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to inspect database-family in compartment id MyOCIAppDBCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage mount-targets in compartment id MyFSSCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage file-systems in compartment id MyFSSCompartmentOCID
Allow dynamic-group FunctionDynamicGroup to manage export-sets in compartment id MyFSSCompartmentOCID

Create Additional Policies for Observability

If you are not an Oracle Cloud Infrastructure administrator, you must be given management access to access relevant services when you create a domain using Oracle WebLogic Server for OCI.

If you are an administrator, by default Oracle WebLogic Server for OCI creates these policies when you create a domain.

Dynamic Group Policies

The following sample policy grants the relevant autoscaling permissions to create functions and deploy an Oracle WebLogic Server for OCI administrator instance:

Allow dynamic-group MyInstancesPrincipalGroup to manage functions-family in compartment id MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to use repos in tenancy
Allow dynamic-group MyInstancesPrincipalGroup to manage ons-subscriptions in compartment id MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to use tag-namespaces in tenancy
Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in tenancy where target.secret.id = '<OCIRAuthTokenSecretID>'
Allow dynamic-group MyInstancesPrincipalGroup to read orm-stacks in compartment id MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to manage instance-agent-command-execution-family in compartment id MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to manage cloudevents-rules in compartment id MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to inspect compartments in tenancy
Allow dynamic-group MyInstancesPrincipalGroup to use ons-topics in compartment id MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to manage log-groups in compartment id MyCompartment

Compartment Policies

Access to Oracle Cloud Infrastructure resources in a compartment is controlled through policies. This task is typically performed by the Oracle Cloud Infrastructure administrator.

If you need to allow a user who is not administrator to be able to enable exporting logs to OCI Logging Service, ensure you grant the required access. For example:

Allow group MyGroup to manage log-groups in compartment MyCompartment
Allow group MyGroup to use log-content in compartment MyCompartment
Allow group MyGroup to manage unified-configuration in compartment MyCompartment

If you need to allow a user who is not an administrator to be able to use autoscaling, ensure you grant the required access. For Example:

Allow group MyGroup to manage functions-family in compartment id MyCompartmentOCID
Allow group MyGroup to manage repos in tenancy
Allow group MyGroup to manage ons-subscriptions in compartment id MyCompartmentOCID
Allow group MyGroup to manage alarms in compartment id MyCompartmentOCID
Allow group MyGroup to read metrics in compartment id MyCompartmentOCID where target.metrics.namespace='oracle_apm_monitoring'
Allow group MyGroup to manage ons-topics in compartment id MyCompartmentOCID
Allow group MyGroup to manage log-groups in compartment id MyCompartmentOCID
Allow group MyGroup to use log-content in compartment id MyCompartmentOCID
Allow group MyGroup to manage unified-configuration in compartment id MyCompartmentOCID
Allow group MyGroup to read objectstorage-namespaces in tenancy
Allow group MyGroup to use apm-domains in compartment id MyCompartmentOCID
Allow group MyGroup to manage cloudevents-rules in compartment id MyCompartmentOCID
Allow group MyGroup to use cloud-shell in tenancy

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're imported to the vault.
In Secret Contents, enter the password you want to store in this secret.
Ensure the password meets the criteria for which it will be used (for example, WebLogic Server administrator password).
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.

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, security lists, gateways, and DHCP options.

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 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 inOracle WebLogic Server for OCI, you can certify the existing network setup using helper scripts. See Validate Existing Network and Script File To Validate Network Setup.

See these topics 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).
The subnet must have a security list that enables inbound access to the managed server ports (by default, 7003 and 7004). If you are using a load balancer, the security list'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 and Script File To Validate Network Setup.

The following diagram illustrations the default destination ports.

Figure 1-5 Default Destination Ports

The following table summarizes the security list requirements for an existing subnet.

Note:

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

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	Admin server ports
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 database 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	Weblogic subnet, CIDR	9071	Used for provisioning and scaling
Stateful Ingress	Weblogic subnet, CIDR	5556	Used for accessing node manager
Stateful Ingress	Weblogic subnet, CIDR	22	Admin server ports

Network security groups are an alternative to security lists. After creating a domain with an existing subnet, you can update the compute instances and assign them to a security group that has the required rules (inbound access to port 22, and so on).

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.

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

Add the routing policy

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

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 and Script File To Validate Network Setup.

Network security groups are an alternative to security lists. After creating a domain with an existing subnet, you can update the load balancer and assign it to a security group that has the required rules (inbound access to port 80, and so on).

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

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 and Script File To Validate Network Setup.

Network security groups are an alternative to security lists. After creating a domain with an existing subnet, you can update the bastion compute instance and assign it to a security group that has the required rules (inbound access to port 22, and so on).

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. However, the configuration is supported only for existing VCNs or existing VCNs with subnets topology. For Oracle Autonomous Database, VCN peering is not suported out-of-box with Terraform scripts. If you want to use private endpoint for Oracle Autonomous Database or Oracle Autonomous Database is on a different VCN, then manually peer the VCNs before provisioning.
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.
- 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 Oracle Cloud Infrastructure 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 meet the following additional requirements:

Multiple domains cannot use the same database.
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 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 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 connect 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.

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 documents at Oracle Fusion Middleware Supported System Configurations:

System Requirements and Supported Platforms for Oracle Fusion Middleware 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. However, you can provision a domain for Oracle WebLogic server version 12c (12.2.1.3) using the terraform scripts See Create a Domain for Oracle WebLogic Server 12.2.1.3.0 Using Terraform. The WebLogic binaries for 12.2.1.3 are also available in the public images.

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 existing VCN peered subnets.

You must run the commands on the validation script file to check the existing network setup. For example, in this case, let's run the commands on the validation script file named validate.sh. See Script File to Validate Network Setup to create the validate.sh file.

Set execute permission to the validate.sh file.

chmod +x validate.sh
Based on the domain type, run the following commands using validate.sh script prior to provisioning:
- Basic domain
  
  ./validate.sh -w <WLS_Subnet_OCID>
- JRF-enabled domain
  
  ./validate.sh -w <WLS_Subnet_OCID> -d <DB_Subnet_OCID>
  
  If you configure a load balancer, the load balancer subnet must have a security list that enables access to port 443, and the WebLogic Server subnet must have a security list that allows load balancer subnet to access port 7003
  
  ./validate.sh -w <WLS_Subnet_OCID> -l <LB_Subnet_OCID
  
  If you configure file system storage, the file system storage subnet must have a security list that enables access to the ports 111 (both TCP and UDP), 2048-2050 (TCP) and 2048 (UDP).
  
  ./validate.sh -w <WLS_Subnet_OCID> -l <LB_Subnet_OCID
  
  If you are using an Application Datasource that is in a diffferent subnet than the database subnet, specify the Application DB Subnet OCID
  
  ./validate.sh -w <WLS_Subnet_OCID> -a <Application_DB_Subnet_OCID>
  
  If you are using an Autonomous Database with private endpoint, specify the Autonomous DB OCID.
  
  ./validate.sh -w <WLS_Subnet_OCID> -t <Autonomous_DB_OCID>
- Basic domain in a private subnet
  
  ./validate.sh -b <Bastion_Subnet_OCID>
  
  If you restricted the bastion compute instance to access port 22 in WebLogic subnet, you can validate using the Bastion Host IP CIDR rather than the entire bastion subnet CIDR.
  
  ./validate.sh -b <Bastion_Subnet_OCID> -i <Bastion_Host_IP_CIDR>
  
  The bastion host IP CIDR must have /32 suffix, else the following error is displayed:
  
  Bastion host IP CIDR is not valid: [1.1.1.1]

An example of validate.sh command to check the existing WebLogic Server subnet (and optionally database subnet) network setup:

example_user@cloudshell:~ (us-phoenix-1)$ ./validate.sh -w <WLS_Subnet_OCID> -d <DB_Subnet_OCID> /
-l <LB_Subnet_OCID> -f <FSS_Subnet_OCID> -a <AppDB_Subnet_OCID> -t <ATPDB_OCID> -b <Bastion_Subnet_OCID> -i <Bastion_Host_IP_CIDR>
ERROR: Route Rule of private WLS subnet [<WLS_Subnet_OCID>] does not use 'ALL Services in Oracle services network' destination
ERROR: Port 22 is not open for access by WLS Subnet CIDR [10.0.0.0/24] in WLS Subnet [<WLS_Subnet_OCID>]
ERROR: Port 9071 is not open for access by WLS Subnet CIDR [10.0.0.0/24] in WLS Subnet [<WLS_Subnet_OCID>]
ERROR: DB port 1521 is not open for access by WLS Subnet CIDR [10.0.0.0/24] in DB Subnet [<DB_Subnet_OCID>]
ERROR: LB port 7003 is not open for access by LB Subnet CIDR [10.0.5.0/24] in WLS Subnet [<WLS_Subnet_OCID>]
ERROR: Port [443] is not open for 0.0.0.0/0 in LB Subnet CIDR [<LoadBalancer_Subnet_OCID>]
ERROR: TCP Port [111] is not open in FSS Subnet for VCN CIDR
ERROR: TCP Port [2048] is not open in FSS Subnet for VCN CIDR
ERROR: TCP Port [2049] is not open in FSS Subnet for VCN CIDR
ERROR: TCP Port [2050] is not open in FSS Subnet for VCN CIDR
ERROR: UDP Port [111] is not open in FSS Subnet for VCN CIDR
ERROR: UDP Port [2048] is not open in FSS Subnet for VCN CIDR
ERROR: DB port 1521 is not open for access by WLS Subnet CIDR [10.0.0.0/24] in Application DB Subnet [<AppDB_Subnet_OCID>]
ERROR: DB port 1522 is not open for access by WLS Subnet CIDR [10.0.0.0/24] in Autonomous DB Subnet [<ATPDB_Subnet_OCID>]
ERROR: SSH port 22 is not open for access by [0.0.0.0/0] in Bastion Subnet [<Bastion_Subnet_OCID>]
WARNING: SSH port 22 is not open for access by Bastion Subnet CIDR [1.1.1.1/32] in private WLS Subnet [<WLS_Subnet_OCID>]