b. Create OIG domains using WDT Models

  1. Introduction

  2. Prerequisites

  3. Create OIG domains using WDT models

    a. Prepare the persistent storage

    b. Create Kubernetes secrets for the domain and RCU

    c. Generate WDT models and the domain resource yaml file

    d. Build the Domain Creation Image

    e. Deploy the OIG domain resource

  4. Verify the results

    a. Verify the domain, pods and services

    b. Verify the domain

    c. Verify the pods

Introduction

This section demonstrates the creation of an OIG domain home using sample WebLogic Deploy Tooling (WDT) model files.

From WebLogic Kubernetes Operator version 4.1.2 onwards, you can provide a section, domain.spec.configuration.initializeDomainOnPV, to automatically initialize an OIG domain on a persistent volume when it is first deployed. This eliminates the need to pre-create your OIG domain using sample WebLogic Scripting Tool (WLST) offline scripts.

With WLST offline scripts it is required to deploy a separate Kubernetes job that creates the domain on a persistent volume, and then deploy the domain with a custom resource YAML. The RCU schema also had to be created and patched manually beforehand. Now, starting from Apr'24 release onwards, using WDT models, all the required information is specified in the domain custom resource YAML file, eliminating the requirement for running a separate Kubernetes job. With WDT models, the WebLogic Kubernetes Operator will create the PersistentVolume (PV) and PersistenVolumeClaim (PVC), create the RCU schemas and patch them, then create the OIG domain on the persistent volume, prior to starting the servers.

Note: This is a one time only initialization. After the domain is created, subsequent updates to this section in the domain resource YAML file will not recreate or update the WebLogic domain. Subsequent domain lifecycle updates must be controlled by the WebLogic Server Administration Console, Enterprise Manager Console, WebLogic Scripting Tool (WLST), or other mechanisms.

WebLogic Deploy Tooling (WDT) models are a convenient and simple alternative to WebLogic Scripting Tool (WLST) configuration scripts. They compactly define a WebLogic domain using model files, variable properties files, and application archive files. For more information about the model format and its integration, see Usage and Working with WDT Model files. The WDT model format is fully described in the open source, WebLogic Deploy Tooling GitHub project.

The main benefits of WDT are:

  • A set of single-purpose tools supporting WebLogic domain configuration lifecycle operations.
  • All tools work off of a shared, declarative model, eliminating the need to maintain specialized WLST scripts.
  • WDT knowledge base understands the MBeans, attributes, and WLST capabilities/bugs across WLS versions.

The initializeDomainOnPv section:

  1. Creates the PersistentVolume (PV) and/or PersistenVolumeClaim (PVC).
  2. Creates and patches the RCU schema.
  3. Creates the OIG domain home on the persistent volume based on the provided WDT models

Prerequisites

Before you begin, perform the following steps:

  1. Review the Domain On PV documentation.
  2. Ensure that the database is up and running.

Create OIG domains using WDT models

In this section you will:

Note: In this section a domain creation image is built using the supplied model files and that image is used for domain creation. You will need your own container registry to upload the domain image to. Having your own container repository is a prerequisite before creating an OIG domain with WDT models. If you don’t have your own container registry, you can load the image on each node in the cluster instead. This documentation does not explain how to create your own container registry, or how to load the image onto each node. Consult your vendor specific documentation for more information.

Note: Building a domain creation image is a one time activity. The domain creation image can be used to create an OIG domain in multiple environments. You do not need to rebuild the domain creation image every time you create a domain.

Prepare the persistent storage

As referenced in Prerequisites the nodes in the Kubernetes cluster must have access to a persistent volume such as a Network File System (NFS) mount or a shared file system.

Domain on persistent volume (Domain on PV) is an operator domain home source type, which requires that the domain home exists on a persistent volume.

When a container is started, it needs to mount that volume. The physical volume should be on a shared disk accessible by all the Kubernetes worker nodes because it is not known on which worker node the container will be started. In the case of Oracle Identity and Access Management, the persistent volume does not get erased when a container stops. This enables persistent configurations.

The example below uses an NFS mounted volume (<persistent_volume>/governancedomainpv). Other volume types can also be used. See the official Kubernetes documentation for Volumes.

Note: The persistent volume directory needs to be accessible to both the master and worker node(s). In this example /scratch/shared/governancedomainpv is accessible from all nodes via NFS.

