GitLab 实例部署

本文介绍如何订阅 Alauda Toolchain Code Repository E1 operator 并部署 GitLab 实例。

命名空间安全策略限制

由于以下原因，GitLab 不支持在 SPA（Security Policy Admission）策略设置为 Restricted 的命名空间中部署：

Init Container 需要 root 权限：GitLab 使用 init container 初始化 PVC 目录权限，这需要 Restricted 策略不允许的 root 权限。
Gitaly 组件需要特殊系统调用：Gitaly 组件需要特定的系统调用，这些调用与配置为 RuntimeDefault 的 seccompProfile 不兼容。

建议：为 GitLab 部署创建专用命名空间，并确保其安全策略未设置为 Restricted。使用 hostPath 存储部署 GitLab 时，命名空间安全策略必须配置为 Privileged。

前提条件部署规划基本信息部署前资源规划部署后配置规划实例部署从 GitLab Quick Start 模板部署从 GitLab High Availability 模板部署从 YAML 部署基于部署规划的 YAML 片段完整 YAML 示例：单实例、节点存储、NodePort 网络访问完整 YAML 示例：高可用、存储类、Ingress 网络访问后续步骤配置单点登录（SSO）配置 HTTPS 配置监控面板配置外部负载均衡器（LB）

前提条件

本文适用于平台提供的 GitLab 17 及更高版本。它基于 Operator 等技术与平台解耦。
请确保已在目标集群中部署（订阅）Alauda Toolchain Code Repository E1 operator，即可以通过 Alauda Toolchain Code Repository E1 operator 创建 GitLab 实例。

部署规划

GitLab 支持多种资源配置，以适应不同的客户场景。在不同场景中，所需资源和配置可能存在较大差异。因此，本节介绍规划 GitLab 实例部署时需要考虑的方面，以及各决策点带来的影响，帮助用户为后续实例部署做出明智决策。

基本信息

平台提供的 Alauda Toolchain Code Repository E1 operator 基于官方 Community GitLab Operator，并进行了企业级能力增强，例如支持 IPv6、支持 ARM 以及修复安全漏洞。在功能方面，它与 Community 版本完全兼容，并通过可选和可自定义的模板提升 GitLab 部署的便捷性。
GitLab 实例包含多个组件，例如负责 Git 仓库访问的 Gitaly component、为应用元数据和用户信息提供存储的 PostgreSQL，以及用于缓存的 Redis 等。平台提供专业的 PostgreSQL Operator 和 Redis Operator，因此部署 GitLab 实例时不再直接部署 Redis 和 PostgreSQL 资源，而是通过配置特定的访问凭证来访问现有实例。

部署前资源规划

部署前资源规划是指需要在部署前确定，并在部署过程中生效的资源规划。主要内容包括：

高可用性

GitLab 支持高可用部署。此模式的主要影响和限制如下：
- 每个组件都将以多个副本进行部署
- 网络访问不再支持 NodePort，而是需要通过 Ingress 配置的域名进行访问
- 存储方式不再支持 node storage，而是需要通过 StorageClass 或 PVC 进行访问

资源

根据 Community 的建议和实践，非高可用 GitLab 实例最低可使用 3 个 CPU 核心和 6Gi 资源运行；在高可用模式下，则至少需要 18 个 CPU 核心和 22Gi 资源才能稳定运行。

存储

存储选择指南

组件	支持的存储类型	描述
Gitaly 存储	块存储（例如 Ceph RBD）文件存储（例如 Ceph FS）	对于生产环境，建议使用存储性能满足以下要求的块存储：读取 IOPS ≥ 8,000，写入 IOPS ≥ 2,000。
上传存储	对象存储（例如 MinIO）文件存储（例如 Ceph FS）	对于生产环境，建议使用对象存储。存储磁盘的顺序读写吞吐量（块大小为 1 MB）不应低于 100 MiB/s。

