We are very excited to announce the Oracle WebLogic Server Kubernetes Operator, which is available today as a Technology Preview and which is delivered in open source at https://oracle.github.io/weblogic-kubernetes-operator. The operator can manage any number of WebLogic domains running in a Kubernetes environment. It provides a mechanism to create domains, automates domain startup, allows scaling WebLogic clusters up and down either manually (on-demand) or through integration with the WebLogic Diagnostics Framework or Prometheus, manages load balancing for web applications deployed in WebLogic clusters, and provides integration with ElasticSearch, logstash and Kibana.
The operator uses the standard Oracle WebLogic Server 126.96.36.199 Docker image, which can be found in the Docker Store or in the Oracle Container Registry. It treats this image as immutable, and all of the state is persisted in a Kubernetes persistent volume. This allows us to treat all of the pods as throwaway and replaceable, and it completely eliminates the need to manage state written into Docker containers at runtime (because there is none).
The diagram below gives a high level overview of the layout of a domain in Kubernetes when using the operator:
The operator can expose the WebLogic Server Administration Console to external users (if desired), and can also allow external T3 access; for example for WLST. Domains can talk to each other, allowing distributed transactions, and so on. All of the pods are configured with Kubernetes liveness and readiness probes, so that Kubernetes can automatically restart failing pods, and the load balancer configuration can include only those Managed Servers in the cluster that are actually ready to service user requests.
We have a lot of documentation available on the project pages on GitHub including details about our design philosophy and architecture, as well as instructions on how to use the operator, video demonstrations of the operator in action, and a developer page for people who are interested in contributing to the operator.
We hope you take the opportunity to play with the Technology Preview and we look forward to getting your feedback.
The Oracle WebLogic Server Kubernetes Operator has the following requirements:
docker images | grep flannel)
For more details on the certification and support statement of WebLogic Server on Kubernetes, refer to My Oracle Support Doc Id 2349228.1.
A series of video demonstrations of the operator are available here:
The overall process of installing and configuring the operator and using it to manage WebLogic domains consists of the following steps. The provided scripts will perform most of these steps, but some must be performed manually:
Complete up-to-date instructions are available at https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/installation.md or read on for an abbreviated version:
To run the operator in a Kubernetes cluster, you need to build the Docker image and then deploy it to your cluster.
First run the build using this command:
mvn clean install
Then create the Docker image as follows:
docker build -t weblogic-kubernetes-operator:developer --no-cache=true
We recommend that you use a tag other than
latest to make it easy to distinguish your image. In the example above, the tag could be the GitHub ID of the developer.
Next, upload your image to your Kubernetes server as follows:
# on your build machine docker save weblogic-kubernetes-operator:developer > operator.tar scp operator.tar YOUR_USER@YOUR_SERVER:/some/path/operator.tar # on the Kubernetes server docker load < /some/path/operator.tar
Verify that you have the right image by running
docker images | grep webloogic-kubernetes-operator on both machines and comparing the image ID.
We will be publishing the image in Oracle Container Registry and the instructions will be updated when it is available there. After it is published, you will not need to build the image yourself, you will have the option to pull it from the registry instead.
The operator is deployed with the provided installation script,
create-weblogic-operator.sh. The input to this script is the file
create-operator-inputs.yaml, which needs to updated to reflect the target environment.
The following parameters must be provided in the input file:
|externalOperatorCert||A base64 encoded string containing the X.509 certificate that the operator will present to clients accessing its REST endpoints. This value is only used when
|externalOperatorKey||A base64 encoded string containing the private key ask tom This value is only used when externalRestOption is set to custom-cert.|
|externalRestOption||Write me. Allowed values:
|externalSans||A comma-separated list of Subject Alternative Names that should be included in the X.509 Certificate. This list should include ...
|namespace||The Kubernetes namespace that the operator will be deployed in. It is recommended that a namespace be created for the operator rather than using the
|targetNamespaces||A list of the Kubernetes namespaces that may contain WebLogic domains that the operator will manage. The operator will not take any action against a domain that is in a namespace not listed here.||default|
|remoteDebugNodePort||Tom is adding a debug on/off parameter
If the debug parameter if set to on, then the operator will start a Java remote debug server on the provided port and will suspend execution until a remote debugger has attached.
|restHttpsNodePort||The NodePort number that should be allocated for the operator REST server on which it should listen for HTTPS requests on.||31001|
|serviceAccount||The name of the service account that the operator will use to make requests to the Kubernetes API server.||weblogic-operator|
|loadBalancer||The load balancer that is installed to provide load balancing for WebLogic clusters. Allowed values are:
|loadBalancerWebPort||The NodePort for the load balancer to accept user traffic.||30305|
|enableELKintegration||Determines whether the ELK integration will be enabled. If set to
The operator provides three REST certificate options:
nonewill disable the REST server.
self-signed-certwill generate self-signed certificates.
custom-certprovides a mechanism to provide certificates that were created and signed by some other means.
The operator provides some optional features that can be enabled in the configuration file.
The operator can install the Traefik Ingress provider to provide load balancing for web applications running in WebLogic clusters. If enabled, an instance of Traefik and an Ingress will be created for each WebLogic cluster. Additional configuration is performed when creating the domain.
Note that the Technology Preview release provides only basic load balancing:
Note that Ingresses are not created for servers that are not part of a WebLogic cluster, including the Administration Server. Such servers are exposed externally using NodePort services.
The operator can install the ELK stack and publish its logs into ELK. If enabled, ElasticSearch and Kibana will be installed in the
default namespace, and a logstash pod will be created in the operator’s namespace. Logstash will be configured to publish the operator’s logs into Elasticsearch, and the log data will be available for visualization and analysis in Kibana.
To enable the ELK integration, set the
enableELKintegration option to
To deploy the operator, run the deployment script and give it the location of your inputs file:
./create-weblogic-operator.sh –i /path/to/create-operator-inputs.yaml
The script will carry out the following actions:
The script will validate each action before it proceeds.
This will deploy the operator in your Kubernetes cluster. Please refer to the documentation for next steps, including using the REST services, creating a WebLogic domain, starting a domain, and so on.
Over the weekend we updated Oracle Developer Cloud Service - your cloud based DevOps and Agile platform - with a new release (18.3.3) adding...
This is the first blog in the series to come, which will help you understand, how you can build a NodeJS REST microservice application...