To create the persistent volume run the following commands:

  1. Create the required directories:

    $ mkdir -p <persistent_volume>/governancedomainpv
    $ sudo chown -R 1000:0 <persistent_volume>/governancedomainpv
    

    For example,

    $ mkdir -p /scratch/shared/governancedomainpv
    $ sudo chown -R 1000:0 /scratch/shared/governancedomainpv
    
  2. On the master node run the following command to ensure it is possible to read and write to the persistent volume:

    cd <persistent_volume>/governancedomainpv
    touch file.txt
    ls filemaster.txt
    

    For example:

    cd /scratch/shared/governancedomainpv
    touch filemaster.txt
    ls filemaster.txt
    
  3. On the first worker node run the following to ensure it is possible to read and write to the persistent volume:

    cd /scratch/shared/governancedomainpv
    ls filemaster.txt
    touch fileworker1.txt
    ls fileworker1.txt
    
  4. Repeat the above for any other worker nodes e.g fileworker2.txt etc. Once proven that it’s possible to read and write from each node to the persistent volume, delete the files created.

    For more information on PV and PVC requirements, see Domain on Persistent Volume (PV).

Create Kubernetes secrets for the domain and RCU

  1. Create a Kubernetes secret for the domain using the create-secret.sh script in the same Kubernetes namespace as the domain:

    $ cd $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils
    $ ./create-secret.sh -l "username=weblogic" -l "password=****" -n <domain_namespace> -d <domain_uid> -s <domain_uid>-weblogic-credentials
    

    where:

    -n <domain_namespace> is the domain namespace you created in Create a namespace for Oracle Identity Governance. For example oigns.

    -d <domain_uid> is the domain UID that you want to create. For example, governancedomain.

    -s <domain_uid>-weblogic-credentials is the name of the secret for this namespace. Note: The secret name must follow this format (<domain_uid>-weblogic-credentials) or domain creation will fail.

    For example:

    $ cd $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils
    $ ./create-secret.sh -l "username=weblogic" -l "password=<password>" -n oigns -d governancedomain -s governancedomain-weblogic-credentials
    

    The output will look similar to the following:

    @@ Info: Setting up secret 'governancedomain-weblogic-credentials'.
    secret/governancedomain-weblogic-credentials created
    secret/governancedomain-weblogic-credentials labeled
    
  2. Verify the secret is created using the following command:

    $ kubectl get secret <kubernetes_domain_secret> -o yaml -n <domain_namespace>
    

    For example:

    $ kubectl get secret governancedomain-weblogic-credentials -o yaml -n oigns
    

    The output will look similar to the following:

    apiVersion: v1
    data:
      password: <password>
      username: d2VibG9naWM=
    kind: Secret
    metadata:
      creationTimestamp: "<DATE>"
      labels:
        weblogic.domainName: governancedomain
        weblogic.domainUID: governancedomain
      name: governancedomain-weblogic-credentials
      namespace: oigns
      resourceVersion: "3216738"
      uid: c2ec07e0-0135-458d-bceb-c648d2a9ac54
    type: Opaque
    
  3. Create a Kubernetes secret for RCU in the same Kubernetes namespace as the domain, using the create-secrets.sh script:

    $ cd $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils
    $ ./create-secret.sh -l "rcu_prefix=<rcu_prefix>" -l "rcu_schema_password=<rcu_schema_pwd>" -l "db_host=<db_host.domain>" -l "db_port=<db_port>" -l "db_service=<service_name>" -l "dba_user=<sys_db_user>" -l "dba_password=<sys_db_pwd>" -n <domain_namespace> -d <domain_uid> -s <domain_uid>-rcu-credentials
    

    where

    <rcu_prefix> is the name of the RCU schema to be created.

    <rcu_schema_pwd> is the password you want to create for the RCU schema prefix.

    <db_host.domain> is the database server hostname.

    <db_port> is the database listener port.

    <service_name> is the database service name.

    <sys_db_user> is the database user with sys dba privilege.

    <sys_db_pwd> is the sys database password.

    <domain_uid> is the domain_uid that you want to create. This must be the same domain_uid used in the domain secret. For example, governancedomain.

    <domain_namespace> is the domain namespace you created in Create a namespace for Oracle Identity Governance. For example oigns.

    <domain_uid>-rcu-credentials is the name of the rcu secret to create. Note: The secret name must follow this format (<domain_uid>-rcu-credentials) or domain creation will fail.

    For example:

    $ cd $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils
    $ ./create-secret.sh -l "rcu_prefix=OIGK8S" -l "rcu_schema_password=<rcu_schema_password>" -l "db_host=mydatabasehost.example.com" -l "db_port=1521" -l "db_service=orcl.example.com" -l "dba_user=sys" -l "dba_password=<dba_password>" -n oigns -d governancedomain -s governancedomain-rcu-credentials
    

    The output will look similar to the following:

    @@ Info: Setting up secret 'governancedomain-rcu-credentials'.
    secret/governancedomain-rcu-credentials created
    secret/governancedomain-rcu-credentials labeled
    
  4. Verify the secret is created using the following command:

    $ kubectl get secret <kubernetes_rcu_secret> -o yaml -n <domain_namespace>
    

    For example:

    $ kubectl get secret governancedomain-rcu-credentials -o yaml -n oigns
    

    The output will look similar to the following:

    apiVersion: v1
    data:
      db_host: <DB_HOST>
      db_port: MTUyMQ==
      db_service: <SERVICE_NAME>
      dba_password: <PASSWORD>
      dba_user: c3lz
      rcu_prefix: <RCU_PREFIX>
      rcu_schema_password: <RCU_PWD>
    kind: Secret
    metadata:
      creationTimestamp: "<DATE>"
      labels:
        weblogic.domainUID: governancedomain
      name: governancedomain-rcu-credentials
      namespace: oigns
      resourceVersion: "31695660"
      uid: 71cfcc73-4c96-42bd-b9a5-988ea9ed27ff
    type: Opaque
    