GitLab 可以使用平台提供的常见存储方式，例如存储类、持久卷声明、节点存储等。
- 建议将 TopoLVM 存储类用于 Gitaly 存储
- 节点存储不适用于 high availability 模式，因为它会将文件存储在主机节点上的指定路径中
此外，GitLab 还支持对象存储。在此模式下，需要单独适配存储访问方式。详情请咨询厂商。

网络

平台提供三种网络访问方式：NodePort、Ingress 和 Gateway API
- NodePort 需要指定 HTTP 和 SSH 端口，并确保端口可用。NodePort 不适用于 high availability 模式
- Ingress 需要指定域名，并确保域名解析正常工作
- Gateway API 适用于提供 Gateway API 而非 Ingress 的集群。它需要一个域名，以及预先在实例命名空间中创建的 Gateway；实例通过附加到该 Gateway 的 HTTPRoute 暴露。详情请参阅 Gateway API 访问
平台支持 HTTPS 协议，需要在实例部署后进行配置。详情请参阅配置 HTTPS。

Redis

GitLab 当前所需的 Redis 组件版本为 v6。建议使用平台提供的 Redis Operator 部署 Redis 实例，然后通过配置访问凭证完成 Redis 集成。
- Redis 访问通过配置具有特定格式内容的 secret 资源实现。详情请参阅配置 Redis、PostgreSQL 和账户凭证。

PostgreSQL

GitLab 当前所需的 PostgreSQL 组件版本为 v16。建议使用平台提供的 PostgreSQL Operator 部署 PostgreSQL 实例，然后通过配置访问凭证完成 PostgreSQL 集成。
- PostgreSQL 访问通过配置具有特定格式内容的 secret 资源实现。详情请参阅配置 Redis、PostgreSQL 和账户凭证。
注意：在高可用模式下，Gitaly 组件处于 Cluster 模式，需要以与上述相同的方式额外配置一个 PostgreSQL 凭证，以访问独立的数据库。它可以是同一 PostgreSQL 实例下的两个不同数据库。

账户凭证

创建 GitLab 实例时，需要配置 root 账户及其密码。此操作通过配置 secret 资源完成。详情请参阅配置 Redis、PostgreSQL 和账户凭证。

部署后配置规划

部署后配置规划是指无需在部署前确定，但可以在部署后根据需要通过标准化操作完成的配置，主要包括 Single Sign-On（SSO）、HTTPS 配置、外部负载均衡器配置等。详情请参阅后续步骤。

实例部署

平台提供的 Alauda Toolchain Code Repository E1 operator 提供两种部署方式：从模板部署和从 YAML 部署。

平台提供两个内置模板：GitLab Quick Start 模板和 GitLab High Availability 模板，同时支持用户自定义模板，以满足特定场景的需求。

内置模板和 YAML 部署的相关信息如下：

从 `GitLab Quick Start` 模板部署

此模板用于快速创建适合开发和测试场景的轻量级 GitLab 实例，不建议用于生产环境。

计算资源：3 个 CPU 核心、6Gi 内存
存储方式：使用本地节点存储，需要配置存储节点 IP 和路径
网络访问：使用 NodePort 方式，与存储共享节点 IP，需要指定端口
依赖服务：需要配置现有 Redis 和 PostgreSQL 的访问凭证
其他设置：需要配置账户凭证，默认禁用 SSO 功能

根据模板提示填写相关信息即可完成部署。

从 `GitLab High Availability` 模板部署

部署高可用 GitLab 实例需要更高的资源配置，并提供更高的可用性标准。

计算资源：18 个 CPU 核心、22Gi 内存
存储方式：使用存储类资源存储 Gitaly，即代码仓库组件
网络访问：使用 Ingress 或 Gateway API 方式，需要指定域名。选择 Gateway API 时，请选择实例命名空间中已存在的 Gateway
依赖服务：需要配置现有 Redis 和 PostgreSQL 的访问凭证，并额外为 Gitaly 组件配置 PG 实例中另一个独立数据库的单独访问凭证
其他设置：需要配置账户凭证，默认禁用 SSO 功能

