1 Overview of the UIM Cloud Native Deployment
Get an overview of Oracle Communications Unified Inventory Management (UIM) cloud native deployment, architecture, and the UIM cloud native package.
This chapter provides an overview of Oracle Communications Unified Inventory Management (UIM) deployed in a cloud native environment using container images and a Kubernetes cluster.
About the UIM Cloud Native Deployment
You can deploy UIM in a Kubernetes-based shared cloud (cluster) while implementing modern DevOps “Configuration as Code” principles to manage system configuration in a consistent manner. You can automate system lifecycle management. You set up your own cloud native environment and can then use the UIM cloud native toolkit to automate the deployment of UIM instances. By leveraging the pre-configured Helm charts, you can deploy UIM instances quickly ensuring your services are up and running in far less time than a traditional deployment.
UIM cloud native supports the following deployment models:
-
On Private Kubernetes Cluster: UIM cloud native is certified for a general deployment of Kubernetes.
-
On Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE): UIM cloud native is certified to run on Oracle's hosted Kubernetes OKE service.
UIM Cloud Native Architecture
This section describes and illustrates the UIM cloud native architecture and the deployment environment.
The following diagram illustrates the UIM cloud native architecture.
The UIM cloud native architecture requires components such as the Kubernetes cluster and WebLogic Kubernetes Operator, which are under your control to install and configure. A single WebLogic Operator can manage multiple UIM domains in multiple namespaces. Each domain is a dynamic cluster with multiple managed servers that is configured for integration with both optional and required components.
About the WebLogic Domain
The following diagram illustrates the UIM cloud native deployment environment and important concepts about producing a WebLogic domain that is capable of supporting UIM cloud native.
Figure 1-2 UIM Cloud Native Deployment Environment
In the deployment environment, the Helm chart that is provided with the UIM cloud native toolkit is deployed into the Kubernetes cluster producing two Kubernetes resources. These resources are then consumed by the WebLogic Kubernetes Operator (WKO).
About Kubernetes Custom Resource Definitions (CRD) and Domain Configuration Config Map
The Kubernetes API provides extensions called custom resources. To understand more about a Custom Resource Definition (CRD) and why it might be used, see the Kubernetes CustomResourceDefinition (CRD) documentation at: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
To configure the operator for your WebLogic domain, you set up and configure your own domain resource. The domain resource does not replace the traditional configuration of the WebLogic domains found in the domain configuration files, but instead co-operates with those files to describe the Kubernetes artifacts of the corresponding domain. Refer to the Oracle WebLogic Kubernetes Operator User Guide to understand how to use a CRD to describe a WebLogic domain resource.
While the domain resource describes much of the operational details for a domain such as domain identification, secrets, pod creation, server instances, startup and shutdown, security, logging, clusters, admin and managed servers, and JVM options, the details about the more traditional configuration (deployed applications, JMS Queues, data sources and so on) are provided in a configuration map and are described using a metadata model specified by the WebLogic Deploy Tooling (WDT). The UIM cloud native toolkit provides the base configuration to produce these resources.
About Oracle WebLogic Server Deploy Tooling (WDT)
The WebLogic Server Deploy Tooling (WDT) has the following main purposes:
- It provides a metadata model that describes a WebLogic Server domain configuration.
- It provides scripts that perform domain lifecycle operations, simplifying the definition and the creation of domains. This capability provides an alternative to programmatic ways of defining domain configuration such as WebLogic Scripting Tool (WLST) or Java Mbeans manipulation.
The UIM cloud native toolkit leverages the WDT metadata model only. It does not use the scripting capabilities directly.
The toolkit provides the WDT metadata for a domain that is capable of supporting UIM. The toolkit enables you to easily override much of the base configuration through the use of Helm charts. Additionally, the toolkit framework allows you to add supplementary WDT metadata fragments to the domain. WDT provides tools that help with this task by inspecting an existing domain to produce the WDT metadata required for the configuration.
For more details about WDT, see the Oracle WebLogic Server Deploy Tooling documentation on GitHub at: https://github.com/oracle/weblogic-deploy-tooling
About UIM Configuration and Specification Layers
The UIM configuration defines the deployment footprint, layout, and tuning. Managing this configuration as a single monolithic unit is not optimal for sustainability or scalability. To address this, a layered configuration approach is adopted, enabling better modularity, maintainability, and risk management.
The following layers are defined, which include a set of values that are specific to the function of that layer:
- Base: This foundational layer is shared across all applications deployed using the common cloud native toolkit. It includes settings such as the ingress controller, SSL, authentication mechanisms, storage volumes, garbage collection (GC), log configuration, and so on.
- UIM-Specific: This layer includes parameters that are specific to a UIM instance such as external authentication providers, custom templates, SAF, JMS queues database identities, and cluster size.
- Shape: The shape layer defines the hardware resource utilization and the resulting tuning. Java Heap Size is an example of a configuration value found in the shape specification.
- Database: The database layer includes the parameters that are specific to schema operations (for example: create, upgrade, delete, purge schema), such as the DB installer image, table space info, and so on. The UIM instance do not read the parameters from this layer.
The layers are implemented as specification files written in YAML:
- application-base
- app-uim
- <shape>/uim
- database
Each UIM deployment requires a project and an instance name:
- Project refers to the Kubernetes namespace where UIM is deployed.
- Instance is a logical identifier used to differentiate multiple UIM deployments within the same namespace.
You can deploy multiple UIM instances within a single project. However, if you intend to use UIM services alongside the core UIM instance, Oracle recommends you to maintain a single UIM instance and add all services within one namespace. If you need more UIM instances, deploy them in separate namespaces.
Each of the above configuration layers: base, UIM-specific, database and shape, should be unique to the project and instance.
About Helm Overrides
The specification files are consumed in a hierarchical fashion. If a value is found in multiple specification files (layers), the one further up the hierarchy takes precedence. This allows the application specification to have the final control over its configuration by being able to override a value that is prescribed in either the shape or base specifications. This allows Oracle to define sealed, base configuration, while still providing you the control over the values used for the UIM instance.
Following are the specification files, listed in the order of the highest priority to the lowest:
- app-uim.yaml
- applications-base.yaml
- <shape>/uim.yaml
- <values>.yaml
While the specification for an app-uim points to the specification for the shape to be used (implying the order here may be out of sequence), the values found in the specification for the shape are loaded for processing before the values in the specification for the application.
The app-uim specification remains the final authority on any values that are found in multiple specification files.
About the Common Cloud Native Toolkit
The Common cloud native toolkit is an archive file that includes the default configuration files, utility scripts, and samples to deploy UIM in a cloud native environment. With UIM cloud native, managing the domain Configuration as Code (CaC) is paramount. UIM cloud native provides guidance on effective management of this configuration to ensure that instances can be created in a standardized and repeatable fashion.
Contents of the Common Cloud Native Toolkit
- Helm charts for UIM and UIM database installer:
- The Helm chart for UIM is located in $COMMON_CNTK/charts/uim-app.
- The Helm chart for the UIM DB Installer is located in $COMMON_CNTK/charts/uim-dbinstaller-app.
- Mechanism to extend the domain and WDT samples and scripts for some common use cases
- Utility scripts to help with the lifecycle of WebLogic Kubernetes Operator
- Sample scripts to manage pre-requisite secrets. These are not pipeline-friendly.
- Scripts to manage the lifecycle of a UIM instance. These are pipeline friendly.