Развертывание экземпляра GitLab

В этом документе представлена подписка GitLab Operator и функциональность развертывания экземпляра GitLab.

Ограничения политики безопасности пространства имён

GitLab не поддерживает развертывание в пространствах имён с политикой SPA (Security Policy Admission), установленной в Restricted, по следующим причинам:

Init-контейнер требует прав root: GitLab использует init-контейнеры для инициализации прав доступа к директории PVC, что требует прав root, не разрешённых при политике Restricted.
Компонент Gitaly требует специальных системных вызовов: Компонент Gitaly требует специфических системных вызовов, несовместимых с seccompProfile, настроенным как RuntimeDefault.

Рекомендация: Создайте отдельное пространство имён для развертывания GitLab и убедитесь, что его политика безопасности не установлена в Restricted. При развертывании GitLab с использованием хранилища hostPath политика безопасности пространства имён должна быть настроена как Privileged.

Содержание

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

Этот документ применим к версиям GitLab 17 и выше, предоставляемым платформой. Он отделён от платформы и основан на технологиях, таких как Operator.
Убедитесь, что GitLab Operator развернут (подписан) в целевом кластере, то есть экземпляр GitLab можно создать через GitLab Operator.

Планирование развертывания

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

Основная информация

GitLab Operator, предоставляемый платформой, основан на официальном сообществе GitLab Operator с улучшениями корпоративного уровня, такими как поддержка IPv6, ARM и исправления уязвимостей безопасности. Он полностью совместим с сообществом по функционалу и повышает удобство развертывания GitLab через опциональные и настраиваемые шаблоны.
Экземпляр GitLab включает несколько компонентов, таких как Gitaly — компонент для доступа к Git-репозиториям, PostgreSQL — компонент, предоставляющий хранилище для метаданных приложения и информации о пользователях, и Redis — компонент для кэширования и др. Платформа предоставляет профессиональные PostgreSQL Operator и Redis Operator, поэтому при развертывании экземпляра GitLab ресурсы Redis и PostgreSQL не разворачиваются напрямую, а доступны через настройку конкретных учётных данных доступа к существующим инстансам.

Планирование ресурсов до развертывания

Планирование ресурсов до развертывания — это планирование ресурсов, которое необходимо определить до развертывания и которое вступает в силу во время развертывания. Основное содержание включает:

Высокая доступность

GitLab поддерживает развертывание с высокой доступностью. Основные последствия и ограничения этого режима:
- Каждый компонент разворачивается с несколькими репликами
- Сетевой доступ больше не поддерживает NodePort, требуется доступ через доменные имена, настроенные через Ingress
- Метод хранения больше не поддерживает node storage, требуется доступ через StorageClass или PVC

Ресурсы

Согласно рекомендациям сообщества и практике, экземпляр GitLab без высокой доступности может работать с минимум 3 ядрами CPU и 6Gi памяти, а в режиме высокой доступности требуется минимум 18 ядер CPU и 22Gi памяти для стабильной работы.

Хранилище

Руководство по выбору хранилища

Компонент	Поддерживаемый тип хранилища	Описание
Хранилище Gitaly	блочное хранилище (например, Ceph RBD) файловое хранилище (например, Ceph FS)	Для производственных сред рекомендуется использовать блочное хранилище с производительностью не ниже: чтение IOPS ≥ 8,000 и запись IOPS ≥ 2,000.
Хранилище загрузок	объектное хранилище (например, MinIO) файловое хранилище (например, Ceph FS)	Для производственных сред рекомендуется использовать объектное хранилище. Последовательная пропускная способность диска (с размером блока 1 МБ) не должна быть ниже 100 МиБ/с.

Для GitLab можно использовать общие методы хранения, предоставляемые платформой, такие как классы хранилищ, persistent volume claims, node storage и др.
- Для хранилища Gitaly рекомендуется класс хранения TopoLVM
- Node storage не подходит для режима high availability, так как хранит файлы в указанном пути на хост-ноде
Кроме того, GitLab поддерживает объектное хранилище. В этом режиме требуется отдельная адаптация метода доступа к хранилищу. Обратитесь к поставщику за подробностями.

