Развертывание экземпляра 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 не подходит для режима высокой доступности, так как хранит файлы в указанном пути на узле хоста
Кроме того, GitLab поддерживает объектное хранилище. В этом режиме требуется отдельная адаптация метода доступа к хранилищу. Обратитесь к поставщику за подробностями.

Сеть

Платформа предоставляет два основных метода сетевого доступа: NodePort и Ingress
- NodePort требует указания HTTP и SSH портов и обеспечения их доступности. NodePort не подходит для режима высокой доступности
- 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

Хранилище

Хранение данных 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, включая случай настройки двух баз данных 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 будут автоматически настроены и доступны для просмотра на панели мониторинга центра операций.

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

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

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

#Содержание

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

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

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

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

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

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

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

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

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

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

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

#Хранилище

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

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

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

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

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

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

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

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

#Настройка HTTPS

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

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