Generate WDT models and the domain resource yaml file

In this section you generate the required WDT models for the OIG domain, along with the domain resource yaml file.

  1. Navigate to the $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils/generate_models_utils directory:

    $ cd $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils/generate_models_utils
    
  2. Make a copy of the create-domain-wdt.yaml file:

    $ cp create-domain-wdt.yaml create-domain-wdt.yaml.orig
    
  3. Edit the create-domain-wdt.yaml and modify the following parameters. Save the file when complete:

    domainUID: <domain_uid>
    domainHome: /u01/oracle/user_projects/domains/<domain_uid>
    image: <image_name>:<tag>
    imagePullSecretName: <container_registry_secret>
    logHome: /u01/oracle/user_projects/domains/logs/<domain_uid>
    namespace: <domain_namespace>
    weblogicDomainStorageType: NFS
    weblogicDomainStorageNFSServer: <nfs_server>
    weblogicDomainStoragePath: <physical_path_of_persistent_storage>
    weblogicDomainStorageSize: 10G
    

    Note: The <domain_namespace> and <domain_uid> must be the same as those used in Creating Kubernetes secrets for the domain and RCU

    For example:

    domainUID: governancedomain
    domainHome: /u01/oracle/user_projects/domains/governancedomain
    image: container-registry.oracle.com/middleware/oig_cpu:12.2.1.4-jdk8-ol8-<October'24>
    imagePullSecretName: orclcred
    logHome: /u01/oracle/user_projects/domains/logs/governancedomain
    namespace: oigns
    weblogicDomainStorageType: NFS
    weblogicDomainStorageNFSServer: mynfsserver
    weblogicDomainStoragePath: /scratch/shared/governancedomain
    weblogicDomainStorageSize: 10G
    

    ``

    Note : If using a shared file system instead of NFS, set weblogicDomainStorageType: HOST_PATH and remove weblogicDomainStorageNFSServer.

    A full list of parameters in the create-domain-wdt.yaml file are shown below:

