Jenkins Shared Libraries — Continuous Integration in Kubernetes

6 min readApr 16, 2020

Hi guys, how are you? Hope you're all doing fine!

Today we will talk a little about Jenkins. Specifically about Jenkins Shared Libraries, which are a functionally of Jenkins we could use to make a better pipelines and integrate, with less difficulty, other software in our deployment.

In this article we will setup a simple Kubernetes cluster using Minikube, then we will install a Jenkins Server, using Helmfile and we will learn to integrate it with GitHub, build an image and push to a registry.

What are Jenkins Shared Libraries?

JSL is the concept of having a common code in your pipeline, which could be distributed in several applications yet, being versioned and referenced. Let’s assume you have to take responsibility for multiple applications, some of them are NodeJS, others are Python, or Maven even. It would be catastrophic to manage all of their pipelines, and integrations, coverage tests or even security issues.

Now, with JSL you could segregate different components of your pipeline, which are called Libraries. They stay in a remote repository, being versioned, under your control. Every time you wish to add another test, or integrate another software, just create a new Library to to this.

By now I believe you got the intention of JSL. So, let’s get our hands dirty.

Set our cluster Up!

We are going to use Minikube. If you don’t know how to install it, there are other articles where I teach you how to do it, but just in case, check the official documentation.

After you’ve installed it, just run:

minikube start

If you are on Windows, you may want to use Hyper-V:

minikube start --vm-driver=hyperv

And if you want a better VM, use the values you need:

minikube start --cpus=4 --memory=8000mb

Ok, with our cluster up, let’s check the command line:

kubectl version
kubectl get ns

If it’s not configured to minikube:

kubectl config get-contexts
kubectl config set-context minikube

Great, let’s install Helm:

Check the official documentation and install accordingly. Put it on your $PATH and make sure to init in your cluster:

helm version
helm init
kubectl get pods -n kube-system|grep tiller

In this article we’ll use Helm v2, because v3 it’s kinda buggy still.

Now, let us install Helmfile. Download it from the releases and put in $PATH and run:

helmfile -v

Don’t forget to rename the binary to helmfile if you need it.

With Helmfile we can integrate multiple Helm Values’ files into a single file and run a single command to sync everything with our cluster.

First, we’ll create our repository:

mkdir JSL-K8s_Pipeline
git init
hub create

If you don’t know what hub is, go check out this article of mine.

To install Jenkins, we are simply going to use this file:

gist for jenkins helmfile

And for our helmfile.yaml:

helmfiles:- "releases/jenkins.yaml"

Our structure would be like this:

tree
.
├── helmfile.yaml
└── releases
    └── jenkins.yaml

1 directory, 2 files

Why are we doing like this? Well, imagine if you have multiple platforms and software to manage, this would make things easier for you.

Now, we install the Jenkins using Helmfile in the directory of helmfile.yaml:

helm repo update
helmfile sync

If you desire to change something or delete it, make sure to run the following:

helm del --purge jenkins
kubectl delete ns jenkins

After the installation process, get the admin password by running:

kubectl get secret --namespace jenkins jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode

And do a port-forward:

kubectl --namespace jenkins port-forward <POD-NAME> 8080:8080

Access the http://localhost:8080 log in and you will see Jenkins:

If you used my Helmfile, you’ll see that we already have the necessary plugins installed. Also, you could take this as an example for your future projects!

Now, before we begin, let’s create a Docker Registry Repository:

And we configure Jenkins to use it on Manage Jenkins ->:

Don’t forget to add some credentials to your DockerHub:

And to use our GitHub Repository as well:

Now, let’s give our Jenkins the necessary permissions:

kubectl create serviceaccount jenkins
kubectl apply -f RoleBinding.yaml

And, inside our Jenkins we already got our Job created, thanks to Helmfile.

In our job configuration, it is set our remote repository for our code:

And this is just something for the real world. If you happen to be using a domain for your Jenkins, you could use web hooks. Just set this here:

And on your repository:

Ok, great. Now let’s go back to our project:

If you check our project configuration, there are already some parameters configured:

You could just use environment variables, that is just a choice of mine.

And all we had to do in our Pipeline was to configure the Jenkinsfile:

After that, just hit the Play button and wait to see your image pushed to your DockerHub repository.

Let’s take a quick look at our Job. This is our Jenkinsfile:

In here, we are considering the parameters we set in the job configuration and passing it to a Jenkins Shared Library called jobsMedium . In this library we have:

We have some container definition. A node container, to run our App. A docker container, to build and push our image. A jnlp container, that is our agent container.

Then we have a definition to our Registry, using our credentials. And for last our PodTemplate . This is the most important step. We have to define a PodTemplate for Jenkins work within its agents. This will take, some containers, and our service account, that we created earlier.

Within this Pod Container we can define our steps using the images of the containers we defined before. Cool, right?

After the job ran we could see our image in our repository: