Предварительная версия. Функциональность может измениться, но основные возможности сохранятся. Совместимость с будущими версиями может потребовать ручных действий по миграции.

Начало работы

Внимание: мы не гарантируем стабильную работу Gitaly на kubernetes нодах с Containerd v2.

Ниже представлена минимально необходимая конфигурация (так называемый happy path), чтобы запустить и подготовить Deckhouse Code.


Включение модуля

Включите модуль code в вашем Kubernetes-кластере на базе Deckhouse, чтобы установить code-operator. Для этого можно использовать ModuleConfig. Пример ниже:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: code
spec:
  enabled: true # включает или отключает модуль
  version: 1
  settings:
    logLevel: Info

Настройка зависимостей

Внимание: мы не гарантируем стабильную работу Gitaly на kubernetes нодах с Containerd v2.

Необходимо установить и настроить зависимости: postgres, redis и s3-хранилище.

Несколько замечаний по конфигурации:

  • Postgres
    • Требуется версия 16 или выше
    • Deckhouse Code требует 2 отдельные базы данных из кластера postgres: основную и дополнительную для компонента praefect
    • Необходимые расширения postgres: btree_gist, pg_trgm, plpgsql
    • Количество соединений на пользователя должно быть не менее 150
    • Дополнительная информация и примеры доступны здесь
  • Redis
    • Версия 7.0 или выше
    • Поддерживаются как прямые подключения, так и через sentinels (Авторизация на уровне Sentinel не поддерживается, только на уровне узла)
    • Дополнительная информация и примеры доступны здесь
  • S3-хранилище
    • Поддерживаются провайдеры YCloud и Generic
    • Политика пользователя должна включать следующие разрешения: s3:ListAllMyBuckets, s3:ListBucket, s3:GetObject, s3:PutObject, s3:DeleteObject
    • Если у пользователя нет прав на создание бакетов, то бакеты должны быть созданы вручную (с учетом заданного bucketNames). Бакеты по умолчанию имеют следующие названия:
      • d8-code-artifacts
      • d8-code-ci-secure-files
      • d8-code-mr-diffs
      • d8-code-git-lfs
      • d8-code-packages
      • d8-code-terraform-state
      • d8-code-uploads
      • d8-code-pages (Если включен функционал Pages)
    • Дополнительная информация и примеры доступны здесь

Применение custom resource codeInstance

code-operator управляет установкой и конфигурацией Deckhouse Code на основе кастомного ресурса codeInstance. Пример ниже:

apiVersion: deckhouse.io/v1
kind: CodeInstance
metadata:
   name: code
spec:
  scaling:
    targetUserCount: 10
  storages:
    s3: # пока поддерживается только внешний
      mode: External
      external:
        provider: YCloud # или Generic
        accessKey: <REPLACE_ME> # accessKey сервисного аккаунта с доступом к S3
        secretKey: <REPLACE_ME> # secretKey сервисного аккаунта с доступом к S3
    postgres: # пока поддерживается только внешний
      mode: External
      external:
        host: <REPLACE_ME>  # URL postgres-мастера
        port: 5432 # может отличаться в зависимости от настроек postgres
        database: <REPLACE_ME> # имя базы данных
        username: <REPLACE_ME> # имя пользователя базы
        password: <REPLACE_ME> # пароль в открытом виде
        praefectDatabase: <REPLACE_ME> # имя базы данных для praefect
        praefectUsername: <REPLACE_ME> # имя пользователя для базы praefect
        praefectPassword: <REPLACE_ME> # пароль для базы praefect
    redis: # пока поддерживается только внешний
      mode: External
      external:
        host: <REPLACE_ME> # для raw redis-кластера. URL хоста
        port: 6379
        auth:
          enabled: true
          password: <REPLACE_ME> # пароль в открытом виде
  gitData:
    storageClass: <REPLACE_ME> # доступный в вашей среде storageClass
    storagePerReplicaGb: 10

Прочие секции

Кастомный ресурс codeInstance поддерживает гораздо больше опций конфигурации. Все они описаны в openapi-спецификации. Ниже представлен обзор ключевых разделов CR и их предназначения.


Network

Все вопросы, связанные с конфигурацией сети, описаны в этом разделе.
Можно указать кастомные CA-сертификаты, переопределить ingress-хосты, управлять HAProxy перед приложением и многое другое — в зависимости от конфигурации вашего кластера.
Подробнее — на этой странице.


GitData

Deckhouse Code использует gitaly для хранения git-репозиториев. Все настройки, связанные с конфигурацией хранилища репозиториев, находятся в этом разделе.


Backup

Поддержка ad-hoc и регулярных резервных копий в s3.
Все параметры, связанные с процессом резервного копирования и восстановления, описаны в этой секции.
Рекомендуем также ознакомиться с этим документом для получения подробностей по процессу backup/restore.


Scaling

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


AppConfig

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


Features

Дополнительно поддерживаются такие функции, как pages, registry, а также incoming/outgoing почта и service_desk.
Их конфигурация представлена в этом разделе.
Пожалуйста, также ознакомьтесь с этим документом по настройке авторизации.


Обзор компонентов Code

Раздел предоставляет обзор существующих компонентов и их функций:

  1. Gitaly - Git RPC-сервис для обработки всех Git-запросов, сделанных GitLab.
  2. Praefect - прозрачный прокси между любым Git-клиентом и узлами хранения Gitaly.
  3. Sidekiq - процессор фоновых заданий.
  4. Webservice - предоставляет пользовательский интерфейс и публичный API продукта.
  5. Webservice-internal-api - предоставляет внутренний API для коммуникации компонентов между собой
  6. Shell - программа, разработанная в GitLab для обработки Git-сессий на основе SSH и изменения списка авторизованных ключей.
  7. Toolbox - многофункциональный инструмент, который позволяет администраторам восстанавливать данные из резервных копий или использовать rails-консоль.
  8. Exporter - процесс, разработанный внутри компании, позволяющий экспортировать метрики о внутренней работе приложения Code в Prometheus.
  9. MRA - означает “утверждение слияния” (merge request approval). Сервис, реализующий соответствующий функционал GitLab, включая возможность CODEOWNERS.
  10. Migrations-job - задание, выполняющее миграции базы данных.
  11. Backup-cronjob - cron-задача, отвечающая за процесс резервного копирования. Опциональный компонент
  12. Pages - функция, позволяющая публиковать статические веб-сайты непосредственно из репозитория в GitLab. Опциональный компонент.
  13. Registry - реестр контейнеров, который позволяет загружать и скачивать образы. Опциональный компонент.
  14. HAProxy - используется как единая точка для всего входящего трафика продукта Deckhouse Code. Опциональный компонент

Подробнее с компонентами можно познакомиться по этой ссылке из официальной документации