使用 Globals 配置 chart

为了在安装 Helm chart 时减少重复配置，可以在 values.yaml 的 global 部分进行一些全局配置。这些全局配置跨多个 chart 使用，其它设置都在各个 chart 自己的范围内。有关全局变量如何工作的更多信息，请查看 Helm 全局配置文档。

Host 配置

全局 host 配置位于 global.hosts 设置之下： 

global:
  hosts:
    domain: example.com
    hostSuffix: staging
    https: false
    externalIP:
    gitlab:
      name: gitlab.example.com
      https: false
    registry:
      name: registry.example.com
      https: false
    minio:
      name: minio.example.com
      https: false
    smartcard:
      name: smartcard.example.com
    kas:
      name: kas.example.com
    pages:
      name: pages.example.com
      https: false
    ssh: gitlab.example.com
名称 类型 默认值 说明
domain String example.com 基础域名。GitLab 和 Registry 在其子域名中暴露。默认值为 example.com，不适用于配置了 name 属性的 hosts。请查看下面的 gitlab.name、minio.name 和 registry.name 的说明。
externalIP   nil 设置云提供商生命的外部 IP 地址。将被模板化到 NGINX chart 中，代替更复杂的 nginx.service.loadBalancerIP。
https Boolean true 如果设置为 true, 您需要确保 NGINX chart 可以访问证书。如果您的 Ingress 前有 TLS 终止，您可能需要查看 global.ingress.tls.enabled。如果要外部 URL 使用 http:// 而不是 https，设置为 false。
hostSuffix String   查看下面的主机后缀文档。
gitlab.https Boolean false 如果 hosts.https 或 gitlab.https 设置为 true，gitlab 的外部 URL 将使用 https:// 而不是 http://。
gitlab.name String   gitlab 的主机名。如果设置了该值，则使用此主机名，无论 global.hosts.domain 和 global.hosts.hostSuffix 设置为何。
gitlab.hostnameOverride String   覆盖 Webservice 的 Ingress 配置中使用的主机名。如果存在必须将主机名重写为内部主机名的 WAF （例如：gitlab.example.com –> gitlab.cluster.local），且 gitlab 必须在其后，设置该值很有用。
gitlab.serviceName String webservice 运行 gitlab 服务器的 service 名称。chart 将模板化服务的主机名（和当前的 .Release.Name），以创建正确的内部 serviceName。
gitlab.servicePort String workhorse 可以用于访问 gitlab 服务器的命名端口。
minio.https Boolean false 如果 hosts.https 或 minio.https 设置为 true，MinIO 的外部 URL 将使用 https:// 而不是 http://。
minio.name String minio MinIO 的主机名。如果设置了该值，则使用此主机名，无论 global.hosts.domain 和 global.hosts.hostSuffix 设置为何。
minio.serviceName String minio 运行 MinIO 服务器的 service 名称。chart 将模板化服务的主机名（和当前的 .Release.Name），以创建正确的内部 serviceName。
minio.servicePort String minio 可以用于访问 MinIO 服务器的命名端口。
registry.https Boolean false 如果 hosts.https 或 gitlab.https 设置为 true，Registry 的外部 URL 将使用 https:// 而不是 http://。
registry.name String registry Registry 的主机名。如果设置了该值，则使用此主机名，无论 global.hosts.domain 和 global.hosts.hostSuffix 设置为何。
registry.serviceName String registry 运行 Registry 服务器的 service 名称。chart 将模板化服务的主机名（和当前的 .Release.Name），以创建正确的内部 serviceName。
registry.servicePort String registry 可以用于访问 Registry 服务器的命名端口。
smartcard.name String smartcard smartcard 认证的主机名。如果设置了该值，则使用此主机名，无论 global.hosts.domain 和 global.hosts.hostSuffix 设置为何。
kas.name String kas KAS 的主机名。如果设置了该值，则使用此主机名，无论 global.hosts.domain 和 global.hosts.hostSuffix 设置为何。
kas.https Boolean false 如果 hosts.https 或 gitlab.https 设置为 true，KAS 的外部 URL 将使用 wss:// 而不是 ws://。
pages.name String pages GitLab Pages 的主机名。如果设置了该值，则使用此主机名，无论 global.hosts.domain 和 global.hosts.hostSuffix 设置为何。
pages.https String   如果 global.pages.https 或 global.hosts.pages.https 或 global.hosts.https 设置为 true, 项目设置 UI 中 GitLab Pages 使用的 URL 将 使用 https:// 而不是 http://。
ssh String   通过 SSH 克隆仓库的主机名。如果设置，则使用此主机名，无论 global.hosts.domain 和 global.hosts.hostSuffix 设置为何。

hostSuffix

在使用基本域名组成主机名时，hostSuffix 附加到子域，但不用于具有自己 name 集的主机。

默认为未设置。如果设置，后缀将使用连字符附加到子域。下面的示例配置的外部域名例如 gitlab-staging.example.com 和 registry-staging.example.com： 

global:
  hosts:
    domain: example.com
    hostSuffix: staging

配置 Horizontal Pod Autoscaler 设置

HPA 的极狐GitLab 全局主机设置位于 global.hpa 键下：

名称 类型 默认值 说明
apiVersion String   在 HorizontalPodAutoscaler 对象定义中使用的 API 版本。

配置 PodDisruptionBudget 设置

PDB 的极狐GitLab 全局 host 设置位于 global.pdb 键下：

名称 类型 默认值 说明
apiVersion String   API version to use in the PodDisruptionBudget object definitions.

配置 CronJob 设置

CronJobs 的极狐GitLab 全局 host 设置位于 global.batch.cronJob 键下：

名称 类型 默认值 说明
apiVersion String   API version to use in the CronJob object definitions.

Ingress 配置

全局 Ingress 配置位于 global.ingress 设置之下：

名称 类型 默认值 说明
apiVersion String   在 Ingress 对象定义中使用的 API 版本。
annotations.*annotation-key* String   annotation-key 是一个字符串，与该值一起作为每个 Ingress 的 annotation。例如：global.ingress.annotations."nginx\.ingress\.kubernetes\.io/enable-access-log"=true。默认不提供全局 annotation。
configureCertmanager Boolean true 查看下面的文档.
class String gitlab-nginx 控制 Ingress 资源中 kubernetes.io/ingress.class annotation 的全局设置。控制 kubernetes.io/ingress.class annotation 或 Ingress 资源中的 spec.IngressClassName 的全局设置。 设置为 none 可以禁用，或设置为 "" 为空。注意：对于 none 或 ""，设置 nginx-ingress.enabled=false 来防止 Charts 部署不必要的 Ingress 资源。
enabled Boolean true 控制是否创建支持 services 的 Ingress 对象的全局设置。
tls.enabled Boolean true 当设置为 false 时，在极狐GitLab 中禁用 TLS。这对于不能使用 Ingress 的 TLS 终止的情况很有用，例如在 Ingress Controller 之前有一个 TLS 终止代理时。如果您想完全禁用 https，应该和 global.hosts.https 一起设置为 false。
tls.secretName String   Kubernetes TLS Secret 的名称，该 Secret 包含用于 global.hosts.domain 中设置的域名的 全局 证书和密钥。
path String / Ingress 对象 中 path 条目的默认值。
pathType String Prefix Path Type 允许您指定路径的匹配方式。当前的默认值为 Prefix，但您可以根据使用情况使用 ImplementationSpecific 或 Exact。
provider String nginx 定义使用的 Ingress provider。nginx 是默认的 provider。

Ingress Path

该 chart 使用 global.ingress.path 作为更改 Ingress 对象的 path 条目的方法。大部分用户不需要该设置，不应该进行配置。