要实现 GitLab 高可用，外部依赖必须满足以下条件：

attachment storage class 必须支持多节点读写（ReadWriteMany）
Redis 和 PostgreSQL 实例必须具备高可用性
网络负载均衡器必须具备高可用性；使用 ALB 时，必须配置 VIP
集群必须拥有超过 2 个节点

根据模板提示填写相关信息即可完成部署。

从 YAML 部署

YAML 部署是最基础且功能最强大的部署能力。这里针对 Deployment Planning 部分的各个维度提供相应的 YAML 片段，然后针对不同场景提供两个完整的 YAML 示例，帮助用户了解 YAML 配置方式并按需进行修改。

基于部署规划的 YAML 片段

高可用

在高可用模式下，Gitaly 需要使用 Cluster 模式，其他组件至少需要 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 instance address
          port: 5432 # PostgreSQL instance port
          user: username # PostgreSQL instance access user
          dbName: praefect-db # PostgreSQL instance access database
          sslMode: require # PostgreSQL instance SSL mode
        dbSecret:
          key: secret # Key in the PostgreSQL instance secret that stores the password
          secret: praefect-db # Secret for the PostgreSQL database used by Gitaly cluster
        enabled: true
        virtualStorages:
        - gitalyReplicas: 3
          maxUnavailable: 1
          name: default

存储

GitLab 数据存储主要包括两部分：

Gitaly 存储：存储代码仓库数据
附件存储：存储用户头像、用户上传的图片等

目前支持三种存储配置方式：存储类、PVC 和本地节点存储。

存储类配置片段：

spec:
  helmValues:
    gitlab:
      gitaly:
        persistence:
          enabled: true
          size: 20Gi # Gitaly storage capacity
          storageClass: topolvm # Storage class used for Gitaly
    global:
      uploads:
        persistence:
          enabled: true
          storageClass: ceph # Storage class used for attachments, needs to support multi-node read-write (ReadWriteMany)
          size: 10Gi # Attachment storage capacity

PVC 配置片段：

spec:
  helmValues:
    gitlab:
      gitaly:
        persistence:
          enabled: true
          existingClaim: pvc-gitaly # PVC name for Gitaly storage, needs to be created in advance
    global:
      uploads:
        persistence:
          enabled: true
          existingClaim: pvc-uploads # PVC name for attachment storage, needs to be created in advance

本地节点存储配置片段：

spec:
  helmValues:
    global:
      nodeSelector:
        kubernetes.io/hostname: node-1 # Node name, not the node IP address
      hostpath:
        enabled: true
        nodeName: node-1 # Node name
        path: /mnt/data/gitlab-hostpath # Node storage path, needs to be created in advance

网络访问

网络访问主要包括三种方式：通过 Ingress 进行域名访问、通过 Gateway API 进行域名访问，以及通过 NodePort 访问。

域名访问（Ingress）配置片段：

spec:
  helmValues:
    gitlab:
      webservice:
        ingress:
          enabled: true # Enable domain name access
    global:
      hosts:
        domain: gitlab.example.com # Domain name
        gitlab:
          hostnameOverride: gitlab.example.com # Domain name
          https: false # Use HTTP access instead of HTTPS
          name: gitlab.example.com # Domain name
        ssh: gitlab.example.com # Domain name
      ingress:
        class: "" # Leave empty to use the cluster default
        enabled: true # Enable domain name access
        tls:
          enabled: false # Use HTTP access instead of HTTPS

NodePort 方式需要配置两个端口：HTTP 端口和 SSH 端口。

NodePort 访问配置片段：

