Configuring Redis, PostgreSQL, and Account Credentials#

This document describes how to configure the credentials required for GitLab instances.

#Prerequisites

• This document applies to GitLab 17 and above versions provided by the platform. It is decoupled from the platform based on technologies such as Operator.

#Redis Credentials

#Requirements

GitLab has the following requirements for Redis deployment mode and version:

• Deployment modes support both Standalone and Sentinel modes, but Redis Cluster mode is not supported
• Redis version 6.2 or above is required

#Credential Format

Create a Secret in the namespace where the GitLab instance is planned to be deployed, select the Opaque type, and add and fill in the following fields in the configuration:

Standalone Example

apiVersion: v1
data:
  host: <base64 encode host>
  password: <base64 encode password>
  port: <base64 encode port>
kind: Secret
metadata:
  name: gitlab-redis
  namespace: <ns-of-gitlab-instance>
type: Opaque

Sentinel Example

apiVersion: v1
data:
  password: <base64 encode password>
  address: <base64 encode address>
  masterName: <base64 encode masterName>
  sentinelPassword: <base64 encode sentinelPassword>
kind: Secret
metadata:
  name: gitlab-redis
  namespace: <ns-of-gitlab-instance>
type: Opaque

#Updating Credentials

If you want to modify Redis connection information after deploying a GitLab instance, you need to directly update the GitLab instance resource, rather than modifying the credential content. For specific operations, please refer to Configuring Redis Access Credentials.

#Using Alauda Cache Service for Redis OSS

Redis service can be provided through Alauda Cache Service for Redis OSS, please consider the following important requirements:

• Choose Redis version 7.2 or above
• Select sentinel mode for architecture type
• Choose RDB persistence template for parameter template, such as system-rdb-redis-7.2-sentinel
• Enable data persistence with storage quota not less than 2G
• In multi-network card scenarios, Redis sentinel will select the default IP of the node to initialize the access address of each Redis node, therefore it does not support accessing nodes with non-default IP + exposed port. In this case, it is recommended to use the LoadBalancer access method to create Redis instances. For more details, please refer to the Alauda Cache Service for Redis OSS feature description documentation.

When creating a Redis instance, a Secret containing connection information is automatically generated, which can be used directly to deploy GitLab. This Secret resource can be filtered using the label middleware.instance/type: Redis.

kubectl get secret -n <ns-of-redis-instance> -l middleware.instance/type=Redis

Using Alauda Cache Service for Redis OSS

Redis service can be provided by Alauda Cache Service for Redis OSS. In some special scenarios, some restrictions need to be noted.

• In multi-nic scenarios, Redis sentinels will choose the default IP of the node to initialize the access address of each Redis node, so it does not support accessing the node's non-default IP + exposed port. In this case, it is recommended to use LoadBalancer access method to create Redis instances. For more details, please refer to the Alauda Cache Service for Redis OSS feature description document.

#PostgreSQL Credentials

#Requirements

GitLab has the following requirements for PostgreSQL versions:

• GitLab 17.x requires PostgreSQL version 14.x
• GitLab 18.x requires PostgreSQL version 16.x

#Credential Format

Create a Secret in the namespace where the GitLab instance is planned to be deployed, select the Opaque type, and add and fill in the following fields in the configuration:

YAML example:

apiVersion: v1
data:
  database: <base64 encode database name>
  host: <base64 encode host>
  password: <base64 encode password>
  port: <base64 encode port>
  username: <base64 encode username>
  sslmode: <base64 encode sslmode>
kind: Secret
metadata:
  name: gitlab-pg
  namespace: <ns-of-gitlab-instance>
type: Opaque

How to create a database on a PG instance

Connect to the PG instance using the psql cli and execute the following command to create a database

create database <database name>;

Creating a separate database for gitaly cluster

In high availability mode, the gitaly component needs to be configured in cluster mode and requires a separate database to store gitaly metadata. You need to create another Secret to store the database connection information, with fields consistent with those described above.

#sslmode

sslmode is a parameter that controls the security of the connection between the Gitlab service and the PostgreSQL database. Available options:

• enable: Enable SSL connection
• disable: Disable SSL connection

When you use Alauda support for PostgreSQL, the sslmode should be set to enable.
When you use external PostgreSQL, the sslmode is depends on your PostgreSQL configuration.

#Updating Credentials

If you want to modify PostgreSQL connection information after deploying a GitLab instance, you need to directly update the GitLab instance resource, rather than modifying the credential content. For specific operations, please refer to Configure PostgreSQL Credentials.

#Using PostgreSQL Provided by Data Services

Data Services supports deploying PostgreSQL instances that can be used for GitLab deployment. When creating a PostgreSQL instance, please consider the following important requirements:

1. Choose a PostgreSQL version that matches your GitLab version, for example, when deploying GitLab 17.x, you need to select PostgreSQL 14.x
2. Storage quota should not be less than 5Gi

When creating a PostgreSQL instance, a Secret containing connection information is automatically generated. This Secret resource can be filtered using the label middleware.instance/type: PostgreSQL.

kubectl get secret -n <ns-of-postgresql-instance> -l middleware.instance/type=PostgreSQL | grep -E '^postgres'

#GitLab Account Credentials

Create a Secret in the namespace where the GitLab instance is planned to be deployed, select the Opaque type, and add and fill in the following fields in the configuration:

apiVersion: v1
data:
  password: <base64 encode password>
kind: Secret
metadata:
  name: gitlab-root-password
  namespace: <ns-of-gitlab-instance>
type: Opaque