GitLab CI/CD for Kubernetes

In today’s world where organisations are growing rapidly continuous integration and continuous deployment has become an essential part of process to make latest version of software available to end users. CI/CD is an important part of software deployment process where it can help is maintaining deployment with minimal human efforts and help to boost the frequency.

CI (continuous integration) enables developers to push changes to there centralizes version control system where is it is being audit and tested by the predefined checks which can help to identify issues in early stages of development followed by the mitigation of those issues

CD (continuous Delivery) It picks the build where CI left it after successful completion (build and tested automatically). The CD deploy the build to the destination whether it is a legacy computes or containerisation environment.

There are plenty of tools available to help us in enabling CI/CD- Jenkins, Spinnaker, Azure Devops, Teamcity, Gitlab etc. In this post we are going to talk about GitLab CI/CD feature. Over the years, GitLab have been evolved multiple folds and from quite a sometime it is now providing CI/CD features. We will learn how to integrate Gitlab CI/CD.

There are three primary stages for it

1. Build
2. Test
3. Deploy

One can add more stages based on the application requirement.

##You can try to build as illustrated in example below.
# Build image
build:
image: docker:latest # preferred image based on requirement
stage: build
services:
  - docker:dind # to run docker in docker
variables:
name: test-image # image name or you can declare multiple varibales as per requirement
only: # which branch can trigger this job in pipeline
  - development
  - staging
  - uat
  - partial
  - production
script:
  - docker info
  - docker login - username $user_name $registry_name - password-stdin
  - docker build -t $name .
  - docker push $name

2. Quality assurance is the key which lowers the priority of failure occurrence. One can enable testing stage in pipeline, There are multiple option you can integrate sonar qube, code-quality (provided by gitlab), lighthousecli (in case of web base frontend release) and the unit test cases written based on your application specific requirement

lighthouse:
image: cypress/browsers:node16.14.2-slim-chrome103-ff102
  stage: test
  script:
      - npm install 
      - npm ci
      - ENV=production npm run build
      - npm install -g @lhci/cli@0.3.x
      - lhci autorun --upload.target=temporary-public-storage --collect.settings.chromeFlags="--no-sandbox" || echo "LHCI failed!"

# we will talk about enabling lighthouse cli in another blog with details

Unit_test: One can enable test cases bases of their preference or can use gitlab code quality.

Unittest:
 image: #in case you have build the image of you preferred tool to run test cases
 stage: test
 needs: [] # if you testcases need to run after some specific job
 script:
      - #set of commands to connect to your own setup or to spawn container

3. This step require to establish connection first with you deployment destination. We will connect k8s to gitlab repo

• To connect kubernetes cluster to your gitlab repository, First
• Create a config file inside requisite nested folders. The file can be empty if you want to connect to a single project only.

.gitlab/agents/<preferred name of agent>/config.yaml.

• Second, Go to operate > Kubernetes clusters | click on connect agent and select the agent name/file it will showcase you set of commands with access token which can be installed on you cluster using helm.
• In order to be able to use cluster across repositories or groups, make sure your cluster is connected in a project/group and shared across the hierarchy

Example for pipeline job:

#For allow sharing in sub groups
ci_access:
  groups:
     - id: your_group/your_sub_group
     - id: your_group/your_sub_group

#For allow sharing in projects
ci_access:
  Projects:
     - id: your_group/project_name
     - id: your_group/projectname

The last piece of the pipeline, is running set of instruction on k8s cluster to perform your you deployment or your desired option.

#Deploy
deploy:
  image:
    name: yourrepo/kubectl:latest
    entrypoint: ['']
  stage: deploy  
  needs:
    - job: lighthouse
      artifacts: false
    - job: test 
  script:
    - kubectl config get-contexts
    - kubectl config use-context $CONTEXT #cluster context to set the right cluster
    - kubectl set image deployment/$deployment_name $conatiner_name=$image_name -n $namespace
  
# this is just a basic set of commands you can test for specific senarios as per your application requirement

Source:

GitLab Documentation