spec:
  helmValues:
    gitlab:
      gitlab-shell:
        service:
          nodePort: 30000 # SSH port number
          type: NodePort
      webservice:
        ingress:
          enabled: false # Disable ingress access
    global:
      appConfig:
        gitlabPort: 30010 # HTTP port number
      gitlabNodePort:
        http: 30010 # HTTP port number
        ssh: 30000 # SSH port number
      hosts:
        domain: 192.168.100.100 # Cluster Node IP
        gitlab:
          https: false
          name: 192.168.100.100 # Cluster Node IP
        ssh: 192.168.100.100 # Cluster Node IP
      ingress:
        enabled: false # Disable ingress access
      shell:
        port: 30000 # SSH port number

Gateway API 访问

在提供 Gateway API 但没有 Ingress controller 的集群中，通过附加到现有 Gateway 的 HTTPRoute 暴露实例。

前提条件：

集群已安装 Gateway API CRD 和 Gateway controller（例如 Envoy Gateway），并且存在可用的 GatewayClass。
GitLab 实例所在的同一命名空间中存在 Gateway。它必须具有一个 HTTP listener，其 hostname 为空或与实例域名匹配，并且其 allowedRoutes 必须允许来自该命名空间的路由。必须在实例配置（sectionName）中指定 listener 名称。
域名解析到 Gateway 的地址（请参阅 Gateway 的 status.addresses）。

最小 Gateway 示例：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gitlab-gateway
  namespace: gitlab # Same namespace as the GitLab instance
spec:
  gatewayClassName: <gateway-class> # GatewayClass provided by the cluster
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same

Gateway API 访问配置片段：

spec:
  helmValues:
    gitlab:
      webservice:
        gatewayRoute:
          enabled: true # Create an HTTPRoute for webservice
          gatewayName: gitlab-gateway # Existing Gateway in the instance namespace
          sectionName: http # Name of the Gateway listener (spec.listeners[].name); must not be empty
        ingress:
          enabled: false # Disable ingress access
    global:
      hosts:
        domain: gitlab.example.com # Domain name
        gitlab:
          hostnameOverride: gitlab.example.com # Domain name
          https: false # Use HTTP access instead of HTTPS
          name: gitlab.example.com # Domain name
        ssh: gitlab.example.com # Domain name
      ingress:
        enabled: false # Disable ingress access

注意：

不要设置 global.gatewayApi.enabled。这会使 chart 创建自己的 Gateway 和 Envoy 配置；使用现有的 Gateway 时不需要这样做。
如果用户通过非 80 端口访问 Gateway 的 HTTP listener（例如，Gateway Service 是 NodePort），请将该端口设置为 global.appConfig.gitlabPort，并将其包含在 spec.externalURL 中（例如，http://gitlab.example.com:30080）。GitLab 无法检测外部端口，因此不进行此设置时，它生成的克隆 URL 和链接会省略端口。
只有 Web 入口会通过 Gateway。要暴露 SSH，请使用上文所示的 gitlab-shell 的 NodePort 配置。
按照示例，将路由附加到 HTTP listener。与 Ingress 访问一样，实例会以 HTTP 部署；如需通过 HTTPS 提供服务，请在部署后参阅配置 HTTPS。
HTTPRoute 不会设置超时或正文大小限制，因此会使用 Gateway controller 的默认值，而不是如何调整 Webservice Ingress 超时和正文大小中所述的 Ingress 注解。使用 Envoy Gateway 时，采用默认值推送 400 MB 的仓库（39 秒）以及克隆该仓库（21 秒）均可正常工作。如果大文件传输被中断，请使用 Gateway controller 的策略资源提高限制（对于 Envoy Gateway，可以使用针对 HTTPRoute 或 Gateway 的 BackendTrafficPolicy 或 ClientTrafficPolicy）。
HTTPRoute 的名称为 <instance name>-gitlab。请使用 kubectl -n <namespace> get httproute <instance name>-gitlab -o yaml 检查其是否已被接受（status.parents[].conditions 应包含状态为 True 的 Accepted 和 ResolvedRefs）。
要将现有实例从 Ingress 切换到 Gateway API，请参阅将现有实例从 Ingress 迁移到 Gateway API。

