Before You Begin with Oracle WebLogic Server for OKE

Before you create a domain with Oracle WebLogic Server for OKE, 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 OKE. 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.

Understand Service Requirements

You require access to several Oracle Cloud Infrastructure services in order to use Oracle WebLogic Server for OKE.

  • Identity and Access Management (dynamic groups and policies)
  • Compute
  • Network
  • Block Storage
  • File Storage and Mount targets
  • Container Engine
  • Registry
  • Vault
  • Resource Manager
  • Load Balancing
  • Database (optional)
  • Cloud Shell (optional)
  • Tagging (optional)
To use Oracle WebLogic Server for OKE, you need at least the following limits available in your tenancy or region or availability domain as applicable:
  • 1 OKE Cluster
  • 4 Compute instances
  • 2 Load Balancers
  • 1 File System Service
  • 1 Mount Target

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

Create a Compartment

Create compartments in Oracle Cloud Infrastructure for your Oracle WebLogic Server for OKE resources, or use existing compartments.

When you create a domain with Oracle WebLogic Server for OKE, by default the Kubernetes cluster, compute instances, networks, and load balancers are all created within a single compartment. You can, however, choose to use a separate compartment for the network resources that are created for the domain, including load balancers, 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 OKE.

Access to Oracle Cloud Infrastructure resources in a compartment is controlled through policies. Your Oracle Cloud Infrastructure user must have management access for Marketplace applications, Resource Manager stacks and jobs, Kubernetes clusters, compute instances, file systems, block storage volumes, load balancers, Key Management vaults and keys, and IAM policies. If you want Oracle WebLogic Server for OKE to create network resources for a domain, then you must also have management access for these network resources.

A sample policy is shown below:

Where, MyCompartment is the compartment in which you created the stack.

Allow group MyGroup to manage instance-family in compartment MyCompartment
Allow group MyGroup to manage orm-family in compartment MyCompartment
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
Allow group MyGroup to manage cluster-family in compartment MyCompartment
Allow group MyGroup to use subnets in compartment MyCompartment
Allow group MyGroup to use vnics in compartment MyCompartment
Allow group MyGroup to inspect compartments in compartment MyCompartment
Allow group MyGroup to read metrics in compartment MyCompartment
Allow group MyGroup to read virtual-network-family in compartment MyCompartment
Allow group MyGroup to manage virtual-network-family in compartment MyCompartment
If you use a separate compartment for network resources, make sure you set up the appropriate policy for the network compartment. For example:
Allow group MyGroup to manage virtual-network-family in compartment MyNetworkCompartment
If you use a separate compartment for FSS resources, make sure you set up the appropriate policy for the FSS compartment. 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
If you intend to create a domain that includes the Java Required Files (JRF) components, then you must set up the policy for the database 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

See Common Policies in the Oracle Cloud Infrastructure documentation.

Create Root Policies

Certain root-level policies must exist in order to use Oracle WebLogic Server for OKE.

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

  • Delegate IAM tasks, including the creation of dynamic groups
  • Use the Cloud Shell to quickly run the Oracle Cloud Infrastructure command line interface (CLI)
  • Inspect tag namespaces and apply defined tags from those namespaces to cloud resources

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 use tag-namespaces in tenancy

Create Dynamic Groups and Policies

When you create a domain, by default the OCI Policies check box is selected and Oracle WebLogic Server for OKE 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

Create a dynamic group in Oracle Cloud Infrastructure whose members are the compute instances that Oracle WebLogic Server for OKE will create for a domain.

The dynamic group is necessary for the compute instances to access encryption keys in Key Management, and also to access the database wallet if you're using Oracle Autonomous Database.

During stack creation for a domain, Oracle WebLogic Server for OKE 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.

  1. Access the Oracle Cloud Infrastructure console.
  2. From the navigation menu, select Identity & Security. Under the Identity group, click Compartments.
  3. Copy the OCID for the compartment that you plan to use for the Oracle WebLogic Server compute instances.
    If you use another compartment just for network resources, copy also the OCID of the network compartment.
  4. Click Dynamic Groups.
  5. Click Create Dynamic Group.
  6. Enter a Name and Description.
  7. For Rule 1, create a rule that includes all instances in the selected compartment in this group.

    ALL {instance.compartment.id = 'WLS_Compartment_OCID'}

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

  8. Click Create Dynamic Group.

