Image credits: Jesus Kiteque on Unsplash
In this post, I am going to give a brief introduction to deploying WSO2 Identity Server on Kubernetes. If you are going to deploy on a Kubernetes cluster, WSO2 has detailed documentation on the process. A basic understanding of Kubernetes is needed to follow this guide. There are plenty of resources out there to get a basic understanding of Kubernetes, even the official documentation is good enough.
For any deployment on proper multi-node Kubernetes setup on either big clouds (AWS, Azure, and GCP) or on-premise or even bare metal I would recommend this guide. If you want to deploy locally on a Mini Kube environment, unfortunately, the above resource doesn’t work without a few modifications. In this post, I'll provide guidance on deploying WSO2 Identity Server on Mini Kube using the above resource as a basis with some modifications.
Installing Mini Kube
As a first step, make sure you have the Mini Kube setup with enough memory and CPU allocated. I would say having 4 CPUs and 8 GB memory is more than enough for this deployment.
Installing Ingress Controller
An ingress controller is needed to access WSO2 Identity Server from the browser. Setting up an Ingress controller with SSL passthrough is simpler than doing an SSL termination. This is the approach mentioned in the official guide from WSO2. The ingress controller add on of Mini Kube doesn’t support the SSL passthrough. We have to deploy the modified Kubernetes manifest to deploy an ingress controller with SSL passthrough instead of the add on. I have a Github repository with the required manifests. Clone the repository and copy the manifests to ~/.minikube/addons location and restart the Mini Kube.
git clone https://github.com/ajanthan/minikube-ingress-with-ssl-passthrough.git cd minikube-ingress-with-ssl-passthrough cp *.yaml ~/.minikube/addons minikube stop minikube start
Installing WSO2 Identity ServerUpdating configurations
Clone the WSO2 Kubernetes resource git repository locally. We are going to modify it to fit Mini Kube. If you want to skip modifying the configurations and head straight into deploying, I have an updated repository with all the changes. You can use it and deploy Mysql and WSO2 Identity Server without going through the following steps.
git clone https://github.com/wso2/kubernetes-is.git
Persistence volume is used to store and data generated by Mysql POD and WSO2 Identity Server POD. By default, NFS is used as a persistence volume provider. For Mini Kube based local setup, setting the Hostpath persistence volume type will simplify the deployment process since it doesn't require any NFS. It will just mount a folder from the host machine. To enable Hostpath persistence volume type for WSO2 Identity Server persistence volume configuration and Mysql configuration, the following changes have to be done.
For WSO2 Identity Server:
When the Hostpath volume persistence is used with Mini Kube, the container needs root access to access the attached volume since the Mini Kube VM doesn’t have any none root users. Creating a none user in Mini Kube VM is also not straightforward. To make things simpler here, we are going to run the WSO2 Identity Server container and the Mysql container as root. Running the containers as root in production is strictly not recommended but for demo purposes, we could run it. Do the following changes to run containers as the root user.
WSO2 Identity Server container:
The default WSO2 Identity Server POD uses an image that requires a trial license from WSO2 because it has bugfix patches that are under a commercial license. In this exercise, we are going to use the open source version of the images from the official Docker hub.
For a single node demo deployment clustering is not needed. The official Kubernetes guide has clustering enabled. Let’s disable the cluster as follows.
Now we are ready to deploy the setup. We are going to deploy a single node WSO2 Identity Server without analytics on the default namespace. The official guide has a script to deploy or undeploy the setup but here we are going to use kubectl to deploy everything manually. I have committed the above changes to my own fork of the original repository. In the end, you should have the below changes to your checkout as in the commit history.
Execute the following commands from the checkout directory to deploy persistent volume for Mysql.
kubectl create -f is/extras/rdbms/mysql/mysql-persistent-volume-claim.yaml kubectl create -f is/extras/rdbms/volumes/persistent-volumes.yaml
A configMap with the script to populate WSO2 specific schema needs to be deployed.
kubectl create configmap mysql-dbscripts --from-file=is/extras/confs/rdbms/mysql/dbscripts/
Deploy Mysql deployment and the service to spin up the POD and expose it as service internally.
kubectl create -f is/extras/rdbms/mysql/mysql-deployment.yaml kubectl create -f is/extras/rdbms/mysql/mysql-service.yaml
Wait for a few minutes and the Mysql POD will be up and running.
Deploying WSO2 Identity Server
The next step is deploying WSO2 Identity Server. First, deploy the volumes and create a service account.
kubectl create serviceaccount wso2svc-account kubectl create -f is/volumes/persistent-volumes.yaml kubectl create -f is/identity-server-volume-claims.yaml
Then apply the configMaps with all the customized configurations for Kubernetes.
kubectl create configmap identity-server-conf --from-file=is/confs/ kubectl create configmap identity-server-conf-axis2 --from-file=is/confs/axis2/ kubectl create configmap identity-server-conf-datasources --from-file=is/confs/datasources/ kubectl create configmap identity-server-conf-identity --from-file=is/confs/identity/
Then apply the deployment and the service for exposing WSO2 Identity Server for internal access.
kubectl create -f is/identity-server-deployment.yaml
Wait until the server is up and running. You may check the logs of the WSO2 Identity Server POD in order to determine whether the server is up and running.
Once the server is up and running you can deploy the service description and ingress controller.
kubectl create -f is/identity-server-service.yaml kubectl create -f is/ingresses/identity-server-ingress.yaml
The final step of the deployment is updating DNS entry for the WSO2 Identity Server hostname. In order to get the IP address for the hostname, issue the following command and get the Mini Kube IP.
Then update your /etc/hosts entry with the following entry with the IP address you received in the previous step.
When you are ready to tear down the setup, issue the following commands in the order.
kubectl delete -f is/identity-server-volume-claims.yaml kubectl delete -f is/volumes/persistent-volumes.yaml kubectl delete -f is/identity-server-service.yaml kubectl delete -f is/identity-server-deployment.yaml kubectl delete -f is/extras/rdbms/mysql/mysql-service.yaml kubectl delete -f is/extras/rdbms/mysql/mysql-deployment.yaml kubectl delete -f is/extras/rdbms/mysql/mysql-persistent-volume-claim.yaml kubectl delete -f is/extras/rdbms/volumes/persistent-volumes.yaml kubectl delete -f is/ingresses/identity-server-ingress.yaml kubectl delete serviceaccount wso2svc-account
In this guide, we have looked at how WSO2 Identity Server can be deployed in a Mini Kube environment. Learn more about WSO2 Identity Server here.