Стадия жизненного цикла модуля: General Availability

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

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

Минимальные требования

Для запуска модуля Code необходимо выполнение следующих требований:

Ресурсы Deckhouse-кластера

Минимальные ресурсы рассчитаны для 100 пользователей (минимальный поддерживаемый scaling.targetUserCount):

Requests Limits
7 CPU / 13 Gb 11 CPU / 17 Gb

При установке в режиме высокой доступности (HA) планируйте как минимум удвоенное количество ресурсов.

Подробная информация о масштабировании доступна в документации по масштабированию.

Внешние зависимости

  • PostgreSQL версии 17 или выше
  • Redis версии 7.0 или выше
  • S3-хранилище (провайдеры YCloud или Generic)

Остальные компоненты

  • Наличие StorageClass для хранения Git-репозиториев (параметр gitData.storageClass)
  • Наличие IngressClass для маршрутизации внешнего трафика к веб-интерфейсу Code

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

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

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

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

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

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

  • Postgres
    • Deckhouse Code требует 2 отдельные базы данных из кластера postgres: основную и дополнительную для компонента praefect
    • Необходимые расширения postgres: btree_gist, pg_trgm, plpgsql
    • Количество соединений на пользователя должно быть не менее 150
    • Дополнительная информация и примеры доступны здесь
  • Redis
    • Поддерживаются как прямые подключения, так и через sentinels (Авторизация на уровне Sentinel не поддерживается, только на уровне узла)
    • Дополнительная информация и примеры доступны здесь
  • S3-хранилище
    • Политика пользователя должна включать следующие разрешения: 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)
    • Дополнительная информация и примеры доступны здесь

Подготовка нод Kubernetes

Управление размещением компонентов Deckhouse компонентов

По умолчанию ресурсы CRD размещаются на нодах с лейблом node-role.deckhouse.io/code=. Чтобы отключить данное поведение, задайте spec.placement.dedicated: false в ресурсе CodeInstance.

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

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

На данный момент система поддерживает только один экземпляр CodeInstance, и он строго должен иметь имя code (см. пример ниже).

Обратите внимание на то, что пароли пишутся в двойных ковычках.

apiVersion: deckhouse.io/v1
kind: CodeInstance
metadata:
   name: code
spec:
  scaling:
    targetUserCount: 100
  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

Для проверки корректности запуска модуля нужно сделать следующее:

  1. Проверить отсутствие ошибок в логах оператора:

    kubectl -n d8-code get deploy/code-operator | grep error

    В результате возможно наличие сообщения с ошибкой об отсутствии расширения для postgres: "controller-runtime.reconcile.preflight-shared","message":"Missing required extensions: [btree_gin]"

    Данное сообщение не является критичным и его можно игнорировать.

  2. Проверить статус пода миграций:

    kubectl -n d8-code get pods | grep migration-v

    В результате все поды должны иметь статус Completed

  3. Проверить статус всех остальных подов в d8-code namespace:

    kubectl -n d8-code get pods

    В результате все поды кроме тех что имеют префикс migration- должны иметь статус Running

Время запуска всех подов зависит от мощности и ресурсов кластера Deckhouse. В среднем оно состовляет 3-4 минуты.

Первый запуск

Создание DNS записей

  • Если при конфигурации CodeInstance не было задано поле spec.network.web.hostname то веб страница code будет доступна по адресу согласно глобальным настройкам Deckhouse code.company.my.

  • Если при конфигурации CodeInstance было задано поле spec.network.web.hostname то веб страница code будет доступна по этому адресу. Создайте DNS-запись типа A, указывающую на IP-адрес Ingress-контроллера, обслуживающего code. Чтобы просмотреть ip адрес ingress контроллера обслуживающего code выполните следующую команду: kubectl -n d8-code get ingress webservice-default.

  • В случае использования продвинутой конфигурации CodeInstance необходимо обратиться к данному разделу

Получение root пароля для входа в Code

kubectl -n d8-code get secret initial-root-password  -oyaml | yq .data.password | base64 -d

Данная команда выведет пароль для пользователя root

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

Кастомный ресурс 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. Опциональный компонент

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

Схема компонентов Code

Минимальная установка

Устанавливаются лишь необходимые компоненты

schema-min

Полная установка

Включая все опциональные компоненты

schema-full