See Managing Dynamic Groups in the Oracle Cloud Infrastructure documentation.

Create Policies for the Dynamic Group

Create policies in Oracle Cloud Infrastructure so that the compute instances in Oracle WebLogic Server for OKE can access your encryption key.

When you create a domain, compute instances in Oracle WebLogic Server for OKE 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 network and database permissions to a dynamic group:

Allow dynamic-group MyInstancesPrincipalGroup to manage all-resources in compartment MyCompartment
Allow service oke to read app-catalog-listing in compartment MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in compartment VaultCompartment where target.secret.id = '<OCID for weblogic admin password secret>'
Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in compartment VaultCompartment where target.secret.id = '<OCID for OCIR token secret>'
Allow dynamic-group MyInstancesPrincipalGroup to read secret-bundles in compartment VaultCompartment where target.secret.id = '<OCID for Database password secret>'
Allow dynamic-group MyInstancesPrincipalGroup to use autonomous-transaction-processing-family in compartment ATP_Database_Compartment
The following sample policy grants access to the OS Management service:
Allow dynamic-group MyInstancesPrincipalGroup to use osms-managed-instances in compartment MyCompartment
Allow dynamic-group MyInstancesPrincipalGroup to read instance-family in compartment MyCompartment

See these topics in the Oracle Cloud Infrastructure documentation:

Create an Auth Token

In order for Oracle WebLogic Server for OKE to push and pull Docker images to and from Oracle Cloud Infrastructure Registry, you must provide an auth token.

Oracle WebLogic Server for OKE can access the registry as the same user that creates a domain, 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 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 an Encryption Key

Create an encryption key in Oracle Cloud Infrastructure Vault. This will allow you to encrypt the passwords required for Oracle WebLogic Server for OKE.

Oracle WebLogic Server for OKE uses a single key to decrypt all passwords for a single domain.

Create Secrets with Passwords

Use Oracle Cloud Infrastructure Vault to create secrets with passwords that you need to create a domain with Oracle WebLogic Server for OKE. Create one secret for each password.

You must provide OCID of the secrets:

  • Administrator password for the new domain
  • Auth token for a user with access to Oracle Cloud Infrastructure Registry
  • Administrator password for an existing database, if you are creating a domain that includes the Java Required Files (JRF) components

To create secrets:

  1. Sign in to the Oracle Cloud Infrastructure Console.
  2. Click the navigation menu Navigation Menu icon, select Identity & Security, and then click Vault.
  3. Select the Compartment where you want to create a secret.
  4. From the list of vaults in the compartment, do one of the following:
    • Click the name of the vault where you want to create a secret.
    • Create a new vault for the secret by following the instructions in To create a new vault, and then click the name of the vault.
  5. Click Secrets, and then click Create Secret.
  6. In the Create Secret dialog box, choose a compartment from the Create in Compartment list.

    Tip:

    Secrets can exist outside the compartment the vault is in.
  7. Click Name, and then enter a name to identify the secret. Avoid entering any confidential information in this field
  8. Click Description, and then enter a brief description of the secret to help identify it. Avoid entering any confidential information in this field.
  9. Choose the encryption key that you want to use to encrypt the secret contents while they are imported to the vault.
  10. Specify the format of the secret contents you are providing by choosing a template type from the Secret Type Template list.
  11. Click Secret Contents, and then enter the secret contents.
  12. Click Create Secret.

For information about optional fields, 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 OKE, 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 OKE 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 resources assigned to a private subnet cannot be directly accessed from outside of Oracle Cloud. We recommend that you use private subnets for the Kubernetes cluster, administration compute instance, and file system.

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

  • The VCN must use DNS for hostnames.
  • The VCN must include an Internet gateway.
  • If you want to create a public subnet for the domain, then the VCN must include a route table that directs traffic to the Internet gateway.
  • The VCN must include a service gateway so that resources in private subnets can access other cloud services like Key Management, Oracle Cloud Infrastructure Registry, and Oracle Autonomous Database.
  • If you want to create a private subnet for the domain, then the VCN must include a route table that directs traffic to the service gateway.
  • If you want resources in private subnets to access services outside of Oracle Cloud, then the VCN must include a Network Address Translation (NAT) gateway.
  • If your VCN includes a NAT gateway and you want to create a private subnet for the domain, then the VCN must include a route table that directs traffic to the NAT gateway.

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