对于那些需要将 path 定义用 /* 结尾以匹配其负载均衡器或代理的用户，例如在 GCP 中使用 ingress.class: gce，在 AWS 中使用 ingress.class: alb，或其它类似提供商。该设置确保整个 chart 的 Ingress 中的所有 path 条目都使用该设置。唯一的例外是 gitlab/webservice deployments 设置，必须指定 path。

云提供商负载均衡器

多种云提供商的 LoadBalancer 实现对 Ingress 资源的配置和作为 chart 一部分部署的 NGINX 控制器有影响。下表提供了示例。

云提供商 Layer 示例
AWS 4 aws/elb-layer4-loadbalancer
AWS 7 aws/elb-layer7-loadbalancer
AWS 7 aws/alb-full

global.ingress.configureCertmanager

控制自动配置 Ingress 对象的 cert-manager 。如果设置为 true，依赖于设置的 certmanager-issuer.email。

如果设置为 false 并且 global.ingress.tls.secretName 未设置，这将激活自动自签名证书的生成，即为所有 Ingress 对象创建 通配符 证书。

如果您希望使用外部 cert-manager，您必须提供以下内容：

  • gitlab.webservice.ingress.tls.secretName
  • registry.ingress.tls.secretName
  • minio.ingress.tls.secretName
  • global.ingress.annotations

极狐GitLab 版本

note该值仅用于开发目的，或应技术支持的要求使用。请避免在生产环境中使用此值，并按照 使用 Helm 部署文档 所述设置版本。

可以使用 global.gitlabVersion 键，更改默认镜像 tag 中使用的极狐GitLab 版本： 

--set global.gitlabVersion=11.0.1

这会影响 webservice、sidekiq 和 migration chart 的默认镜像 tag。注意 gitaly、gitlab-shell 和 gitlab-runner 的镜像标签应分别更新为与极狐GitLab 版本兼容的版本。

PostgreSQL 设置

全局 PostgreSQL 配置位于 global.psql 设置之下： 

global:
  psql:
    host: psql.example.com
    # serviceName: pgbouncer
    port: 5432
    database: gitlabhq_production
    username: gitlab
    applicationName:
    preparedStatements: false
    databaseTasks: true
    connectTimeout:
    keepalives:
    keepalivesIdle:
    keepalivesInterval:
    keepalivesCount:
    tcpUserTimeout:
    password:
      useSecret: true
      secret: gitlab-postgres
      key: psql-password
      file:
名称 类型 默认值 说明
host String   要使用数据库所在的 PostgreSQL 服务器的主机名。如果使用本 chart 部署的 PostgreSQL，则可以省略此项。
serviceName String   运行 PostgreSQL 数据库的 service 的名称。如果该配置存在，且 host 的值不存在 , 则 chart 将服务的主机名替换 host 的值。
database String gitlabhq_production 要在 PostgreSQL 服务器上使用的数据库的名称。
password.useSecret Boolean true 控制从 Secret 还是从文件中读取密码。
password.file String   定义包含 PostgreSQL 密码的文件路径。如果 password.useSecret 设置为 true，则忽略该配置。
password.key String   定义 Secret 中包含密码的 key 的名称。如果 password.useSecret 设置为 false，则忽略该配置。
password.secret String   定义要拉取的 Kubernetes Secret 的名称，如果 password.useSecret 设置为 false，则忽略该配置。
port Integer 5432 连接 PostgreSQL 服务器的端口。
username String gitlab 用于对数据库进行身份验证的用户名。
preparedStatements Boolea false 在与 PostgreSQL 服务器通信时，是否使用 prepared statements。
databaseTasks Boolean true 极狐GitLab 是否应该为特定的数据库执行数据库任务。共享 host/端口/数据库匹配 main 时自动禁用。
connectTimeout Integer   数据库连接的等待秒数。
keepalives Integer   Controls whether client-side TCP keepalives are used (1, meaning on, 0, meaning off).
keepalivesIdle Integer   TCP 应向服务器发送 keepalive 消息之前的非活动秒数。零值使用系统默认值。
keepalivesInterval Integer   应重新传输未被服务器确认的 TCP 保持连接消息的秒数。 零值使用系统默认值。
keepalivesCount Integer   在客户端与服务器的连接被视为死亡之前可能丢失的 TCP 保持连接数。 零值使用系统默认值。
tcpUserTimeout Integer   在连接被强制关闭之前，传输的数据可能保持未被确认的毫秒数。 零值使用系统默认值。
applicationName String   连接数据库的应用程序名称。设置为空字符串 ("") 表示禁用。默认情况下，将设置为正在运行的进程的名称 (例如 sidekiq, puma) 。
ci.enabled Boolean Not defined 启用两个数据库连接。

PostgreSQL per chart

在一些复杂的部署中，可能需要使用不同的 PostgreSQL 配置对应 chart 的不同部分。从 v4.2.0 开始，global.psql 中可用的所有属性可以以每个 chart 为基础进行配置，例如 gitlab.sidekiq.psql。如果提供了本地设置，将覆盖全局配置值，并继承任何_不存在于_ global.psql 的值，psql.load_balancing 除外。

按照设计，PostgreSQL 负载均衡 从不 继承全局配置值。

PostgreSQL SSL

noteSSL 支持仅限于双向 TLS。

如果要通过双向 TLS 连接 PostgreSQL 数据库和极狐GitLab，创建一个 Secret，包含客户端密钥、客户端证书和服务器证书颁发机构作为不同的 key。然后使用 global.psql.ssl 映射描述 Secret 的结构。 

global:
  psql:
    ssl:
      secret: db-example-ssl-secrets # Name of the secret
      clientCertificate: cert.pem    # Secret key storing the certificate
      clientKey: key.pem             # Secret key of the certificate's key
      serverCA: server-ca.pem        # Secret key containing the CA for the database server
名称 类型 默认值 说明
secret String   包含以下 key 的 Kubernetes Secret 的名称。
clientCertificate String   在 Secret 中，包含客户端证书的 key 的名称。
clientKey String   在 Secret 中，包含客户端证书密码文件的 key 的名称。
serverCA String   在 Secret 中，包含服务器证书颁发机构的 key 的名称。

您可能还需要设置 extraEnv 值，使导出环境值指向正确的键。 

global:
  extraEnv:
      PGSSLCERT: '/etc/gitlab/postgres/ssl/client-certificate.pem'
      PGSSLKEY: '/etc/gitlab/postgres/ssl/client-key.pem'
      PGSSLROOTCERT: '/etc/gitlab/postgres/ssl/server-ca.pem'

PostgreSQL 负载均衡

该特性功能需要使用 外部 PostgreSQL，因为 chart 在 HA 模式下不会部署 PostgreSQL。Rails 组件能够利用 PostgreSQL 集群对只读查询进行负载均衡。

该特性可以通过两种方式配置：

  • 使用域名静态列表作为辅助。
  • 使用基于 DNS 的服务发现机制。

带有静态列表的配置如下： 

global:
  psql:
    host: primary.database
    load_balancing:
       hosts:
       - secondary-1.database
       - secondary-2.database

服务发现的配置可能更复杂。有关配置、参数及相关操作的详细信息，请查看服务发现文档 

global:
  psql:
    host: primary.database
    load_balancing:
      discover:
        record:  secondary.postgresql.service.consul
        # record_type: A
        # nameserver: localhost
        # port: 8600
        # interval: 60
        # disconnect_timeout: 120
        # use_tcp: false
        # max_replica_pools: 30

关于处理陈旧数据，还可以进行进一步修改。管理中心文档详细介绍了相关信息，这些属性可以直接添加到 load_balancing 下。 

global:
  psql:
    load_balancing:
      max_replication_difference: # See documentation
      max_replication_lag_time:   # See documentation
      replica_check_interval:     # See documentation

配置多个数据库连接

gitlab:db:decomposition:connection_status Rake 任务引入于 15.11 版本。

在 16.0 版本中，极狐GitLab 默认使用两个数据库连接指向同一个 PostgreSQL 数据库。

要选择加入此功能，您首先需要确保 PostgreSQL 的 max_connections 足够高（使用超过可用最大连接数的 50%）。您可以通过使用 Toolbox 容器 运行以下 Rake 任务来验证：

如果您希望切换回单一数据库连接，请将 ci.enabled 键设置为 false： 

global:
  psql:
    ci:
      enabled: false

Redis 配置

全局 Redis 配置位于 global.redis 设置之下。

默认情况下使用单个、非复制的 Redis 实例。如果需要，可以改为部署高度可用的 Redis。要安装 HA Redis 集群，需要在安装极狐GitLab chart 时设置 redis.cluster.enabled=true。

您可以通过设置 redis.install=false，并按照我们的高级配置文档进行配置，带入一个外部 Redis 实例。 

global:
  redis:
    host: redis.example.com
    serviceName: redis
    port: 6379
    auth:
      enabled: true
      secret: gitlab-redis
      key: redis-password
    scheme:
名称 类型 默认值 说明
host String   要使用数据库所在的 Redis 服务器的主机名。可以省略，使用 serviceName 进行代替。
serviceName String redis 运行 Redis 数据库的 service名称。如果该配置存在，且 host 的值不存在 , 则 chart 将服务的主机名替换 host 的值。这样使用 Redis 作为整个 chart 一部分时很方便。
port Integer 6379 连接 Redis 服务器的端口。
user String   用于对 Redis (Redis 6.0+) 进行身份验证的用户。
password.enabled Boolean true 提供了是否在 Redis 实例中使用密码的切换功能。
password.key String   定义 Secret 中包含密码的 key 的名称。
password.secret String   定义要拉取的 Kubernetes Secret 的名称。
scheme String redis 用于生成 Redis URL 的 URI 方案。有效值为 redis、rediss 和 tcp。如果使用 rediss（SSL 加密连接）方案，服务器使用的证书应该是系统可信链的一部分。可以通过将它们添加到自定义证书颁发机构列表来完成。

Redis 特定 chart 配置

直接在 redis 键下，配置 Redis chart： 

redis:
  install: true
  image:
    registry: registry.example.com
    repository: example/redis
    tag: x.y.z

有关更多信息，请参考完整参数列表。

Redis Sentinel support

当前仅支持 Sentinel 与 极狐GitLab 分开部署。这样，应该使用 redis.install=false 禁用通过 chart 部署 Redis 。在部署 chart 之前，需要手动创建包含 Redis 密码的 Kubernetes Secret。

从 chart 安装 HA Redis 集群不支持使用 sentinels。如果希望使用 sentinel support，Redis 集群需要与 chart 分开创建。可以在 Kubernetes 集群内部或外部完成。

redis:
  install: false
global:
  redis:
    host: redis.example.com
    serviceName: redis
    port: 6379
    sentinels:
      - host: sentinel1.example.com
        port: 26379
      - host: sentinel2.exeample.com
        port: 26379
    auth:
      enabled: true
      secret: gitlab-redis
      key: redis-password
名称 类型 默认值 说明
host String   需要设置为在 sentinel.conf 中指定的集群名称。
sentinels.[].host String   用于 Redis HA 设置的 Redis Sentinel 服务器的主机名。
sentinels.[].port Integer 26379 连接 Redis Sentinel 服务器的端口。

除非重新指定上表中的属性，否则常规 Redis 配置中的所有之前配置的 Redis 属性将继续适用于 Sentinel support。

多 Redis 支持

极狐GitLab chart 支持针对不同的持久化类，使用单独的 Redis 实例运行，目前包括：

实例 目的
cache 存储缓存数据
queues 存储 Sidekiq 后台任务
sharedState 存储分布式锁等各种持久化数据
actioncable ActionCable 的发布/订阅后端队列
traceChunks 临时存储作业跟踪
rateLimiting 存储 RackAttack 和 Application Limits 的速率限制使用情况
sessions 存储用户会话数据
repositoryCache 存储代码库相关数据

可以指定任意数量的实例。任何未指定的实例将由指定的主 Redis 实例处理，主 Redis 通过 global.redis.host 指定，或使用 chart 部署 Redis 实例。 例如： 

redis:
  install: false
global:
  redis:
    host: redis.example
    port: 6379
    auth:
      enabled: true
      secret: redis-secret
      key: redis-password
    cache:
      host: cache.redis.example
      port: 6379
      auth:
        enabled: true
        secret: cache-secret
        key: cache-password
    sharedState:
      host: shared.redis.example
      port: 6379
      auth:
        enabled: true
        secret: shared-secret
        key: shared-password
    queues:
      host: queues.redis.example
      port: 6379
      auth:
        enabled: true
        secret: queues-secret
        key: queues-password
    actioncable:
      host: cable.redis.example
      port: 6379
      auth:
        enabled: true
        secret: cable-secret
        key: cable-password
    traceChunks:
      host: traceChunks.redis.example
      port: 6379
      auth:
        enabled: true
        secret: traceChunks-secret
        key: traceChunks-password
    rateLimiting:
      host: rateLimiting.redis.example
      port: 6379
      auth:
        enabled: true
        secret: rateLimiting-secret
        key: rateLimiting-password
    sessions:
      host: sessions.redis.example
      port: 6379
      auth:
        enabled: true
        secret: sessions-secret
        key: sessions-password
    repositoryCache:
      host: repositoryCache.redis.example
      port: 6379
      auth:
        enabled: true
        secret: repositoryCache-secret
        key: repositoryCache-password

下表描述了 Redis 实例中的属性。

名称 类型 默认值 说明
.host String   要使用数据库所在的 Redis 服务器的主机名。
.port Integer 6379 连接 Redis 服务器的端口。
.auth.enabled Boolean true 提供了是否在 Redis 实例中使用密码的切换功能。
.auth.key String   定义 Secret 中包含密码的 key 的名称。
.auth.secret String   定义要拉取的 Kubernetes Secret 的名称。

需要定义主 Redis，因为还有未分开的其它持久化类。

每个实例定义也可能使用 Redis Sentinel support。Sentinel 配置不共享，需要为每个使用 Sentinels 的实例指定。关于配置 Sentinel 服务器的属性，请参考 Sentinel 配置文档。

指定 Redis 安全方案 (SSL)

要使用 SSL 连接到 Redis：

  1. 更新您的配置以使用 rediss（两个 s）方案参数。

  2. 在您的配置中，将 authClients 设置为 false： 

    global:
  redis:
    scheme: rediss
redis:
  tls:
    enabled: true
    authClients: false

    此配置是必需的，因为 Redis 默认为双向 TLS，并非所有 chart 组件都支持。

  3. 遵循 Bitnami 的启用 TLS 的步骤。确保 chart 组件信任用于创建 Redis 证书的证书颁发机构。
  4. 可选。如果您使用自定义证书颁发机构，请参阅自定义证书颁发机构全局配置。

无密码 Redis 服务器

某些 Redis 服务（例如 Google Cloud Memorystore）不使用密码和关联的 AUTH 命令。可以通过以下配置设置禁用密码的使用和要求： 

global:
  redis:
    auth:
      enabled: false
    host: ${REDIS_PRIVATE_IP}
redis:
  enabled: false

Registry 配置

全局 Registry 设置位于 global.registry 下。 

global:
  registry:
    bucket: registry
    certificate:
    httpSecret:
    notificationSecret:
    notifications: {}
    ## Settings used by other services, referencing registry:
    enabled: true
    host:
    api:
      protocol: http
      serviceName: registry
      port: 5000
    tokenIssuer: gitlab-issuer

有关 bucket、certificate、httpSecret 和 notificationSecret 设置的更多详细信息，请参阅 Registry chart 文档。

有关 enabled、host、api 和 tokenIssuer 的详细信息，请参阅命令行选项和 webcervice 的文档。

host 用于覆盖自动生成的外部镜像库主机名引用。

通知

该设置用于配置 Registry 通知。参考以下示例片段，其中 Authorization header 包含敏感数据，其它 header 包含常规数据：

global:
  registry:
    notifications:
      events:
        includereferences: true
      endpoints:
        - name: CustomListener
          url: https://mycustomlistener.com
          timeout: 500mx
          threshold: 5
          backoff: 1s
          headers:
            X-Random-Config: [plain direct]
            Authorization:
              secret: registry-authorization-header
              key: password

在该示例中，X-Random-Config header 是 regular header，它的值由 values.yaml 文件的 plaintext 或通过 --set flag 提供。然而，Authorization header 是敏感的，因此最好从 Kubernetes Secret 挂载它。有关 Secret 结构的详细信息，请参考 Secret 文档。

Gitaly 配置

全局 Gitaly 设置位于 global.gitaly 下。 

global:
  gitaly:
    internal:
      names:
        - default
        - default2
    external:
      - name: node1
        hostname: node1.example.com
        port: 8075
    authToken:
      secret: gitaly-secret
      key: token
    tls:
      enabled: true
      secretName: gitlab-gitaly-tls

Gitaly hosts

Gitaly 是一项提供对 Git 仓库的高级 RPC 访问的服务，该服务处理极狐GitLab 发出的所有 Git 调用。

管理员可以通过以下方式选择使用 Gitaly 节点：

有关管理新项目要使用的节点的详细信息，查看 仓库存储路径文档。

如果提供了 gitaly.host，gitaly.internal 和 gitaly.external 属性会被 忽略。 查看 废弃的 Gitaly 配置。

此时所有 Gitaly 服务，无论内部或外部，Gitaly 身份验证令牌都是相同的，确保它们对齐。

Internal

internal 下目前只有一个键，即 names，它是一个由 chart 管理的 存储名称 列表。对于每个列出的名称，按逻辑顺序，将生成一个名为 ${releaseName}-gitaly-${ordinal} 的 pod，其中 ordinal 是 names 列表中的索引。如果启用了动态配置，会匹配 PersistentVolumeClaim。

该列表默认为 ['default']，它提供了与一个 存储路径 相关的 1 个 pod。

Manual scaling of this item is required, by adding or removing entries in 在 gitaly.internal.names 中添加或删除条目，可以在需要时扩缩容。当缩容时，任何还未移动到另一节点的仓库都将不可用。由于 chart 是一个 StatefulSet，动态配置的磁盘 不会 被回收，意味着数据磁盘将持久化，当重新添加节点到 names 列表中并再次扩容时，上面的数据仍然可以访问。

您可以在示例文件夹中找到多个内部节点的配置示例。

External

external 为集群外部的 Gitaly 节点提供配置。这个列表的每一项都有 3 个键:key provides a configuration for Gitaly nodes external to the cluster. Each item of this list has 3 keys:

  • name：存储的名称，需要带有 name: default 的条目。
  • hostname：Gitaly 服务的主机。
  • port：（可选）到达主机的端口号。默认为 8075。
  • tlsEnabled：（可选）为特定条目覆盖 global.gitaly.tls.enabled 的值。

我们为使用外部 Gitaly 服务 提供高级配置指南。

您可以使用外部 Praefect 提供高可用的 Gitaly 服务。两者配置可以互换，从使用者角度看，没有区别。

Mixed

支持同时使用 internal 和 external Gitaly 节点，请注意：

  • 必须始终具有名称为 default 的 Internal 默认节点。
  • 先对外暴露 External 节点，然后是 Internal 节点。

可以在示例文件夹中，找到混合 internal 和 external 节点的实例配置。

authToken

Gitaly 的 authToken 属性有两个子键：

  • secret 定义要拉取的 Kubernetes Secret 的名称。
  • key 定义 Secret 中包含 authToken 的 键的名称。

所有 Gitaly 节点必须共享相同的 authentication token。

废弃的 Gitaly 设置

名称 类型 默认值 说明
host (deprecated) String   Gitaly 服务器使用的主机名。可以省略，使用 serviceName 进行代替。如果设置该值，将覆盖 internal 或 external 的任何值。
port (deprecated) Integer 8075 连接 Gitaly 服务器使用的端口。
serviceName (deprecated) String   运行 Gitaly 服务器的 service 名称。 果该配置存在，且 host 的值不存在 , 则 chart 将服务的主机名（当前为 .Release.Name）替换 host 的值。这样使用 Gitaly 作为整个 chart 一部分时很方便。

TLS 设置

查看 Gitaly chart 文档，获取如何配置通过 TLS 使用 Gitaly 的详细信息。

Praefect 配置

全局 Praefect 配置位于 global.praefect 键下。

默认情况下禁用 Praefect。启用时如果无额外配置，将创建 3 个 Gitaly 副本，并且需要在 PostgreSQL 实例上手动创建 Praefect 数据库。

启用 Praefect

要使用默认设置启用 Praefect，请设置 global.praefect.enabled=true。

Praefect 全局设置 

global:
  praefect:
    enabled: false
    virtualStorages:
    - name: default
      gitalyReplicas: 3
      maxUnavailable: 1
    dbSecret: {}
    psql: {}
名称 类型 默认值 说明
enabled Boolean false 是否启用 Praefect
virtualStorages List 所需的虚拟存储列表（每个都由 Gitaly StatefulSet 支持）
dbSecret.secret String   用于数据库认证的 Secret 名称
dbSecret.key String   在 dbSecret.secret 中，要使用的键的名称
psql.host String   要使用的数据库服务器的主机名（使用外部数据库时）
psql.port String   数据库服务器的端口（使用外部数据库时）
psql.user String praefect 要使用的数据库用户
psql.dbName String praefect 要使用的数据库的名称

MinIO 配置

全局 MinIO 配置位于 global.minio 键下。查看 MinIO chart 文档，获取更多相关配置信息。 

global:
  minio:
    enabled: true
    credentials: {}

appConfig 配置

Webservice、Sidekiq 和 Gitaly chart 共享 global.appConfig 键下的多个配置。 

global:
  appConfig:
    # cdnHost:
    contentSecurityPolicy:
      enabled: false
      report_only: true
      # directives: {}
    enableUsagePing: true
    enableSeatLink: true
    enableImpersonation: true
    applicationSettingsCacheSeconds: 60
    usernameChangingEnabled: true
    issueClosingPattern:
    defaultTheme:
    defaultProjectsFeatures:
      issues: true
      mergeRequests: true
      wiki: true
      snippets: true
      builds: true
      containerRegistry: true
    webhookTimeout:
    gravatar:
      plainUrl:
      sslUrl:
    extra:
      googleAnalyticsId:
      matomoUrl:
      matomoSiteId:
      matomoDisableCookies:
      oneTrustId:
      googleTagManagerNonceId:
      bizible: 
    object_store:
      enabled: false
      proxy_download: true
      storage_options: {}
      connection: {}
    lfs:
      enabled: true
      proxy_download: true
      bucket: git-lfs
      connection: {}
    artifacts:
      enabled: true
      proxy_download: true
      bucket: gitlab-artifacts
      connection: {}
    uploads:
      enabled: true
      proxy_download: true
      bucket: gitlab-uploads
      connection: {}
    packages:
      enabled: true
      proxy_download: true
      bucket: gitlab-packages
      connection: {}
    ciSecureFiles:
      enabled: false
      bucket: gitlab-ci-secure-files
      connection: {}
    externalDiffs:
      enabled:
      when:
      proxy_download: true
      bucket: gitlab-mr-diffs
      connection: {}
    terraformState:
      enabled: false
      bucket: gitlab-terraform-state
      connection: {}
    dependencyProxy:
      enabled: false
      bucket: gitlab-dependency-proxy
      connection: {}
    backups:
      bucket: gitlab-backups
    microsoft_graph_mailer:
      enabled: false
      user_id: "YOUR-USER-ID"
      tenant: "YOUR-TENANT-ID"
      client_id: "YOUR-CLIENT-ID"
      client_secret:
        secret:
        key: secret
      azure_ad_endpoint: "https://login.microsoftonline.com"
      graph_endpoint: "https://graph.microsoft.com"
    incomingEmail:
      enabled: false
      address: ""
      host: "imap.gmail.com"
      port: 993
      ssl: true
      startTls: false
      user: ""
      password:
        secret:
        key: password
      mailbox: inbox
      idleTimeout: 60
      inboxMethod: "imap"
      clientSecret:
        key: secret
      pollInterval: 60
      deliveryMethod: webhook
      authToken: {}

    serviceDeskEmail:
      enabled: false
      address: ""
      host: "imap.gmail.com"
      port: 993
      ssl: true
      startTls: false
      user: ""
      password:
        secret:
        key: password
      mailbox: inbox
      idleTimeout: 60
      inboxMethod: "imap"
      clientSecret:
        key: secret
      pollInterval: 60
      deliveryMethod: webhook
      authToken: {}

    cron_jobs: {}
    sentry:
      enabled: false
      dsn:
      clientside_dsn:
      environment:
    gitlab_docs:
      enabled: false
      host: ""
    smartcard:
      enabled: false
      CASecret:
      clientCertificateRequiredHost:
    sidekiq:
      routingRules: []

一般应用程序设置

可用于调整 Rails 应用程序常规属性的 appConfig 设置如下表所述：

名称 类型 默认值 说明
cdnHost String (empty) 设置 CDN 的基本 URL，提供静态 asset（例如，https://mycdnsubdomain.fictional-cdn.com）。
contentSecurityPolicy Struct   查看下方的文档。
enableUsagePing Boolean true 是否启用 usage ping support。
enableSeatLink Boolean true 是否启用 seat link support。
enableImpersonation   nil 是否启用管理员模拟用户。
applicationSettingsCacheSeconds Integer 60 应用程序设置缓存无效的间隔值（以秒为单位）
usernameChangingEnabled Boolean true 是否允许用户修改用户名。
issueClosingPattern String (empty) 自动关闭议题的模式。
defaultTheme Integer   实例的默认主题的数字 ID。使用一个数字表示主题的 ID。
defaultProjectsFeatures.*feature* Boolean true 查看下方的文档.
webHookTimeout Integer   hook 被认为失败之前的等待时间。

Content Security Policy

设置 Content Security Policy（CSP）可以帮助组织 JavaScript 跨站点脚本（XSS）攻击。查看Content Security Policy 文档，获取有关配置详细信息。

极狐GitLab 自动为 CSP 提供安全的默认值。 

global:
  appConfig:
    contentSecurityPolicy:
      enabled: true
      report_only: false

添加自定义 CSP： 

global:
  appConfig:
    contentSecurityPolicy:
      enabled: true
      report_only: false
      directives:
        default_src: "'self'"
        script_src: "'self' 'unsafe-inline' 'unsafe-eval' https://www.recaptcha.net https://apis.google.com"
        frame_ancestors: "'self'"
        frame_src: "'self' https://www.recaptcha.net/ https://content.googleapis.com https://content-compute.googleapis.com https://content-cloudbilling.googleapis.com https://content-cloudresourcemanager.googleapis.com"
        img_src: "* data: blob:"
        style_src: "'self' 'unsafe-inline'"

不正确地配置 CSP 规则可能会阻止 GitLab 组件正常工作。在实施策略之前，您可能还需要将 report_only 更改为 true，以测试配置。

defaultProjectsFeatures

用于决定创建新项目时，是否使用相应功能的标记。所有标记的默认值为 true。 

defaultProjectsFeatures:
  issues: true
  mergeRequests: true
  wiki: true
  snippets: true
  builds: true
  containerRegistry: true

Gravatar/Libravatar 设置

默认情况下，chart 使用 gravatar.com 上的 Gravatar 头像服务。 但是如果需要，也可以使用自定义的 Libravatar 服务：

名称 类型 默认值 说明
gravatar.plainURL String (empty) 指向 Libravatar 实例的 HTTP URL（而不是使用 gravatar.com）。
gravatar.sslUrl String (empty) 指向 Libravatar 实例的 HTTPS URL（而不是使用 gravatar.com）。

整合对象存储

除了以下描述如何为对象存储进行单独设置的部分之外，我们还添加了一个统一对象存储配置，以简化这些项目的共享配置的使用。使用 object_store，你您以配置一个 connection，它将用于没有单独配置 connection 属性的对象存储中，任何或所有支持的功能。 

  enabled: true
  proxy_download: true
  storage_options:
  connection:
    secret:
    key:
名称 类型 默认值 说明
enabled Boolean false 启用统一对象存储的使用。
proxy_download Boolean true 通过 GitLab 启用所有下载的代理，而不是从 bucket 直接下载。
storage_options String {} 查看下方文档。
connection String {} 查看下方文档。

属性结构是共享的，这里的所有属性都可以被下面的单个配置项覆盖。 connection 属性结构是相同的。

注意： 如果您希望偏离默认值，bucket、enabled 和 proxy_download 属性是唯一必须在每个配置项级别（global.appConfig.artifacts.bucket，…）配置的属性。

当将 AWS 提供程序用于 connection（这是任何与 S3 兼容的提供商，例如包含的 MinIO）时，GitLab Workhorse 可以卸载所有与存储相关的上传。 使用统一配置时，自动为您启用。

指定存储桶

每个对象类型应存储在不同的桶中。默认情况下，不同的对象类型使用如下存储桶名称：

对象类型 存储桶名称
CI artifacts gitlab-artifacts
Git LFS git-lfs
Packages gitlab-packages
Uploads gitlab-uploads
External merge request diffs gitlab-mr-diffs
Terraform State gitlab-terraform-state
CI Secure Files gitlab-ci-secure-files
Dependency Proxy gitlab-dependency-proxy
Pages gitlab-pages

您可以使用这些默认值或自行配置存储桶名称： 

--set global.appConfig.artifacts.bucket=<BUCKET NAME> \
--set global.appConfig.lfs.bucket=<BUCKET NAME> \
--set global.appConfig.packages.bucket=<BUCKET NAME> \
--set global.appConfig.uploads.bucket=<BUCKET NAME> \
--set global.appConfig.externalDiffs.bucket=<BUCKET NAME> \
--set global.appConfig.terraformState.bucket=<BUCKET NAME> \
--set global.appConfig.ciSecureFiles.bucket=<BUCKET NAME> \
--set global.appConfig.dependencyProxy.bucket=<BUCKET NAME>

storage_options

storage_options 用于配置 S3 服务器端加密。

启用加密的最简单方法是在 S3 存储桶上设置默认加密，但您可能需要设置存储桶策略以确保只上传加密对象。 为此，您必须在 storage_options 区域设置发送正确的加密 header：

设置 说明
server_side_encryption 加密模式（AES256 或 aws:kms）
server_side_encryption_kms_key_id Amazon 资源名称，只有当 server_side_encryption 为 aws:kms 时需要设置，查看 使用 KMS 加密的 Amazon 文档

示例如下： 

  enabled: true
  proxy_download: true
  connection:
    secret: gitlab-rails-storage
    key: connection
  storage_options:
    server_side_encryption: aws:kms
    server_side_encryption_kms_key_id: arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

LFS, Artifacts, Uploads, Packages, External MR diffs, and Dependency Proxy

这些设置的详细信息如下。文档不会单独重复，因为除了 bucket 属性的默认值之外，它们在结构上是相同的。 

  enabled: true
  proxy_download: true
  bucket:
  connection:
    secret:
    key:
名称 类型 默认值 说明
enabled Boolean 对于 LFS, artifacts, uploads, and packages，默认为 true 通过对象存储启用这些功能。
proxy_download Boolean true 通过 GitLab 启用所有下载的代理，而不是从bucket 直接下载。
bucket String 多种 要从对象存储 provisioner 使用的存储桶的名称。 默认将是git-lfs、gitlab-artifacts、gitlab-uploads 或gitlab-packages，具体取决于服务。
connection String {} 查看下方文档。

connection

connection 属性已转换为 Kubernetes Secret。这个 secret 的内容应该是一个 YAML 格式的文件。 默认为 {}，如果 global.minio.enabled 为 true，则将被忽略。

这个属性有两个子键：secret 和 key。

  • secret 是 Kubernetes Secret 的名称. 使用外部对象存储需要此值。
  • key 是包含 YAML 块的键的名称。 默认为 connection。

AWS 和 Google 提供商的示例 可以在 examples/objectstorage 中找到。

创建包含 connection 内容的 YAML 文件后，使用此文件在 Kubernetes 中创建 secret。 

kubectl create secret generic gitlab-rails-storage \
    --from-file=connection=rails.yaml

when (仅限 External MR Diffs)

externalDiffs 设置有一个额外的键 when 有条件地存储对象存储上的特定差异。 默认情况下，此设置在 Charts 中保留为空，用于由 Rails 代码分配的默认值。

接收电子邮件设置

命令行选项页面 中解释了接收电子邮件设置。

KAS 设置

自定义 secret

可以选择自定义 KAS secret 名称和 key，也可以使用 Helm 的 --set variable 选项： 

--set global.appConfig.gitlab_kas.secret=custom-secret-name \
--set global.appConfig.gitlab_kas.key=custom-secret-key \

或配置您的 values.yaml： 

global:
  appConfig:
    gitlab_kas:
      secret: "custom-secret-name"
      key: "custom-secret-key"

如果您想要自定义 secret 值，参考 secrets 文档。

自定义 URLs

可以使用 Helm 的 --set variable 选项自定义后端使用的 KAS 的 URL。 

--set global.appConfig.gitlab_kas.externalUrl="wss://custom-kas-url.example.com" \
--set global.appConfig.gitlab_kas.internalUrl="grpc://custom-internal-url" \

或配置您的 values.yaml： 

global:
  appConfig:
    gitlab_kas:
      externalUrl: "wss://custom-kas-url.example.com"
      internalUrl: "grpc://custom-internal-url"

外部 KAS

通过配置启用并配置所需的 URL，使后端可以识别外部的 KAS 服务器（即不由 chart 管理）。您可以使用 Helm 的 --set variable 选项： 

--set global.appConfig.gitlab_kas.enabled=true \
--set global.appConfig.gitlab_kas.externalUrl="wss://custom-kas-url.example.com" \
--set global.appConfig.gitlab_kas.internalUrl="grpc://custom-internal-url" \

或配置您的 values.yaml： 

global:
  appConfig:
    gitlab_kas:
      enabled: true
      externalUrl: "wss://custom-kas-url.example.com"
      internalUrl: "grpc://custom-internal-url"

TLS 设置

KAS 支持其 kas pod 和其他极狐GitLab chart 组件之间的 TLS 通信。

先决条件：

  • 使用 15.5.1 或更高版本。您可以使用 global.gitlabVersion: <version> 设置您的极狐GitLab 版本。如果您需要在初始部署后强制更新镜像，还可以设置 global.image.pullPolicy: Always。
  • 创建证书颁发机构和您的 kas pod 将信任的证书。

要配置 kas 使用您创建的证书，请设置以下值。

值 描述
global.kas.tls.enabled 安装证书卷并启用与 kas 端点的 TLS 通信。
global.kas.tls.secretName 指定哪个 Kubernetes TLS 密钥存储您的证书。
global.kas.tls.caSecretName 指定哪个 Kubernetes TLS secret 存储您的自定义 CA。

例如，您可以在 values.yaml 文件中使用以下内容来部署 chart： 

.internal-ca: &internal-ca gitlab-internal-tls-ca # The secret name you used to share your TLS CA.
.internal-tls: &internal-tls gitlab-internal-tls # The secret name you used to share your TLS certificate.

global:
  certificates:
    customCAs:
    - secret: *internal-ca
  hosts:
    domain: gitlab.example.com # Your gitlab domain
  kas:
    tls:
      enabled: true
      secretName: *internal-tls
      caSecretName: *internal-ca

建议审核者设置

note建议审核者 secret 是自动创建的，仅适用于 SaaS。私有化部署实例不需要此 secret。

通过使用 Helm 的 --set variable 选项，可以选择自定义建议审核者的 secret 名称和 key： 

--set global.appConfig.suggested_reviewers.secret=custom-secret-name \
--set global.appConfig.suggested_reviewers.key=custom-secret-key \

或者通过设置您的 values.yaml： 

global:
  appConfig:
    suggested_reviewers:
      secret: "custom-secret-name"
      key: "custom-secret-key"

如果您想自定义 secret 值，请参阅 secrets 文档。

LDAP

在 ldap.servers 下，允许配置 LDAP 用户认证。 它以 map 映射形式诚信啊，可以转化成 gitlab.yml （与从源安装时相同）中的 LDAP 服务器配置，

可以通过提供保存密码的 secret 来配置密码。然后密码将在运行时注入极狐GitLab 配置中。

示例配置片段如下： 

ldap:
  preventSignin: false
  servers:
    # 'main' is the GitLab 'provider ID' of this LDAP server
    main:
      label: 'LDAP'
      host: '_your_ldap_server'
      port: 636
      uid: 'sAMAccountName'
      bind_dn: 'cn=administrator,cn=Users,dc=domain,dc=net'
      base: 'dc=domain,dc=net'
      password:
        secret: my-ldap-password-secret
        key: the-key-containing-the-password

当使用 global chart 时，--set 配置项示例： 

--set global.appConfig.ldap.servers.main.label='LDAP' \
--set global.appConfig.ldap.servers.main.host='your_ldap_server' \
--set global.appConfig.ldap.servers.main.port='636' \
--set global.appConfig.ldap.servers.main.uid='sAMAccountName' \
--set global.appConfig.ldap.servers.main.bind_dn='cn=administrator\,cn=Users\,dc=domain\,dc=net' \
--set global.appConfig.ldap.servers.main.base='dc=domain\,dc=net' \
--set global.appConfig.ldap.servers.main.password.secret='my-ldap-password-secret' \
--set global.appConfig.ldap.servers.main.password.key='the-key-containing-the-password'
note在 Helm --set 中，逗号被视为特殊字符，确保在诸如 bind_dn 之类的值中转义逗号： --set global.appConfig.ldap.servers.main.bind_dn='cn=administrator\,cn=Users\,dc=domain\,dc=net'。

禁用 LDAP web 登录

当首选 SAML 等替代方法时，阻止通过 Web UI 使用 LDAP 凭据会很有用。这样允许 LDAP 用于组同步，同时还允许您的 SAML 身份提供商进行额外的检查，例如自定义 2FA。

当禁用 LDAP web 登录时，用户将不会在登录页面上看到 LDAP 选项卡。这样不会禁用使用 LDAP 凭据进行 Git 访问。

要禁用 LDAP web 登录，设置 global.appConfig.ldap.preventSignin: true。

使用自定义 CA 或自签名 LDAP 证书

如果 LDAP 服务器使用自定义 CA 或自签名 LDAP 证书，您必须：

  1. 确保将自定义 CA/自签名证书创建为集群/命名空间中的 Secret： 

    # Secret
kubectl -n gitlab create secret generic my-custom-ca-secret --from-file=unique_name.crt=my-custom-ca.pem

# ConfigMap
kubectl -n gitlab create configmap my-custom-ca-configmap --from-file=unique_name.crt=my-custom-ca.pem

  2. 然后进行以下配置： 

    # Configure a custom CA from a Secret
--set global.certificates.customCAs[0].secret=my-custom-ca-secret

# Or from a ConfigMap
--set global.certificates.customCAs[0].configMap=my-custom-ca-configmap

# Configure the LDAP integration to trust the custom CA
--set global.appConfig.ldap.servers.main.ca_file=/etc/ssl/certs/unique_name.pem

这样做可以确保 CA 安装在 /etc/ssl/certs/ca-cert-my-custom-ca.pem 下的相关 pod 中，并指定其在 LDAP 配置中的使用。

note在 15.9 及更高版本中，/etc/ssl/certs/ 中的证书不再以 ca-cert- 为前缀。之前以 ca-cert- 为前缀，是因为容器使用 Alpine 为已部署的 pod 准备证书 secrets。现在 gitlab-base 容器现在用于此操作，它基于 Debian。

Cron jobs 关联设置

Sidekiq 包括可配置为使用 cron 样式计划定期运行的维护作业。下面提供了示例。有关更多工作示例，请查看 gitlab.yml。

该设置在 Sidekiq、Webservice（用于在 UI 中显示工具提示）和 Toolbox（用于调试目的）的 pods 之间共享。 

global:
  appConfig:
    cron_jobs:
      stuck_ci_jobs_worker:
        cron: "0 * * * *"
      pipeline_schedule_worker:
        cron: "19 * * * *"
      expire_build_artifacts_worker:
        cron: "*/7 * * * *"