Сеть

Платформа предоставляет два основных метода сетевого доступа: NodePort и Ingress
- NodePort требует указания HTTP и SSH портов и обеспечения их доступности. NodePort не подходит для режима high availability
- Ingress требует указания доменного имени и обеспечения корректного разрешения домена
Платформа поддерживает протокол HTTPS, который необходимо настроить после развертывания экземпляра. Подробнее см. Настройка HTTPS.

Redis

Версия компонента Redis, необходимая GitLab, — v6. Рекомендуется развертывать инстансы Redis с помощью Redis Operator, предоставляемого платформой, а затем завершать интеграцию Redis настройкой учётных данных доступа.
- Доступ к Redis осуществляется путём настройки ресурса secret с определённым форматом содержимого. Подробнее см. Настройка учётных данных Redis, PostgreSQL и аккаунтов.

PostgreSQL

Версия компонента PostgreSQL, необходимая GitLab, — v14. Рекомендуется развертывать инстансы PostgreSQL с помощью PostgreSQL Operator, предоставляемого платформой, а затем завершать интеграцию PostgreSQL настройкой учётных данных доступа.
- Доступ к PostgreSQL осуществляется путём настройки ресурса secret с определённым форматом содержимого. Подробнее см. Настройка учётных данных Redis, PostgreSQL и аккаунтов.
Примечание: В режиме высокой доступности компонент Gitaly работает в режиме кластера и требует дополнительной учётной записи PostgreSQL, настроенной аналогично вышеописанному способу, для доступа к отдельной базе данных. Это могут быть две разные базы данных в одном экземпляре PostgreSQL.

Учётные данные аккаунта

При создании экземпляра GitLab необходимо настроить root-аккаунт и его пароль. Это делается путём настройки ресурса secret. Подробнее см. Настройка учётных данных Redis, PostgreSQL и аккаунтов.

Планирование конфигурации после развертывания

Планирование конфигурации после развертывания — это настройки, которые не нужно определять до развертывания, но которые можно выполнить по мере необходимости через стандартизированные операции после развертывания. К ним относятся единый вход (SSO), настройка HTTPS, конфигурация внешнего балансировщика нагрузки и др. Подробнее см. Следующие шаги.

Развертывание экземпляра

GitLab Operator, предоставляемый платформой, предлагает два метода развертывания: развертывание из шаблонов и развертывание из YAML.

Платформа предоставляет два встроенных шаблона: шаблон GitLab Quick Start и шаблон GitLab High Availability, а также поддерживает пользовательские шаблоны для удовлетворения специфических сценариев.

Информация о встроенных шаблонах и развертывании из YAML приведена ниже:

Развертывание из шаблона `GitLab Quick Start`

Этот шаблон используется для быстрого создания облегчённого экземпляра GitLab, подходящего для сценариев разработки и тестирования, не рекомендуется для производственных сред.

Вычислительные ресурсы: 3 ядра CPU, 6Gi памяти
Метод хранения: используется локальное node storage, требуется настройка IP и пути узла хранения
Сетевой доступ: используется метод NodePort, IP ноды совпадает с IP хранилища, требуется указание портов
Зависимые сервисы: требуется настройка учётных данных доступа к существующим Redis и PostgreSQL
Другие настройки: требуется настройка учётных данных аккаунта, функция SSO по умолчанию отключена

Завершите развертывание, заполнив соответствующую информацию согласно подсказкам шаблона.

Развертывание из шаблона `GitLab High Availability`

Развёртывание экземпляра GitLab с высокой доступностью требует более высокой конфигурации ресурсов и обеспечивает более высокий стандарт доступности.

Вычислительные ресурсы: 18 ядер CPU, 22Gi памяти
Метод хранения: используется класс хранения для хранения Gitaly — компонента репозитория кода
Сетевой доступ: используется метод Ingress, требуется указание доменного имени
Зависимые сервисы: требуется настройка учётных данных доступа к существующим Redis и PostgreSQL, а также отдельные учётные данные для другой независимой базы данных в экземпляре PG для компонента Gitaly
Другие настройки: требуется настройка учётных данных аккаунта, функция SSO по умолчанию отключена

