Intended audience

sysadm staff members

Gitlab installation#

The deployment of the gitlab instances is managed by:
  • terraform for the the infrastructure part

  • ArgoCd for the Gitlab deployment

Each deployment relies on a dedicated AKS instance and a dedicated blob storage.


The terraform code is deploying and configuring a full, dedicated Azure Kubernetes Service matching this environment:

Gitlab Infrastructure


The output of terraform displays all the necessary information to connect to the kubernetes. It’s also possible to get the information by executing those commands:

terraform output gitlab-<instance>_aks_summary
terraform output --raw gitlab-<instance>_storage_summary

Once the infrastructure is created and available, Gitlab is deployed by ArgoCD. It’s done by deploying the Gitlab Operator and a gitlab configuration (for example, the staging configuration ).

A couple of other components are also deployed in parallel to manage the monitoring, an additional ingress controller and cert-manager. The applications are available in the k8s-clusters-conf repository.

Important components#

  • The gitlab transactional data is stored on a couple of kubernetes PVs associated to their relative Azure volumes

kubectl -n gitlab-system get pv                                                                                                                                                                                                                                  17:36:19
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                                                                               STORAGECLASS   REASON   AGE
pvc-38afb357-36e4-4661-9be6-011f58a24c95   64Gi       RWO            Retain           Bound    gitlab-system/repo-data-gitlab-gitaly-0                                                                             default                 20d
pvc-46544290-0278-4b41-b616-7466cd5140f9   8Gi        RWO            Retain           Bound    gitlab-system/data-gitlab-postgresql-0                                                                              default                 20d
pvc-988b8047-2ac9-426b-8792-37d749141657   8Gi        RWO            Retain           Bound    gitlab-system/redis-data-gitlab-redis-master-0                                                                      default                 20d
pvc-c55bdefa-089b-4cda-b0d0-a1daafb6f37f   16Gi       RWO            Retain           Bound    monitoring/prometheus-gitlab-production-promethe-prometheus-db-prometheus-gitlab-production-promethe-prometheus-0   default                 19d

By default, the operator use a Delete reclaim policy which is risky. After the initial installation, it was manually changed to switch to a Retain policy

  • The gitlab assets (attachments, container registry data, …) are stored in a dedicated object storage account


<Not yet available>


The backup will be stored on a minio instance installed on the Rocquencourt infrastructure. see #4645


An upgrade of gitlab is done in two major steps (always test in staging before upgrading the production environment)

It’s important to follow the operatore releases to not be more than 3 minor versions late, or the migration will not be supported be the operator.

> kubernetes logs gitlab-controller-manager-xxxx-xxxx
Configuration error detected: chart version 6.5.1 not supported; please use one of the following: 6.5.2, 6.4.4, 6.3.5

At this point, The gitlab operator is updated but the Gitlab upgrade itself is not yet started.

  • Step 2 Upgrade the gitlab version

    • Follow the recommended upgrade path depending of the current deployed version of the gitlab instance and the allowed versions of the operator

    • Update the chart version matching the desired gitlab version (should be present on the release page of the operator) in the gitlab resource declaration

    • Commit and push the change

    • Wait a couple of minutes to let ArgoCD applies the change

    • A upgrade of the gitlab services should happen and the launch of a migration pod should be done

    • After a couple of minutes (could be as long as an hour), the cluster should stabilize if everything is ok (no pending pods, no pods in error, …)

    • Check the deployed version and the operator logs to check if nothing is wrong

> kubectl -n gitlab-system get gitlab                                                                                                                                                                                                                          17:33:39
gitlab   Running   6.5.2