WebLogic Server has been certified to run on Docker Containers and Kubernetes. Tooling has been developed to make it easy for customers to migrate their WebLogic applications to run in Kubernetes. The tooling allows users manage their domains, update their domains and applications, monitor them, persist the logs, automate the creation and patching of images which enables the automation of WebLogic deployments through CI/CD processes.
A Kubernetes Operator is an application specific controller that extends the Kubernetes API to create, configure, and manage instances of complex applications.
We are adopting the Operator pattern and using it 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 create, configure, and manage a WebLogic domain. Find the GitHub project for the WebLogic Kubernetes Operator and documentation that includes a Quick Start guide and samples.
The WebLogic Kubernetes Operator contains built-in knowledge about how to perform lifecycle operations on a WebLogic Server domain. For example, it knows the order in which it needs to perform a rolling restart of the domain, min order to preserve the guarantees of a WebLogic Server cluster such as session replication and service migration.
Some of the operations performed by the operator are:
The Oracle WebLogic Deploy Tooling (WDT) 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 lifecycle operations in a repeatable fashion, which makes it perfect for the Continuous Delivery of applications. The GitHub project for the WebLogic Deploy Tooling you can find the documentation and samples. Read the blog Make WebLogic Domain Provisioning and Deployment Easy! which walks you through a complete sample.
WebLogic Deploy Tooling enables you to introspect a domain configuration and the application binaries and then create the domain in a Docker image or on a volume. WDT supports introspecting 10.3.6, 12.1.3, 12.2.1.X domains and then create these domains in WebLogic 12.2.1.X.
When invoking WDT discover, two files are created:
Once the yaml model has been created you can customize and validate your configuration to meet Kubernetes requirements. Invoking WDT create takes the domain yaml model and archive and creates a domain home with the application deployed. You can find a sample of creating a Docker image with the domain home and application deployed to it with WDT at GitHub Sample.
The WebLogic Image Tool is an open source tool that allows you to automate building, patching, and updating your WebLogic Server Docker images, including your own customized images. This tool can be scripted and used in CI/CD processes. Find the WebLogic Image Tool GitHub project at https://github.com/oracle/weblogic-image-tool.
There are four major use cases for this tool:
Using the Image tool, you can incorporate the use cases above into an automated process for patching and updating all of your WebLogic infrastructure and applications running in Docker and Kubernetes.. Oracle recommends that you apply quarterly Patch Set Updates (PSU) to your WebLogic Server binaries, latest Java update, and latest OS update as these updates contain important security fixes!
The Image Tool leverages an important new capability built into My Oracle Support (MOS) that provides a REST API for specifying and downloading patches. The Image Tool automatically downloads all the one-off patches and PSUs you specify from My Oracle Support (MOS) using this REST API, including updates to OPatch, if required. The tool checks for patch conflicts invoking MOS APIs. You must provide the MOS credentials with the necessary support entitlements, and manually download the WebLogic or Java installers before invoking the tool. Patches and installers are cached to prevent having to download them multiple times.
The Image Tool follows Docker best practices to automatically build an image with the recommended image layering, following best practices, and performing cleanup to minimize image size. The tool ensures that the image remains patchable and only uses standard and publicly documented Oracle tools and APIs.
We have posted a YouTube video which demonstrates using the WebLogic Image Tool to create a customized WebLogic Server install image. If you are interested in learning about how to use these images to automate your CI/CD processes to deploy WebLogic domains in Kubernetes, please refer to our documentation and a demonstration YouTube video using Jenkins.
The WebLogic Monitoring Exporter exposes WebLogic Server metrics that can be read and collected by monitoring tools such as Prometheus, and displayed in Grafana dashboards. The WebLogic Monitoring Exporter tool available in open source here.
As it runs, WebLogic Server generates a rich set of metrics and runtime state information that provides detailed performance and diagnostic data about the servers, clusters, applications, and other resources that are running in a WebLogic domain. The WebLogic Monitoring Exporter enables administrators of Kubernetes environments to easily monitor this data using tools like Prometheus and Grafana, tools that are commonly used for monitoring Kubernetes environments.
Now that the entire metric footprint of WebLogic is being exported to Prometheus you can scale the WebLogic Server cluster by setting rules in Prometheus based on the metrics. When the rule is met, Prometheus calls onto the WebLogic Operator to scale the WebLogic cluster.
For more information on the design and implementation of the WebLogic Monitoring Exporter, see Exporting Metrics from WebLogic Server. For more information on Using Prometheus and Grafana to Monitor WebLogic Server on Kubernetes see WebLogic on Kubernetes monitoring using Prometheus and Grafana. Try the end-to-end sample which shows you how to monitor your WebLogic domain running in Kubernetes with Prometheus and out of the box Grafana dash boards. The sample also shows you how to set alerting rules in Prometheus. When alert conditions are met, the Prometheus server fires alerts which can send notifications accordingly to various receivers like email, Slack, webhook, and such.
The WebLogic Logging Exporter exports WebLogic server logs directly from the WebLogic servers to the Elastic Stack. Logs can be analyzed and then displayed in Kibana dashboards. You can find the logging exporter code in its GitHub project and sample.
The combination of these tools enables the automatic deployment of application updates, patching, or changes to the domain configuration through a CI/CD process. In the image bellow I describe a scenario where a user automates an application update deployment to a running WebLogic domain through a CI/CD pipeline using the tools.
In a CI/CD process the pipeline is triggered by a check-in of the deployment archive containing the new version of the application binaries and the WDT model with configuration changes required for the deployment of the new application.
In step one of the pipeline the Image Tool update is invoked passing in the WDT model, the deployment archive, and the name of the base domain image where the new application will be deployed. The Image Tool creates a version2 of the domain image by extending the original domain image from the repository and invoking the WebLogic Deploy Tool to deploy the new application. The Image Tool then pushes the version2 of the domain image to the local repository.
In step two, the pipeline edits the domain.yaml with the new domain image name version2.
The domain.yaml is used to create the Domain Custom Resource, which is a data structure representation of the WebLogic domain in Kubernetes. The Domain Custom Resource describes the desired running state of the WebLogic domain in Kubernetes and extends Kubernetes APIs to begin serving the custom resource object. Users will want to version control their domain.yaml in case they might need to rollback to the previous state of the Domain Custom Resource.
In step three, the pipeline invokes “kubectl apply –f domain.yaml”. This will cause a change in the Domain Custom Resource to define a new image which WebLogic Server pods/containers are based on. When the Operator observes a change in the image name of the Domain Custom Resource, it triggers a rolling restart of the WebLogic domain. The Operator will shutdown the servers in a graceful manner to allow for service migration or session data replication to other servers of the WebLogic cluster and thus guarantee high availability during the roll out of the updates.
Changes to the WebLogic deployments and domain configuration can be visualized in Prometheus and the Grafana dashboards. Users can also visualize the updates in the WebLogic server logs being exported to the Elasticstack and can be displayed in Kibana dashboards.
The WebLogic team continues enhancing these tools, to facilitate and automate updating WebLogic deployments while offering the least interruptions to the running applications.
Some features in the Roadmap of the tools are:
We encourage you to try these tools to help you manage WebLogic deployments in Kubernetes. Please stay tuned for more information. We hope this blog is helpful to those of you seeking to patch, update, and deploy through an automated CI/CD process, and look forward to your feedback.
The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the sole discretion of Oracle Corporation.