Для обеспечения высокой доступности GitLab внешние зависимости должны соответствовать следующим условиям:

attachment storage class должен поддерживать многонодовый доступ на чтение и запись (ReadWriteMany)
Инстансы Redis и PostgreSQL должны быть высокодоступными
Сетевой балансировщик нагрузки должен быть высокодоступным; при использовании ALB должен быть настроен VIP
В кластере должно быть более 2 нод

Завершите развертывание, заполнив соответствующую информацию согласно подсказкам шаблона.

Развертывание из YAML

Развертывание из YAML — это самый базовый и мощный способ развертывания. Здесь мы предоставляем соответствующие фрагменты YAML для каждого аспекта из раздела Планирование развертывания, а затем два полных примера YAML для разных сценариев, чтобы помочь пользователям понять метод конфигурации YAML и при необходимости внести изменения.

Фрагменты YAML на основе планирования развертывания

Высокая доступность

В режиме высокой доступности Gitaly должен использовать кластерный режим, а другие компоненты — минимум 2 реплики. Фрагмент конфигурации YAML для развертывания с высокой доступностью:

spec:
  helmValues:
    gitlab:
      gitlab-shell:
        maxReplicas: 2
        minReplicas: 2
      sidekiq:
        maxReplicas: 2
        minReplicas: 2
      webservice:
        maxReplicas: 2
        minReplicas: 2
    global:
      praefect:
        psql:
          host: host.example # Адрес экземпляра PostgreSQL
          port: 5432 # Порт экземпляра PostgreSQL
          user: username # Пользователь для доступа к PostgreSQL
          dbName: praefect-db # База данных для доступа PostgreSQL
          sslMode: require # Режим SSL для PostgreSQL
        dbSecret:
          key: secret # Ключ в секрете PostgreSQL, хранящий пароль
          secret: praefect-db # Секрет для базы данных PostgreSQL, используемой кластером Gitaly
        enabled: true
        virtualStorages:
        - gitalyReplicas: 3
          maxUnavailable: 1
          name: default

Хранилище

Хранение данных GitLab включает две основные части:

Хранилище Gitaly: хранит данные репозиториев кода
Хранилище вложений: хранит аватары пользователей, загруженные изображения и т. п.

В настоящее время поддерживаются три метода конфигурации хранилища: класс хранения, PVC и локальное node storage.

Фрагмент конфигурации класса хранения:

spec:
  helmValues:
    gitlab:
      gitaly:
        persistence:
          enabled: true
          size: 20Gi # Ёмкость хранилища Gitaly
          storageClass: topolvm # Класс хранения для Gitaly
    global:
      uploads:
        persistence:
          enabled: true
          storageClass: ceph # Класс хранения для вложений, должен поддерживать многонодовый доступ на чтение и запись (ReadWriteMany)
          size: 10Gi # Ёмкость хранилища вложений

Фрагмент конфигурации PVC:

spec:
  helmValues:
    gitlab:
      gitaly:
        persistence:
          enabled: true
          existingClaim: pvc-gitaly # Имя PVC для хранилища Gitaly, должен быть создан заранее
    global:
      uploads:
        persistence:
          enabled: true
          existingClaim: pvc-uploads # Имя PVC для хранилища вложений, должен быть создан заранее

Фрагмент конфигурации локального node storage:

spec:
  helmValues:
    global:
      nodeSelector:
        kubernetes.io/hostname: node-1 # Имя ноды, не IP
      hostpath:
        enabled: true
        nodeName: node-1 # Имя ноды
        path: /mnt/data/gitlab-hostpath # Путь локального хранилища, должен быть создан заранее

Сетевой доступ

Сетевой доступ включает два основных метода: доступ по доменному имени и доступ через NodePort.

Фрагмент конфигурации доступа по доменному имени:

