CI/CD Implementation for a Simple Web Application Using Jenkins

Periyasamy Vellingirisamy
Apr 22, 2020

24.7k
0
3
- facebook
- twitter
- linkedIn
- Reddit
- WhatsApp
- Email
- Print
- Other Artcile

Introduction

This article explains how to implement CI/CD (Continues Integration and Continues Delivery) for a simple web application using Jenkins in the local machine. Here you can learn how to set up a deployment pipeline in Jenkins. Before moving on to this article, I would strongly recommend going through some basics of Docker and Kubernetes.

Key Goals

Once the source code is checked-in into the repository, GitHub WebHook notify to Jenkins.
Get the latest code from the GitHub repository.
After that, it will create docker image of the application and pushed into Docker Hub.
Pull the image from Docker Hub and deploy it into Kubernetes.

Prerequisites

GitHub installation on our local machine. - GitHub download
Docker installation and configuration. - Create a Docker image for a simple web application.
Kubernetes configuration. - Kubernetes configuration in a local machine
Jenkins installation. - Jenkins download

Typically, creating a simple pipeline has a few steps:

Source code integration with version control tools. In my case, I choose GitHub.
Creating a docker image.
Making availability of docker image in a central repository to deploy it in the cloud. In my case, I chose Docker Hub.
Deployment in Kubernetes.

Step 1

Let's start by getting the latest version of Jenkins from the above link and installing it. While installing Jenkins in your local machine it will also install the required plugins. There are a few configurations to be applied during installation, like (User creation, Plugin install). Please pay attention to that. Once the installation is successfully completed, we can navigate http://localhost:8080/ to access Jenkins. It looks like below in the local machine.

CI/CD Implementation For Simple Web Application Using Jenkins

Step 2

To set up a new pipeline, click New Item in the left menu, then select Pipeline and hit OK.

Step 3

Once you hit Ok, it will open deployment configuration wizard. There you can see a few sections like

General
Build Triggers
Advanced Project Options
Pipeline

In the General section, we need to provide a project description and select the GitHub Project option.

Step 4

Let's move on to another section called Build Trigger, the name itself states that various ways for triggering the build. Here, I am selecting "GitHub hook trigger for GITScm polling". This means when the user check-in the code into the GitHub repository, GitHub WebHook will notify the Jenkins server.

Step 5

Next, in the Pipeline section, we can see two options below:

Pipeline Script

Pipeline Script from SCM

Pipeline Script

If we choose a pipeline script, here we can write our Groovy script for the pipeline steps. However, this process is not recommended due to a loss of configuration while the Jenkins server is down or crashed. Therefore, I am choosing the second option, Pipeline script from SCM, then providing a few inputs like below.

Note

We should not specify any credentials directly. Instead, we can add it in the Jenkins server itself by clicking the Credentials option. There are various types to create credentials.

I chose:

GitHubCredentials - Using a username and password option.
DockerPassoword - Using a secret text option.

Step 6

Next, let's visit the project structure and its configuration.

Here, you can see the four files that must be placed on this location. If you want, you can change the location, but you need to change the configuration as well. So let's follow the default.

Demo.sln - Solution file of our project.

Dockerfile - Here we write the necessary steps for building a docker image of our application.

JenkinsFile - It consists of pipeline steps.

deployment-service.yaml - This file has a Kubernetes deployment configuration.

Step 7

We discussed more about these two files (DockerFile and deployment-service.yaml) in my previous articles. Also, you can refer to the below links:

So, let's move on with Jenkins file. Please refer Jenkins stage reference link for more detail. Now let's go with our actual implementation of JenkinsFile. There are various stages to complete our pipeline.

For more details about the below script, sign in to the configured GitHub repository and get the latest code. Next, it will build the docker image of that application and push it into DockerHub. After that, it will deploy the docker image into the Kubernetes cluster. The Kubernetes deployment YAML file will get the latest image from DockerHub and deploy the latest one.

In the Github Checkout stage, you can see some syntax. Don't worry, Jenkins provides an option to create pipeline syntax. Click on Pipeline Syntax and create it.

For GitHub syntax:

For pushing a Docker Image into Docker Hub, It is required credentials to access the particular repository of the docker hub. To do that, you can generate a script like below.

Step 8

Awesome! That's it. We have almost completed our settings. Now click the Save button at bottom of the configuration page. You will see the pipeline dashboard like below.

Step 9

Now click Build Now option, Make sure your local Kubernetes cluster is in a running state. Once the deployment has completed successfully, you can see light green color filled against the corresponding build no.

Note

As we know, Jenkins is running in our local machine and I mentioned that we are doing an experiment in the local system. You may wonder why do we need to trigger the Build Now option manually? Whenever we check in the code, the build should be triggered automatically right?" The issue is that we cannot configure http://localhost:8080/ with Online GitHub WebHook Server, so we perform this action manually.

Step 10

Now you can navigate to your Kubernetes dashboard and check out the pods and navigate to the application URL. There you can see your latest changes deployed in the server.

Step 11

If you are facing any issue while deploying any stage, please click the console output of the corresponding build number in the build history tab. There you can find some logs.