An analysis of a Proof of Concept (PoC) Java application which deploys the WSO2 Carbon 5 kernel in Docker Containers with the support of orchestration capabilities of Google Kubernetes

In this post, I have chosen to provide an analysis of a Proof of Concept (PoC) Java application which is capable of deploying a sample version of the WSO2 Carbon 5 kernel in Docker Containers with the help of Docker Container orchestration capabilities of Google Kubernetes. This post may not contain detailed analysis of all the Docker and Google Kubernetes concepts utilized but I intend to make future posts which may cover advanced details related to these concepts. 

Following are the basic functionalities, I have added to the application:

• Deploy a tenant-specified number of Docker Container instances (inside Kubernetes Pods) with the WSO2 Carbon kernel running inside, each of them.
• Scale the number of Docker Container instances (inside Kubernetes Pods) running during the application run time.
• Make a rolling update to a currently deployed version of the Carbon kernel with an updated version of the Carbon kernel.
• Roll back to an older build version of the currently deployed version of the Carbon kernel.
• Remove a currently deployed tenant specific set of Docker Container instances.

Note: In this application, a particular tenant (user) can have only a single set of Docker instances  (with Carbon kernel deployed) running during the application run time. The tenant can make a rolling update to deploy an updated kernel version.

You can use this GitHub link to check the Java implementation of these functionalities and the instructions to run this application has been provided in the README.md file in the repository. In addition, I have added the sample wso2carbon-kernel-5.0.0-SNAPSHOT.zip file to the following GitHub link.

When analyzing the application implementation, the Docker and Kubernetes concepts have been used as follows:

• The tenant has to provide the Carbon kernel zip file which will be deployed. 
• Initially, the application will generate a Dockerfile which provides instructions to deploy the kernel zip and run the bin/wso2server.sh file at the initiation of each Docker Container.
• Build up a Docker Image using the Dockerfile generated.   
• Google Kubernetes Replication Controller concept has been used to generate the tenant specified number of Pods, where each pod contains one running Docker Container instance of the above generated Docker Image.
• During scaling, the Replication Controller is updated with the new number of replicas. Depending on the updated value, new replicas are added to the existing number of Pods to meet the new value (if the updated value is higher than the previous) or existing Pods are deleted to meet the new value (if the updated value is lower than the previous)
• During a rolling update, it is first checked if the specified tenant has an already running set of Container instances and if yes, a new Docker Image will be built as in the case of deployment operation and that particular Image will be updated in the already running Replication Controller. The currently running Pods will be deleted (since they are running the previous Docker Image) in order to make way for the Replication Controller to spring up new Pods with the updated Docker Image. If not deployed, the tenant is requested to deploy the kernel before making a rolling update. 
• During a rollback operation, a similar procedure to that of a rolling update is carried out from the point of updating the Replication Controller, with the only difference being that the tenant has to choose the new Docker Image from existing Docker Images (previous build versions of the kernel from the same tenant) before the Replication Controller is updated.

Note: 

• This application has been well tested in Ubuntu 14.04.3 LTS OS trusty version and has not  yet been tested in any other platform. 
• Except for minor bugs in relation with file permissions which have not yet been fixed, this application performs the basic functionalities mentioned above quite convincingly.
• I have used spotify/docker-client as the Docker Remote API, fabric8's Kubernetes API and Apache Stratos' Kubernetes client for Kubernetes operations in the Java code.

I expect to spend further time on fixing existing bugs and carrying out further testing in the future. Any comments, suggestions and help with regards to this application and related topics are highly appreciated.