Parameter Definition Default
adminPort Port number for the Administration Server inside the Kubernetes cluster. 7001
adminNodePort Port number for the Administration Server outside the Kubernetes cluster. 30701
configuredManagedServerCount Number of Managed Server instances to generate for the domain. 5
datasourceType Type of JDBC datasource applicable for the OIG domain. Legal values are agl and generic. Choose agl for Active GridLink datasource and generic for Generic datasource. For enterprise deployments, Oracle recommends that you use GridLink data sources to connect to Oracle RAC databases. See the Enterprise Deployment Guide for further details. generic
domainHome Home directory of the OIG domain. If not specified, the value is derived from the domainUID as /shared/domains/<domainUID>. /u01/oracle/user_projects/domains/governancedomain
domainPVMountPath Mount path of the domain persistent volume. /u01/oracle/user_projects/domains
domainUID Unique ID that will be used to identify this particular domain. Used as the name of the generated WebLogic domain as well as the name of the Kubernetes domain resource. This ID must be unique across all domains in a Kubernetes cluster. This ID cannot contain any character that is not valid in a Kubernetes service name. governancedomain
edgInstall Used only if performing an install using the Enterprise Deployment Guide. See, Enterprise Deployment Guide for Oracle Identity and Access Management in a Kubernetes Cluster. false
exposeAdminNodePort Boolean indicating if the Administration Server is exposed outside of the Kubernetes cluster. false
exposeAdminT3Channel Boolean indicating if the T3 administrative channel is exposed outside the Kubernetes cluster. true
frontEndHost The entry point URL for the OIM. example.com
frontEndHost The entry point port for the OIM. 14000
image OIG container image. The operator requires OIG 12.2.1.4. Refer to Obtain the OIG container image for details on how to obtain or create the image. For WDT domains you must use April 24 or later. oracle/oig:12.2.1.4.0
imagePullSecretName Name of the Kubernetes secret to access the container registry to pull the OIG container image. The presence of the secret will be validated when this parameter is specified.
initialManagedServerReplicas Number of Managed Servers to initially start for the domain. 2
javaOptions Java options for starting the Administration Server and Managed Servers. A Java option can have references to one or more of the following pre-defined variables to obtain WebLogic domain information: $(DOMAIN_NAME), $(DOMAIN_HOME), $(ADMIN_NAME), $(ADMIN_PORT), and $(SERVER_NAME). -Dweblogic.StdoutDebugEnabled=false
logHome The in-pod location for the domain log, server logs, server out, and Node Manager log files. If not specified, the value is derived from the domainUID as /shared/logs/<domainUID>. /u01/oracle/user_projects/domains/logs/governancedomain
namespace Kubernetes namespace in which to create the domain. oigns
oimCPU Initial CPU Units, 1000m = 1 CPU core. 1000m
oimMaxCPU Max CPU Cores pod is allowed to consume. 2
oimMemory Initial memory allocated to a pod. 4Gi
oimMaxMemory Max memory a pod is allowed to consume. 8Gi
oimServerJavaParams The memory parameters to use for the OIG managed servers. "-Xms8192m -Xmx8192m"
productionModeEnabled Boolean indicating if production mode is enabled for the domain. true
soaCPU Initial CPU Units, 1000m = 1 CPU core. 1000m
soaMaxCPU Max CPU Cores pod is allowed to consume. 1
soaMemory Initial Memory pod allocated to a pod. 4Gi
soaMaxMemory Max Memory pod is allowed to consume. 10Gi
soaServerJavaParams The memory parameters to use for the SOA managed servers. "-Xms8192m -Xmx8192m"
t3PublicAddress Public address for the T3 channel. This should be set to the public address of the Kubernetes cluster. This would typically be a load balancer address. For development environments only: In a single server (all-in-one) Kubernetes deployment, this may be set to the address of the master, or at the very least, it must be set to the address of one of the worker nodes. If not provided, the script will attempt to set it to the IP address of the Kubernetes cluster
weblogicDomainStorageType Persistent volume storage type. Options are NFS for NFS volumes or HOST_PATH for shared file system. NFS
weblogicDomainStorageNFSServer Hostname or IP address of the NFS Server. nfsServer
weblogicDomainStoragePath Physical path to the persistent volume. /scratch/governancedomainpv
weblogicDomainStorageSize Total storage allocated to the persistent storage. 10Gi