If you use an existing VCN and existing subnets inOracle WebLogic Server for Oracle Cloud Infrastructure, you can certify the existing network setup using helper scripts. See Validate Existing Network Setup and Script File To Validate Network Setup.

See these topics in the Oracle Cloud Infrastructure documentation:

Create a Subnet for the Kubernetes Cluster

Oracle WebLogic Server for OKE can create a subnet for the Kubernetes cluster that hosts your 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 OKE, the worker nodes in the Kubernetes cluster are assigned to a subnet. We recommend that you use a private subnet for the Kubernetes cluster.

By default subnets span an entire region in Oracle Cloud Infrastructure. Alternatively, you can create multiple subnets that are each specific to one availability domain (AD) in a region. Oracle WebLogic Server for OKE supports both regional and AD-scoped subnets.

If you want to use an existing subnet for the Kubernetes cluster 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) from the subnet that you plan to use for the administration compute instance.
  • The subnet must have a security list that enables inbound access to all ports from the subnet that you plan to use for the load balancer.
  • The subnet must have a security list that enables outbound access to the NFS port (2049) on the file system subnet.
  • 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 use an existing subnet, you can specify the subnet compartment that is different than the VCN compartment.

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

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

See VCNs and Subnets and Network Resource Configuration for Cluster Creation and Deployment in the Oracle Cloud Infrastructure documentation.

Create a Subnet for the Administration Host

Oracle WebLogic Server for OKE can create a subnet for your domain's administration compute instance, 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 OKE, the administration compute instance is assigned to a subnet. We recommend that you use a private subnet.

By default subnets span an entire region in Oracle Cloud Infrastructure. Alternatively, you can create multiple subnets that are each specific to one availability domain (AD) in a region. Oracle WebLogic Server for OKE supports both regional and AD-scoped subnets.

If you want to use an existing subnet for the administration compute instance 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) from the subnet that you plan to use for the bastion compute instance.
  • 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 the Kubernetes cluster.
  • The subnet must have a security list that enables outbound access to the WebLogic administration server ports (by default, 7001 and 7002) on the subnet that you plan to use for the Kubernetes cluster.
  • The subnet must have a security list that enables outbound access to the NFS port (2049) on the file system subnet.

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

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

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

See VCNs and Subnets in the Oracle Cloud Infrastructure documentation.

Create a Subnet for the Bastion Host

Oracle WebLogic Server for OKE can create a public subnet in Oracle Cloud Infrastructure for the bastion compute instance that is used to access your 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 OKE, we recommend that you use a private subnet for the Kubernetes cluster and the administration compute instance. Because these resources can not be directly accessed from outside of Oracle Cloud, Oracle WebLogic Server for OKE creates a bastion compute instance on a public subnet.

By default subnets span an entire region in Oracle Cloud Infrastructure. Alternatively, you can create subnets that are specific to one availability domain (AD) in a region. Oracle WebLogic Server for OKE supports both regional and AD-scoped subnets.

If you want to use an existing subnet for the bastion compute instance 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 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 the administration compute instance.

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

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

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

See VCNs and Subnets in the Oracle Cloud Infrastructure documentation.

Create a Subnet for the Load Balancer

Oracle WebLogic Server for OKE can create a subnet for the load balancer that is used to access an 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, Oracle WebLogic Server for OKE creates two load balancers and assigns them to a public subnet.

  • The public load balancer is used to access applications on the WebLogic managed servers.
  • The private load balancer is used to access the WebLogic Server administration console and the Jenkins console. It is not assigned a public IP address from the subnet.

By default subnets span an entire region in Oracle Cloud Infrastructure. Alternatively, you can create subnets that are specific to one availability domain (AD) in a region. Oracle WebLogic Server for OKE supports both regional and AD-scoped subnets.