Sentry 设置

使用以下设置启用 Sentry 错误报告。 

global:
  appConfig:
    sentry:
      enabled:
      dsn:
      clientside_dsn:
      environment:
名称 类型 默认值 说明
enabled Boolean false 启用或禁用集成
dsn String   后端错误的 Sentry DSN
clientside_dsn String   前端错误的 Sentry DSN
environment String   查看 Sentry 环境文档

Smartcard Authentication 设置 

global:
  appConfig:
    smartcard:
      enabled: false
      CASecret:
      clientCertificateRequiredHost:
      sanExtensions: false
      requiredForGitAccess: false
名称 类型 默认值 说明
enabled Boolean false 启用或禁用 smartcard authentication
CASecret String   包含 CA 证书的 Secret 的名称
clientCertificateRequiredHost String   用于 smartcard authentication 的主机名。默认情况下，使用提供的或计算的 smartcard 主机名。
sanExtensions Boolean false 启用 SAN 扩展以将用户与证书匹配
requiredForGitAccess Boolean false 要求使用 smartcard 登录的浏览器会话才能访问 Git。

Sidekiq 路由规则设置

支持在计划之前，将作业从 worker 路由到所需的队列。 Sidkiq 客户端将作业与配置的路由规则列表进行匹配。规则从头到尾进行匹配，只要找到匹配的 worker，就会停止这个 worker 的进程（首次匹配优先）。如果 worker 不匹配任何规则，它会回退到由 worker 名称生成的队列名称。

