Before You Begin
Before you create a domain with Oracle WebLogic Server for OCI, you must complete one or more prerequisite tasks.
Some tasks are required for any type of Oracle WebLogic Server domain that you create with Oracle WebLogic Server for OCI. Other tasks are optional or only applicable for specific domain configurations.
Note:
Before you provision an instance, you can estimate the cost of the resources and services to use in your instance. See Oracle Cloud Cost Estimator.Required Tasks
Optional Tasks
- Create a Virtual Cloud Network
- Create a Private Endpoint
- Create a Network Security Group
- Create a Private Subnet for the Oracle WebLogic Server Nodes
- Configure the Load Balancer
- Create a Subnet for the Load Balancer
- Create a Subnet for the Bastion Node
- Create a Subnet for the Mount Target
- Create a Database
- Create a Confidential Application
- Create an Application Performance Monitoring Domain
- Create an Auth Token
- Create a Certificate Authority
- Validate Existing Network Setup
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.
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.
MyGroup
is the group name of the user who will create the OCI stack.MyCompartment
andMySecretCompartment
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.
MyGroup
is the group name of the user who will create the OCI stack.MyCompartment
,MyNetworkCompartment
, andMyDBCompartment
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
|
Allow group MyGroup to manage
virtual-network-family in compartment
MyNetworkCompartment |
To create VCNs and subnets | Network Compartment |
Load Balancer
|
Allow group MyGroup to manage
load-balancers in compartment
MyNetworkCompartment |
To create a load balancer | Network Compartment |
Enable Secured Production Mode |
Allow group MyGroup to read
certificate-authorities in tenancy |
To identify the compartment where the certificate authority resides. |
Root 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 |
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 |
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 |
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 |
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.
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:
Required policies
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
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
|
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
|
Allow dynamic-group
MyInstancesPrincipalGroup to manage
load-balancers in compartment
MyNetworkCompartment |
To add load balancer backends | Network Compartment |
Enable Secured Production Mode |
|
To create certificates from the private key generated for the WebLogic Server custom identity store (used in SSL). |
Certificate Compartment |
|
To use a certificate authority to sign a certificate using the certificate sign request (OCI CreateCertificate requires CERTIFICATE_CREATE and CERTIFICATE_AUTHORITY_APPLY permissions). |
Certificate Compartment |
|
|
To retrieve the public certificate chain for the created certificate so it can be imported into the WebLogic Server custom trust store (used for SSL connections). |
Certificate Compartment |
|
|
To read the certificate authority rule for Maximum Validity Duration for Certificates so certificate requests do not exceed this duration. |
Certificate Authority (CA) 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 |
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.
- Create the script.
- Create a file with name:
create_autoscaling_policies.py
- Go to Script File to Create Policies for Autoscaling Functions Post Provisioning.
- Copy and paste the script to the
create_autoscaling_policies.py
file. - Save the file.
- Create a file with name:
- 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 hascreate_policies
set tofalse
, 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 whencreate_policies == true
.
Create the dynamic group and required policies through the OCI console
ALL {resource.type = 'fnfunc', resource.compartment.id='ocid_for_stack_compartment'}
Required policies
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 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
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 |
Enable Secured Production Mode |
Allow dynamic-group
FunctionDynamicGroup to read
certificate-authorities in compartment
MyCACompartment |
To read the certificate authority rule for Maximum Validity Duration for Certificates so certificate requests do not exceed this duration. | Certificate Authority (CA) 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:
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 (secured production mode) | Stateful Ingress | TCP | Bastion NSG OCID | 9002 | Administration Server SSL port | |
WebLogic Managed Server (secured production mode) | Stateful Ingress | TCP | Admin network, or load balancer NSG OCID | 7004 | Managed Server SSL port | |
WebLogic Managed Server (secured production mode) | Stateful Ingress | TCP | WebLogic Managed Server NSG OCID | 9072 | Administration Server internal SSL port | |
WebLogic Managed Server (secured production mode) | Stateful Ingress | TCP | WebLogic Managed Server NSG OCID | 9002 | Administration Server SSL ports | |
WebLogic Managed Server (secured production mode) | Stateful Ingress | TCP | WebLogic Managed Server NSG OCID | 9004 | Managed Server Administration SSL port | |
WebLogic Managed Server (secured production mode) | Stateful Ingress | TCP | WebLogic Managed Server NSG OCID | 5556 | Node Manager port | |
WebLogic Administration Server (not secured production mode) | Stateful Ingress | TCP | Bastion NSG OCID | 7001, 7002 | Administration Server ports | |
WebLogic Administration Server (not secured production mode) | 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 or, if secured production mode, 7002 and 9002 by default).
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 or, if secured production mode, 7002 and 9002 by default).
- The subnet must have a security list that enables inbound access to
the managed server ports (by default, 7003 and 7004 or if secured production
mode, only 7004 by default).
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 or if secured production mode, only 7004 by default) 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. - The subnet must have a security list that enables inbound access to the node
manager port (by default, 5556).
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 node manager port (by default, 5556) on the subnet you plan to use for 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.
Figure 1-6 Default Destination Ports

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 (not secured production mode) |
Stateful Ingress | Bastion network, TCP | 9002 | Administration Server SSL port (secured production mode) |
Stateful Ingress | Your admin network, or your load balancer subnet, TCP | 7004 | Managed Server SSL port (secured production mode) |
Stateful Ingress | Weblogic subnet, CIDR | 22 | Administration Server ports (not secured production mode) |
Stateful Ingress | Weblogic subnet, CIDR | 9071 | Used for provisioning and scaling (not secured production mode) |
Stateful Ingress | Weblogic subnet, CIDR | 9072 | SSL internal port used for provisioning and scaling (secured production mode) |
Stateful Ingress | Weblogic subnet, CIDR | 9002 | Administration Server SSL administration port (secured production mode) |
Stateful Ingress | Weblogic subnet, CIDR | 5556 | Used for accessing node manager |
Stateful Ingress | Weblogic subnet, CIDR | 9004 | Managed Server SSL administration port (secured production mode) |
Stateful Ingress | Your admin network, or your load balancer subnet, TCP | 7003, 7004 | Managed Server ports (not secured production mode) |
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
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 Create a Certificate Authority.
Note:
If you will be enabling secured production mode ensure that you have an OCI Certificate Authority available. If you do not yet have an OCI Certificate Authority see Create a Certificate Authority.
Create a 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 or
7004 if you will be enabling secured
production mode
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.
Note:
This section is not required when secured production mode is selected since SSL is configured end to end. Without secured production mode SSL is terminated at 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.
- If you will be enabling secured production mode select "Use SSL" and specify the
following properties:
- Certificate resource: Certificate service managed certificate
- Select Certificate authority option.
- Certificate authority in CA Compartment: Select the certificate authority from section Create a Certificate Authority
- Select Verify peer certificate
- Verify depth: 1
- 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.
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 or, if secured production mode, only 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 or if secured production
mode, only 7004 by default) 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 port1522
. - 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 14.1.2.0.0 or 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 VCN10.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 |
xls
)
at Oracle Fusion Middleware Supported System Configurations:
- System Requirements and Supported Platforms for Oracle WebLogic Server 14c (14.1.2.0.0)
- 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.
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.
Create a Certificate Authority
Create a Certificate Authority or use an existing Certificate Authority.
When you create a domain with Oracle WebLogic Server for OCI, you can enable Secured Production Mode and provide the Certificate Authority to be used for issuing SSL certificates. During provisioning a private key is generated for use in the PKCS12 Custom Identity SSL configuration of the WebLogic Administration Server, all managed servers, all node managers, and if Authentication Using Identity Domains (aka Identity Cloud Service) is enabled, for the AppGateway. A certificate signing request (CSR) for a wildcard certificate is presented to the OCI Certificate service with the generated private key using the Certificate Authority specified. The certificate chain for the certificate created is retrieved and added to a PKCS12 keystore for use in the Custom Trust SSL configuration of the WebLogic Administration Server, all managed servers, and if Authentication Using Identity Domains (aka Identity Cloud Service) is enabled, for the AppGateway.
See Creating a Certificate Authority.
Note:
Only Root Certificate Authority without any Subordinate Certificate Authorityis supported.
Note:
When creating an OCI Certificate Authority the Maximum Validity Duration for Certificates (Days) defaults to 90 days. WLS for OCI will set the certificate expiration based on this value or 365, depending on which is lower. Ensure that you are aware that the certificates will need to be renewed by the expiration date.
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, port 7004 if -z or --securemode argument set to true, 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.
-
Scale out fails on reapply. This occurs when ports 22 and 9071 or if -z or --securemode argument set to true ports 22, 9072, 9002, 9004, 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.
network_validation.sh
, and then copy and paste the script in network_validation.sh to this
network_validation.sh
file.
network_validation.sh
:
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]
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]