If you want to use an existing subnet for the load balancer 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 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 WebLogic administration server ports (by default, 7001 and 7002) on the subnet that you plan to use for the Kubernetes cluster.
  • The subnet must have a security list that enables outbound access to the WebLogic managed server ports (by default, 7003 and 7004) on the subnet that you plan to use for the Kubernetes cluster.
  • The subnet must have a security list that enables outbound access to the Jenkins port (80) on the subnet that you plan to use for the Kubernetes cluster.
If you use an existing subnet, you can specify the subnet compartment that is different than the VCN compartment.

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

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

See VCNs and Subnets in the Oracle Cloud Infrastructure documentation.

Create a Subnet for the File System

Oracle WebLogic Server for OKE can create a subnet for the shared file system that you use to manage your 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 OKE, the file system is assigned to a subnet. We recommend that you use a private subnet for the file system.

By default subnets span an entire region in Oracle Cloud Infrastructure. Alternatively, you can create multiple subnets that are each specific to one availability domain (AD) in a region. Oracle WebLogic Server for OKE supports both regional and AD-scoped subnets.

If you want to use an existing subnet for the file system 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 NFS port (2049) from the private subnet that you plan to use for the Kubernetes cluster.
  • The subnet must have a security list that enables inbound access to the NFS port from the private subnet that you plan to use for the administration compute instance.

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

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

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

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.

A JRF-enabled domain supports the Oracle Application Development Framework (ADF). When you create a domain with Oracle WebLogic Server for OKE and associate it with an existing database, Oracle WebLogic Server for OKE 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

Choose one of these database options:

  • Oracle Autonomous Database
    • Create a serverless database. Oracle WebLogic Server for OKE does not yet support using a dedicated deployment database.
    • See Creating an Autonomous Database in the Oracle Cloud Infrastructure documentation.
  • Oracle Cloud Infrastructure Database

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 - Update the network security group that is assigned to the database, or update the security lists for the subnet on which the database was created, if necessary.

To create a JRF-enabled domain with Oracle WebLogic Server for OKE, 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)

Oracle WebLogic Server for OKE supports the same database versions and drivers as those for on-premise WebLogic Server installations. See System Requirements and Supported Platforms for Oracle Fusion Middleware 12c (12.2.1.4.0) at Oracle Fusion Middleware Supported System Configurations.

Create a Confidential Application