默认情况下，路由规则没有配置（或空数组），所有作业都被路由到从 worker 名称生成的队列中。

路由规则列表是一个有序的查询元组数组和对应的队列：

  • 查询遵循 worker 匹配查询语法。
  • <queue_name> 必须匹配在 sidekiq.pods 下定义的有效 Sidekiq 队列名称 sidekiq.pods[].queues。如果队列名称是 nil 或空字符串，worker 被路由到由 worker 名称生成的队列。

查询支持通配符匹配 *，它匹配所有的 worker。在这种情况下，通配符查询必须留在列表的末尾，否则后面的规则会被忽略： 

global:
  appConfig:
    sidekiq:
      routingRules:
      - ["resource_boundary=cpu", "cpu-boundary"]
      - ["feature_category=pages", null]
      - ["feature_category=search", "search"]
      - ["feature_category=memory|resource_boundary=memory", "memory-bound"]
      - ["*", "default"]

Rails 配置

极狐GitLab 套件的很大一部分基于 Rails。因此，该项目中的许多容器都使用此堆栈运行。这些设置适用于所有容器，并提供一种简单的访问方法来全局设置，而不是单独设置。 

global:
  rails:
    bootsnap:
      enabled: true

Workhorse 配置

极狐GitLab 套件的几个组件通过 GitLab Workhorse 与 API 通信。这是 Webservice chart 的一部分。所有需要与 GitLab Workhorse 通信的 chart 都会使用这些设置，并提供一种简单的访问方法来全局设置，而不是单独设置。 