spec:
  helmValues:
    gitlab:
      webservice:
        ingress:
          enabled: true # Включить доступ по доменному имени
    global:
      hosts:
        domain: gitlab.example.com # Доменное имя
        gitlab:
          hostnameOverride: gitlab.example.com # Доменное имя
          https: false # Использовать HTTP вместо HTTPS
          name: gitlab.example.com # Доменное имя
        ssh: gitlab.example.com # Доменное имя
      ingress:
        class: "" # Оставить пустым для использования значения по умолчанию кластера
        enabled: true # Включить доступ по доменному имени
        tls:
          enabled: false # Использовать HTTP вместо HTTPS

Метод NodePort требует настройки двух портов: HTTP и SSH.

Фрагмент конфигурации доступа NodePort:

spec:
  helmValues:
    gitlab:
      gitlab-shell:
        service:
          nodePort: 30000 # Порт SSH
          type: NodePort
      webservice:
        ingress:
          enabled: false # Отключить ingress
    global:
      appConfig:
        gitlabPort: 30010 # Порт HTTP
      gitlabNodePort:
        http: 30010 # Порт HTTP
        ssh: 30000 # Порт SSH
      hosts:
        domain: 192.168.100.100 # IP ноды кластера
        gitlab:
          https: false
          name: 192.168.100.100 # IP ноды кластера
        ssh: 192.168.100.100 # IP ноды кластера
      ingress:
        enabled: false # Отключить ingress
      shell:
        port: 30000 # Порт SSH

Конфигурация учётных данных доступа Redis

Это фрагмент конфигурации в экземпляре GitLab для учётных данных Redis после настройки ресурса secret с учётными данными Redis:

Пример для standalone:

spec:
  helmValues:
    global:
      redis:
        auth:
          enabled: true
          key: password # Ключ в секрете подключения Redis, хранящий пароль
          secret: gitlab-redis-password # Секрет с ключом подключения Redis
        host: 192.168.100.200 # Адрес Redis
        port: 6379 # Порт Redis

Пример для Sentinel:

spec:
  helmValues:
    global:
      redis:
        auth:
          enabled: true
          key: password # Ключ в секрете подключения Redis, хранящий пароль
          secret: gitlab-redis-password # Секрет с ключом подключения Redis
        host: mymaster # Имя группы мониторинга Sentinel
        sentinels:
          - host: 192.168.100.200 # Адрес узла Sentinel
            port: 16379 # Порт узла Sentinel
          - host: 192.168.100.201 # Адрес узла Sentinel
            port: 16379 # Порт узла Sentinel
          - host: 192.168.100.202 # Адрес узла Sentinel
            port: 16379 # Порт узла Sentinel

Конфигурация учётных данных доступа PostgreSQL

Это фрагмент конфигурации в экземпляре GitLab для учётных данных PostgreSQL после настройки ресурса secret с учётными данными PostgreSQL, включая случай с двумя базами данных в режиме высокой доступности:

spec:
  helmValues:
    global:
      psql:
        database: gitlab-db # База данных PostgreSQL
        host: 192.168.100.300 # Адрес PostgreSQL
        password:
          key: password # Ключ в секрете PostgreSQL, хранящий пароль
          secret: gitlab-pg-password # Секрет PostgreSQL
        port: 5432 # Порт PostgreSQL
        username: gitlab-user # Пользователь PostgreSQL

Конфигурация root-аккаунта

Это фрагмент конфигурации в экземпляре GitLab для учётных данных аккаунта после настройки ресурса secret с учётными данными аккаунта:

spec:
  helmValues:
    global:
      initialRootPassword:
        key: password # Ключ в секрете root-аккаунта GitLab, хранящий пароль
        secret: gitlab-root-password # Секрет root-аккаунта GitLab

Полный пример YAML: одиночный экземпляр, node storage, сетевой доступ NodePort