Before creating an Oracle WebLogic Server for OKE 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 OKE provisions an App Gateway and other security components in Oracle Identity Cloud Service. In order for Oracle WebLogic Server for OKE 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 with Passwords.

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

  1. From the Oracle Identity Cloud Service Console, click the navigation menu, and then select Applications.
  2. Click Add.
  3. Select Confidential Application.
  4. Enter a Name, and then click Next.
  5. Click Configure this application as a client now.
  6. For Allowed Grant Types, select Client Credentials.
  7. Below Grant the client access to Identity Cloud Service Admin APIs, click Add.
  8. Select Identity Domain Administrator, and then click Add.
  9. (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.
  10. Complete the Add Confidential Application wizard. Record the values of Client ID and Client Secret.
  11. Select the check box for your application, click Activate, and then click OK.
  12. 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.

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 OKE. 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 the administration instance private subnet and the worker nodes private subnets.

  • Validates if internet gateway is created for public bastion, file shared system and load balancer subnets.

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

  • Checks if the existing subnet for the load balancer has a security list that enables inbound access to ports 80 and 443.

  • Validates if all protocols are open in private subnet for Kubernetes worker node for the Worker CIDR range.

  • Validates if all protocols are open in private subnet for Kubernetes worker node for the VCN CIDR range.

  • Validates if the file shared system has a security list that enables outbound access to ports 111 and 2048 (both TCP and UDP).

  • Validates if the database port is accessible from WebLogic Server subnets.

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 validateoke.sh. See Script File To Validate Network Setup to create the validateoke.sh file.
  1. Set execute permission to the validateoke.sh file.

    chmod +x validateoke.sh

  2. Run the validateoke.sh command.

    ./validateoke.sh [OPTIONS]

    The following table lists the options that can be used with the validateoke.sh comand.
    Parameter Description
    Short Form Long Form  
    -b --bastionsubnet Bastion Subnet OCID
    -a --adminsubnet Administration Host Subnet OCID
    -w --workersubnet Worker Subnet OCID
    -f --fsssubnet File Shared System Subnet OCID
    -l --lbsubnet Load Balancer Subnet OCID
    -d --dbsubnet Database Subnet OCID

    This parameter is required only if you provision a JRF domain.

    -i --bastionipcidr Bastion Host IP CIDR

    The bastion host IP CIDR must have /32 suffix.

    - --debug Runs script in BASH debug mode (set -x)
    -h --help Displays help and exits
    - --version Displays output version information and exits
  3. Based on the domain type, run the following commands prior to provisioning:
    • Basic domain

      ./validateoke.sh -b <Bastion Subnet OCID> -a <Administration Host Subnet OCID> -w <Worker Subnet OCID> -f <File Shared System Subnet OCID> -l <Load Balancer Subnet OCID>

    • JRF-enabled domain

      ./validateoke.sh -b <Bastion Subnet OCID> -a <Administration Host Subnet OCID> -w <Worker Subnet OCID> -f <File Shared System Subnet OCID> -l <Load Balancer Subnet OCID> -d <DB Subnet OCID>

    Note:

    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.

    ./validateoke.sh -b <Bastion Subnet OCID> -i <Bastion Host IP CIDR> -a <Administration Host Subnet OCID> -w <Worker Subnet OCID> -f <File Shared System Subnet OCID> -l <Load Balancer Subnet OCID> -d <DB Subnet OCID>

An example of validateoke.sh command to check the existing WebLogic Server subnet (and optionally database subnet) network setup when the required ports, gateways are missing in the existing VCN and existing subnets:
example_user@cloudshell:~ (us-phoenix-1)$ ./validateoke.sh -b <Bastion Subnet OCID> 
-a <Administration Host Subnet OCID> -w <Worker Subnet OCID> -f <File Shared System Subnet OCID> 
-l <Load Balancer Subnet OCID> -d <DB Subnet OCID>
ERROR: SSH port 22 is not open for access by [0.0.0.0/0] in <Bastion Subnet OCID>
WARNING: SSH port 22 is not open for access by Bastion Subnet CIDR [10.0.0.0/24] in private Admin Host Subnet [<Administration Host Subnet OCID>]
ERROR: Missing Service or NAT gateway in the VCN of the private ADMIN_SUBNET Host subnet ocid [<Administration Host Subnet OCID>]
WARNING: Missing internet gateway in the VCN of the BASTION_SUBNET subnet [<Bastion Subnet OCID>]
WARNING: Missing internet gateway in the VCN of the LB_SUBNET subnet [<Load Balancer Subnet OCID>]
WARNING: Missing internet gateway in the VCN of the FSS_SUBNET_OCID subnet [<File Shared System Subnet OCID>]
WARNING: For LB CIDR - Ports are not open in Workers Subnet CIDR 31474
WARNING: For LB CIDR - Ports are not open in Workers Subnet CIDR 10256
WARNING: For LB CIDR - Ports are not open in Workers Subnet CIDR 31804
WARNING: All Ports are not open for LB Subnet CIDR
WARNING: All Ports are not open for LB Subnet CIDR
WARNING: All Ports are not open for LB Subnet CIDR
ERROR: All Protocols are not open for WORKER's Subnet CIDR
ERROR: All Protocols are not open in WORKER's Subnet for VCN CIDR
ERROR: TCP -- 111 -- Port is not open in FSS Subnet for VCN CIDR
ERROR: TCP -- 2048 -- Port is not open in FSS Subnet for VCN CIDR
ERROR: TCP -- 2049 -- Port is not open in FSS Subnet for VCN CIDR
ERROR: TCP -- 2050 -- Port is not open in FSS Subnet for VCN CIDR
ERROR: TCP -- 111 -- Port is not open in FSS Subnet for VCN CIDR
ERROR: TCP -- 2048 -- Port is not open in FSS Subnet for VCN CIDR
ERROR: TCP -- 2049 -- Port is not open in FSS Subnet for VCN CIDR
ERROR: TCP -- 2050 -- Port is not open in FSS Subnet for VCN CIDR
ERROR: DB port 1521 is not open for access by VCN CIDR [10.0.0.0/16] or Worker Subnet CIDR [10.0.1.0/24] in DB Subnet [<DB Subnet OCID>]