1. Using Oracle WebLogic Server for OKE (Release 21.3.2 or earlier)
  2. Get Started with Oracle WebLogic Server for OKE
  3. About Oracle WebLogic Server for OKE

About Oracle WebLogic Server for OKE

Use Oracle WebLogic Server for OKE to quickly create your Java Enterprise Edition (Java EE) application environment in Oracle Cloud Infrastructure, including an Oracle WebLogic Server domain, in a fraction of the time it would normally take on-premises.

Oracle WebLogic Server for OKE is available as a set of applications in the Oracle Cloud Infrastructure Marketplace. After launching one of these applications, you use a simple wizard interface to configure and provision your domains along with any supporting cloud resources like Kubernetes clusters, file systems, compute instances, networks and load balancers. Each server in the domain runs in a separate container in the Kubernetes cluster.

You can track and monitor the progress of an Oracle WebLogic Server for OKE stack in Resource Manager. A stack also provides a convenient method of deleting the cloud resources for a domain when you no longer require them.

After creating an Oracle WebLogic Server domain, you can use various tools in Oracle WebLogic Server for OKE to update the domain configuration and deploy your applications. When you apply any domain changes to a kubernetes cluster, it deletes the existing pods and creates a new one.

Oracle WebLogic Server for OKE can also create a domain that includes the Java Required Files (JRF) components. A JRF-enabled domain:

  • Supports the Oracle Application Development Framework (ADF)
  • Connects to an existing database in Oracle Cloud Infrastructure

Oracle WebLogic Server for OKE uses Jenkins to automate the creation of custom images for your WebLogic Server domain, and the deployment of these images to the Kubernetes cluster. See Jenkins.

Oracle WebLogic Server for OKE supports these Oracle WebLogic Server editions:

Oracle WebLogic Server for OKE supports these billing options:
  • Universal Credits (also called UCM), where you are billed for the cost of the Oracle WebLogic Server Enterprise Edition or Oracle WebLogic Suite license (based on OCPUs per hour), for VMs running in the WebLogic node pool, in addition to the cost of the compute resources.
  • Bring Your Own License (BYOL), which allows you to reuse your existing on-premise Oracle WebLogic Server Enterprise Edition and Oracle WebLogic Suite licenses in Oracle Cloud.

Oracle WebLogic Server for OKE supports these Oracle WebLogic Server releases:

Oracle WebLogic Server for OKE requires Oracle Cloud Infrastructure Vault in order to securely store the passwords for your domains. See Oracle Cloud Infrastructure Vault FAQ.

WebLogic Domain Home Source Types

When using the WLS operator to start WebLogic Server instances from a domain, you can use either the Model in Image and Domain in Image source types.

To identify whether a version uses the Model in Image or the Domain in Image source type, see the Supported Image column in Patches Included in Oracle WebLogic Server for OKE.

Important:

From Oracle WebLogic Server for OKE release 21.2.2 onwards, Domain in Image is deprecated.
The following tables highlights the difference between the domain home source types.

Table 1-1 Domain Home Source Types

Model in Image Domain in Image
The WDT model and archive files must be embedded in docker image. The kubernetes secrets can be passed for macro references within the model in the docker image. The WLS Operator's domain introspector job uses the WDT artifacts in the docker image to create the domain, and then starts the domain's WebLogic pods. All the files that are required to run your domain in Kubernetes (binaries, patches, configuration, applications, and so on) are stored in the Docker image for your domain.
Different domains can use the same image, but require different domainUID and may have different configuration. Requires a different image for each domain, but all servers in that domain use the same image.
Runtime state should not be kept in the images. Application and configuration may be. Runtime state should not be kept in the images, but applications and configuration are.
If you want to mutate the domain home configuration, then you can override it with additional model files supplied in a ConfigMap or you can supply a new image. If you want to deploy application updates, then you must create a new image. If you want to mutate the domain home configuration, then you can apply configuration overrides or create a new image. If you want to deploy application updates, then you must create a new image.
You can deploy model files to a ConfigMap to mutate the domain, and may not need to restart the entire domain for the change to take effect. Instead, you can initiate a rolling upgrade, which restarts your WebLogic Server instance Pods one at a time. Also, the model file syntax is far simpler and less error prone than the configuration override syntax, and, unlike configuration overrides, allows you to directly add data sources and JMS modules. You can use configuration overrides to mutate the domain configuration, but there are limitations.
Dynamic updates to domain configuration can be leveraged through ConfigMap. Not supported.