global:
  workhorse:
    serviceName: webservice-default
    host: api.example.com
    port: 8181
名称 类型   默认值 说明
serviceName String webservice-default 将内部 API 流量定向到的 service 的名称。不要包含发布名称，因为它将被模板化。应当与 gitlab.webservice.deployments 中的条目匹配。查看 gitlab/webservice chart 文档  
scheme String http API 端点 Scheme  
host String   API 端点的完全限定主机名或 IP 地址。覆盖 serviceName  
port Integer 8181 关联的 API 服务器端口  
tls.enabled Boolean false 当设置为 true 时，启用对 Workhorse 的 TLS 支持。  

Bootsnap Cache

Rails 代码库使用了 Shopify’s Bootsnap Gem。

bootsnap.enabled 控制是否激活该特性。默认为 true。

测试表明，启用 Bootsnap 可提高整体应用程序性能。当预编译缓存可用时，一些应用程序容器的提升会超过 33%。 目前，极狐GitLab 并未随容器一起提供此预编译缓存，因此“仅”获得 14% 左右的提升。 在没有预编译缓存的情况下，这种提升是有代价的，会导致每个 Pod 初始启动时小型 IO 的强烈峰值。 因此，我们公开了一种在可能会出现问题的环境中禁用 Bootsnap 的方法。

