Развертывание экземпляра 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 и учётных данных.

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

Планирование конфигурации после развертывания относится к настройкам, которые не нужно определять до развертывания, а можно выполнять по мере необходимости с помощью стандартизированных операций после развертывания. К ним относятся Single Sign-On (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

Хранилище {storage}

Хранение данных 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 # Путь к node storage, должен быть создан заранее

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

Сетевой доступ включает два основных метода: доступ по доменному имени и доступ через 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, включая случай настройки двух баз данных 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 # Путь node storage, должен быть создан заранее
      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)

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

Настройка Single Sign-On (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 Metrics будет автоматически настроен и доступен для просмотра на панели мониторинга центра операций.

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

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

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

#Содержание

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

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

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

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

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

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

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

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

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

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

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

#Хранилище {storage}

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

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

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

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

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

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

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

#Настройка Single Sign-On (SSO)

#Настройка HTTPS

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

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