We are very excited to announce the release of WebLogic Server Kubernetes Operator 3.0.0. This latest version of the operator introduces features and support that gives our users flexibility when applying updates to their domains and applications, and when automating CI/CD pipelines.
WebLogic Server Kubernetes Operator 3.0.0 supports:
The WebLogic Server Kubernetes Operator is one five open source tools that compose the WebLogic Kubernetes ToolKit. The ToolKit lets users migrate their existing applications, manage and update their domains, deploy and update their applications, monitor them, persist the logs, and automate the creation and patching of images. The tools in the ToolKit are:
A Kubernetes Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex applications.
We have adopted the operator pattern to integrate WebLogic Server and Kubernetes, allowing Kubernetes to serve as a container infrastructure hosting WebLogic Server instances. The WebLogic Server Kubernetes Operator extends Kubernetes to enable creation, configuration, and management of a WebLogic Server domain. Find the GitHub project for the WebLogic Server Kubernetes Operator and documentation that includes a Quick Start guide and samples.
The WebLogic Server Kubernetes Operator contains built-in knowledge about how to perform lifecycle operations on a WebLogic Server domain. Some of the operations performed by the operator are:
The operator supports three different domain home source types (patterns): Domain home in PV, Domain Home in Image, and Model in Image. The differences between these patterns are the domain home location and how you update the domain configuration and applications.
There are advantages to each domain home source type, but sometimes there are technical limitations of various cloud providers that may make one type better suited to your needs. See the documentation that compares the three patterns and will help you choose one.
The WebLogic Server Deploy Tooling makes the automation of WebLogic Server domain provisioning and applications deployment easy. Instead of writing WLST scripts that need to be maintained, WDT creates a declarative, metadata model that describes the domain, applications, and the resources used by the applications. This metadata model makes it easy to provision, deploy, and perform domain configuration lifecycle operations in a repeatable fashion. In the GitHub project for WebLogic Server Deploy Tooling you will find the documentation and samples. Read the blog Make WebLogic Domain Provisioning and Deployment Easy! which walks you through a complete sample.
WDT enables you to “discover” and introspect a domain configuration with its application binaries, and to “create” a replica of the domain configuration and application in another location. WDT supports discovering and introspecting WebLogic Server 10.3.6, 12.1.3, 12.2.1.x, and 14.1.1.x domains, and creating replicas of these domains in WebLogic Server 12.2.1.x or 14.1.1.x.
When invoking WDT Discover, two files are created:
After the YAML model file has been created, you can customize and validate your configuration to meet Kubernetes requirements. The metadata representation of the domain configuration is a simpler and more readable way to represent the domain configuration. Two important features of WDT, which provide flexibility in creating or modifying domain configuration, are the ability to combine models in the order specified, and using model macros to reference arbitrary properties, environment variables, or secrets from model files.
Invoking WDT Create takes the WDT YAML model file and archive, and creates a domain home with the application deployed. You will find a sample of creating a Docker image with the domain home and application deployed to it with WDT at GitHub Sample.
WDT provides additional tools to make it easier for you to write your own models, validate models, and compare models. The Model Help Tool provides examples about the folders and attributes when creating a new domain model, or expanding an existing model, including discovered models. The Compare Model Tool lets you look at the differences between two models. The Validate Model Tool provides validation of the model before the domain is created.
WDT also supports modifying domain configuration and applications. The Update Domain Tool modifies domain configuration by adding or removing objects from the domain configuration and the Deploy Applications Tool deploys and undeploys applications. WDT also supports sparse models where the model only describes what is required for the specific operation without describing other artifacts. For example, to deploy or modify a JDBC data source in an existing domain, the model needs to describe only the data source in question.
With the new operator 3.0 release, we are enabling support for deployment of WebLogic Server domains in Kubernetes using WDT models included in WebLogic Server Docker images. We recommend that such images be created with the WebLogic Image Tool.
The WebLogic Image Tool is an open source tool that lets you automate building, patching, and updating your WebLogic Server Docker images, including your own customized images. Find the WebLogic Image Tool’s GitHub project at https://github.com/oracle/weblogic-image-tool. For more detailed information, read the blog Automate WebLogic Image Building and Patching.
There are four major use cases for this tool:
The WebLogic Image Tool integrates with WebLogic Server Deploy Tooling to create WebLogic Server or FMW Infrastructure images containing a domain or including a WDT model that the operator can then deploy and manage in a Kubernetes cluster.
Operator 3.0.0 introduces a new domain source type (pattern) called Model in Image. Model in Image is an alternative to the operator’s Domain in Image and Domain in PV patterns. The Model in Image pattern enables creating WebLogic Server Kubernetes configurations from Docker images that contain WDT model files and application archives. Using the WebLogic Image Tool, you generate a Docker image that contains the WebLogic binaries and places the WDT YAML model file and application archive in a specific directory inside of the image for the operator to retrieve before running the servers in Kubernetes pods.
When operator 3.0.0 detects that the WebLogic Server Docker image being referenced contains a WDT model, it will create the WebLogic Server domain configuration in Kubernetes, based on the content of the WDT model. The operator invokes WDT Create, taking the WDT model inside the image, and any additional models in a WDT ConfigMap, aggregates them and creates a domain home. The operator encrypts and packages the domain, places it in a ConfigMap, and then starts WebLogic Server pods based on the domain home. The server pods will obtain their domain home from the ConfigMap.
Unlike Domain in PV and Domain in Image, Model in Image eliminates the need to pre-create your WebLogic domain home prior to deploying your domain resource. For more details about the Model in Image pattern, see the Model In Image documentation and try the sample in our operator GitHub project.
When you want to perform configuration updates, you can provide one or more sparse models containing the configuration changes in a WDT ConfigMap or create a new image with the WDT models containing the changes. You would ask the operator to apply the changes and propagate them to a running domain. Then the operator will invoke WDT Update to make the changes to the domain home and initiate a rolling restart; the servers will now point to the updated domain in the ConfigMap. After the domain rolling restart, the configuration changes are visible in the WebLogic Server Administration Console, via REST, or WLST.
The advantages of the Model in Image pattern are:
Our future plans include continued enhancements of the operator, for example, to provide the ability to make configuration changes dynamically, without requiring a rolling restart of the WebLogic domain, and to optimize the operator so that it can manage WebLogic domains in very large Kubernetes clusters (such as, about 1,600 namespaces). If you are interested in deploying a WebLogic domain and operator 3.0.0, clone the WebLogic Server Kubernetes Operator project and try the different samples. We hope this announcement is helpful to those of you seeking to deploy WebLogic Server on Kubernetes, and we look forward to your feedback.