如果可能，我们建议启用此功能。

GitLab Shell 配置

以下是 GitLab Shell chart 全局配置示例： 

global:
  shell:
    port:
    authToken: {}
    hostKeys: {}
    tcp:
      proxyProtocol: false
名称 类型 默认值 说明
port Integer 22 查看下面的 port 文档。
authToken     查看 GitLab Shell chart 文档中的 authToken 部分。
hostKeys     查看 GitLab Shell chart 文档中的 hostKeys 部分。
tcp.proxyProtocol Boolean false 查看下面的 TCP proxy protocol 文档。

Port

您可以控制 Ingress 用于传递 SSH 流量的端口，以及极狐GitLab 通过 global.shell.port 提供的 SSH URL 中使用的端口。 这会反映在服务侦听的端口，以及项目 UI 中提供的 SSH 克隆 URL。 

global:
  shell:
    port: 32022

您可以结合 global.shell.port 和 nginx-ingress.controller.service.type=NodePort，为 NGINX controller Service 对象设置一个 NodePort。请注意，如果设置了 nginx-ingress.controller.service.nodePorts.gitlab-shell，当为 NGINX 设置 NodePort 时，将覆盖 global.shell.port。 

global:
  shell:
    port: 32022

nginx-ingress:
  controller:
    service:
      type: NodePort

TCP 代理协议

您可以在 SSH Ingress 上启用 代理协议，以正确处理来自添加了代理协议 header 的上游代理的连接。这样，将阻止 SSH 接收额外的 header 并且不会破坏 SSH。

global:
  shell:
    tcp:
      proxyProtocol: true # default false

GitLab Pages 配置