Redis 访问凭证配置

在配置包含 Redis 凭证的 secret 资源后，这指的是 GitLab 实例中 Redis 凭证的配置片段：

单机示例：

spec:
  helmValues:
    global:
      redis:
        auth:
          enabled: true
          key: password # Key in the Redis connection secret that stores the password
          secret: gitlab-redis-password # Secret containing Redis connection key
        host: 192.168.100.200 # Redis instance address
        port: 6379 # Redis instance port

Sentinel 示例：

spec:
  helmValues:
    global:
      redis:
        auth:
          enabled: true
          key: password # Key in the Redis connection secret that stores the password
          secret: gitlab-redis-password # Secret containing Redis connection key
        host: mymaster # Sentinel monitor instances group name
        sentinels:
          - host: 192.168.100.200 # Sentinel node address
            port: 16379 # Sentinel node port
          - host: 192.168.100.201 # Sentinel node address
            port: 16379 # Sentinel node port
          - host: 192.168.100.202 # Sentinel node address
            port: 16379 # Sentinel node port

PostgreSQL 访问凭证配置

在配置包含 PostgreSQL 凭证的 secret 资源后，这指的是 GitLab 实例中 PostgreSQL 凭证的配置片段，其中还包括高可用模式下配置两个 PostgreSQL 数据库的情况：

spec:
  helmValues:
    global:
      psql:
        database: gitlab-db # PostgreSQL instance access database
        host: 192.168.100.300 # PostgreSQL instance address
        password:
          key: password # Key in the PostgreSQL instance secret that stores the password
          secret: gitlab-pg-password # PostgreSQL instance secret
        port: 5432 # PostgreSQL instance port
        username: gitlab-user # PostgreSQL instance access user

Root 账户配置

在配置包含账户凭证的 secret 资源后，这指的是 GitLab 实例中账户凭证的配置片段：

spec:
  helmValues:
    global:
      initialRootPassword:
        key: password # Key in the GitLab root account secret that stores the password
        secret: gitlab-root-password # GitLab root account secret

完整 YAML 示例：单实例、节点存储、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 # Node name
      appConfig:
        gitlabPort: 30010 # HTTP port number
        object_store:
          enabled: true
        omniauth:
          blockAutoCreatedUsers: false
          dex:
            enabled: false
          enabled: false
      gitlabNodePort:
        http: 30010 # HTTP port number
        ssh: 30000 # SSH port number
      hostpath:
        enabled: true
        nodeName: node-1 # Node name
        path: /mnt/data/gitlab-hostpath # Node storage path, needs to be created in advance
      hosts:
        domain: 192.168.100.100 # Cluster Node IP
        gitlab:
          https: false
          name: 192.168.100.100 # Cluster Node IP
        ssh: 192.168.100.100 # Cluster Node IP
      ingress:
        enabled: false
        tls:
          enabled: false
      initialRootPassword:
        key: password
        secret: gitlab-root-password # Root account secret
      psql:
        database: gitlab-db # PostgreSQL instance access database
        host: 192.168.100.100 # PostgreSQL instance address
        password:
          key: password # Key in the PostgreSQL instance secret that stores the password
          secret: gitlab-pg-password # PostgreSQL instance secret
        port: 5432 # PostgreSQL instance port
        username: gitlab-user # PostgreSQL instance access user
      redis:
        auth:
          enabled: true
          key: password # Key in the Redis instance secret that stores the password
          secret: gitlab-redis-password # Redis instance secret
        host: 192.168.100.200 # Redis instance address
        port: 6379 # Redis instance port
      uploads:
        persistence:
          enabled: true

完整 YAML 示例：高可用、存储类、Ingress 网络访问

