CI CD pipeline.

Goal:

The goal was to implement continuous integration and continuous deployment (CI-CD) for the application.

Steps:

We created CI-CD for our project using Jenkins. The steps involved are as follows:

1. Jenkins will poll any changes pushed in the git repository of the specific branches.
2. If it finds a push, it builds the image locally.
3. It then logins to the docker hub and pushes the newly built image.
4. It then login's to Kubernetes master and restarts the service which was recently updated.
5. It logs out of the Kubernetes master.
6. It logs out of the docker hub.

About the JenkinsFile:

The JenkinsFile is functional and is monitored for each branch in the application. All the JenkinsFile can be found in branch: ci-cd-setup

Stages in JenkinsFile:

Note: the sh are the shell script commands.

stage('Initialize') {
            steps {
                script {
                    properties([pipelineTriggers([pollSCM('* * * * *')])])
                }
                git branch: 'ci-cd-setup' , url: 'https://github.com/airavata-courses/terra.git'
            }
        }

This stage is the initializing stage. The Git repository will be monitored on the branch, ci-cs-setup. The JenkinsFile will scan for the recent pushes. Remember you can use this technique to trigger build after pushing in the repository instead of configuring WebHooks in the Git.

stage('Image Build') {
      steps {
        sh 'docker build -t gauti091/user-management:linux user.session.management/'
      }
    }

If in the previous stage, a push is detected, then, in this stage the image is built based on the recent code changes. The image will be built locally and stored.

stage('Docker Login') {
      steps {
        sh 'echo $DOCKERHUB_CREDENTIALS_PSW | docker login -u $DOCKERHUB_CREDENTIALS_USR --password-stdin'
      }
    }

In this stage, Jenkins will try to log in to the docker hub account. The DockerHub credentials should be stored in the 'Manage Credentials'.

stage('Docker Push') {
      steps {
        sh 'docker push gauti091/user-management:linux'
      }
    }

In this stage, the image built-in stage 2, which was stored locally will be pushed in the docker hub account which was logged in the previous step.

stage('Deploy image'){
         steps{
            sshagent(credentials:['kuber-root-some1']){
              sh """ssh -tt [email protected] -o "StrictHostKeyChecking no"  << EOF
                   whoami
                   kubectl get pods
                   kubectl rollout restart deployment/service-sql
                   pwd
                   ls
                   exit
                   EOF"""
          }

This is an important stage. In this Jenkins will login to the Kubernetes master system and restart the pod. The Kubernetes will pull the recent code changes and deploy the pod. Remember here to generate the ssh-keys. The 'public key' should be copied into the remote server(Here, Kubernetes), and the private key must be stored in authorized_keys of the Jenkins System/Client machine.

post {
    always {
      sh 'docker logout'
    }

With this, Jenkins will log out of the docker hub.
Note: the sh are the shell script commands.

Challenges might be faced:

Public Key(Denied)
It is because either the public key is not properly added to the remote server authorized_keys or the private key local server authorized_keys

Multi branch pipeline vs Pipeline:

If you want the code to be built after a push event trigger in multiple branches then, Multi-branch pipeline would be beneficial. You can store the JenkinsFile in one branch which will monitor another branch then the build will be triggered by two branches. In a multi-branch pipeline, you need to store JenkinsFile in a branch and provide the path while configuring.

Jenkins is not able to install

Install JDK first then Jenkins.