spec:
  helmValues:
    gitlab:
      gitaly:
        persistence:
          enabled: true
        resources:
          limits:
            cpu: 1
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 512Mi
        volumePermissions:
          enabled: true
      gitlab-shell:
        resources:
          limits:
            cpu: 500m
            memory: 512Mi
          requests:
            cpu: 300m
            memory: 300Mi
      migrations:
        resources:
          limits:
            cpu: 2
            memory: 2Gi
          requests:
            cpu: 500m
            memory: 512Mi
      sidekiq:
        resources:
          limits:
            cpu: 500m
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 200Mi
      webservice:
        ingress:
          enabled: false
        resources:
          limits:
            cpu: 1
            memory: 2.5Gi
          requests:
            cpu: 500m
            memory: 512Mi
        workhorse:
          resources:
            limits:
              cpu: 300m
              memory: 300Mi
            requests:
              cpu: 200m
              memory: 200Mi
    global:
      nodeSelector:
        kubernetes.io/hostname: node-1 # Имя ноды
      appConfig:
        gitlabPort: 30010 # Порт HTTP
        object_store:
          enabled: true
        omniauth:
          blockAutoCreatedUsers: false
          dex:
            enabled: false
          enabled: false
      gitlabNodePort:
        http: 30010 # Порт HTTP
        ssh: 30000 # Порт SSH
      hostpath:
        enabled: true
        nodeName: node-1 # Имя ноды
        path: /mnt/data/gitlab-hostpath # Путь локального хранилища, должен быть создан заранее
      hosts:
        domain: 192.168.100.100 # IP ноды кластера
        gitlab:
          https: false
          name: 192.168.100.100 # IP ноды кластера
        ssh: 192.168.100.100 # IP ноды кластера
      ingress:
        enabled: false
        tls:
          enabled: false
      initialRootPassword:
        key: password
        secret: gitlab-root-password # Секрет root-аккаунта
      psql:
        database: gitlab-db # База данных PostgreSQL
        host: 192.168.100.100 # Адрес PostgreSQL
        password:
          key: password # Ключ в секрете PostgreSQL, хранящий пароль
          secret: gitlab-pg-password # Секрет PostgreSQL
        port: 5432 # Порт PostgreSQL
        username: gitlab-user # Пользователь PostgreSQL
      redis:
        auth:
          enabled: true
          key: password # Ключ в секрете Redis, хранящий пароль
          secret: gitlab-redis-password # Секрет Redis
        host: 192.168.100.200 # Адрес Redis
        port: 6379 # Порт Redis
      uploads:
        persistence:
          enabled: true

Полный пример YAML: высокая доступность, класс хранения, сетевой доступ Ingress

spec:
  helmValues:
    gitlab:
      gitaly:
        persistence:
          enabled: true
          size: 20Gi # Ёмкость хранилища Gitaly
          storageClass: topolvm # Класс хранения для Gitaly
        resources:
          limits:
            cpu: 4
            memory: 4Gi
          requests:
            cpu: 1
            memory: 1Gi
        volumePermissions:
          enabled: true
      gitlab-shell:
        maxReplicas: 2
        minReplicas: 2
        resources:
          limits:
            cpu: 1
            memory: 1Gi
          requests:
            cpu: 250m
            memory: 600Mi
      migrations:
        resources:
          limits:
            cpu: "1"
            memory: 1Gi
      sidekiq:
        maxReplicas: 2
        minReplicas: 2
        resources:
          limits:
            cpu: 2
            memory: 2Gi
          requests:
            cpu: 1
            memory: 1Gi
      webservice:
        ingress:
          enabled: true # Включить доступ через Ingress
        maxReplicas: 2
        minReplicas: 2
        resources:
          limits:
            cpu: 2
            memory: 4Gi
          requests:
            cpu: 1
            memory: 2Gi
        workhorse:
          resources:
            limits:
              cpu: 1
              memory: 1Gi
            requests:
              cpu: 200m
              memory: 200Mi
    global:
      appConfig:
        object_store:
          enabled: true
        omniauth:
          blockAutoCreatedUsers: false
          dex:
            enabled: false
          enabled: false
      hosts:
        domain: gitlab.example.com # Доменное имя
        gitlab:
          hostnameOverride: gitlab.example.com # Доменное имя
          https: false
          name: gitlab.example.com # Доменное имя
        ssh: gitlab.example.com # Доменное имя
      ingress:
        class: ""
        configureCertmanager: false
        enabled: true
        tls:
          enabled: false
      initialRootPassword:
        key: password
        secret: gitlab-root-password # Секрет root-аккаунта
      praefect:
        psql:
          host: 192.168.100.300 # Адрес PostgreSQL
          port: 5432 # Порт PostgreSQL
          user: gitlab-user # Пользователь PostgreSQL
          dbName: gitlab-praefect # База данных PostgreSQL
          sslMode: require
        dbSecret:
          key: password # Ключ в секрете PostgreSQL, хранящий пароль
          secret: praefect-db # Секрет базы данных PostgreSQL для кластера Gitaly
        enabled: true
        virtualStorages:
          - gitalyReplicas: 3
            maxUnavailable: 1
            name: default
      psql:
        database: gitlab-db # База данных PostgreSQL
        host: 192.168.100.300 # Адрес PostgreSQL
        password:
          key: password # Ключ в секрете PostgreSQL, хранящий пароль
          secret: gitlab-pg # Секрет PostgreSQL
        port: 5432 # Порт PostgreSQL
        username: gitlab-user # Пользователь PostgreSQL
      redis:
        auth:
          enabled: true
          key: password # Ключ в секрете Redis, хранящий пароль
          secret: gitlab-redis-password # Секрет Redis
        host: 192.168.100.200 # Адрес Redis
        port: 6379 # Порт Redis
      uploads:
        persistence:
          enabled: true
          size: 10Gi # Ёмкость хранилища вложений
          storageClass: ceph # Класс хранения для вложений, должен поддерживать многонодовый доступ на чтение и запись (ReadWriteMany)

