Okay, this is a bit of a change in direction. We will actually be running WebLogic 12 in Kubernetes. The instructions should work fine for WebLogic 14 (according to Oracle). However, the domain I am testing with we know works in WebLogic 12, and the Docker and Kubernetes setup comes defaulted to WL 12. So that will just be easier.
The Kubernetes Operator
WebLogic provides an operator for Kubernetes. This guy lives on its own, and can manage any number of domains in any number of namespaces. For our purposes, we only care about one domain, and at least for dev, only one namespace. Follow the instructions here to install this.
The Helm chart that is used to install the operator also includes a custom resource definition for a WebLogic domain. This means that you only really need to tell Kubernetes about your domain, and the operator will handle the rest. As laid out in the instructions, there are a few different ways you can really provide the information for the domain. We chose the Domain in Image, as this is easy for us to build, and seems like the most versatile and familiar to us.
Creating the Domain
We created a Docker image with our domain “baked into” it. We started from the Oracle-provided WL 12 base image, and ran our own deployment scripting on top of that to get our domain into the image. With that now in hand, it is easy to modify the example domain YAML files provided with our own image, for something resembling this:
apiVersion: "weblogic.oracle/v8"
kind: Domain
metadata:
name: example
namespace: default
labels:
weblogic.domainUID: example
spec:
domainHome: /u01/app/weblogic/domains/example
domainHomeSourceType: Image
image: "domain-home-in-image:v1"
imagePullPolicy: "IfNotPresent"
webLogicCredentialsSecret:
name: example-weblogic-credentials
includeServerOutInPodLog: true
serverStartPolicy: "IF_NEEDED"
serverPod:
# an (optional) list of environment variable to be set on the servers
env:
- name: JAVA_OPTIONS
value: "-Dweblogic.StdoutDebugEnabled=false"
- name: USER_MEM_ARGS
value: "-Djava.security.egd=file:/dev/./urandom "
adminServer:
serverStartState: "RUNNING"
Inspector
When the domain is deployed, the Kubernetes operator will spin up an inspector, which will create a container from the provided image, and go into it to, well, inspect it. The operator will get information on what containers will need to be created and how the domain is configured. When the inspector is done, the operator will start up the Admin server, as well as the other containers as needed.
If you are used to running your domain across a few physical servers, with multiple nodes running on the same server, you will need to adjust the ports you are used to in order to work in a Kubernetes context (obviously). The Kubernetes operator will also predictably name the containers, to help with discoverability and all that goodness. You will probably need to take that into account when building your domain as well.
Running
If that all worked, you should now have your domain running in Kubernetes. Depending on the setup, you will still need to create services to expose your endpoints. If you have a WebLogic cluster in your domain, you can set up the operator and Domain to automatically create a Kubernetes NodePort service for the cluster, so you can expose that directly. Otherwise, you will just get ClusterIP services, which just means that containers running inside the same Kubernetes cluster can talk to those services, but they are not exposed externally.
End Matter
This really turned into just a general overview, rather than a technical deep-dive like I had originally planned. Time constraints and changes in directions mean that I can’t actually give a deep dive into this. Luckily, the instructions from Oracle, linked above, do a decent job of laying out what happens and have some okay examples. So look at those.