spec:
  helmValues:
    gitlab:
      gitaly:
        persistence:
          enabled: true
          size: 20Gi # Gitaly storage capacity
          storageClass: topolvm # Storage class used for 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 # Enable Ingress access
        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 # Domain name
        gitlab:
          hostnameOverride: gitlab.example.com # Domain name
          https: false
          name: gitlab.example.com # Domain name
        ssh: gitlab.example.com # Domain name
      ingress:
        class: ""
        configureCertmanager: false
        enabled: true
        tls:
          enabled: false
      initialRootPassword:
        key: password
        secret: gitlab-root-password # Root account secret
      praefect:
        psql:
          host: 192.168.100.300 # PostgreSQL instance address
          port: 5432 # PostgreSQL instance port
          user: gitlab-user # PostgreSQL instance access user
          dbName: gitlab-praefect # PostgreSQL instance access database
          sslMode: require
        dbSecret:
          key: password # Key in the PostgreSQL instance secret that stores the password
          secret: praefect-db # Secret for the PostgreSQL database used by Gitaly cluster
        enabled: true
        virtualStorages:
          - gitalyReplicas: 3
            maxUnavailable: 1
            name: default
      psql:
        database: gitlab-db # PostgreSQL instance access database
        host: 192.168.100.300 # PostgreSQL instance address
        password:
          key: password # Key in the PostgreSQL instance secret that stores the password
          secret: gitlab-pg # PostgreSQL instance secret
        port: 5432 # PostgreSQL instance port
        username: gitlab-user # PostgreSQL instance access user
      redis:
        auth:
          enabled: true
          key: password # Key in the Redis instance secret that stores the password
          secret: gitlab-redis-password # Redis instance secret
        host: 192.168.100.200 # Redis instance address
        port: 6379 # Redis instance port
      uploads:
        persistence:
          enabled: true
          size: 10Gi # Attachment storage capacity
          storageClass: ceph # Storage class used for attachments, needs to support multi-node read-write (ReadWriteMany)

后续步骤

配置单点登录（SSO）

配置 SSO 包括以下步骤：

在 global 集群中注册 SSO 身份验证客户端
准备 SSO 身份验证配置
配置 GitLab 实例以使用 SSO 身份验证配置

在 global 集群中创建以下 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 authentication callback address, where <gitlab-host> is replaced with the GitLab instance access address
metadata:
  name: m5uxi3dbmiwwizlyzpzjzzeeeirsk # This value is calculated based on the hash of the id field, online calculator: https://go.dev/play/p/QsoqUohsKok
  namespace: cpaas-system
alignPasswordDB: true
public: false
spec: {}