被其它 chart 使用的全局 GitLab Pages 设置位于 global.pages 键下： 

global:
  pages:
    enabled:
    accessControl:
    path:
    host:
    port:
    https:
    externalHttp:
    externalHttps:
    artifactsServer:
    objectStore:
      enabled:
      bucket:
      proxy_download: true
      connection: {}
        secret:
        key:
    localStore:
      enabled: false
      path:
    apiSecret: {}
      secret:
      key:
名称 类型 默认值 说明
enabled Boolean False 决定是否在集群中安装 GitLab Pages chart
accessControl Boolean False 启用 GitLab Pages 访问控制
path String /srv/gitlab/shared/pages Pages deployment 关联文件的存储路径。注意：因为使用了对象存储，默认情况下未使用。
host String   Pages 根域名
port String   用于在 UI 中构建 Pages URL 的端口。 如果不设置，则根据 Pages 的 HTTPS 配置情况设置默认值 80 或 443。
https Boolean True UI 是否应显示 Pages 的 HTTPS URL，优先于global.hosts.pages.https 和 global.hosts.https。默认设置为 True。
externalHttp List [] HTTP 请求到达 Pages daemon 的 IP 地址列表。用于支持自定义域名。
externalHttps List [] HTTPS 请求到达 Pages daemon 的 IP 地址列表。用于支持自定义域名。
artifactsServer Boolean True 在 GitLab Pages 中启用 viewing artifacts。
objectStore.enabled Boolean True 为 Pages 启用对象存储。
objectStore.bucket String gitlab-pages 用于存储与 Pages 相关内容的存储桶。
objectStore.connection.secret String   包含对象存储连接详细信息的 Secret。
objectStore.connection.key String   存储连接详细信息的 Secret 中的键。
localStore.enabled Boolean False 启用对与 Pages 相关的内容使用本地存储（而不是 objectStore）
localStore.path String /srv/gitlab/shared/pages Pages 文件将被存储的路径； 仅在 localStore 设置为 true 时使用。
apiSecret.secret String   包含 Base64 编码形式的 32 位 API 密钥的 Secret。
apiSecret.key String   存储 API key 的 Secret 中的键。

Webservice 配置

全局 Webservice 设置（也被其它 chart 使用）位于 global.webservice 键下。 

global:
  webservice:
    workerTimeout: 60

workerTimeout

配置请求超时（以秒为单位），在此之后 Webservice worker 进程会被 Webservice master 进程终止默认值为 60 秒。

自定义证书颁发机构

note这些设置不会通过 requirements.yaml 影响仓库外部的 chart。

某些用户可能需要添加自定义证书颁发机构，例如在为 TLS 服务使用内部颁发的 SSL 证书时。为了提供此功能，我们提供了一种机制，通过 Secret 或 ConfigMaps 将自定义根证书颁发机构注入应用程序。

要创建 Secret 或 ConfigMap： 

# Create a Secret from a certificate file
kubectl create secret generic secret-custom-ca --from-file=unique_name=/path/to/cert

# Create a ConfigMap from a certificate file
kubectl create configmap cm-custom-ca --from-file=unique_name=/path/to/cert

要配置 Secret 或 ConfigMap，或两者，请在全局变量中指定它们： 

global:
  certificates:
    customCAs:
      - secret: secret-custom-CAs           # Mount all keys of a Secret
      - secret: secret-custom-CAs           # Mount only the specified keys of a Secret
        keys:
          - unique_name.crt
      - configMap: cm-custom-CAs            # Mount all keys of a ConfigMap
      - configMap: cm-custom-CAs            # Mount only the specified keys of a ConfigMap
        keys:
          - unique_name_1.crt
          - unique_name_2.crt
noteSecret 密钥名称中的 .crt 扩展名对于 Debian update-ca-certificates 软件包很重要。此步骤确保自定义 CA 文件安装有该扩展名，并在证书 initContainers 中进行处理。以前，当证书 helper 镜像基于 Alpine 时，实际上不需要文件扩展名。基于 UBI 的 update-ca-trust 实用程序没有此要求。

您可以提供任意数量的 Secret 或 ConfigMap，每个都包含任意数量的保存 PEM 编码 CA 证书的密钥。这些被配置为 global.certificates.customCAs 下的条目。 除非 keys: 提供了要安装的特定键的列表，否则所有键都已安装。所有 Secret 和 ConfigMap 中的所有挂载密钥都必须是唯一的。 Secrets 和 ConfigMaps 可以以任何方式命名，但它们不能包含冲突的键名。

Application 资源

极狐GitLab 可以选择包含一个 Application 资源，可以创建它来识别集群中的 GitLab 应用程序，需要已在集群中部署 v1beta1 版本的 Application CRD。

设置 global.application.create 为 true，可以启用： 

global:
  application:
    create: true

某些环境（例如 Google GKE Marketplace）不允许创建 ClusterRole 资源。设置以下值以禁用应用程序自定义资源定义中的 ClusterRole 组件，以及相关 chart 打包到 Cloud Native GitLab。 

global:
  application:
    allowClusterRoles: false
nginx:
  controller:
    scope:
      enabled: true
gitlab-runner:
  rbac:
    clusterWideAccess: false
certmanager:
  install: false

GitLab base 镜像

极狐GitLab Helm Chart 使用通用的极狐GitLab 基础镜像来执行各种初始化任务。 该镜像支持 UBI 构建并与其他镜像共享镜像层。 它取代了现已弃用的 busybox 镜像。

note如果有自定义 busybox 设置，chart 将回退到旧的 busybox。 这个 busybox 配置回退最终将被删除。请将您的设置迁移到 global.gitlabBase。

Service Accounts

GitLab Helm chart 允许使用自定义 Service Accounts 运行 pod。 在 global.serviceAccount 进行如下配置： 

global:
  serviceAccount:
    enabled: false
    create: true
    annotations: {}
    ## Name to be used for serviceAccount, otherwise defaults to chart fullname
    # name:
  • 设置 global.serviceAccount.enabled 控制通过 spec.serviceAccountName 对每个组件的 ServiceAccount 的引用。
  • 设置 global.serviceAccount.create 通过 Helm 控制 ServiceAccount 对象的创建。
  • 设置 global.serviceAccount.name 控制 ServiceAccount 对象名称和每个组件引用的名称。
note不要将 global.serviceAccount.create=true 与 global.serviceAccount.name 一起使用，因为它会使 chart 创建多个具有相同名称的 ServiceAccount 对象。相反，如果指定全局名称，请使用 global.serviceAccount.create=false。

Annotations

自定义 annotations 适用于 Deployment、Service 和 Ingress 对象。 

global:
  deployment:
    annotations:
      environment: production

  service:
    annotations:
      environment: production

  ingress:
    annotations:
      environment: production

Node Selector

自定义的 nodeSelector 适用于全局的所有组件，也可以在每个子 chart 上，单独覆盖任何全局默认值。 

global:
  nodeSelector:
    disktype: ssd

Note: 外部维护的 chart 不遵循 global.nodeSelector，可能需要根据可用 chart 值单独配置。包括 Prometheus、cert-manager 和 Redis 等。

Labels

Common Labels

通过使用 common.labels，标签可以适用于几乎所有由各种对象创建的对象。可以在 global 键下，或在特定 chart 的配置下使用。示例如下： 

global:
  common:
    labels:
      environment: production
gitlab:
  gitlab-shell:
    common:
      labels:
        foo: bar

在上面的示例配置中，几乎所有由 Helm chart 部署的组件都将具有 environment: production 标签集。所有 GitLab shell chart 的组件将具有 foo: bar 标签集。某些 chart 允许额外的嵌套。例如 Sidekiq 和 Webservices chart 允许根据您的配置需求进行额外的部署： 

gitlab:
  sidekiq:
    pods:
      - name: pod-0
        common:
          labels:
            baz: bat

在上面的示例中，与 pod-0 Sidekiq 部署相关的所有组件也将收到标签集 baz: bat。有关其他详细信息，请参阅 Sidekiq 和 Webservice chart。

我们依赖的一些 chart 被排除在此标签配置之外。只有 GitLab 组件子 chart 会收到这些额外的标签。

Pod

自定义标签可应用于各种 Deployments 和 Jobs。这些标签是对有 Helm chart 构建的现有或预配置标签的补充。这些补充标签不会用于 matchSelectors。 

global:
  pod:
    labels:
      environment: production

Service

自定义标签可以应用于 services。这些标签是对有 Helm chart 构建的现有或预配置标签的补充。 

global:
  service:
    labels:
      environment: production

Tracing

GitLab Helm chart 支持 tracing，配置示例如下： 

global:
  tracing:
    connection:
      string: 'opentracing://jaeger?http_endpoint=http%3A%2F%2Fjaeger.example.com%3A14268%2Fapi%2Ftraces&sampler=const&sampler_param=1'
    urlTemplate: 'http://jaeger-ui.example.com/search?service={{ service }}&tags=%7B"correlation_id"%3A"{{ correlation_id }}"%7D'
  • global.tracing.connection.string 用于配置 tracing spans 的发送位置。
  • global.tracing.urlTemplate 用于配置 GitLab 性能栏中，tracing info URL 渲染的模板。

