CI/CD on Kubernetes with GitLab

What is CI/CD?

• Continuous Integration: It is the practice of collaboratively working on a project using a source code manager where all of the changes made to the code base are validated by creating a build and running automated tests against the build. This helps the team in avoiding the integration hell which refers to everyone merging their changes into the release branch together before the release day.

• Continuous Delivery: It refers to having an automated release process to complement the automated testing provided by Continuous Integration acting as an extension of continuous integration and improving your release rate in a sustainable way.

• Continuous Deployment: It takes above practice one step further and basically refers to releasing all the changes that passed all stages of the complete pipeline for all of the environments to the end users/customers.

Integrating Kubernetes with Gitlab:

1. Go to your **Project **-> Operations -> Kubernetes

Note: You would require Maintainer permissions to access above page.

2. Once there, go to Add Kubernetes cluster -> Add an existing Kubernetes cluster and provide the details :

• Kubernetes cluster name (required): The name for for the cluster identification in Gitlab.

• Environment scope (required): The specific environment you want to use this cluster for.

• API URL (required): The URL at which the Kubernetes Master is accessible. e.g., *https://kubernetes.example.com instead of https://kubernetes.example.com/api/v1.*

• CA certificate (optional): Here, you’ll need to add contents of the “CA certificate” in case a self-signed TLS certificate is used for the cluster.

• Token: A service token through which GitLab can authenticate against Kubernetes. Make sure that the specified service token are scoped to a particular namespace. Follow the Kubernetes documentation to create one. You can also view or create service tokens in the Kubernetes using the Kubernetes dashboard (under Config -> Secrets).

**Note: **Make sure that the service token have admin privileges on the cluster.

• Project namespace (optional): A predefined namespace can be provide if no namespace is provided then a new namespace will be created by GitLab for you.

3. Once done, click the Create Kubernetes cluster button to finish the integration.

It will take a couple of minutes, and then your cluster will be ready to go.

Few considerations for choosing the namespace:

• It is recommended to have a unique namespace per project.

• The default namespace should be avoided and not used.

• In case you’re using a secret with broader permissions the project namespace need not to be the namespace of the secret.

• The secret’s namespace and project namespace can be same if the secret was created by yourself or someone else specifically for the project.

Enabling or disabling the Kubernetes cluster integration

Once you have successfully added your cluster information, to control the Kubernetes cluster integration:

• Click the Enabled/Disabled switch

• Click Save for the changes to take effect

Now you can start using the Kubernetes cluster for deployments.

Note: You can use the same procedure to disable the Kubernetes cluster integration.

Install GitLab runner on the Kubernetes Cluster(optional)

To fully configure CI/CD on the newly integrated Kubernetes Cluster we will now have to add a GitLab CI/CD runner to the cluster which will be responsible for handling the project pipeline. Steps:

1. Go to your **Project **-> Settings -> CI/CD

Note: You would require Maintainer permissions to access above page.

2. Once there, go to Runners -> Specific Runners -> Set up a specific Runner automatically

3. Click on Install Runner on Kubernetes and then select the previously integrated Kubernetes cluster.

4. Click on Install for Helm Tiller. Once done then click on Install for GitLab Runner

Now that you have your GitLab Runner installed, you can successfully use your Kubernetes cluster to build and deploy your project as per a specified GitLab config.

Create and Add the GitLab config

Create a file name called .gitlab-ci.yaml ****and add it your project. A GitLab config defines your project CI/CD pipeline and helps the Runners to understand your build, test and deploy structure.

A sample GitLab config for a Go project:

More examples can be found at:

https://gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/gitlab/ci/templates

To view your CI/CD pipeline :

1. Go to your **Project **-> CI/CD -> Pipelines

Now you can see all the builds for the pipeline listed under All, with different columns such as Status, Pipeline, Commit, and Stages.

You can modify other settings of the CI/CD setup to match your requirement under your **Project **-> Settings -> CI/CD

Now you can go ahead start adding your changes to your project and based on your configuration those changes will be build, tested and delivered/deployed accordingly.

---