Настройка Redis, PostgreSQL и учетных данных аккаунта#

В этом документе описывается, как настроить учетные данные, необходимые для экземпляров GitLab.

#Предварительные требования

• Этот документ применяется к версиям GitLab 17 и выше, предоставляемым платформой. Он отделен от платформы и основан на таких технологиях, как Operator.

#Учетные данные Redis

#Требования

GitLab предъявляет следующие требования к режиму развертывания и версии Redis:

• Поддерживаются режимы развертывания Standalone и Sentinel, но режим Redis Cluster не поддерживается
• Требуется версия Redis 7.2 или выше

#Формат учетных данных

Создайте Secret в namespace, где планируется развертывание экземпляра GitLab, выберите тип Opaque и добавьте и заполните следующие поля в конфигурации:

Пример Standalone

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

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

#Обновление учетных данных

Если необходимо изменить информацию для подключения к Redis после развертывания экземпляра GitLab, нужно напрямую обновить ресурс экземпляра GitLab, а не изменять содержимое учетных данных. Для конкретных операций смотрите Configuring Redis Access Credentials.

#Использование Alauda Cache Service for Redis OSS

Сервис Redis может предоставляться через Alauda Cache Service for Redis OSS, обратите внимание на следующие важные требования:

• Выберите версию Redis 7.2 или выше
• Выберите режим sentinel для типа архитектуры
• Выберите шаблон параметров с RDB persistence, например system-rdb-redis-7.2-sentinel
• Включите сохранение данных с квотой хранилища не менее 2G
• В сценариях с несколькими сетевыми интерфейсами Redis sentinel выберет IP по умолчанию узла для инициализации адреса доступа каждого узла Redis, поэтому не поддерживается доступ к узлам с не-стандартным IP + открытым портом. В этом случае рекомендуется использовать метод доступа LoadBalancer для создания экземпляров Redis. Подробнее смотрите в документации по функционалу Alauda Cache Service for Redis OSS.

При создании экземпляра Redis автоматически создается Secret с информацией для подключения, который можно использовать напрямую для развертывания GitLab. Этот ресурс Secret можно отфильтровать по метке middleware.instance/type: Redis.

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

Использование Alauda Cache Service for Redis OSS

Сервис Redis может предоставляться через Alauda Cache Service for Redis OSS. В некоторых особых сценариях необходимо учитывать ограничения.

• В сценариях с несколькими сетевыми интерфейсами Redis sentinels выбирают IP по умолчанию узла для инициализации адреса доступа каждого узла Redis, поэтому не поддерживается доступ к не-стандартному IP узла + открытому порту. В этом случае рекомендуется использовать метод доступа LoadBalancer для создания экземпляров Redis. Подробнее смотрите в документации по функционалу Alauda Cache Service for Redis OSS.

#Учетные данные PostgreSQL

#Требования

GitLab предъявляет следующие требования к версиям PostgreSQL:

#Формат учетных данных

Создайте Secret в namespace, где планируется развертывание экземпляра GitLab, выберите тип Opaque и добавьте и заполните следующие поля в конфигурации:

Пример YAML:

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

Как создать базу данных на экземпляре PG

Подключитесь к экземпляру PG с помощью psql cli и выполните команду для создания базы данных

create database <database name>;

Создание отдельной базы данных для кластера gitaly

В режиме высокой доступности компонент gitaly должен быть настроен в кластерном режиме и требует отдельную базу данных для хранения метаданных gitaly. Необходимо создать еще один Secret для хранения информации о подключении к базе данных с полями, аналогичными описанным выше.

#sslmode

sslmode — параметр, управляющий безопасностью соединения между сервисом GitLab и базой данных PostgreSQL. Доступные опции:

• enable: включить SSL-соединение
• disable: отключить SSL-соединение

При использовании Alauda support for PostgreSQL параметр sslmode должен быть установлен в enable.
При использовании внешнего PostgreSQL значение sslmode зависит от вашей конфигурации PostgreSQL.

#Обновление учетных данных

Если необходимо изменить информацию для подключения к PostgreSQL после развертывания экземпляра GitLab, нужно напрямую обновить ресурс экземпляра GitLab, а не изменять содержимое учетных данных. Для конкретных операций смотрите Configure PostgreSQL Credentials.

#Использование PostgreSQL, предоставляемого Data Services

Data Services поддерживает развертывание экземпляров PostgreSQL, которые можно использовать для развертывания GitLab. При создании экземпляра PostgreSQL учитывайте следующие важные требования:

1. Выберите версию PostgreSQL, соответствующую версии GitLab, например, при развертывании GitLab 17.z необходимо выбрать PostgreSQL 14.z
2. Квота хранилища должна быть не менее 5Gi

При создании экземпляра PostgreSQL автоматически создается Secret с информацией для подключения. Этот ресурс Secret можно отфильтровать по метке middleware.instance/type: PostgreSQL.

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

#Учетные данные аккаунта GitLab

Создайте Secret в namespace, где планируется развертывание экземпляра GitLab, выберите тип Opaque и добавьте и заполните следующие поля в конфигурации:

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

#Учетные данные объектного хранилища

Подготовьте файл конфигурации MinIO с именем rails-storage.yaml со следующим содержимым:

provider: AWS
region: us-east-1
aws_access_key_id: example
aws_secret_access_key: example
endpoint: "http://minio.example.com"
path_style: true

• provider — тип объектного хранилища, для MinIO используется фиксированное значение AWS
• region — регион объектного хранилища, для MinIO используется фиксированное значение us-east-1
• aws_access_key_id — ключ доступа для объектного хранилища
• aws_secret_access_key — секретный ключ доступа для объектного хранилища
• endpoint — адрес доступа к объектному хранилищу
• path_style — метод доступа к объектному хранилищу, здесь используется фиксированное значение true

Сохраните файл конфигурации как секрет в кластере, при этом namespace должен совпадать с namespace экземпляра GitLab:

kubectl create secret generic gitlab-object-storage -n <ns-of-gitlab-instance> --from-file=connection=rails-storage.yaml

Подробнее смотрите в разделе Using Object Storage for LFS Files.