extraEnv

extraEnv 允许您在通过 GitLab chart 部署的 pod 的所有容器中，暴露额外的环境变量。设置在全局级别的环境变量将合并到 chart 级别的环境变量，chart 级别的环境变量优先级高。

使用 extraEnv 的示例如下： 

global:
  extraEnv:
    SOME_KEY: some_value
    SOME_OTHER_KEY: some_other_value

extraEnvFrom

extraEnvFrom 允许 Pods 的所有容器中的其它数据源，暴露其它环境变量。额外的环境变量可以设置在 global 级别 (global.extraEnvFrom) 和子 chart 级别 (<subchart_name>.extraEnvFrom)。

Sidekiq 和 Webservice chart 支持额外的本地覆盖。有关详细信息，请参阅相关文档。

下面是一个使用 extraEnvFrom 的示例： 

global:
  extraEnvFrom:
    MY_NODE_NAME:
      fieldRef:
        fieldPath: spec.nodeName
    MY_CPU_REQUEST:
      resourceFieldRef:
        containerName: test-container
        resource: requests.cpu
gitlab:
  kas:
    extraEnvFrom:
      CONFIG_STRING:
        configMapKeyRef:
          name: useful-config
          key: some-string
          # optional: boolean
note该实现不支持重新使用具有不同内容类型的值名称。您可以使用相似的内容覆盖相同的名称，但不能混合使用 secretKeyRef、configMapKeyRef 等源。

OAuth 配置

OAuth 集成对于支持它的服务来说是开箱即用的。global.oauth 中指定的服务在部署期间会自动注册为极狐GitLab 中的 OAuth 客户端应用程序。默认情况下，如果启用了访问控制。包含 GitLab Pages。 

global:
  oauth:
    gitlab-pages: {}
    # secret
    # appid
    # appsecret
    # redirectUri
    # authScope
名称 类型 默认值 说明
secret String   带有 OAuth 凭证的 Secret 的名称。
appIdKey String   Secret 中存储服务的 App ID 的键。默认值为 appid。
appSecretKey String   Secret 中存储服务的 App Secret 的键。默认值为 appsecret。
redirectUri String   成功授权后，将用户重定向到的 URI。
authScope String api 使用 GitLab API 时进行身份验证的范围。

查看 secrets 文档，获取更多详细信息。

Kerberos

要在 Helm chart 中配置 Kerberos 集成，您必须在 global.appConfig.kerberos.keytab.secret 设置中提供一个密钥，其中包含一个d带有极狐GitLab host 提供服务主体的 Kerberos keytab 。 如果您没有 keytab 文件，您的 Kerberos 管理员可以帮助创建 keytab 文件。

您可以使用以下代码段创建密钥（假设您将 chart 安装在 gitlab 命名空间中，并且 gitlab.keytab 是包含服务主体的 keytab 文件）： 

kubectl create secret generic gitlab-kerberos-keytab --namespace=gitlab --from-file=keytab=./gitlab.keytab

通过设置 global.appConfig.kerberos.enabled=true 启用 Git 的 Kerberos 集成，还将 kerberos 提供程序添加到启用的 OmniAuth 提供程序列表中，以在浏览器中进行 ticket-based 的身份验证。

如果 false，Helm chart 仍将在 toolbox、Sidekiq 和 Web 服务 Pod 中挂载 keytab，可与手动配置的 Kerberos OmniAuth 设置一起使用。

您可以在 global.appConfig.kerberos.krb5Config 中提供 Kerberos 客户端配置。 

global:
  appConfig:
    kerberos:
      enabled: true
      keytab:
        secret: gitlab-kerberos-keytab
        key: keytab
      servicePrincipalName: ""
      krb5Config: |
        [libdefaults]
            default_realm = EXAMPLE.COM
      dedicatedPort:
        enabled: false
        port: 8443
        https: true
      simpleLdapLinkingAllowedRealms:
        - example.com

查看 Kerberos 文档，了解更多详细信息。

Kerberos 的专用端口

当使用 HTTP 协议进行 Git 操作时，极狐GitLab 支持使用专用端口进行 Kerberos 协商，以解决在身份验证交换中出现 negotiate headers 时，Git 回退到基本身份验证的限制。

使用极狐GitLab CI/CD 时，当前需要使用专用端口 - 因为极狐GitLab Runner helper 依赖于 URL 内的凭据从极狐GitLab 克隆。

这可以通过 global.appConfig.kerberos.dedicatedPort 设置启用： 

global:
  appConfig:
    kerberos:
      [...]
      dedicatedPort:
        enabled: true
        port: 8443
        https: true

这会在极狐GitLab UI 中启用一个额外的克隆 URL，该 URL 专用于 Kerberos 协商。https: true 设置仅用于 URL 生成，不会公开任何额外的 TLS 配置。TLS 在 Ingress for GitLab 中终止和配置。

note由于当前对我们的 nginx-ingress Helm chart 的分支的限制 - 指定 dedicatedPort 当前不会公开用于 chart 的 nginx-ingress 控制器的端口。集群操作员需要自己公开这个端口。

LDAP 自定义允许的 realm

当用户的 LDAP DN 与用户的 Kerberos realm 不匹配时，global.appConfig.kerberos.simpleLdapLinkingAllowedRealms 可用于指定一组用于将 LDAP 和 Kerberos 身份链接在一起的 realm。

Outgoing email

通过 global.smtp.*、global.appConfig.microsoft_graph_mailer.* 和 global.email.*，可进行 Outgoing email 配置。 

global:
  email:
    display_name: 'GitLab'
    from: 'gitlab@example.com'
    reply_to: 'noreply@example.com'
  smtp:
    enabled: true
    address: 'smtp.example.com'
    tls: true
    authentication: 'plain'
    user_name: 'example'
    password:
      secret: 'smtp-password'
      key: 'password'
  appConfig:
    microsoft_graph_mailer:
      enabled: false
      user_id: "YOUR-USER-ID"
      tenant: "YOUR-TENANT-ID"
      client_id: "YOUR-CLIENT-ID"
      client_secret:
        secret:
        key: secret
      azure_ad_endpoint: "https://login.microsoftonline.com"
      graph_endpoint: "https://graph.microsoft.com"

查看 outgoing email 文档获取配置项的更多信息。

查看 Omnibus SMTP 设置文档，可查看更多详细案例。

Platform

platform 键是为特定平台（如 GKE 或 EKS）的特定功能保留的。

Affinity

关联配置可通过 global.antiAffinity 和 global.affinity 获得。 Affinity 允许您根据节点标签或已在节点上运行的 pod 的标签来限制您的 pod 有资格安排在哪些节点上。这允许在集群中分布 Pod 或选择特定节点，从而确保在节点发生故障时具有更大的弹性。 

global:
  antiAffinity: soft
  affinity:
    podAntiAffinity:
      topologyKey: "kubernetes.io/hostname"
名称 类型 默认值 描述
antiAffinity String soft 应用于 pod 的 Pod 反亲和性。
affinity.podAntiAffinity.topologyKey String kubernetes.io/hostname Pod 反亲和拓扑密钥。
  • global.antiAffinity 可以取以下两个值：
    • soft：定义一个 preferredDuringSchedulingIgnoredDuringExecution 反亲和性，Kubernetes scheduler 将尝试执行规则但不保证结果。
    • hard：定义了 requiredDuringSchedulingIgnoredDuringExecution 反亲和性，必须其中规则满足才能将 Pod 调度到节点上。
  • global.affinity.podAntiAffinity.topologyKey 定义一个节点属性，使用两个将它们划分为逻辑区域。 最常见的 topologyKey 值是：
    • kubernetes.io/hostname
    • topology.kubernetes.io/zone
    • topology.kubernetes.io/region

Kubernetes 参考资料：Pod 间亲和性和反亲和性

Pod Priority 和 Preemption

Pod 优先级可以通过 global.priorityClassName 配置，或通过每个子 chart 的 priorityClassName 配置。 设置 Pod 优先级允许您告诉调度程序驱逐优先级较低的 Pod，以便调度挂起的 Pod。 

global:
  priorityClassName: system-cluster-critical
名称 类型 默认值 描述
priorityClassName String   指派给 Pod 的 Priority class。

日志轮换

引入于 15.6 版本。

默认情况下，极狐GitLab Helm chart 不会轮换日志。这可能会导致长时间运行的容器出现临时存储问题。

要启用日志轮换，请将 GITLAB_LOGGER_TRUNCATE_LOGS 环境变量设置为 true。您还可以通过分别设置 GITLAB_LOGGER_TRUNCATE_INTERVAL 和 GITLAB_LOGGER_MAX_FILESIZE 环境变量来配置日志轮换频率和最大日志大小： 

global:
  extraEnv:
    GITLAB_LOGGER_TRUNCATE_LOGS: true
    GITLAB_LOGGER_TRUNCATE_INTERVAL: 300
    GITLAB_LOGGER_MAX_FILESIZE: 1000