For me this presentation is the result of having done a workshop at the PaaSForum in Mallorca, and then to work that around into a setup where I was able to run the MedRec Weblogic sample application against a managed Database under Kubernetes.
Kubernetes Weblogic Operator Tutorial
I already wrote a blog about my workshop at the PaaSForum this year, but Marc Lameriks from Amis, did a walkthrough on the workshop. It basically comes down to this tutorial, which you can do as a self-paced tutorial. Or checkout a Meetup in your neighbourhoud. If you're in the Netherlands, we'll be happy to organized one, or if you like I would come over to your place and we could set something up. See also the links at the end of part 2 of our presentations for more info on the tutorial for instance.I did the tutorial more or less three times now, once at the PaaSForum, then I re-did it, but deliberately changed namespace-names, domain-name, etc. Just to see where the dependencies are, and actually to see where the pitfalls are. It's based on my method to get to know an unfamiliar city: deliberately get lost in it. Two years ago we moved to another part of Amersfoort. To get to know my new neighbourhood, I often took another way home then I when I left. And this is basically what I did with the tutorial too.
The last time I did it was to try to run a more real-life application with an actual database. And therefor I setup a new OKE cluster, this time in a compartment of our own company cloud subscription. Interesting in that is that you work with a normal customer-alike subscription within a compartment. Another form of a deliberate D-Tour. But also to setup a database and see that configuration overrides to change your runtime datasource-connection pool actually works.
Cheatsheet
When doing the tutorial, you'll find that besides all the configurations on the Cloud Pages, to setup your OKE Cluster, configure Oracle Pipelines, you'll find that you'll have to enter a lot of commandline-commands. Most of them are kubectl commands, some helm, and a bit of OCI commandline interface. Doing it the first time I soon got lost in the meaning of them and what I was doing with it. Also, most kubectl commands work with namespaces where your Weblogic has another namespace then the Weblogic Operator. And as is my habit nowadays, I soon put the commands in smart but simple scripts. And those I want to share with you. Maybe not all, but at least enough so you'll get the idea.I also found the official kubernetes.io kubectl cheat sheet and this one on github. But those are more explanations of the particular commands.
I found it helpfull to set up this Cheatsheet following the tutorial. I guess this helps in relating the commands in what they're meant for.
Shell vs. Alias
At the UKOUG TechFest, someone pointed that you could use aliases too. Of course. You could do an alias likealias k=kubectl
However, you'll still need to extend every command with the proper namespace, pod naming, etc.
Therefor, I used the approach of creating a oke_env.sh script that I can include in every script, and a property file to store the credentials to put in secrets. Then call (source) the oke_env.sh script in every other script.
Setup Oracle Kubernetes Engine instance on Oracle Cloud Infrastructure
These scripts refer to the first part of the tutorial: 0. Setup Oracle Kubernetes Engine instance on Oracle Cloud Infrastructure.oke_env.sh
It all starts with my oke_env.sh. Here you'll find all the particular necessary variables that are used in most other scripts. I think in a next iteration I would move the OIC_USER, OCID_TENANCY and OCID_CLUSTERID to my credential properties file. But I introduced that later on, during my experiments.#!/bin/bash echo Set OKE Environment export OCID_USER="ocid1.user.oc1..{here goes that long string of characters}" export OCID_TENANCY="ocid1.tenancy.oc1..{here goes that other long string of characters}" export OCID_CLUSTERID="ocid1.cluster.oc1.eu-frankfurt-1.{yet another long string of characters}" export REGION="eu-frankfurt-1" # or your other region export CLR_ADM_BND=makker-cluster-admin-binding export K8S_NS="medrec-weblogic-operator-ns" export K8S_SA="medrec-weblogic-operator-sa" export HELM_CHARTS_HOME=/u01/content/weblogic-kubernetes-operator export WL_OPERATOR_NAME="medrec-weblogic-operator" export WLS_DMN_NS=medrec-domain-ns export WLS_USER=weblogic export WLS_DMN_NAME=medrec-domain export WLS_DMN_CRED=medrec-domain-weblogic-credentials export OCIR_CRED=ocirsecret export WLS_DMN_YAML=/u01/content/github/weblogic-operator-medrec-admin/setup/medrec-domain/domain.yaml export WLS_DMN_UID=medrec-domain export MR_DB_CRED=mrdbsecret export ADM_POD=medrec-domain-adminserver export MR1_POD=medrec-domain-medrec-server1 export MR2_POD=medrec-domain-medrec-server2 export MR3_POD=medrec-domain-medrec-server3 export DMN_HOME=/u01/oracle/user_projects/domains/medrec-domain export LCL_LOGS_HOME=/u01/content/logs export ADM_SVR=AdminServer export MR_SVR1=medrec-server1 export MR_SVR2=medrec-server2 export MR_SVR3=medrec-server3
credentials.properties
This stores the most important credentials. That allows me to abstract those from the scripts. However, as mentioned, I should move the OIC_USER, OCID_TENANCY and OCID_CLUSTERID variables to this file.
weblogic.user=weblogic weblogic.password=welcome1 ocir.user=my.email@address.nl ocir.password=my;difficult!pa$$w0rd ocir.email=my.email@address.nl oci.tenancy=ourtenancy oci.region=fra db.medrec.username=MEDREC_OWNER db.medrec.password=MEDREC_PASSWORD db.medrec.url=jdbc:oracle:thin:@10.11.12.13:1521/pdb1.subsomecode.medrecokeclstr.oraclevcn.com
create_kubeconfig.sh
After having setup the OKE Cluster in OCI, and configured your OCI CLI, the first actuall command you issue is to create a Kube Config file, using the OCI CLI. This one is executed only once, normally for every setup. So this script is merely to document my commands:#!/bin/bash SCRIPTPATH=$(dirname $0) # . $SCRIPTPATH/oke_env.sh echo Create Kubeconfig -> Copy command from Access Kube Config from cluster mkdir -p $HOME/.kube oci ce cluster create-kubeconfig --cluster-id $OCID_CLUSTERID --file $HOME/.kube/config --region $REGION --token-version 2.0.0
The SCRIPTPATH variable declaration is a trick to be able to refer to other scripts relatively from that variable. Then as you will see in all my subsequent scripts, I source here the oke_env.sh script. Doing so I can refer to the particular variables in the oci command. There for, as described in the tutorial, you should note down your OCID_CLUSTERID and update that into the oke_env.sh file, as well as the REGION variable.
Note by the way, that recently Oracle Kubernetes Engine upgraded to only support the Kubeconfig token version 2.0.0. See also this document.
getnodes.sh
This one is a bit dumb, and could as easily be created by an alias:#!/bin/bash SCRIPTPATH=$(dirname $0) # . $SCRIPTPATH/oke_env.sh echo Get K8s nodes kubectl get node
Even the call to the oke_env.sh doesn't add anything, really but it is a base for the other scripts and when needing to add namespaces it makes sense.
create_clr_rolebinding.sh
The last part of setting up the OKE cluster is to create a role binding. This is done with:#!/bin/bash SCRIPTPATH=$(dirname $0) # . $SCRIPTPATH/oke_env.sh echo Create cluster role binding echo kubectl create clusterrolebinding $CLR_ADM_BND --clusterrole=cluster-admin --user=$OCID_USER kubectl create clusterrolebinding $CLR_ADM_BND --clusterrole=cluster-admin --user=$OCID_USER
Install WebLogic Operator
The second part of the tutorial is about seting up your project environment with Github and have Oracle Pipelines build your projects image. This is not particularly related to K8S, so no relevant scripts there.The next part of the tutorial is about installing the operator: 2. Install WebLogic Operator.
create_kubeaccount.sh
Installling Weblogic Operator is done using Helm. As far as I have understood is Helm a sort of package manager for Kubernetes. Funny thing in naming is that where Kubernetes is Greek for the steering officer on a ship, helm is the steering device of a ship. It makes use of Tiller, the server side part of Helm. A tiller is the "steering stick" or lever that manages the Helm device. (To be honest, to me it feels a bit the otherway around, I guess I would have named the server side Helm and the client Tiller).As a first step is to create a Helm Cluster admin role binding, a kubernetes namespace for the Weblogic Operator and a serviceaccount within this namespace. To do so the script create_kubeaccount.sh does the following:
#!/bin/bash SCRIPTPATH=$(dirname $0) # . $SCRIPTPATH/oke_env.sh echo Create helm-user-cluster-admin-role 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 echo Create namespace $K8S_NS kubectl create namespace $K8S_NS echo kubectl create serviceaccount -n $K8S_NS $K8S_SA kubectl create serviceaccount -n $K8S_NS $K8S_SA
install_weblogic_operator.sh
Installing the Weblogic operator is done with this script. Notice that you need to execute the helm command within the folder in which you checked out the Weblogic Operator github repository.
#!/bin/bash SCRIPTPATH=$(dirname $0) # . $SCRIPTPATH/oke_env.sh echo Install Weblogic Operator $WL_OPERATOR_NAME cd $HELM_CHARTS_HOME helm install kubernetes/charts/weblogic-operator \ --name $WL_OPERATOR_NAME \ --namespace $K8S_NS \ --set image=oracle/weblogic-kubernetes-operator:2.3.0 \ --set serviceAccount=$K8S_SA \ --set "domainNamespaces={}" cd $SCRIPTPATH
The script will cd to the Weblogic Operator local repository and executes helm. In the begin of the script the current folder is saved as SCRIPTPATH. After running the helm command, it does a cd back to it.
delete_weblogic_operator.sh
During my investigations the Weblogic Operator was upraded. If you take a closer look to the command in the tutorial, you'll notice that the image that is used is oracle/weblogic-kubernetes-operator:2.0, but I used oracle/weblogic-kubernetes-operator:2.3.0 in the script above.I found it usefull to be able to delete the operator to be able to re-install it again. To delete the weblogic operator run the delete_weblogic_operator.sh script:
#!/bin/bash SCRIPTPATH=$(dirname $0) # . $SCRIPTPATH/oke_env.sh echo Delete Weblogic Operator $WL_OPERATOR_NAME cd $HELM_CHARTS_HOME helm del --purge $WL_OPERATOR_NAME cd $SCRIPTPATH
Again in this script the helm command is surrounded by a cd to the helm charts folder of the Weblogic Operator local github repository, and back again to the current folder.
getpods.sh
After having installed the Weblogic Operator, you can list the pods of the kubernetes namespace it runs in, using this script:#!/bin/bash SCRIPTPATH=$(dirname $0) # . $SCRIPTPATH/oke_env.sh echo Get K8s pods for $K8S_NS kubectl get po -n $K8S_NS
list_wlop.sh
You can check the Weblogic Operator installion by performing a helm list of the Weblogic Operator charts. I wrapped that ino this script:#!/bin/bash SCRIPTPATH=$(dirname $0) # . $SCRIPTPATH/oke_env.sh echo List Weblogic Operator $WL_OPERATOR_NAME cd $HELM_CHARTS_HOME helm list $WL_OPERATOR_NAME cd $SCRIPTPATH
No comments:
Post a Comment