Следующие шаги

Настройка единого входа (SSO)

Настройка SSO включает следующие шаги:

Зарегистрировать клиент аутентификации SSO в глобальном кластере
Подготовить конфигурацию аутентификации SSO
Настроить экземпляр GitLab для использования конфигурации аутентификации SSO

Создайте следующий ресурс Oauth2Client в глобальном кластере для регистрации клиента аутентификации SSO.

apiVersion: dex.coreos.com/v1
kind: OAuth2Client
name: OIDC
id: gitlab-dex # Client ID
secret: Z2l0bGFiLW9mZmljaWFsLTAK # Client secret
redirectURIs:
  - <gitlab-host>/users/auth/dex/callback # Адрес обратного вызова аутентификации GitLab, где <gitlab-host> заменяется на адрес доступа к экземпляру GitLab
metadata:
  name: m5uxi3dbmiwwizlyzpzjzzeeeirsk # Это значение вычисляется на основе хеша поля id, онлайн-калькулятор: https://go.dev/play/p/QsoqUohsKok
  namespace: cpaas-system
alignPasswordDB: true
public: false
spec: {}

Поле	Описание	Пример
name	Отображаемое имя ресурса.	OIDC
id	Client ID для аутентификации SSO. Допускается любое значение, кроме alauda-dex, которое зарезервировано и может вызвать конфликты.	gitlab-dex
secret	Client secret для аутентификации SSO. Может быть любым значением.	Z2l0bGFiLW9mZmljaWFsLTAK
redirectURIs	URL обратного вызова аутентификации GitLab, формат `<gitlab-host>/users/auth/dex/callback`.	https://example.gitlab.com/users/auth/dex/callback
metadata.name	Имя ресурса, которое должно быть вычислено на основе хеша поля `id`. Можно использовать онлайн-калькуляторы хешей, например https://go.dev/play/p/QsoqUohsKok.	m5uxi3dbmiwwizlyzpzjzzeeeirsk
metadata.namespace	Системное пространство имён платформы, должно быть `cpaas-system`.	cpaas-system

Подготовьте содержимое конфигурации согласно комментариям в JSON ниже.

{
 "name": "openid_connect",
 "label": "OIDC",
 "args": {
   "name": "dex",
   "scope": ["openid", "profile", "email"],
   "response_type": "code",
   "issuer": "<platform-url>/dex", # Адрес аутентификации платформы, где <platform-url> заменяется на адрес доступа к платформе
   "discovery": true,
   "client_auth_method": "query",
   "client_options": {
     "identifier": "test-dex", # Client ID
     "secret": "Z2l0bGFiLW9mZmljaWFsLTAK", # Client secret
     "redirect_uri": "<gitlab-host>/users/auth/dex/callback" # Адрес обратного вызова аутентификации GitLab, где <gitlab-host> заменяется на адрес доступа к экземпляру GitLab
   }
 }
}

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

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-sso-config
  namespace: gitlab
