This time we are going to explain you how the Kubernetes-CI Jenkins plugin works, taking advantage of containers and Kubernetes (K8s).

In summary, this plugin provides:

Jenkins slave lifecycle: it manages Jenkins slaves with Pod definitions into Kubernetes clusters. It is no longer necessary to have slaves deployed in advance, as the time it takes to deploy them using containers and Kubernetes is minimum.

Autodiscovery: here is a smooth integration between the plugin and K8s; if the Jenkins Master is deployed into a K8s cluster, the plugin discovers it and populates the cloud configuration for you. Moreover, a default Pod configuration and a default repository configuration pointing to Helm chart are also provided.

CI/CD pipeline: our vision is that charts are a key element to build them, so you can deploy and delete charts through build steps provided by the plugin.

As an ElasticKube believer, I’m going to use it in order to show how the things are going, but you can also use kubectl to do that.

Our starting point is a Kubernetes cluster up and running. Have a look at this doc in case you need help to create a cluster, but keep in mind that by using ElasticKube (Getting started), all the processes will be easier. Just by executing:

curl -s [https://elastickube.com](https://elasticbox.com/kubernetes/)| bash

EB1Jenkins

We are going to use the Jenkins chart provided by Helm in order to deploy our Jenkins Master into the Kubernetes cluster.

EB2Jenkins

Using ElasticKube you can configure the repository of your choice, and here we are pointing to a Helm repository fork, where we configured the Jenkins Chart with a fixed NodePort at 30800.

Let’s now deploy the Jenkins chart.

EB3Jenkins

When we click on play button, this is what you see:

EB4Jenkins

(We configured a new label called “jenkins-type”, with “master” as value).

Click on Deploy button.

EB5Jenkins

As you can see above, after a few seconds we find a new Jenkins service, a replication controller and the Pod that will be the Jenkins Master is still deploying. Again, using kubectl, you will be able to see the same in the command line. Eventually, the Pod finishes to deploy:

EB6Jenkins

Now, we will be able to access to our Jenkins service through 30800 port:

EB7Jenkins

To continue, we will go to Manage Jenkins area and we are going to install our Kubernetes-CI plugin.

EB8Jenkins

Below, this is how Jenkins installs the plugin and restarts.

EB9Jenkins

EB10Jenkins

Once the restarting has been completed if we go again to the Manage Jenkins area and in the system configuration page, you will find how the plugin has auto-discovered the Kubernetes Cloud Configurations for you.

Also, note that you will find the previously mentioned default Pod and charts repository configurations.

EB11Jenkins

Now that we have everything we need, we will create our Jenkins jobs. Once you have created it, if you go to Build Steps area, you will be able to deploy the Charts from the repository that you have configured in the Cloud configuration.

EB12Jenkins

Once you click on Kubernetes-Deploy Chart, you have to configure the proper Build step. In this case, we will deploy a rabbitmq chart:

EB13Jenkins

Once we have completed the Build Step, we can enqueue a new build. To run a build, Jenkins will provision a new Jenkins slave. In the following steps you will see how this new slave is provisioned and executes the Build.

EB14Jenkins

As a result of the Build, you will be able to see how the rabbitmq has been deployed in the Kubernetes cluster. Note how the new slave has been provisioned first.

EB15Jenkins

Once the slave is up and running it executes the rabbitmq chart deployment in Kubernetes.

EB16Jenkins

The build finishes removing the slave, as well as the rabbitmq chart as we have configured it in the build step.

You can check both components have been deleted in the ElasticKube instances screen, as it is also stated in the Jenkins Console, where you can see the Output of the job execution:

EB17Jenkins

Want to Learn More About Cloud Application Manager and ElasticKube?

Cloud Application Manager is a powerful, scalable platform for deploying applications into production across any cloud infrastructure – private, public or hosted. It provides interactive visualization to automate application provisioning, including configuration, deployment, scaling, updating and migration of applications in real-time. Offering two approaches to cloud orchestration — Cloud Application Manager and ElasticKube — enterprise IT and developers alike can benefit from multi-cloud flexibility.

Visit the Cloud Application Manager product page to learn more or contact us for a no-obligation, custom consultation.