Note: The above CPU and memory values are for examples only. For Enterprise Deployments, please review the performance recommendations and sizing requirements in Enterprise Deployment Guide for Oracle Identity and Access Management in a Kubernetes Cluster.

  1. Run the generate_wdt_models.sh, specifying your input file and an output directory to store the generated artifacts:

     $ cd $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils/generate_models_utils
     $ ./generate_wdt_models.sh -i create-domain-wdt.yaml -o <path_to_output_directory>
    

    For example:

    $ cd $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils/generate_models_utils
    $ ./generate_wdt_models.sh -i create-domain-wdt.yaml -o output
    

    The output will look similar to the following:

    input parameters being used
    export version="create-weblogic-sample-domain-inputs-v1"
    export adminPort="7001"
    export domainUID="governancedomain"
    export configuredManagedServerCount="5"
    export initialManagedServerReplicas="1"
    export productionModeEnabled="true"
    export t3ChannelPort="30012"
    export datasourceType="generic"
    export edgInstall="false"
    export domainHome="/u01/oracle/user_projects/domains/governancedomain"
    export image="container-registry.oracle.com/middleware/oig_cpu:12.2.1.4-jdk8-ol8-<October'24>"
    export imagePullSecretName="orclcred"
    export logHome="/u01/oracle/user_projects/domains/logs/governancedomain"
    export exposeAdminT3Channel="false"
    export adminNodePort="30701"
    export exposeAdminNodePort="false"
    export namespace="oigns"
    javaOptions=-Dweblogic.StdoutDebugEnabled=false
    export domainPVMountPath="/u01/oracle/user_projects"
    export weblogicDomainStorageType="NFS"
    export weblogicDomainStorageNFSServer="mynfsServer"
    export weblogicDomainStoragePath="/scratch/shared/governancedomainpv"
    export weblogicDomainStorageReclaimPolicy="Retain"
    export weblogicDomainStorageSize="10Gi"
    export frontEndHost="example.com"
    export frontEndPort="14000"
    export oimServerJavaParams="-Xms8192m -Xmx8192m "
    export soaServerJavaParams="-Xms8192m -Xmx8192m "
    export oimMaxCPU="2"
    export oimCPU="1000m"
    export oimMaxMemory="8Gi"
    export oimMemory="4Gi"
    export soaMaxCPU="1"
    export soaCPU="1000m"
    export soaMaxMemory="10Gi"
    export soaMemory="4Gi"
    	
    validateWlsDomainName called with governancedomain
    WDT model file, property file and sample domain.yaml are genereted successfully at output/weblogic-domains/governancedomain
    

    ``

    This will generate domain.yaml, oig.yaml and oig.properties in output/weblogic-domains/governancedomain.

  2. Copy the generated files to a $WORKDIR/yaml directory:

     $ mkdir $WORKDIR/yaml
     $ cp output/weblogic-domains/governancedomain/*.* $WORKDIR/yaml
    

    ``

Build the Domain Creation Image

In this section you build a domain creation image to host the WDT model files and WebLogic Deploy Tooling (WDT) installer.

Domain creation images are used for supplying WDT model files, WDT variables files, WDT application archive files (collectively known as WDT model files), and the directory where the WebLogic Deploy Tooling software is installed (known as the WDT Home), when deploying a domain using a Domain on PV model. You distribute WDT model files and the WDT executable using these images, and the WebLogic Kubernetes Operator uses them to manage the domain.

Note: These images are only used for creating the domain and will not be used to update the domain. The domain creation image is used for domain creation only, it is not the product container image used for OIG.

For more details on creating the domain image, see Domain creation images.

The steps to build the domain creation image are shown in the sections below.

Prerequisites

Verify that your environment meets the following prerequisites:

  • You have created the yaml files are per Generate WDT models and the domain resource yaml file.
  • You have a container registry available to push the domain creation image to.
  • A container image client on the build machine, such as Docker or Podman.
    • For Docker, a minimum version of 18.03.1.ce is required.
    • For Podman, a minimum version of 3.0.1 is required.
  • An installed version of JDK to run Image Tool, version 8+.
  • Proxies are set accordingly at the OS level if required.
Prepare the build domain image script

The sample scripts for the Oracle Identity Governance domain image creation are available at $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image.

  1. Navigate to the $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image/properties directory:

    $ cd $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image/properties
    
  2. Make a copy of the build-domain-creation-image.properties:

    $ cp build-domain-creation-image.properties build-domain-creation-image.properties.orig
    
  3. Edit the build-domain-creation-image.properties and modify the following parameters. Save the file when complete:

    JAVA_HOME=<Java home location>
    IMAGE_TAG=<Image tag name>
    REPOSITORY=<Container image repository to push the image>
    REG_USER= <Container registry username>
    IMAGE_PUSH_REQUIRES_AUTH=<Whether image push requires authentication to the registry>
    WDT_MODEL_FILE=<Full Path to WDT Model file oig.yaml> 
    WDT_VARIABLE_FILE=<Full path to WDT variable file oig.properties>
    WDT_ARCHIVE_FILE=<Full Path to WDT Archive file> 
    WDT_VERSION="Version of WebLogic Deploy Tool version to use"
    WIT_VERSION="Version of WebLogic Image Tool to use"
    

    For example:

    JAVA_HOME=/scratch/jdk
    IMAGE_TAG=oig-aux-generic-v1
    BASE_IMAGE=ghcr.io/oracle/oraclelinux:8-slim
    REPOSITORY=container-registry.example.com/mytenancy/idm
    REG_USER=mytenancy/myemail@example.com
    IMAGE_PUSH_REQUIRES_AUTH=true
    WDT_MODEL_FILE="/scratch/OIGK8S/fmw-kubernetes/OracleIdentityGovernance/yaml/oig.yaml"
    WDT_VARIABLE_FILE="/scratch/OIGK8S/fmw-kubernetes/OracleIdentityGovernance/oig.properties"
    WDT_ARCHIVE_FILE=""
    WDT_VERSION="3.5.3"
    WIT_VERSION="1.12.1"
    

    A full list of parameters and descriptions in the build-domain-creation-image.properties file are shown below:

Parameter Definition Default
JAVA_HOME Path to the JAVA_HOME for the JDK8+.
IMAGE_TAG Image tag for the final domain creation image. oig-aux-generic-v1
BASE_IMAGE The Oracle Linux product container image to use as a base image. ghcr.io/oracle/oraclelinux:8-slim
REPOSITORY Container image repository that will host the domain creation image. iad.ocir.io/mytenancy/idm
REG_USER Username to authenticate to the <REPOSITORY> and push the domain creation image. mytenancy/oracleidentitycloudservice/myemail@example.com
IMAGE_PUSH_REQUIRES_AUTH If authentication to <REPOSITORY> is required then set to true, else set to false. If set to false, <REG_USER> is not required. true
WDT_MODEL_FILE Absolute path to WDT model file oig.yaml. For example $WORKDIR/yaml/oig.yaml.
WDT_MODEL_FILE Absolute path to WDT variable file oig.properties. For example $WORKDIR/yaml/oig.properties.
WDT_ARCHIVE_FILE Absolute path to WDT archive file.
WDT_VERSION WebLogic Deploy Tool version. If not specified the latest available version will be downloaded. It is recommended to use the default value. 3.5.3
WIT_VERSION WebLogic Image Tool Version. If not specified the latest available version will be downloaded. It is recommended to use the default value. 1.12.1
TARGET Select the target environment in which the created image will be used. Supported values: Default or OpenShift. See Additional Information. Default
CHOWN userid:groupid to be used for creating files within the image, such as the WDT installer, WDT model, and WDT archive. If the user or group does not exist in the image, they will be added with useradd/groupadd. oracle:oracle

Note: If IMAGE_PUSH_REQUIRES_AUTH=true, you must edit the $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image/properties/.regpassword and change <REGISTRY_PASSWORD> to your registry password.

REG_PASSWORD="<REPOSITORY_PASSWORD>"
Run the build-domain-creation-image script
  1. Execute the build-domain-creation-image.sh by specifying the input properties parameter files:

     $ cd $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image
     $ ./build-domain-creation-image.sh -i properties/build-domain-creation-image.properties
    

    ``

    Note: If using a password file, you must add -p properties/.regpassword to the end of the command.

    Executing this command will build the image and push it to the container image repository.

    The output will look similar to the following:

    Click here to see example output:

Deploy the OIG domain resource

In this section you modify the OIG domain.yaml and deploy the OIG domain using the build image created.

Modify the OIG domain.yaml

In this section you modify the domain.yaml file in preparation for creating the OIG domain.

  1. Edit the $WORKDIR/yaml/domain.yaml and update the %DOMAIN_CREATION_IMAGE% with the previously generated image name.

    Note: %DOMAIN_CREATION_IMAGE% takes the format of <REPOSITORY>:<TAG>:

    domain:
             # Domain | DomainAndRCU
             createIfNotExists: DomainAndRCU
             # Image containing WDT installer and Model files.
             domainCreationImages:
                 - image: '%DOMAIN_CREATION_IMAGE%'
             domainType: OIG
    
    

    For example:

    domain:
            # Domain | DomainAndRCU
            createIfNotExists: DomainAndRCU
            # Image containing WDT installer and Model files.
            domainCreationImages:
                - image: 'container-registry.example.com/mytenancy/idm:oig-aux-generic-v1'
            domainType: OIG
    
    
  2. In circumstances where you may be pulling the OIG product container image from Oracle Container Registry, and then the domain image from a private registry, you must first create a secret (privatecred) for the private registry. For example:

    $ kubectl create secret docker-registry "privatecred" --docker-server=container-registry.example.com \
    --docker-username="user@example.com" \
    --docker-password=password --docker-email=user@example.com \
    --namespace=oigns
    

    Then specify both secrets for imagePullSecrets in the domain.yaml. For example:

     ...
    spec:
      # The WebLogic Domain Home
      domainHome: /u01/oracle/user_projects/domains/governancedomain
    
      # The domain home source type
      # Set to PersistentVolume for domain-in-pv, Image for domain-in-image, or FromModel for model-in-image
      domainHomeSourceType: PersistentVolume
    
      # The WebLogic Server image that the Operator uses to start the domain
      image: "container-registry.oracle.com/middleware/oig_cpu:12.2.1.4-jdk8-ol8-<October'24>"
    
      # imagePullPolicy defaults to "Always" if image version is :latest
      imagePullPolicy: IfNotPresent
    
      imagePullSecrets:
      - name: orclcred
      - name: privatecred
      # Identify which Secret contains the WebLogic Admin credentials
    ...
    

    ``

    For more information about the configuration parameters in domain.yaml, see Domain Resources.

    Click here to see an example domain.yaml:

    Note: By default, WebLogic operator will create the RCU schema using WDT tooling and patch them during every domain deployment. If the RCU Schema with the given prefix already exists, and error will be thrown and the domain creation will fail. If you want to delete the schema every time during domain deployment, then can change the value "-Dwdt.config.disable.rcu.drop.schema=true" to "-Dwdt.config.disable.rcu.drop.schema=false".

Optional WDT Models ConfigMap

If required, you can provide a Kubernetes ConfigMap with additional WDT models and WDT variables files as supplements, or overrides, to those in domainCreationImages. For example in the output/weblogic-domains/governancedomain/domain.yaml:

      domain:
          ...
          domainCreationImages:
              ...
          domainCreationConfigMap: mymodel-domain-configmap

The files inside domainCreationConfigMap must have file extensions, .yaml, .properties, or .zip.

  1. To create a configmap run the following command:

     $ cd $WORKDIR/kubernetes/create-oim-domain/domain-home-on-pv/wdt-utils
     $ ./create-configmap.sh -n oigns -d governancedomain -c mymodel-domain-configmap -f wdt_models/mymodel.yaml
    

For more information on the usage of additional configuration, see Optional WDT models ConfigMap.

Deploy the OIG domain

In this section you deploy the OIG domain using the domain.yaml.

  1. Run the following command to create OIG domain resources:

    $ kubectl create -f $WORKDIR/yaml/domain.yaml
    

    The following steps will be performed by WebLogic Kubernetes Operator:

    • Run the introspector job.
    • The introspection job will create the RCU Schemas and then patch them.
    • The introspector job pod will create the domain on PV using the model provided in the domain creation image.
    • The introspector job pod will execute OIG offline configuration actions post successful creation of domain via WDT.
    • Brings up the Administration Server, and the SOA Managed Server (soa_server1).

    The output will look similar to the following:

    domain.weblogic.oracle/governancedomain created
    cluster.weblogic.oracle/governancedomain-oim-cluster created
    cluster.weblogic.oracle/governancedomain-soa-cluster created
    

    Whilst the domain creation is running, you can run the following command to monitor the progress:

    $ kubectl get pods -n oigns -w
    

    You can also tail the logs for the pods by running:

    $ kubectl logs -f <pod> -n oigns
    

    WDT specific logs can be found in <persistent_volume>/domains/wdt-logs.

    Once everything is started you should see the Administration Server and SOA server are running:

    NAME                           READY   STATUS    RESTARTS   AGE
    governancedomain-adminserver   1/1     Running   0          13m
    governancedomain-soa-server1   1/1     Running   0          10m
    

    If there are any failures, follow Domain creation failure with WDT models in the Troubleshooting section.

    Note: Depending on the speed of your cluster, it can take around 25 minutes for all the pods to be in READY 1/1 state.

  2. Start the OIM server by running the following command:

     $ kubectl patch cluster -n oigns governancedomain-oim-cluster --type=merge -p '{"spec":{"replicas":1}}'
    

    ``

    The output will look similar to the following:

     cluster.weblogic.oracle/governancedomain-oim-cluster patched
    

    ``

    You can view the status of the OIM server by running:

     $ kubectl get pods -n oigns -w
    

    ``

    Once the OIM server is running, the output will look similar to the following:

     NAME                           READY   STATUS    RESTARTS   AGE
    governancedomain-adminserver   1/1     Running   0          16m
    governancedomain-soa-server1   1/1     Running   0          13m
    governancedomain-oim-server1   1/1     Running   0          5m22s
    

    ``

Verify the results

Verify the domain, pods and services

  1. Verify the domain, servers pods and services are created and in the READY state with a STATUS of 1/1, by running the following command:

    $ kubectl get all,domains -n <domain_namespace>
    

    For example:

    $ kubectl get all,domains -n oigns
    

    The output will look similar to the following:

     NAME                               READY   STATUS    RESTARTS   AGE
     pod/governancedomain-adminserver   1/1     Running   0          25m
     pod/governancedomain-oim-server1   1/1     Running   0          7m18s
     pod/governancedomain-soa-server1   1/1     Running   0          20m
    
     NAME                                           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)               AGE
     service/governancedomain-adminserver           ClusterIP   None             <none>        7001/TCP              25m
     service/governancedomain-cluster-oim-cluster   ClusterIP   10.102.36.107    <none>        14002/TCP,14000/TCP   20m
     service/governancedomain-cluster-soa-cluster   ClusterIP   10.102.230.187   <none>        8001/TCP              20m
     service/governancedomain-oim-server1           ClusterIP   None             <none>        14002/TCP,14000/TCP   7m18s
     service/governancedomain-oim-server2           ClusterIP   10.111.183.16    <none>        14002/TCP,14000/TCP   20m
     service/governancedomain-oim-server3           ClusterIP   10.107.144.169   <none>        14002/TCP,14000/TCP   20m
     service/governancedomain-oim-server4           ClusterIP   10.110.18.114    <none>        14002/TCP,14000/TCP   20m
     service/governancedomain-oim-server5           ClusterIP   10.106.220.13    <none>        14002/TCP,14000/TCP   20m
     service/governancedomain-soa-server1           ClusterIP   None             <none>        8001/TCP              20m
     service/governancedomain-soa-server2           ClusterIP   10.104.204.68    <none>        8001/TCP              20m
     service/governancedomain-soa-server3           ClusterIP   10.110.104.108   <none>        8001/TCP              20m
     service/governancedomain-soa-server4           ClusterIP   10.103.117.118   <none>        8001/TCP              20m
     service/governancedomain-soa-server5           ClusterIP   10.101.65.38     <none>        8001/TCP              20m
    
     NAME                                      AGE
     domain.weblogic.oracle/governancedomain   32m
    
     NAME                                                   AGE
     cluster.weblogic.oracle/governancedomain-oim-cluster   32m
     cluster.weblogic.oracle/governancedomain-soa-cluster   32m
    

    The default domain created by the sample WDT models has the following characteristics:

    • An Administration Server named AdminServer listening on port 7001.
    • A configured OIG cluster named oig_cluster of size 5.
    • A configured SOA cluster named soa_cluster of size 5.
    • One started OIG managed Server, named oim_server1, listening on port 14000.
    • One started SOA managed Server, named soa_server1, listening on port 8001.
    • Log files that are located in <persistent_volume>/logs/<domainUID>

Verify the domain

  1. Run the following command to describe the domain:

    $ kubectl describe domain <domain_uid> -n <namespace>
    

    For example:

    $ kubectl describe domain governancedomain -n oigns
    
    Click here to see example output:

Verify the pods

  1. Run the following command to see the pods running the servers and which nodes they are running on:

    $ kubectl get pods -n <namespace> -o wide
    

    For example:

    $ kubectl get pods -n oigns -o wide
    

    The output will look similar to the following:

    NAME                                                        READY   STATUS      RESTARTS   AGE     IP            NODE           NOMINATED NODE   READINESS GATES
    governancedomain-adminserver                                1/1     Running     0          26m     10.244.1.42   worker-node2   <none>           <none
    governancedomain-oim-server1                                1/1     Running     0          7m56s   10.244.1.44   worker-node2   <none>           <none>
    governancedomain-soa-server1                                1/1     Running     0          21m     10.244.1.43   worker-node2   <none>           <none>
    

    You are now ready to configure an Ingress to direct traffic for your OIG domain as per Configure an ingress for an OIG domain.