By default, UIM uses the WebLogic embedded LDAP as the authentication provider. The UIM cartridge deployment users and application administrative users are created in embedded LDAP during instance creation. For human users, you may set up an optional authentication for the users who access UIM through user interfaces. See "Planning and Validating Your Cloud Environment" for information on the components that are required for setting up your cloud environment. The UIM cloud native toolkit provides samples that you use to integrate components such as OpenLDAP, WebLogic Kubernetes Operator (WKO), and Traefik. This section describes the tasks you must do for configuring optional authentication for UIM cloud native human users.

Perform the following tasks using the samples provided with the UIM cloud native toolkit:

• Install and configure OpenLDAP. This is required to be done once for your organization.
• Install OpenLDAP clients. This is required to be performed on each host that installs and runs the toolkit scripts and when a Kubernetes cluster is shared by multiple hosts.
• In the OpenLDAP server, create the root node for each UIM instance.

Installing and Configuring OpenLDAP

OpenLDAP enables your organization to handle authentication for all instances of UIM. You install and configure OpenLDAP once for your organization.

To install and configure OpenLDAP:

1. Run the following command, which installs OpenLDAP:

   $ sudo -s  yum -y install "openldap" "migrationtools"
   

2. Specify a password by running the following command:

   $ sudo -s slappasswd
   New password:
   Re-enter new password:

3. Configure OpenLDAP by running the following commands:

   $ sudo -s
   $ cd /etc/openldap/slapd.d/cn=config
   $ vi olcDatabase\=\{2\}hdb.ldif

4. Update the values for the following parameters:

   Note:

   Ignore the warning about editing the file manually.
   • olcSuffix: dc=uimcn-ldap,dc=com
   • olcRootDN: cn=Manager,dc=uimcn-ldap,dc=com
   • olcRootPW:ssha

     where ssha is the SSHA that is generated

5. Update the dc values for the olcAccess parameter as follows:

   olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external, cn=auth" 
   read by dn.base="cn=Manager,dc=uimcn-ldap,dc=com" read by * none

6. Test the configuration by running the following command:

   sudo -s slaptest -u

   Ignore the checksum warnings in the output and ensure that you get a success message at the end.

7. Run the following commands, which restart and enable LDAP:

   sudo -s systemctl restart slapd
   sudo -s systemctl enable slapd
   sudo -s cp -rf /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif
   

8. Create a root node named domain, which will be the top parent for all UIM instances.
9. Run the following command to create a new file named base.ldif:

   sudo -s  vi /root/base.ldif

10. Add the following entries to the base.ldif file:

    dn: ou=Domains,dc=uimcn-ldap,dc=com
    objectClass: top
    objectClass: organizationalUnit
    ou: Domains

11. Run the following commands to update the values in the base.ldif file:

    ldapadd -x -W -D "cn=Manager,dc=uimcn-ldap,dc=com" -f /root/base.ldif  
    ldapsearch -x cn=Manager -b dc=uimcn-ldap,dc=com

12. Open the LDAP port 389 on all Kubernetes nodes in the cluster.

Installing OpenLDAP Clients

In environments where the Kubernetes cluster is shared by multiple hosts, you must install the OpenLDAP clients on each host. You use the scripts in the toolkit to populate the LDAP server with users and groups.

sudo -s yum -y install openldap-clients

Creating the Root Node

You must create the root node for each UIM instance before additional UIM non-automation user and UIM group can be created.

The toolkit provides a sample script ($UIM_CNTK/samples/credentials/managed-uim-ldap-credentials.sh) that you can use to create the root node in the LDAP tree for the UIM instance.

Run the $UIM_CNTK/samples/credentials/managed-uim-ldap-credentials.sh script by passing in -o account.

The UIM Cloud Native Tool Kit provides support for SAML-based authentication provider. This section describes the tasks you must do to configure an optional SAML-based authentication provider for UIM Cloud Native Deployment.

