How to Build Kubernetes CI/CD Pipeline with GitLab

1. Introduction of Kubernetes
2. CI / CD Concept
3. The Flow of CI / CD
4. Building a CI/CD Pipeline using GitLab
5. Code

Introduction of Kubernetes

Kubernetes is an open-source framework for managing workloads and services that allows for declarative configuration and automation. In addition, it has a comprehensive and quickly expanding ecosystem. As a result, services, support, and tools for Kubernetes are widely available.

When the programmer deploys Kubernetes, it gives a cluster. A cluster is a collection of worker machines known as nodes that run containerized apps. Each cluster contains at least one worker node. The worker node(s) host the Pods that make up the application workload. The control plane supervises the clusters worker nodes and Pods. In production situations, the control plane distributes across many computers, and a cluster is distributed across numerous nodes to provide fault tolerance and high availability.

CI / CD Concept

CI/CD is a word that is frequently come across in conjunction with other terms such as DevOps, Agile, Scrum, Kanban, and automation. It regards a necessary aspect of the process without a thorough grasp of what it is.

Continuous Integration (CI)

The initial step does not involve quality assurance (QA). In other words, it is unconcerned whether or not the code fulfills the functionalities required by the customer. It instead assures that the code is of high quality. Developers are instantly aware of any concerns with code quality via unit and integration tests.

Continuous Delivery (CD)

1.     User Acceptance Testing (UAT)

UAT is the first step in the CD production process. During this phase, automated tests are run on the code to confirm that it satisfies the client’s expectations. For example, a web application may function appropriately without error. However, the client wants the visitor to arrive at a landing page before proceeding to the main page. The present code directs the user to the main page, contrary to the client’s wishes. The UAT testing identifies this type of issue.

2.     Deployment

It is the second stage of the CD creation process. It entails updating the servers/pods/containers that host the application to reflect the revised version. Again, this should be done automatically, preferably with the help of a configuration management tool like Ansible, Chef, or Puppet.

The Flow of CI / CD

Continuous Integration/Continuous Delivery and Deployment is abbreviated as CI/CD. When developing a new software product, a team that does not use CI/CD must go through the following stages:

The product manager (representing the client’s interests) specifies the product’s characteristics and the behavior that it must exhibit. Therefore, the documentation must be as detailed and precise as feasible.

The developers begin working on the program with the business analysts by writing code, performing unit tests, and binding the results to a version control system (for example, git).

The project is moved to QA after the development phase completes. Several tests take place on the product, including User Acceptance Tests, Integration Tests, and Performance Tests. There should be no variations to the code base during that time till the QA process completes. If bugs occur, developers fix them and push changes to QA for testing.

Building a CI/CD Pipeline using GitLab

GitLab, like Github, is a Git-based platform that offers a variety of tools and technologies for various stages of the SDLC.

It is straightforward to create a Gitlab account. Go to this link, establish an account, or sign in with Google or GitHub. When the user signs in, the user redirects to the homepage to explore various choices, such as creating a new project.

To create a new project on Gitlab, follow these steps:

Gitlab takes the user to a form where you may fill up the specifics of your project, such as the title and description.

To clone the project, click “clone” and copy the HTTPS URL. To clone the project into your local system, open a terminal or command line and type the following command:

git clone <https clone URL>

Now that the project is on the local system, the user may begin constructing the CI/CD pipeline and deploying it to Gitlab via Gitlab-ci.

Users can configure GitLab CI/CD by generating a file called GitLab-ci.yml in the project’s root directory. This file is written in YAML, a simple and easy-to-use language.

When there is a modification to the code in the repository, Gitlab produces a pipeline that runs. These pipelines can contain single or numerous phases that run sequentially (in series). Each stage can have numerous jobs that are done in parallel by the GitLab-runner.

Code

In the repository, create a Python script called test.py and add the following lines of code to it. An example of how to design and execute pipelines provides below.

if __name__ == '__main__':
  print('hello world')
  for i in range(5):
    print('testing', i)

Predefined CI/CD variables in.gitlab-ci.yml may use without previously declaring them.

test_variable:
  stage: test
  script:
    - echo "$CI_JOB_STAGE"

The script prints the test variable’s stage, which is a test:

The stages section defines a list of pipeline phases. Because these processes carry one after the other, it is critical to sequence them following their dependencies. The script tag specifies a shell script or commands that the runner runs. For example, the echo command can print something on the terminal, and the cat command can display the contents of the Python script.

variables:
  example: this is an example variable
stages:
  - stage1
  - stage2
build:
  stage: stage1
  script:
    - echo "We are currently in stage 1"
    - echo "These are the contents of test.py"
    - cat test.py
    - echo $example
test:
  stage: stage2
  script:
    - echo "We are currently in stage 2"
    - echo "running python script"
    - python3 test.py
git add -A
git commit -m "initial commit"
git push origin master

When the user enters the correct username and password, the changes push to the repository. Gitlab instantaneously runs the code in the.GitLab-ci file by constructing a pipeline. To examine a list of pipelines, go to the CI/CD section on the left navbar. The recent is at the top and has the tag “latest.” It also indicates whether the pipeline succeeded or failed. To observe the phases of the pipeline and all the done processes, click on “passed” or “failed.” It displays the several stages and the status, indicating whether or not each stage completes.