type: Opaque
data:
  provider: <base64 encoded config> # Сохраните вышеуказанное содержимое конфигурации, закодированное в base64, в поле provider

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

spec:
  helmValues:
    global:
      appConfig:
        omniauth:
          enabled: true
          allowSingleSignOn:
            - dex
          syncProfileAttributes:
            - email
          syncProfileFromProvider:
            - dex
          blockAutoCreatedUsers: false
          providers:
            - key: provider
              secret: dex-provider # Секрет с конфигурацией аутентификации SSO

Включение SSO для платформ с самоподписанными сертификатами

Если платформа доступна по HTTPS и использует самоподписанный сертификат, необходимо смонтировать CA самоподписанного сертификата в экземпляр GitLab следующим образом:

В пространстве имён cpaas-system глобального кластера найдите секрет с именем dex.tls, получите содержимое ca.crt из секрета, сохраните его как новый секрет и создайте в пространстве имён экземпляра GitLab.

Формат сертификата

Сертификат должен быть в формате PEM.

apiVersion: v1
data:
  ca.crt: <base64-encoded PEM сертификата>
kind: Secret
metadata:
  name: dex-tls
  namespace: cpaas-system
type: kubernetes.io/tls

Отредактируйте экземпляр GitLab для использования этого CA:

spec:
  helmValues:
    global:
      certificates:
        customCAs:
          - secret: dex-tls

Настройка HTTPS

После развертывания экземпляра GitLab можно настроить HTTPS по необходимости.

Сначала создайте секрет TLS-сертификата в пространстве имён, где расположен экземпляр.

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-tls-cert
  namespace: gitlab
type: kubernetes.io/tls
data:
  tls.crt: <base64 encoded cert>
  tls.key: <base64 encoded key>

Затем отредактируйте YAML-конфигурацию экземпляра GitLab для включения доступа по HTTPS:

spec:
  helmValues:
    gitlab:
      webservice:
        ingress:
          enabled: true
    global:
      hosts:
        domain: gitlab.example.com # Доменное имя
        gitlab:
          hostnameOverride: gitlab.example.com # Доменное имя
          https: true # Включить HTTPS
          name: gitlab.example.com # Доменное имя
        ssh: gitlab.example.com # Доменное имя
      ingress:
        class: ""
        enabled: true
        tls:
          enabled: true # Включить HTTPS
          secretName: gitlab-tls-cert # Имя секрета сертификата

Настройка панели мониторинга

GitLab Operator по умолчанию поддерживает панель мониторинга центра операций платформы. При развертывании GitLab Operator и экземпляра GitLab метрики GitLab будут автоматически настроены и доступны для просмотра на панели мониторинга центра операций.

Настройка внешнего балансировщика нагрузки (LB)

Настройка внешнего балансировщика нагрузки (LB) для GitLab

Развертывание экземпляра GitLab#

#Содержание

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

#Планирование развертывания

#Основная информация

#Планирование ресурсов до развертывания

#Планирование конфигурации после развертывания

#Развертывание экземпляра

#Развертывание из шаблона GitLab Quick Start

#Развертывание из шаблона GitLab High Availability

#Развертывание из YAML

#Фрагменты YAML на основе планирования развертывания

#Высокая доступность

#Хранилище

#Сетевой доступ

#Конфигурация учётных данных доступа Redis

#Конфигурация учётных данных доступа PostgreSQL

#Конфигурация root-аккаунта

#Полный пример YAML: одиночный экземпляр, node storage, сетевой доступ NodePort

#Полный пример YAML: высокая доступность, класс хранения, сетевой доступ Ingress

#Следующие шаги

#Настройка единого входа (SSO)

#Настройка HTTPS

#Настройка панели мониторинга

#Настройка внешнего балансировщика нагрузки (LB)