Traditionally, when you install Oracle WebLogic, you simply download the  necessary WebLogic and FMW Infrastructure jar files, spin up one or multiple servers, install the software and configure your domain, either automated or manual.

Depending on which Cloud strategie you choose you could either:

 

  • Use pure IaaS, so in essence this means you obtain compute power, storage and network from a certain cloud provider, which can be any you choose: AWS, Azure, Google or maybe Oracle.
  • Use PaaS, where your application server platform and generic middleware is part of the cloud subscription. In this scenario you might choose for Oracle's Java Cloud Service  or some other PaaS such as SOA Cloud Service, depending on the needs. Looking at Java based applications, other vendors also offer Java in the Cloud:

        But when you come from the WebLogic application server, the 1st obvious choice seems the Java Cloud Service. This is only one part of the stage of a future roadmap of your application landscape, because the  applications you develop can still be monoliths. I will come to that later.

 

Along with a strategy of "breaking up the monoliths", DevOps, and Cloud, also containerizing your infrastructure is inevitable for the future state of your applicationlandscape. Now Oracle Product Development stated during Oracle OpenWorld, that regarding containerization, they will follow the strategy of the Cloud Native Compute Foundation which means that products like WebLogic will be developed with respect to container technology such as Docker, CoreOS and Kubernetes.

 

 

Install WebLogic on a Kubernetes platform

 

To install a WebLogic Domain on a Kubernetes platform in the cloud, I used the Oracle Kubernetes Engine which is through the OCI console very easy to set up.

  1. Login to you overall Cloud Dashboard and select Compute in the left pane; this brings you into the Oracle Cloud Infrastructure Dashboard
  2. Click on Developer and create the OKE cluster. Be sure that Helm and Tiller are ticked

 

You have to create a compartment in OCI before creating the OKE. You can find this here https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcompartments.htm

After that in your root compartment, you have to create a policy to manage OKE resources, so select in the left pane:

Identity-->policies and create the following policy"

 

Now the base platform is ready, and we use a linux client to access, manage and build further on our Kubernetes platform.

For that we need to obtain the kubeconfig file from the OKE and place it on our client:

 

Local we create a hidden directory

 

mkdir -p $HOME/.kube

 

Next, you need to install the cloud commandline: https://docs.cloud.oracle.com/iaas/Content/API/SDKDocs/cliinstall.htm and then configure it to use with you cloud tenant

 

oci setup config

 

This sets some basic config, generates an API key pair and creates the config file. The public key you will have to upload to you console:

Then create the kubeconfig file locally:

Then, see if the cluster is accessible

 

The Kubernetes Operator for WebLogic

Before we are going to install our WebLogic domain into Kubernetes, first a so called Operator is required. An operator is an extended api on top of the basic K8S when you setup a K8S cluster.  A WebLogic platform has so many specifics in it, which can't be managed by standard K8S api's, so the operator takes care of that. Operations such as WebLogic clustering, shared domain artifacts, t3 and rmi channel access, and lots more are handled by this operator.

To obtain the operator, clone it from github to a directory you prefer:

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

 

Go to the directory weblogic-kubernetes-operator, where we will install the operator using helm

 

Install the operator using Helm

Before we install the operator, first a role binding needs to be setup for helm in the k8s cluster:

cat << EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: helm-user-cluster-admin-role
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system
EOF

 

Next, out from the cloned git repository you can install the operator using helm:

 

And after a while the operator pod comes online and running

 

Some operational actions can be done with helm. You can inspect the values from your helm chart and see how it's implemented.

So from you directory where the helm chart is located:

To whats implemented:

The operator pod to be seen from your K8S Dashboard

 

 

 

More about the how and why about operators, I advise you to read https://www.qualogy.com/techblog/oracle/whitepaper-kubernetes-and-the-oracle-cloud and the documentation about it which is available on https://docs.helm.sh/

 

 

Preparing and creating a WebLogic domain

Before preparing, you should know what kind of domain model you would like to choose: the domain in docker image or the domain on persistent volume.

If you are really have to preserve state, or make logfiles accessible outside your domain you should us the one on persistent volume.

 

Create a Persistent volume

Using an input file with and changing the values to your to be created domain, namespace, etc:

 

 

# Copyright 2018, Oracle Corporation and/or its affiliates.  All rights reserved.
# Licensed under the Universal Permissive License v 1.0 as shown at http://oss.oracle.com/licenses/upl.

# The version of this inputs file.  Do not modify.
version: create-weblogic-sample-domain-pv-pvc-inputs-v1

# The base name of the pv and pvc
baseName: weblogic-storage

# Unique ID identifying a domain. 
# If left empty, the generated pv can be shared by multiple domains
# This ID must not contain an underscope ("_"), and must be lowercase and unique across all domains in a Kubernetes cluster.
domainUID:

# Name of the namespace for the persistent volume claim
namespace: wls-domain-namespace-1

# Persistent volume type for the persistent storage.
# The value must be 'HOST_PATH' or 'NFS'. 
# If using 'NFS', weblogicDomainStorageNFSServer must be specified.
weblogicDomainStorageType: HOST_PATH

# The server name or ip address of the NFS server to use for the persistent storage.
# The following line must be uncomment and customized if weblogicDomainStorateType is NFS:
#weblogicDomainStorageNFSServer: nfsServer

# Physical path of the persistent storage.
# When weblogicDomainStorageType is set to HOST_PATH, this value should be set the to path to the
# domain storage on the Kubernetes host.
# When weblogicDomainStorageType is set to NFS, then weblogicDomainStorageNFSServer should be set
# to the IP address or name of the DNS server, and this value should be set to the exported path
# on that server.
# Note that the path where the domain is mounted in the WebLogic containers is not affected by this
# setting, that is determined when you create your domain.
# The following line must be uncomment and customized:
weblogicDomainStoragePath: /u01

# Reclaim policy of the persistent storage
# The valid values are: 'Retain', 'Delete', and 'Recycle'
weblogicDomainStorageReclaimPolicy: Retain

# Total storage allocated to the persistent storage.
weblogicDomainStorageSize: 10Gi
weblogicDomainStoragePath: /u01

Now in that directory there is a create script to execute:

 

 

Now the both generated yaml files can be used to apply to the k8s WebLogic namespace:

And in our namespace the storage is created:

 

 

Generating yaml files and create the domain

 

Oracle provides on Github several solutions to create domains. There  domain models I chose was the one to have a perstistent volume to store logs and other artifacts. The storageclass I used was the oci storageclass.

To generation took care of the following:

 

 

  • Create a Job for the entire domaincreation
  • Create a ConfigMap in K8S for parameterizing the WebLogic Domain( based on the yaml inputs)
  • Generation of a domain yaml file out of the input and template yamls
  • Start up scheduled pods for creating the entire domain
  • Final creation of WebLogic Admin Server and Managed Server Pods and start them using the scripts which were included.

And the pod which creates the domain

 

 

 

When this job has finished the final empty WebLogic domain will be created.

 

The road to transformation

 

Now the question is, or this is already production worthy. My opinion is no, because these setups re based on what;s there on github at the moment; so I'd recommend first to start lightweighted and set some of these models up to try them out. To set up an enterprise ready WebLogic Kubernetes platform, also aspects such as automation, loadbalancers, networking, and so on needs to be sorted out how this can be setup in a way that WebLogic can act in a containerized world.

 

In one of my next article I will look at migrating existing WebLogic domain to Kubernetes.