Oracle WebLogic Server Kubernetes Operator

Introduction

A WebLogic domain can be located either in a persistent volume (PV) or in a Docker image. There are advantages to both approaches, and sometimes there are technical limitations of various cloud providers that may make one approach better suited to your needs.

This lab uses the Docker image with the WebLogic domain inside the image deployment.

This means that all the artifacts and domain-related files are stored within the image. There is no central, shared domain folder.

Similar to the standard installation topology where you distribute your domain to different hosts to scale out Managed Servers.

The main difference is that by using a container-packaged WebLogic domain, you don't need to use the pack/unpack mechanism to distribute domain binaries and configuration files between multiple hosts.

In a Kubernetes environment, the Operator ensures that only one Administration Server and multiple Managed Servers will run in the domain.

The Operator is an application-specific controller that extends Kubernetes to create, configure, and manage instances of complex applications. Therefore, simplifies the management and operation of WebLogic domains and deployments.

The Helm is a framework that helps you manage Kubernetes applications, and helm charts help you define and install Helm applications in a Kubernetes cluster.

Lab Objectives

In this lab you will:

Set up an Oracle Kubernetes Engine instance
Install the WebLogic Server Kubernetes Operator
Install a load balancer
Deploy a WebLogic domain
Scale a WebLogic cluster
Update a deployed application by a rolling restart of the new image
Assign WebLogic pods to nodes (a scenario simulating a cluster spanning 2 data centers)

Click the next button below to begin.

Task 1: Set up an Oracle Kubernetes Engine instance

Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetes is a fully-managed, scalable, and highly available service that you can use to deploy your container applications to the cloud.

Use the Container Engine for Kubernetes (OKE) when your development team wants to reliably build, deploy, and manage cloud-native applications.

In this task, you will connect to your OKE cluster via Cloud Shell.

Start by "sign in" to the OCI Console.
On the Oracle Linux desktop, open the html page for the sign in information and the credentials.
Use the credentials provided on this page.
Click OCI Console to sign in.
Copy and paste the credentials and click Sign In.
You have successfully signed in to the Oracle cloud.
Select Developer Services and Kubernetes Clusters.
Select your Luna compartment in the compartment dropdown menu and select your instance.
You should see the cluster is being created and will take around 10 to 15 minutes to complete.
Click Work Request to see the status.
When the cluster operation is completed the status changes to SUCCEEDED.
After 10 to 15 minutes, the nodes creation with start.
Before continuing with the lab, wait for the node pool have been created before moving on to the next step. It should take less than 5 minutes to complete.
When succeeded, access the cluster by clicking on button Access Cluster.
Make sure Cloud Shell Access is selected and click copy. You should see copied when clicked.
Now click the button Launch Cloud Shell to launch the cloud shell environment.
After a few seconds the cloud console is ready.
Paste the command you copied earlier in to the Cloud Shell and hit ENTER.
Now check to see if the nodes are ready by using the kubectl command.
```
kubectl get node
```
The nodes are ready.

The Oracle Kubernetes Engine instance on OCI is deployed and you are now ready for the next task.

Click Next to continue.

Task 2: Install the WebLogic Server Kubernetes Operator

The Operator is an application-specific controller that extends Kubernetes to create, configure, and manage instances of complex applications.

The Operator simplifies the management and operation of WebLogic domains and deployments.

In this task, you will prepare OCI Cloud Shell (client) environment and install the Operator.

Clone the operator git repository.

git clone https://github.com/oracle/weblogic-kubernetes-operator.git -b v4.0.1

Clone is successful.

Prepare the Kubernetes environment.
Kubernetes distinguishes between the concept of a user account and a service account for a number of reasons. The main reason is that user accounts are for humans while service accounts are for processes, which run in pods.
The operator also requires service accounts. If a service account is not specified, it defaults to default (for example, the namespace's default service account).
If you want to use a different service account, then you must create the operator's namespace and the service account before installing the operator Helm chart.

Create the operator's namespace.

kubectl create namespace sample-weblogic-operator-ns

Create the service account.

kubectl create serviceaccount -n sample-weblogic-operator-ns sample-weblogic-operator-sa

Add the weblogic-operator repository to Helm.

helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update

Install the operator using Helm.
Before you execute the operator helm install, make sure that you are in the operator's local Git repository folder.
```
cd ~/weblogic-kubernetes-operator/
```
Use the helm install command to install the operator Helm chart. As part of this, you must specify a "release" name for their operator.
You can override the default configuration values in the operator Helm chart by doing one of the following:
1. Creating a custom YAML file containing the values to be overridden, and specifying the --values option on the Helm command line.
2. Overriding individual values directly on the Helm command line, using the --set option.
Using the last option, simply define overriding values using the --set option.
Note the values:
- The name of the Helm release.
- The relative path to the Helm chart.
- namespace: The namespace where the operator is to be deployed.
- serviceAccount: The service account required to run the operator.
Earlier versions of the operator's Helm chart only supported selecting namespaces that the operator would manage using a list. Now, namespaces may be chosen using a list, label selector, or regular expression.
Execute the following helm command.
```
helm install sample-weblogic-operator weblogic-operator/weblogic-operator \
--namespace sample-weblogic-operator-ns \
--set serviceAccount=sample-weblogic-operator-sa \
--wait
```
The command executed successfully.

Check the operator pod.

kubectl get po -n sample-weblogic-operator-ns

The pods are running.

NAME                                         READY   STATUS    RESTARTS   AGE
weblogic-operator-7cd4cc88bf-2f74n           1/1     Running   0          2m19s
weblogic-operator-webhook-857cbdf974-nqnkk   1/1     Running   0          2m19s

Check the operator Helm chart.
```
helm list -n sample-weblogic-operator-ns
```
The chart is deployed.

You have now installed the Operator.

Congratulations on completing this task!

Click Next to continue.

Task 3: Install a load balancer

The Oracle WebLogic Server Kubernetes Operator supports three load balancers: Traefik, Voyager, and Apache.

In this task, you will install the Traefik Ingress controller to provide load balancing for WebLogic clusters.

Change to your operator local Git repository folder.
```
cd ~/weblogic-kubernetes-operator/
```
Create a namespace for Traefik.
```
kubectl create namespace traefik
```

Add Traefik repository to Helm.

helm repo add traefik https://helm.traefik.io/traefik --force-update

Install the Traefik operator in the traefik namespace with the provided sample values.

helm install traefik-operator \
traefik/traefik \
--namespace traefik \
--values kubernetes/samples/charts/traefik/values.yaml  \
--set "kubernetes.namespaces={traefik}" \
--set "serviceType=LoadBalancer"

Successfully installed Traefik.

Note the Traefik's load balancer external IP address.
```
kubectl get service -n traefik
```
The EXTERNAL-IP of the traefik-operator service is in pending state.
After a few seconds the EXTERNAL-IP of the traefik-operator service is displayed.
This is the public IP address of the load balancer that you will use to access the WebLogic Server Administration Console and the application.
Verify the helm charts.
```
helm list -n traefik
```
The traefik-operator is running.

You have now installed a load balancer.

Congratulations on completing this task!

Click Next to continue.

Task 4: Deploy a WebLogic domain

In this task, you will deploy and configure the Operator on OKE.

Prepare the Kubernetes cluster to run WebLogic domains.
Create the domain namespace:
```
kubectl create namespace sample-domain1-ns
```

Create a Kubernetes secret containing the Administration Server boot credentials.

kubectl -n sample-domain1-ns create secret generic sample-domain1-weblogic-credentials \
--from-literal=username=weblogic \
--from-literal=password=welcome1

Label the domain namespace.

kubectl label ns sample-domain1-ns weblogic-operator=enabled

Now we can update the Traefik ingress controller configuration.
After you have your domain namespace (the WebLogic domain is not deployed yet), you have to update the load balancer and operator configuration to specify where the domain will be deployed.
Before executing the domain helm install, be sure that you are in the WebLogic operator local Git repository folder.
```
cd ~/weblogic-kubernetes-operator/
```

Update Traefik.

Execute the following helm upgrade command.

helm upgrade traefik-operator \
traefik/traefik \
--namespace traefik \
--reuse-values \
--set "kubernetes.namespaces={traefik,sample-domain1-ns}" \
--wait

The command ran successfully.

Deploy a WebLogic domain on Kubernetes.
To deploy WebLogic domain, you need to create a domain resource definition which contains the necessary parameters for the operator to start the WebLogic domain properly.
We provided for you a domain.yaml file that contains a YAML representation of the custom resource object. Please copy it locally:
```
curl -LSs https://raw.githubusercontent.com/pandey-ankit/weblogic/main/weblogic-kubernetes/domain.v9.yaml  >~/domain.yaml
```
You can review it in your favorite editor or browser.
Create the domain custom resource object.
```
kubectl apply -f ~/domain.yaml -n sample-domain1-ns  
```
The domain.yaml file applied successfully.
Check the pods in the domain namespace until all are in RUNNING status.
```
kubectl get po -n sample-domain1-ns
```
Progress of creating the containers.
Run the command until the admin server and 2 managed servers is in running state.
You should see three running pods similar to the results shown above. If you don't see all the running pods, wait and then check periodically. The entire domain deployment may take up to 2-3 minutes depending on the compute shapes.

In order to access any application or the Administration Console deployed on WebLogic, you have to configure a Traefik Ingress.

As a simple solution, it's best to configure path routing, which will route external traffic through Traefik to the domain cluster address or the Administration Server Console.

Execute the following ingress resource definition:

cat <<EOF | kubectl apply -f -
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: console
  namespace: sample-domain1-ns
spec:
  routes:
    - kind: Rule
      match: PathPrefix(\`/console\`)
      services:
        - kind: Service
          name: sample-domain1-admin-server
          port: 7001
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: opdemo
  namespace: sample-domain1-ns
spec:
  routes:
    - kind: Rule
      match: PathPrefix(\`/opdemo\`)
      services:
        - kind: Service
          name: sample-domain1-cluster-cluster-1
          port: 8001
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: remote-console
  namespace: sample-domain1-ns
spec:
  routes:
    - kind: Rule
      match: PathPrefix(\`/\`)
      services:
        - kind: Service
          name: sample-domain1-admin-server
          port: 7001
EOF

The ingress resource definition ran successfully.

Note the two backends, namespace, serviceName, and servicePort definitions. The first backend is the domain cluster service to reach the application at the root context path. The second is for the admin console which is a different service.

Once the Ingress has been created construct the URL of the Administration Console based on the following pattern.
```
http://EXTERNAL_IP/console
```
The EXTERNAL_IP was determined during the Traefik install.
If you forgot to note it down, then execute the following command to get the public IP address.
```
kubectl describe svc traefik-operator --namespace traefik | grep Ingress | awk '{print $3}'
```
Open the Administration Console in a browser.
Example http://111.222.111.222/console
Logon to the console using the following user credentials.
User: weblogic
Password: welcome1
Enter the credentials.
Test the sample web application.
```
http://EXTERNAL_IP/opdemo/?dsname=testDatasource
```
Example http://111.222.111.222/opdemo/?dsname=testDatasource
The application is working.
Refresh the page and notice the hostname changes. It reflects the Managed Server's name which responds to the request.

You should see load balancing between the two Managed Servers.

Congratulations on completing this task!

Click Next to continue.

Task 5: Scale a WebLogic cluster

WebLogic Server supports two types of clustering configurations, configured and dynamic. Configured clusters are created by manually configuring each individual Managed Server instance. In dynamic clusters, the Managed Server configurations are generated from a single, shared template.

With dynamic clusters, when additional server capacity is needed, new server instances can be added to the cluster without having to manually configure them individually.

Also, unlike configured clusters, scaling up of dynamic clusters is not restricted to the set of servers defined in the cluster but can be increased based on runtime demands.

The Operator provides several ways to initiate scaling of WebLogic clusters, including:

On-demand, updating the domain resource directly (using kubectl).
Calling the operator's REST scale API, for example, from curl.
Using a WLDF policy rule and script action to call the operator's REST scale API.
Using a Prometheus alert action to call the operator's REST scale API.

The easiest way to scale a WebLogic cluster in Kubernetes is to simply edit the replicas property within a domain resource.

To retain changes, edit the domain ,yaml file and apply the changes using kubectl. Use your favorite editor to open the domain.yaml file.

Use the vi tool to open the domain.yaml file.
```
vi ~/domain.yaml
```
Scroll to the line replicas (It is at the bottom of the file).
and change the value to 3. Remember to save the file.
Position the cursor over the character and type r, then type one character to replace. It will automatically returns to command mode (you do not need to press Esc).
Apply the changes using kubectl.
```
kubectl apply -f ~/domain.yaml
```
Check the changes in the number of pods.
Use the kubectl command.
```
kubectl get po -n sample-domain1-ns
```
Check they are in RUNNING state.
Using the WebLogic Server Administration Console.

You have scaled the WebLogic cluster by adding a managed server.

Congratulations on completing this task!

Click Next to continue.

Task 6: Update a deployed application by a rolling restart of the new image

In this task, you will deploy a new image that contains an updated version of the application with a green title on the main page.

Edit the domain resource definition (domain.yaml) and modify the image location.
Use the vi tool to open the domain.yaml file.
```
vi ~/domain.yaml
```
Go to the image line.
Replace the whole line with the new version or just change the version number to 2.
```
image: "iad.ocir.io/weblogick8s/weblogic-operator-tutorial-store:2.0"
```
Image is replaced with the new version.
Don't forget the leading spaces to keep the proper indentation.

Apply the domain resource changes.

kubectl apply -f ~/domain.yaml -n sample-domain1-ns

You can immediately check the status of your servers/pods.
```
kubectl get po -n sample-domain1-ns
```
The operator now performs a rolling server restart, one server at a time. The first one is the Admin Server, then the Managed servers and so on.
During the rolling restart, check your web application periodically.
```
http://EXTERNAL_IP/opdemo/?dsname=testDatasource   
```
If the server has not yet restarted you will continue to see the old version (black fonts) of the application.
If the server is restarted, you should see the change (green fonts) you made to the application.

You have deployed with the new version of the image.

Congratulations on completing this task!

This is the end of the lab.

To exit, click the End Session icon on the Luna tool bar.