Prerequisite: Inventory application has to be registered with Authentication Provider to generate Metadata File which is required during UIM Image creation. In case, Authentication Provider is chosen to be Identity Cloud Service, see Registering the Inventory Application in Identity Cloud Service in the Knowledge article #Doc ID 2956673.1.

To enable SAML-based authentication provider, add the corresponding customizations to the uim-cn-base image and layered image as follows:

1. Extract uim-app-archive.zip for customization references.

   unzip workspace/uim-image-builder/staging/cnsdk/uim-model/uim-app-archive.zip -d workspace/customization

2. Export the following variables as required:

   mkdir workspace/temp
   export WORKSPACEDIR=$(pwd)/workspace
   export CUSTOMFOLDER=$(pwd)/workspace/customization
   export TEMPDIR=$(pwd)/workspace/temp
   export DMANIFEST=$(pwd)/workspace/uim-image-builder/bin/
   uim_cn_ci_manifest.yaml
   export STAGING=$(pwd)/workspace/uim-image-builder/staging

3. Update $CUSTOMFOLDER/custom/plans/inventory-clusterPlan.xml as follows:
   1. Change logoutURL address

      <variable>
            <name>logoutURL</name>
            <value>https://<instance>.<project>.uim.org:<LB_PORT>/saml2/sp/slo/init</value>
      </variable>

   2. Add new Variable assignment to inv.war and weblogic-web-app root element, in order to remove cookie-path:

      <module-override>
          <module-name>inv.war</module-name>
          <module-type>war</module-type>
          <module-descriptor external="false">
            <root-element>weblogic-web-app</root-element>
            <uri>WEB-INF/weblogic.xml</uri>
            <variable-assignment>
                  <name>cookie-path</name>
                  <xpath>/weblogic-web-app/session-descriptor/cookie-path</xpath>
                  <operation>remove</operation>
            </variable-assignment>
          </module-descriptor>

   3. Add a new module in order to remove cookie-path from unified-topology-ui.war:

      <module-override>
          <module-name>unified-topology-ui.war</module-name>
          <module-type>war</module-type>
          <module-descriptor external="false">
            <root-element>weblogic-web-app</root-element>
            <uri>WEB-INF/weblogic.xml</uri>
            <variable-assignment>
                  <name>cookie-path</name>
                  <xpath>/weblogic-web-app/session-descriptor/cookie-path</xpath>
                  <operation>remove</operation>
            </variable-assignment>
          </module-descriptor>
      </module-override>

   4. Add a new module in order to remove cookie-path for InventoryRSOpenAPI.war:

      <module-override>
          <module-name>InventoryRSOpenAPI.war</module-name>
          <module-type>war</module-type>
          <module-descriptor external="false">
            <root-element>weblogic-web-app</root-element>
            <uri>WEB-INF/weblogic.xml</uri>
            <variable-assignment>
                  <name>cookie-path</name>
                  <xpath>/weblogic-web-app/session-descriptor/cookie-path</xpath>
                  <operation>remove</operation>
            </variable-assignment>
          </module-descriptor>
      </module-override>

