Jenkins Shared Libraries — Continuous Integration in Kubernetes

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:

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

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

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

If it’s not configured to 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:

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:

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:

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:

And for our helmfile.yaml:

Our structure would be like this:

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:

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

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

And do a port-forward:

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:

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:

All the files used in this article are on my GitHub.

Guys, thanks some much for reading this article. If you want to connect with me here is my In.

Anyway, thanks so much for reading this!

See ya!

This is just a bit of my life. Writing another line everyday!