字段	描述	示例
name	资源的显示名称。	OIDC
id	用于 SSO 身份验证的客户端 ID。除 alauda-dex 外可以使用任意值，alauda-dex 为保留值，可能会引发冲突。	gitlab-dex
secret	用于 SSO 身份验证的客户端 secret。可以设置为任意值。	Z2l0bGFiLW9mZmljaWFsLTAK
redirectURIs	GitLab 身份验证回调 URL，格式为 `<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 authentication address, where <platform-url> is replaced with the platform access address
   "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 authentication callback address, where <gitlab-host> is replaced with the GitLab instance access address
   }
 }
}

将配置内容保存到 secret 中，并在 GitLab 实例所在的命名空间中创建该 secret。

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-sso-config
  namespace: gitlab
type: Opaque
data:
  provider: <base64 encoded config> # Save the above configuration content base64 encoded to the provider field

编辑 GitLab 实例，添加以下配置：

spec:
  helmValues:
    global:
      appConfig:
        omniauth:
          enabled: true
          allowSingleSignOn:
            - dex
          syncProfileAttributes:
            - email
          syncProfileFromProvider:
            - dex
          blockAutoCreatedUsers: false
          providers:
            - key: provider
              secret: dex-provider # Secret containing SSO authentication configuration

为使用自签名证书的平台启用 SSO

如果平台通过 HTTPS 访问并使用自签名证书，则需要按如下方式将自签名证书的 CA 挂载到 GitLab 实例：

在 global 集群的 cpaas-system 命名空间中，找到名为 dex.tls 的 secret，从该 secret 中获取 ca.crt 内容，将其保存为新的 secret，并在 GitLab 实例所在的命名空间中创建该 secret。

证书格式

证书必须为 PEM 格式。

apiVersion: v1
data:
  ca.crt: <base64-encode a PEM-formatted certificate>
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 证书 secret。

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>

然后编辑 GitLab 实例的 YAML 配置，以启用 HTTPS 访问：

spec:
  helmValues:
    gitlab:
      webservice:
        ingress:
          enabled: true
    global:
      hosts:
        domain: gitlab.example.com # Domain name
        gitlab:
          hostnameOverride: gitlab.example.com # Domain name
          https: true # Enable HTTPS
          name: gitlab.example.com # Domain name
        ssh: gitlab.example.com # Domain name
      ingress:
        class: ""
        enabled: true
        tls:
          enabled: true # Enable HTTPS
          secretName: gitlab-tls-cert # Certificate secret name

对于通过 Gateway API 暴露的实例，TLS 会在 Gateway 处终止。请向 Gateway 添加一个引用证书 secret 的 HTTPS listener（Gateway 和该 secret 位于实例命名空间中）：

spec:
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: gitlab-tls-cert # Certificate secret name
      allowedRoutes:
        namespaces:
          from: Same

然后将路由附加到该 listener，并在 GitLab 实例中启用 HTTPS：

spec:
  externalURL: https://gitlab.example.com # Add the port if the listener is not reached on 443
  helmValues:
    gitlab:
      webservice:
        gatewayRoute:
          sectionName: https # Name of the HTTPS listener
    global:
      hosts:
        gitlab:
          https: true # Enable HTTPS

如果用户通过非 443 端口访问 HTTPS listener，还需要将 global.appConfig.gitlabPort 设置为该端口。此时，路由只会附加到 HTTPS listener，因此发送到 HTTP listener 的请求会返回 404。若要将这些请求发送到 HTTPS，请向 HTTP listener 附加一个带有 RequestRedirect 过滤器（scheme: https）的 HTTPRoute。如果两个 listener 通过非默认端口（例如 NodePort）访问，还需要在过滤器中将 port 设置为外部 HTTPS 端口；否则，重定向会保留 HTTP 端口。

配置监控面板

Alauda Toolchain Code Repository E1 operator 默认支持平台运维中心监控面板。部署 Alauda Toolchain Code Repository E1 operator 和 GitLab 实例后，GitLab Metrics 将自动配置，并可在运维中心监控面板中查看。

配置外部负载均衡器（LB）

为 GitLab 配置外部负载均衡器（LB）

GitLab 是 GitLab Inc. 的商标。

Alauda 是独立供应商。本产品与 GitLab Inc. 无关联，也未获其认可或赞助。所有商标均归其各自所有者所有，仅用于标识目的。

GitLab 实例部署#

#目录

#前提条件

#部署规划

#基本信息

#部署前资源规划

#部署后配置规划

#实例部署

#从 GitLab Quick Start 模板部署

#从 GitLab High Availability 模板部署

#从 YAML 部署

#基于部署规划的 YAML 片段

#高可用

#存储

#网络访问

#Gateway API 访问

#Redis 访问凭证配置

#PostgreSQL 访问凭证配置

#Root 账户配置

#完整 YAML 示例：单实例、节点存储、NodePort 网络访问

#完整 YAML 示例：高可用、存储类、Ingress 网络访问

#后续步骤

#配置单点登录（SSO）

#配置 HTTPS

#配置监控面板

#配置外部负载均衡器（LB）