4. Update security files in $CUSTOMFOLDER/custom/security/saml2:
   1. Place Identity Provider(IdP) metadatafile in $CUSTOMFOLDER/custom/security/saml2/.
   2. Copy $CUSTOMFOLDER/custom/security/saml2/saml2idppartner.properties.sample to $CUSTOMFOLDER/custom/security/saml2/saml2idppartner.properties and update the details of description and metadatafile:

      saml2.idp.partners=customidp
      customidp.description=<IDP Partner>
      customidp.metadata.file=<IDPMetadata.xml>
      customidp.enabled=true
      customidp.redirectUris=/Inventory/*
      customidp.virtualUserEnabled=true

5. Run the customization script and create UIM images, use -c uim as follows:

   ./workspace/uim-image-builder/bin/customization.sh
   ./workspace/uim-image-builder/bin/build-uim-images.sh -f $DMANIFEST -s $STAGING -c uim

6. After you build the uim-cn-base image with layered tag, update the project.yaml file as follows:

   authentication:
     saml:
       enabled: true
       entityId: samlUIM #Use same entity id when configuring Idp Provider

7. SSL Incoming configuration on UIM CN Instance should be enabled. See "Configuring Secure Incoming Access with SSL" for more information.
8. Create a UIM instance:

   $UIM_CNTK/scripts/create-instance.sh -p sr -i quick -s $SPEC_PATH

To enable Oracle Access Manager (OAM) authentication, add the corresponding customizations to the uim-cn-base image as follows:

1. Export additional variable ENABLEOAM:

   export ENABLEOAM=true

2. Extract uim-app-archive.zip for customization references.

   unzip workspace/uim-image-builder/staging/cnsdk/uim-model/uim-app-archive.zip -d workspace/customization

3. Export the following variables as required:

   mkdir workspace/temp
   export WORKSPACEDIR=$(pwd)/workspace
   export CUSTOMFOLDER=$(pwd)/workspace/customization
   export TEMPDIR=$(pwd)/workspace/temp
   export DMANIFEST=$(pwd)/workspace/uim-image-builder/bin/uim_cn_ci_manifest.yaml
   export STAGING=$(pwd)/workspace/uim-image-builder/staging

4. Run the customization script and create UIM image, use -c uim as follows:

   ./workspace/uim-image-builder/bin/customization.sh
   ./workspace/uim-image-builder/bin/build-uim-images.sh -f $DMANIFEST -s $STAGING -c uim

5. Build uim-cn-base image by running the build-uim-images script.

6. After you build the uim-cn-base image, update the project.yaml file as follows:

   authentication:
     oam:
       enabled: true
       host: <oam-project>-<oam-instance>-oam-ohs # provide as <oam-project>-<oam-instance>-oam-ohs.<ohs-namespace>.svc.cluster.local if OHS service is running on a different namespace.
       port: 7777
       frontendhost: <oam-instance>.<oam-project>.ohs.<oam-host-suffix>  #Ex. quick.sr.ohs.uim.org

7. Update the instance.yaml file by setting the loadBalancerIP and loadBalancerPort values as follows:

   # Mandatory, if OAM Authentication is enabled, set this value to loadbalancer IP.
   # If external hardware/software load balancer is used, set this value to that frontend host IP.
   # If OCI Load Balancer is used, then set externalLoadBalancerIP from OCI LBaaS
   # If Nginx/Traefik or any other Generic Ingress Controller is used, then set to one of the worker nodes
   loadBalancerIP: ""
    
   # For Generic and Traefik Ingress Controllers:
   # If ssl is enabled this would be loadbalancer's ssl port.
   # IF ssl is disabled this would be loadblancer's non ssl port.
   # For examle ssl and non-ssl ports for external loadbalancer would be 443 and 80 respectively.
   # If loadbalancer is not created, provide nodePort of Nginx/Traefik or any other Generic Ingress Controller
   loadBalancerPort: 80

   Note:

   Setting the loadBalancerIP and loadBalancerPort values is mandatory if OAM Authentication is enabled.

   If an external hardware or software load balancer is used, set the loadBalancerIP value to front-end host IP value.

   If OCI load balancer is used, set the loadBalancerIP to externalLoadBalancerIP value from OCI LBaaS.

   If Nginx, Traefik, or any other Generic Ingress Controller is used, set the loadBalancerIP to one of the worker nodes.

8. If SSL is enabled on Identity Provider service, pass the truststore with Identity Provider certificates to UIM instance as follows:

   1. Generate truststore by passing Identity Provider certificate:

       keytool -importcert -v -alias <param> -file <path to IDP cert> -keystore idptrust.jks -storepass <password>

   2. Create a Kubernetes secret by passing the generated truststore. The secret name should match the truststore name.

       kubectl create secret generic <trustsecretname> -n
                <project> --from-file=<trustsecretname>.jks=idptrust.jks
                --from-literal=passphrase=<password>

9. Update Instance.yaml with truststore:

   # SSL Configuration
   ssl:
     # Trust keystore
     trust:   # provide trust name and identity to configure external SSL for SAF
       name: <trustsecretname> # Secret name that contains the truststore file.
     #Identity keystore
     identity:
       useDemoIdentity: true  # set to false and specify the parameters below to use custom identity

10. Restart the UIM instance.

    The URLs to access UIM UI and WebLogic UI when OAM authentication is enabled are as follows:

    • The URL for access to the UIM UI: https://<oam-instance>.<oam-project>.ohs.<hostSuffix>:<port>/Inventory sample https://sr.quick.ohs.uim.org:30444/Inventory
    • The URL for access to the WebLogic UI: https://admin.<uim-instance>.<uim-project>.uim.org:30444/console sample https://admin.quick.sr.uim.org:30444/console

The UIM cloud native toolkit provides the following pre-configured shapes:

• charts/uim/shapes/dev.yaml. This can be used for development, QA and user acceptance testing (UAT) instances.
• charts/uim/shapes/devsmall.yaml. This can be used to reduce CPU requirements for small development instances.
• charts/uim/shapes/prod.yaml. This can be used for production, pre-production, and disaster recovery (DR) instances.
• charts/uim/shapes/prodlarge.yaml. This can be used for production, pre-production and disaster recovery (DR) instances that require more memory for UIM cartridges and order caches.
• charts/uim/shapes/prodsmall.yaml. This can be used to reduce CPU requirements for production, pre-production and disaster recovery (DR) instances. For example, it can be used to deploy a small production cluster with two managed servers when the input request rate does not justify two managed servers configured with a prod or prodlarge shape. For production instances, Oracle recommends two or more managed servers. This provides increased resiliency to a single point of failure and can allow order processing to continue while failed managed servers are being recovered.

You can create custom shapes using the pre-configured shapes. See "Creating Custom Shapes" for details.

The pre-defined shapes come in standard sizes, which enable you to plan your Kubernetes cluster resource requirement.

The following table lists the sizing requirements of the shapes for an admin server:

These values are encoded in the specifications and are automatically part of the individual pod configuration. The Kubernetes schedulers evaluate the Kube request settings to find space for each pod in the worker nodes of the Kubernetes cluster.

The shapes are pre-tuned for generic development and production environments. You can create a UIM instance with either of these shapes, by specifying the preferred one in the instance specification.

# Name of the shape. The UIM cloud native shapes are devsmall, dev, prodsmall, prod, and prodlarge.
# Alternatively, custom shape name can be specified (as the filename without the extension)

By default, UIM cloud native has its pods scheduled on all worker nodes in the Kubernetes cluster in which it is installed. However, in some situations, you may want to choose a subset of nodes where pods are scheduled.

# If UIM CN instances must be targeted to a subset of worker nodes in the
# Kubernetes cluster, tag those nodes with a label name and value, and choose
# that label+value here.
#   keys:
#    - key    : any node label key
#    - operator : Valid operators are In, NotIn,Exists, DoesNotExist. Gt, and Lt.
#    - values : values is an array of string values.
#               If the operator is In or NotIn, the values array must be non-empty.
#               If the operator is Exists or DoesNotExist, the values array must be empty (values can be removed from below).
#               If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer.
#
# This can be overriden in instance specification if required.
# Node Affinity can be achieved by operator "In" and Node Anti-Affinity by "NotIn"
# oracle.com/licensed-for-coherence is just an indicative example; any
# label and its values can be used for choosing nodes.
uimcnTargetNodes: {} # This empty declaration should be removed if adding items here.
#uimcnTargetNodes:
#  nodeLabel:
#   keys:
#    - key: oracle.com/licensed-for-coherence
#      operator: In
#      values:
#       - true
#    - key: failure-domain.beta.kubernetes.io/zone
#      operator: NotIn
#      values:
#       - PHX-AD-2
#       - PHX-AD-3

# Example1
#uimcnTargetNodes: {}
uimcnTargetNodes:
  nodeLabel:
   keys:
    - key: failure-domain.beta.kubernetes.io/zone
      operator: In
      values:
      - PHX-AD-2
      - PHX-AD-3

# Example2
# uimcnTargetNodes: {} # This empty declaration should be removed if adding items here.
uimcnTargetNodes:
  nodeLabel:
   keys:
    - key: name
      operator: DoesNotExist
    - key: failure-domain.beta.kubernetes.io/zone
      operator: NotIn
      values:
      - PHX-AD-2
      - PHX-AD-3

A Kubernetes ingress is responsible for establishing access to back-end services. However, creating an ingress is not sufficient. An Ingress controller connects the back-end services with the front-end services that are external to Kubernetes through edge objects such as NodePort services, Load Balancers, and so on. In UIM cloud native, an ingress controller can be configured in the project specification.

UIM cloud native supports annotation-based generic ingress creation that uses standard Kubernetes Ingress API as verified by Kubernetes Conformance tests. This can be used for any Kubernetes certified ingress controller, if that ingress controller offers annotations that are usually proprietary to the ingress controller, required for UIM. Annotations applied to an ingress resource allow you to use features such as connection timeout, URL rewrite, retry, additional headers, redirects, sticky cookie services, and so on, and to improve the performance of that ingress resource. The ingress controllers support a corresponding set of annotations. For information on annotations that are supported by your ingress controller and the list of various ingress controllers, see https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/.

Any ingress controller, which conforms to the standard Kubernetes ingress API and supports annotations needed by UIM should work, although Oracle does not certify individual ingress controllers to confirm this generic compatibility.

For information about about Ingress NGINX Controller, see https://github.com/kubernetes/ingress-nginx/blob/main/README.md#readme.

The configurations required in your project specification are as follows:

# valid values are TRAEFIK, GENERIC, OTHER
ingressController: "GENERIC"

You need to provide the following annotations to enable cookies that can meet the hardware sizing requirements.

ingress:
  className: nginx  ##provide ingressClassName value, default value for nginx ingressController is nginx.
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/affinity-mode: "persistent"
    nginx.ingress.kubernetes.io/session-cookie-name: "nginxingresscookie"
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"

loadBalancerPort: 30543 #Provide LoadBalancer SSL port
 
ssl:
  incoming: true
    
  ingress:
    annotations:
      nginx.ingress.kubernetes.io/configuration-snippet: |
        more_clear_input_headers "WL-Proxy-Client-IP" "WL-Proxy-SSL";
        more_set_input_headers "X-Forwarded-Proto: https";
        more_set_input_headers "WL-Proxy-SSL: true";
      nginx.ingress.kubernetes.io/ingress.allow-http: "false"	

# valid values are TRAEFIK, GENERIC, OTHER
ingressController: "TRAEFIK"

By default, UIM cloud native supports standard Kubernetes ingress API and provides sample files for integration. If your required ingress controller does not support one or more configurations through annotations on generic ingress, or you use your ingress controller's CRD instead, you can choose "OTHER".

By choosing this option, UIM cloud native does not create or manage any ingress required for accessing the UIM cloud native services. However, you may choose to create your own ingress objects based on the service and port details mentioned in the tables that follow. The toolkit uses an ingress Helm chart ($UIM_CNTK/samples/charts/ingress-per-domain/templates/generic-ingress.yaml) and scripts for creating the ingress objects. If you want to use a generic ingress controller, these samples can be used as a reference and customized as necessary.

The following table lists the service name and service ports for Ingress rules:

Ingresses need to be created for each of the above rules per the following guidelines:

• Before running create-instance.sh, ingress must be created.
• After running delete-instance.sh, ingress must be deleted.

You can develop your own code to handle your ingress controller or copy the sample ingress-per-domain chart and add additional template files for your ingress controller with a new value for the type (for example, NGINX).

• The reference sample for creation is: $UIM_CNTK/scripts/create-ingress.sh
• The reference sample for deletion is: $UIM_CNTK/scripts/delete-ingress.sh

When a UIM instance is deleted, the state of the database remains unaffected, which makes it available for re-use. This is common in the following scenarios:

• When an instance is deleted and the same instance is re-created using the same project and the instance names, the database state is unaffected. For example, consider a performance instance that does not need to be up and running all the time, consuming resources. When it is no longer actively being used, its specification files and PDB can be saved and the instance can be deleted. When it is needed again, the instance can be rebuilt using the saved specifications and the saved PDB. Another common scenario is when developers delete and re-create the same instance multiple times while configuration is being developed and tested.
• When a new instance is created to point to the data of another instance with a new project and instance names, the database state is unaffected. A developer, who might want to create a development instance with the data from a test instance in order to investigate a reported issue, is likely to use their own instance specification and the UIM data from PDB of the test instance.

UIM cloud native can be configured to use a Kubernetes Persistent Volume to store data that needs to be retained even after a pod is terminated. This data includes application logs, JFR recordings and DB Installer logs, but does not include any sort of UIM state data. When an instance is re-created, the same persistent volume need not be available. When persistent storage is enabled in the instance specification, these data files, which are written inside a pod are re-directed to the persistent volume.

Data from all instances in a project may be persisted, but each instance does not need a unique location for logging. Data is written to a project-instance folder, so multiple instances can share the same end location without destroying data from other instances.

The final location for this data should be one that is directly visible to the users of UIM cloud native. The development instances may simply direct data to a shared file system for analysis and debugging by cartridge developers. Whereas, formal test and production instances may need the data to be scraped by a logging toolchain such as EFK, that can then process the data and make it available in various forms. The recommendation therefore is to create a PV-PVC pair for each class of destination within a project. In this example, one for developers to access and one that feeds into a toolchain.

A PV-PVC pair would be created for each of these "destinations", that multiple instances can then share. A single PVC can be used by multiple UIM domains. The management of the PV and PVC lifecycles is beyond the scope of UIM cloud native.

The UIM cloud native infrastructure administrator is responsible for creating and deleting PVs or for setting up dynamic volume provisioning.

The UIM cloud native project administrator is responsible for creating and deleting PVCs as per the standard documentation in a manner such that they consume the pre-created PVs or trigger the dynamic volume provisioning. The specific technology supporting the PV is also beyond the scope of UIM cloud native. However, samples for PV supported by NFS are provided.

Creating a PV-PVC Pair

The technology supporting the Kubernetes PV-PVC is not dictated by UIM cloud native. Samples have been provided for NFS and BV, and can either be used as is, or as a reference for other implementations.

To create a PV-PVC pair supported by NFS:

1. Edit the sample PV and PVC yaml files and update entries with enclosing brackets

   Note:

   PVCs need to be ReadWriteMany.

   vi $UIM_CNTK/samples/nfs/pv.yaml
   vi $UIM_CNTK/samples/nfs/pvc.yaml

2. Create the Kubernetes PV and PVC.

   kubectl create -f $UIM_CNTK/samples/nfs/pv.yaml
   kubectl create -f $UIM_CNTK/samples/nfs/pvc.yaml

3. Set up the storage volume. The storage volume type is emptydir by default.

   storageVolume:
     type: emptydir # Acceptable values are pvc and emptydir  
     volumeName: storage-volume
   #  pvc: storage-pvc #Specify this only if case type is PVC
   isBlockVolume: false # set this to true if BlockVolume is used

   Deleting the pod that has storage volume type as emtpydir deletes the corresponding logs. To retain the logs:

   • Set the storageVolume.type to pvc.
   • Uncomment storageVolume.pvc.
   • Specify the name of the pvc created.

   # The storage volume must specify the PVC to be used for persistent storage.
   storageVolume:
     type: pvc # Acceptable values are pvc and emptydir  
     volumeName: storage-volume
     pvc: storage-pvc #Specify this only if case type is PVC
     isBlockVolume: false # set this to true if BlockVolume is used

[oracle@localhost project-instance]$ dir
server, UIM, uim-dbinstaller

To create a PV-PVC pair supported by BV:

1. Edit the sample PV and PVC yaml files and update entries with enclosing brackets:

   vi $UIM_CNTK/samples/bv/pv.yaml
   vi $UIM_CNTK/samples/bv/pvc.yaml

2. Create the Kubernetes PV and PVC as follows:

   kubectl create -f $UIM_CNTK/samples/bv/pv.yaml
   kubectl create -f $UIM_CNTK/samples/bv/pvc.yaml

3. Repeat step 1 and 2 to create PV-PVCs required for all the servers such as introspector, admin, db-installer, and for each managed server.

   Note:

   Do not provide <server-name> in the prefix for db-installer PV-PVC.
4. Set up the storage volume. By default the type is set to emtydir:

   storageVolume:
     type: emptydir # Acceptable values are pvc and emptydir
     volumeName: storage-volume
     # pvc: storage-pvc #Specify this only if case type is PVC
     isBlockVolume: false # set this to true if BlockVolume is used

5. To use Block Volume:
   1. Set StorageVolume.type to pvc.
   2. Uncomment line #pvc: storage-pvc and replace storage-pvc with the appropriate suffix of all the PVCs, which is same as the name of db-installer PVC.
   3. Set StorageVolume.isBlockVolume to true.

   storageVolume:
     type: pvc # Acceptable values are pvc and emptydir
     volumeName: dev-nfs-pv
     pvc: <project>-<storage-endpoint>-bv-pvc #this is equal to suffix of pvc and equal to pvc used by db-installer
     isBlockVolume: true  # set this to true if BlockVolume is used

6. Change permissions of blockVolume using initContainer. By default, initContainerImage is commented. Uncomment it and mention the corresponding image name that you want to use.

   #uncomment this to use initContainer for introspector,admin,db-installer,ms pods and change permission of mount volume
   initContainerImage: "container-registry.oracle.com/os/oraclelinux:8-slim"

UIM cloud native generates traditional textual logs. By default, these log files are generated in the managed server pod, but can be re-directed to a Persistent Volume Claim (PVC) supported by the underlying technology that you choose. See "Setting Up Persistent Storage" for details.

storageVolume:
  type: emptydir # Acceptable values are pvc and emptydir  
  volumeName: storage-volume
#  pvc: storage-pvc #Specify this only if case type is PVC

# The storage volume must specify the PVC to be used for persistent storage.
storageVolume:
  type: pvc # Acceptable values are pvc and emptydir  
  volumeName: storage-volume
  pvc: storage-pvc #Specify this only if case type is PVC

• The UIM application logs can be found at: pv-directory/project-instance/UIM/logs
• The UIM WebLogic server logs can be found at: pv-directory/project-instance/server
• The UIM DB Installer logs can be found at: pv_directory/project-instance/uim-dbinstaller/logs

All managed server pods running UIM cloud native carry annotations added by WebLogic Operator and additional annotation by UIM cloud native.

uimcn.metricspath: /Inventory/metrics
uimcn.metricsport: 8502

UIM cloud native provides a sample Grafana dashboard that you can use to visualize WebLogic metrics available from a Prometheus data source.

You use the WebLogic Monitoring Exporter (WME) tool to expose WebLogic server metrics. WebLogic Monitoring Exporter is part of the WebLogic Kubernetes Toolkit. It is an open source project, based at: https://github.com/oracle/weblogic-monitoring-exporter. You can include WME in your UIM cloud native images. Once a UIM cloud native image with WME is generated, creating a UIM cloud native instance with that image automatically deploys a WME WAR file to the WebLogic server instances. While WME metrics are available through WME Restful Management API endpoints, UIM cloud native relies on Prometheus to scrape and expose these metrics. This version of UIM supports WME 1.3.0. See WME documentation for details on configuration and exposed metrics.