Prerequisites to Create a Domain

Complete the prerequisites before you create a domain.

Required Tasks

• Create Policies for the Dynamic Group
• Create a Database
• Create a Confidential Application
• Approve Scripts to View Parameters
• Validate Existing Network Setup

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 specific components in Oracle Cloud Infrastructure.

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

Allow dynamic-group MyInstancesPrincipalGroup to use autonomous-transaction-processing-family in compartment ATP_Database_Compartment
Allow dynamic-group MyInstancesPrincipalGroup to inspect db-systems in compartment id OCIDBCompartmentID
Allow dynamic-group MyInstancesPrincipalGroup to inspect databases in compartment id OCIDBCompartmentID

See these topics in the Oracle Cloud Infrastructure documentation:

• Common Policies
• Writing Policies for Dynamic Groups

Create a Database

If you are using Domain on PV, a WebLogic Kubernetes Operator (WKO) domain home source type, to create an Oracle WebLogic Server Java Required Files (JRF) domain, then, before creating the domain that includes the JRF components, you must create a database in Oracle Cloud Infrastructure.

A JRF-enabled domain is used by Fusion Middleware products. The JRF domain has database requirements. The database components are created using the Repository Creation Utility (RCU); a new RCU schema is created before creating a JRF-based domain.

A JRF-enabled domain includes the Java Required Files (JRF) components and requires access to an existing database in Oracle Autonomous Database or Oracle Cloud Infrastructure Database (DB System). If using a DB System database, ensure that the DB System and the Kubernetes cluster are in the same Virtual Cloud Network (VCN).

Note:

For each schema that is created in the database, a data source is created in WebLogic Server. These data sources should not be used by applications deployed to the WebLogic domain after provisioning is complete. Instead, you must create independent data sources. See About Data Sources.

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.

    Note:

    Oracle Application Express (APEX) autonomous database is not supported.
• Oracle Cloud Infrastructure Database
  • Create a bare metal, virtual machine (VM), or Exadata DB system.
  • The Virtual Cloud Network (VCN) of the Oracle Cloud Infrastructure database must be same as the WebLogic Server VCN.
  • 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 - 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
• Oracle Cloud Identifier (OCID) of the Oracle Cloud Infrastructure Database database system or the Autonomous Transaction Processing (ATP) database. This information is optional if you use a database connection string.

Oracle WebLogic Server for OKE supports the same database versions and drivers as those for on-premise WebLogic Server installations. Refer to the following documents at Oracle Fusion Middleware Supported System Configurations:

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

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.

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.

Approve Scripts to View Parameters

At times, the Jenkins UI input parameters in a list are not rendered. So, you need to approve groovy scripts to view all the parameters in a list.

Complete the following steps to approve the scripts:

1. Sign in to the Jenkins console for your stack. See Access the Jenkins Console.
2. Go to Dashboard > Manage Jenkins.
3. Under Security, click In-process Script Approval.
4. Click Approve against all the groovy scripts.

   All the parameters are now listed in the pipeline jobs.

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 following command prior to creating a domain:

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

   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>

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