Install the GitLab service in a cloud-native way

using flux V2 Helm operator.

For this example, I’ll use the AWS eks cluster as I cannot meet the below requirements for GitLab service in my local.

A Kubernetes cluster, version 1.13 or higher. 8vCPU and 30GB of RAM is recommended

However, if you have enough resources and you are more interested in trying this out in the local environment. Please follow my previous article here to set up the local environment first.

Terraform GitOps pipeline for Kubernetes with Flux V2

Also, I’ll just use eksctl to quickly create a cluster with flux v2 for this example. If you are interested in terraforming properAWS EKS clusters with GitOps pipeline, you can refer to my previous article here for all required scripts and a detailed guide.

AWS EKS with Terraform + GITOPS

Create cluster

eksctl create cluster --name gitlab-demo --nodes=3

This will take a couple of minutes to complete. Once done you can check the nodes and pod status.

Install Flux

eksctl enable flux --config-file flux-config.yaml

flux-config.yaml file

Note: make sure you replace the owner and authTokenPath params with your github username and token path.

Once done we can see flux-system components are running in the cluster.

Now we are ready to Install apps to our cluster in GitOps way.

Before we install any apps to our cluster let’s understand how flux works.

Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy.

In this guide, we mainly focus on Helm Operator, which allows to declaratively manage Helm chart releases. The desired state of the Helm release is defined through a Custom resource namely HelmRelease . Based on the state of the HelmRelease resource in the cluster. Helm operator performs the required Helm actions.

Hope you get the basic idea about how Helm operator works in flux context.

As we bootstrapped demo-gitlab cluster with fluxv2-bootstrap-demo Git repo. We just need to commit the required HelmReleasemanifests files to the repo. Flux operators in the cluster will make sure to sync the repo state with the cluster.

lkravi/fluxv2-bootstrap-demo

Let’s create a new folder under gitlab-demo and put our GitLab manifest files to it.

repo.yaml file

Commit the changes to the main branch and experience the magic 😇. After few seconds you can see it’s starting deploying all GitLab components to the gitlab namespace we just added.

We can confirm that our Helm chart successfully installs all the components described in the GitLab Documentation.

Retrieve LB address

kubectl get ingress -lrelease=gitlab -n gitlab

As you can remember I have provided gitlab.lkravi.me domain name as my global host domain for GitLab when I commit my Helm Release to flux repo.

Now I just need to set A record for *.gitlab.lkravi.me to route my traffic to the LB address I have retrieved in the previous step.

Furthermore, I have provisioned Public SSL/TLS certificates through AWS Certificate Manager.

Almost ready! Let’s try to load the URL

To collect the password for root user run following command

kubectl get secret gitlab-gitlab-initial-root-password -n gitlab -ojsonpath='{.data.password}' | base64 --decode ; echo

Now you know the password and you can sign in as a root user.

Don’t forget to clean up your AWS resource.

eksctl delete cluster --name=gitlab-demo

References:

GitLab Install guide: https://docs.gitlab.com/charts/quickstart/index.html
Flux: https://fluxcd.io/docs/

lkravi - Overview