Configure charts using globals

为了减少在安装我们的包装 Helm Chart 时的配置重复，可以在 values.yaml 的 global 部分设置多个配置选项。这些全局设置会在多个 Chart 中使用，而其他所有设置则限定在它们的 Chart 内。有关全局变量如何工作的更多信息，请参阅 Helm 文档关于 globals。

• 主机
• Ingress
• 极狐GitLab版本
• PostgreSQL
• Redis
• Registry
• Gitaly
• Praefect
• MinIO
• appConfig
• Rails
• Workhorse
• 极狐GitLab Shell
• Pages
• Webservice
• 自定义证书颁发机构
• 应用程序资源
• 极狐GitLab基础镜像
• 服务账户
• 注解
• 追踪
• extraEnv
• extraEnvFrom
• OAuth
• Kerberos
• 外发电子邮件
• 平台
• 亲和性
• Pod 优先级和抢占
• 日志轮转
• Jobs
• Traefik

配置主机设置#

极狐GitLab全局主机设置位于 global.hosts 键下。

yaml
1global:
2  hosts:
3    domain: example.com
4    hostSuffix: staging
5    https: false
6    externalIP:
7    gitlab:
8      name: gitlab.example.com
9      https: false
10    registry:
11      name: registry.example.com
12      https: false
13    minio:
14      name: minio.example.com
15      https: false
16    smartcard:
17      name: smartcard.example.com
18    kas:
19      name: kas.example.com
20    pages:
21      name: pages.example.com
22      https: false
23    ssh: gitlab.example.com

hostSuffix#

在使用基础 domain 组装主机名时，hostSuffix 将附加到子域，但不会用于有其自己的 name 设置的主机。

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

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

配置水平 Pod 自动扩缩器设置#

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

配置 PodDisruptionBudget 设置#

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

配置 CronJob 设置#

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

配置监控设置#

极狐GitLab 的 ServiceMonitors 和 PodMonitors 全局设置位于 global.monitoring 键下：

配置 Ingress 设置#

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

Ingress 路径#

此 Chart 使用 global.ingress.path 作为帮助那些需要更改其 Ingress 对象的 path 条目定义的用户的一种方法。 许多用户不需要此设置，因此不应配置它。

对于那些需要将其 path 定义末尾设置为 /* 以匹配其负载均衡器 / 代理行为的用户，例如在 GCP 中使用 ingress.class: gce 或在 AWS 中使用 ingress.class: alb 时。

此设置确保 Ingress 资源中的所有 path 条目都以此方式呈现。唯一的例外是填充 gitlab/webservice 部署设置 时，必须指定 path。

global.ingress.configureCertmanager#

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

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

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

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

global.ingress.useNewIngressForCerts#

更改 cert-manager 行为的全局设置，以使用每次动态创建的新 Ingress 执行 ACME 挑战验证。

默认逻辑（当 global.ingress.useNewIngressForCerts 为 false 时）重用现有的 Ingress 进行 验证。这种默认情况在某些情况下不适用。将标志设置为 true 将意味着每次验证都会创建一个新的 Ingress 对象。

在与 GKE Ingress 控制器一起使用时，global.ingress.useNewIngressForCerts 不能设置为 true。有关启用此功能的详细信息，请参阅发行说明。

极狐GitLab版本#

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

shell
--set global.gitlabVersion=11.0.1

这会影响 webservice、sidekiq 和 migration Chart 中使用的默认镜像标签。请注意，gitaly、gitlab-shell 和 gitlab-runner 镜像标签应 单独更新为与极狐GitLab版本兼容的版本。

为所有镜像标签添加后缀#

如果您希望为 Helm Chart 中使用的所有镜像名称添加一个后缀，可以使用 global.image.tagSuffix 键。 这种用例的一个示例可能是，如果您希望使用极狐GitLab构建的符合 fips 的容器镜像，它们都是用 -fips 扩展名构建的。

shell
--set global.image.tagSuffix="-fips"

所有容器的自定义时区#

如果您希望为所有极狐GitLab容器设置自定义时区，可以使用 global.time_zone 键。

shell
--set global.time_zone="America/Chicago"

配置 PostgreSQL 设置#

极狐GitLab 的 PostgreSQL 全局设置位于 global.psql 键下。 极狐GitLab 使用两个数据库连接：一个用于 main 数据库，一个用于 ci。默认情况下，它们指向同一个 PostgreSQL 数据库。

在 global.psql 下的值是默认值，并应用于两个数据库配置。如果您希望使用两个数据库，可以在 global.psql.main 和 global.psql.ci 中指定连接详细信息。

yaml
1global:
2  psql:
3    host: psql.example.com
4    # serviceName: pgbouncer
5    port: 5432
6    database: gitlabhq_production
7    username: gitlab
8    applicationName:
9    preparedStatements: false
10    databaseTasks: true
11    connectTimeout:
12    keepalives:
13    keepalivesIdle:
14    keepalivesInterval:
15    keepalivesCount:
16    tcpUserTimeout:
17    password:
18      useSecret: true
19      secret: gitlab-postgres
20      key: psql-password
21      file:
22    main: {}
23      # host: postgresql-main.hostedsomewhere.else
24      # ...
25    ci: {}
26      # host: postgresql-ci.hostedsomewhere.else
27      # ...

每个 Chart 的 PostgreSQL#

在某些复杂部署中，可能需要使用不同的 PostgreSQL 配置来配置此 Chart 的不同部分。从 v4.2.0 开始，可以在每个 Chart 的基础上设置 global.psql 中提供的所有属性，例如 gitlab.sidekiq.psql。提供的本地设置将覆盖全局值，并继承 global.psql 中未提供的值，除了 psql.load_balancing。

PostgreSQL 负载均衡 设计上不会从全局继承。

PostgreSQL SSL#

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

yaml
1global:
2  psql:
3    ssl:
4      secret: db-example-ssl-secrets # 秘密的名称
5      clientCertificate: cert.pem    # 存储证书的秘密密钥
6      clientKey: key.pem             # 证书密钥的秘密密钥
7      serverCA: server-ca.pem        # 数据库服务器的 CA 的秘密密钥

您可能还需要设置 extraEnv 值以导出环境值以指向正确的密钥。

yaml
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。

极狐GitLab 中的 Rails 组件具有使用 PostgreSQL 集群来负载均衡只读查询的能力。

此功能可以通过两种方式配置：

• 使用辅助节点的静态主机名列表。
• 使用基于 DNS 的服务发现机制。

使用静态列表进行配置非常简单：

yaml
1global:
2  psql:
3    host: primary.database
4    load_balancing:
5       hosts:
6       - secondary-1.database
7       - secondary-2.database

服务发现的配置可能更为复杂。有关此配置的完整详细信息、参数及其相关行为，请参阅 GitLab 管理文档中的服务发现。

yaml
1global:
2  psql:
3    host: primary.database
4    load_balancing:
5      discover:
6        record:  secondary.postgresql.service.consul
7        # record_type: A
8        # nameserver: localhost
9        # port: 8600
10        # interval: 60
11        # disconnect_timeout: 120
12        # use_tcp: false
13        # max_replica_pools: 30

还可以进一步调整与处理陈旧读取有关的设置。极狐GitLab 管理文档详细介绍了这些项目，并且这些属性可以直接添加到 load_balancing 下。

yaml
1global:
2  psql:
3    load_balancing:
4      max_replication_difference: # 请参阅文档
5      max_replication_lag_time:   # 请参阅文档
6      replica_check_interval:     # 请参阅文档

配置多个数据库连接#

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

配置 Redis 设置#

极狐GitLab 的 Redis 全局设置位于 global.redis 键下。

默认情况下，我们使用一个单一的、非复制的 Redis 实例。如果需要高可用的 Redis，我们建议使用外部 Redis 实例。

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

yaml
1global:
2  redis:
3    host: redis.example.com
4    serviceName: redis
5    database: 7
6    port: 6379
7    auth:
8      enabled: true
9      secret: gitlab-redis
10      key: redis-password
11    scheme:

配置 Redis Chart 特定设置#

直接配置 Redis Chart 的设置位于 redis 键下：

yaml
1redis:
2  install: true
3  image:
4    registry: registry.example.com
5    repository: example/redis
6    tag: x.y.z

Redis Sentinel 支持#

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

通过极狐GitLab Chart 安装的 HA Redis 集群不支持使用哨兵。如果需要哨兵支持，需要在极狐GitLab Chart 安装之外单独创建 Redis 集群。这可以在 Kubernetes 集群内或外部完成。

yaml
1redis:
2  install: false
3global:
4  redis:
5    host: redis.example.com
6    serviceName: redis
7    port: 6379
8    sentinels:
9      - host: sentinel1.example.com
10        port: 26379
11      - host: sentinel2.exeample.com
12        port: 26379
13    auth:
14      enabled: true
15      secret: gitlab-redis
16      key: redis-password

在配置 Redis 设置中之前的所有 Redis 属性在哨兵支持的情况下仍然适用，除非在上表中重新指定。

Redis Sentinel 密码支持#

yaml
1redis:
2  install: false
3global:
4  redis:
5    host: redis.example.com
6    serviceName: redis
7    port: 6379
8    sentinels:
9      - host: sentinel1.example.com
10        port: 26379
11      - host: sentinel2.example.com
12        port: 26379
13    auth:
14      enabled: true
15      secret: gitlab-redis
16      key: redis-password
17    sentinelAuth:
18      enabled: false
19      secret: gitlab-redis-sentinel
20      key: sentinel-password

global.redis.sentinelAuth 可用于为所有哨兵实例配置哨兵密码。

请注意，sentinelAuth 不能通过Redis 实例特定设置或 global.redis.redisYmlOverride 覆盖。

多个 Redis 支持#

极狐GitLab Chart 支持与不同持久性类一起运行的独立 Redis 实例，目前为：

可以指定任意数量的实例。未指定的任何实例将由主 Redis 实例处理，或者使用从 Chart 部署的 Redis 实例。 唯一的例外是 极狐GitLab 代理服务器 (KAS)，它会按以下顺序查找 Redis 配置：

1. global.redis.kas
2. global.redis.sharedState
3. global.redis.host

例如：

yaml
1redis:
2  install: false
3global:
4  redis:
5    host: redis.example
6    port: 6379
7    auth:
8      enabled: true
9      secret: redis-secret
10      key: redis-password
11    actioncable:
12      host: cable.redis.example
13      port: 6379
14      password:
15        enabled: true
16        secret: cable-secret
17        key: cable-password
18    cache:
19      host: cache.redis.example
20      port: 6379
21      password:
22        enabled: true
23        secret: cache-secret
24        key: cache-password
25    kas:
26      host: kas.redis.example
27      port: 6379
28      password:
29        enabled: true
30        secret: kas-secret
31        key: kas-password
32    queues:
33      host: queues.redis.example
34      port: 6379
35      password:
36        enabled: true
37        secret: queues-secret
38        key: queues-password
39    rateLimiting:
40      host: rateLimiting.redis.example
41      port: 6379
42      password:
43        enabled: true
44        secret: rateLimiting-secret
45        key: rateLimiting-password
46    repositoryCache:
47      host: repositoryCache.redis.example
48      port: 6379
49      password:
50        enabled: true
51        secret: repositoryCache-secret
52        key: repositoryCache-password
53    sessions:
54      host: sessions.redis.example
55      port: 6379
56      password:
57        enabled: true
58        secret: sessions-secret
59        key: sessions-password
60    sharedState:
61      host: shared.redis.example
62      port: 6379
63      password:
64        enabled: true
65        secret: shared-secret
66        key: shared-password
67    traceChunks:
68      host: traceChunks.redis.example
69      port: 6379
70      password:
71        enabled: true
72        secret: traceChunks-secret
73        key: traceChunks-password
74    workhorse:
75      host: workhorse.redis.example
76      port: 6379
77      password:
78        enabled: true
79        secret: workhorse-secret
80        key: workhorse-password

下表描述了每个 Redis 实例字典的属性。

主要 Redis 定义是必需的，因为还有其他持久性类尚未分离。

每个实例定义也可以使用 Redis Sentinel 支持。哨兵 配置不共享，需要为每个使用哨兵的实例指定。请参考 哨兵配置 以获取用于配置哨兵服务器的属性。

指定安全的 Redis 方案 (SSL)#

要通过 SSL 连接到 Redis：

1. 将您的配置更新为使用 rediss（双 s）方案参数。

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

   yaml
   1global:
   2  redis:
   3    scheme: rediss
   4redis:
   5  tls:
   6    enabled: true
   7    authClients: false

   由于 Redis 默认使用双向 TLS，这需要这样配置，而不是所有 Chart 组件都支持这种情况。

3. 请按照 Bitnami 的步骤启用 TLS。确保 chart 组件信任用于创建 Redis 证书的证书颁发机构。

4. 可选。如果您使用自定义证书颁发机构，请参阅自定义证书颁发机构全局配置。

无密码 Redis 服务器#

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

yaml
1global:
2  redis:
3    auth:
4      enabled: false
5    host: ${REDIS_PRIVATE_IP}
6redis:
7  enabled: false

配置镜像仓库设置#

全局镜像仓库设置位于 global.registry 键下。

yaml
1global:
2  registry:
3    bucket: registry
4    certificate:
5    httpSecret:
6    notificationSecret:
7    notifications: {}
8    ## 由其他服务使用的设置，引用 registry：
9    enabled: true
10    host:
11    api:
12      protocol: http
13      serviceName: registry
14      port: 5000
15    tokenIssuer: gitlab-issuer
16

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

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

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

通知#

此设置用于配置镜像仓库通知。它接受一个映射（遵循上游规范），但增加了通过 Kubernetes 密钥提供敏感标头的功能。例如，考虑以下代码片段，其中 Authorization 标头包含敏感数据，而其他标头包含常规数据：

yaml
1global:
2  registry:
3    notifications:
4      events:
5        includereferences: true
6      endpoints:
7        - name: CustomListener
8          url: https://mycustomlistener.com
9          timeout: 500mx
10          # 已弃用：请使用 `maxretries`，https://gitlab.com/gitlab-org/container-registry/-/issues/1243。
11          # 使用 `maxretries` 时，将忽略 `threshold`：https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads#endpoints
12          threshold: 5
13          maxretries: 5
14          backoff: 1s
15          headers:
16            X-Random-Config: [plain direct]
17            Authorization:
18              secret: registry-authorization-header
19              key: password

在此示例中，标头 X-Random-Config 是一个常规标头，其值可以在 values.yaml 文件中以明文提供或通过 --set 标志提供。但是，标头 Authorization 是敏感的，因此建议从 Kubernetes 密钥中挂载。有关密钥结构的详细信息，请参阅密钥文档。

配置 Gitaly 设置#

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

yaml
1global:
2  gitaly:
3    internal:
4      names:
5        - default
6        - default2
7    external:
8      - name: node1
9        hostname: node1.example.com
10        port: 8075
11    authToken:
12      secret: gitaly-secret
13      key: token
14    tls:
15      enabled: true
16      secretName: gitlab-gitaly-tls

Gitaly 主机#

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

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

• chart 内部，作为 StatefulSet 的一部分，通过 Gitaly chart 。
• chart 外部，作为外部宠物。
• 混合环境，使用内部和外部节点。

有关管理哪些节点将用于新项目的详细信息，请参阅仓库存储路径文档。

如果提供了 gitaly.host，则将忽略 gitaly.internal 和 gitaly.external 属性。有关更多详细信息，请参阅已弃用的 Gitaly 设置。

目前，预计所有 Gitaly 服务（内部或外部）都使用相同的 Gitaly 认证令牌。请确保这些保持一致。

内部#

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

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

需要手动缩放此项，通过在 gitaly.internal.names 中添加或删除条目。当缩小规模时，尚未移动到其他节点的任何仓库将变得不可用。由于 Gitaly chart 是一个 StatefulSet，动态配置的磁盘将不会被回收。这意味着数据磁盘将继续存在，并且当通过重新添加节点到 names 列表中再次扩大规模时，数据可以被访问。

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

外部#

external 键为集群外的 Gitaly 节点提供了配置。此列表的每个项目有 3 个键：

• name：存储的名称。name: default 的条目是必需的。
• hostname：Gitaly 服务的主机。
• port：（可选）要访问主机的端口号。默认为 8075。
• tlsEnabled：（可选）为此特定条目覆盖 global.gitaly.tls.enabled。

我们提供了一个使用外部 Gitaly 服务的高级配置指南。您还可以在示例文件夹中找到多外部服务配置示例。

您可以使用外部 Praefect 来提供高可用性的 Gitaly 服务。这两者的配置是可以互换的，因为从客户端的角度来看，没有区别。

混合#

可以同时使用内部和外部 Gitaly 节点，但请注意：

• 必须始终有一个名为 default 的节点，内部默认提供此节点。
• 外部节点将首先被填充，然后是内部节点。

在示例文件夹中可以找到一个混合内部和外部节点配置示例。

authToken#

Gitaly 的 authToken 属性有两个子键：

• secret 定义要从中提取的 Kubernetes Secret 的名称。
• key 定义上述密钥中包含 authToken 的密钥名称。

所有 Gitaly 节点必须共享相同的认证令牌。

已弃用的 Gitaly 设置#

TLS 设置#

有关通过 TLS 运行 Gitaly 的配置，请参阅 Gitaly chart 文档。

配置 Praefect 设置#

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

Praefect 默认禁用。启用时无需额外设置，将创建 3 个 Gitaly 副本，并需要在默认的 PostgreSQL 实例上手动创建 Praefect 数据库。

启用 Praefect#

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

有关如何使用 Praefect 操作 Gitaly 集群的详细信息，请参阅 Praefect 文档。

Praefect 的全局设置#

yaml
1global:
2  praefect:
3    enabled: false
4    virtualStorages:
5    - name: default
6      gitalyReplicas: 3
7      maxUnavailable: 1
8    dbSecret: {}
9    psql: {}

配置 MinIO 设置#

GitLab 全局 MinIO 设置位于 global.minio 键下。有关这些设置的更多详细信息，请参阅 MinIO chart 中的文档。

yaml
global:
  minio:
    enabled: true
    credentials: {}

配置 appConfig 设置#

Webservice、Sidekiq 和 Gitaly chart 共享多个设置，这些设置通过 global.appConfig 键进行配置。

yaml
1global:
2  appConfig:
3    # cdnHost:
4    contentSecurityPolicy:
5      enabled: false
6      report_only: true
7      # directives: {}
8    enableUsagePing: true
9    enableSeatLink: true
10    enableImpersonation: true
11    applicationSettingsCacheSeconds: 60
12    usernameChangingEnabled: true
13    issueClosingPattern:
14    defaultTheme:
15    defaultColorMode:
16    defaultSyntaxHighlightingTheme:
17    defaultProjectsFeatures:
18      issues: true
19      mergeRequests: true
20      wiki: true
21      snippets: true
22      builds: true
23      containerRegistry: true
24    webhookTimeout:
25    gravatar:
26      plainUrl:
27      sslUrl:
28    extra:
29      googleAnalyticsId:
30      matomoUrl:
31      matomoSiteId:
32      matomoDisableCookies:
33      oneTrustId:
34      googleTagManagerNonceId:
35      bizible:
36    object_store:
37      enabled: false
38      proxy_download: true
39      storage_options: {}
40      connection: {}
41    lfs:
42      enabled: true
43      proxy_download: true
44      bucket: git-lfs
45      connection: {}
46    artifacts:
47      enabled: true
48      proxy_download: true
49      bucket: gitlab-artifacts
50      connection: {}
51    uploads:
52      enabled: true
53      proxy_download: true
54      bucket: gitlab-uploads
55      connection: {}
56    packages:
57      enabled: true
58      proxy_download: true
59      bucket: gitlab-packages
60      connection: {}
61    externalDiffs:
62      enabled:
63      when:
64      proxy_download: true
65      bucket: gitlab-mr-diffs
66      connection: {}
67    terraformState:
68      enabled: false
69      bucket: gitlab-terraform-state
70      connection: {}
71    ciSecureFiles:
72      enabled: false
73      bucket: gitlab-ci-secure-files
74      connection: {}
75    dependencyProxy:
76      enabled: false
77      bucket: gitlab-dependency-proxy
78      connection: {}
79    backups:
80      bucket: gitlab-backups
81    microsoft_graph_mailer:
82      enabled: false
83      user_id: "YOUR-USER-ID"
84      tenant: "YOUR-TENANT-ID"
85      client_id: "YOUR-CLIENT-ID"
86      client_secret:
87        secret:
88        key: secret
89      azure_ad_endpoint: "https://login.microsoftonline.com"
90      graph_endpoint: "https://graph.microsoft.com"
91    incomingEmail:
92      enabled: false
93      address: ""
94      host: "imap.gmail.com"
95      port: 993
96      ssl: true
97      startTls: false
98      user: ""
99      password:
100        secret:
101        key: password
102      mailbox: inbox
103      idleTimeout: 60
104      inboxMethod: "imap"
105      clientSecret:
106        key: secret
107      pollInterval: 60
108      deliveryMethod: webhook
109      authToken: {}
110
111    serviceDeskEmail:
112      enabled: false
113      address: ""
114      host: "imap.gmail.com"
115      port: 993
116      ssl: true
117      startTls: false
118      user: ""
119      password:
120        secret:
121        key: password
122      mailbox: inbox
123      idleTimeout: 60
124      inboxMethod: "imap"
125      clientSecret:
126        key: secret
127      pollInterval: 60
128      deliveryMethod: webhook
129      authToken: {}
130
131    cron_jobs: {}
132    sentry:
133      enabled: false
134      dsn:
135      clientside_dsn:
136      environment:
137    gitlab_docs:
138      enabled: false
139      host: ""
140    oidcProvider:
141      openidIdTokenExpireInSeconds: 120
142    smartcard:
143      enabled: false
144      CASecret:
145      clientCertificateRequiredHost:
146    sidekiq:
147      routingRules: []

常规应用设置#

可以用于调整 Rails 应用程序一般属性的 appConfig 设置如下所述：

内容安全策略#

设置内容安全策略 (CSP) 可以帮助阻止 JavaScript 跨站脚本 (XSS) 攻击。有关配置详细信息，请参阅 GitLab 文档。内容安全策略文档

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

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

添加自定义 CSP：

yaml
1global:
2  appConfig:
3    contentSecurityPolicy:
4      enabled: true
5      report_only: false
6      directives:
7        default_src: "'self'"
8        script_src: "'self' 'unsafe-inline' 'unsafe-eval' https://www.recaptcha.net https://apis.google.com"
9        frame_ancestors: "'self'"
10        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"
11        img_src: "* data: blob:"
12        style_src: "'self' 'unsafe-inline'"

不正确配置 CSP 规则可能会阻止 GitLab 正常工作。在推出策略之前，您可能还希望将 report_only 更改为 true 以测试配置。

defaultProjectsFeatures#

标志决定是否应默认使用各自功能创建新项目。所有标志默认设置为 true。

yaml
1defaultProjectsFeatures:
2  issues: true
3  mergeRequests: true
4  wiki: true
5  snippets: true
6  builds: true
7  containerRegistry: true

Gravatar/Libravatar 设置#

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

将分析服务连接到极狐GitLab 实例#

配置 Google Analytics 和 Matomo 等分析服务的设置在 appConfig 下的 extra 键下定义：

统一对象存储#

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

yaml
1  enabled: true
2  proxy_download: true
3  storage_options:
4  connection:
5    secret:
6    key:

属性结构是共享的，所有属性都可以通过下面的各个项目覆盖。connection 属性结构是相同的。

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

当使用 AWS 提供程序作为连接（即任何 S3 兼容的提供程序，如包括的 MinIO）时，极狐GitLab Workhorse 可以卸载所有存储相关的上传。当使用此统一配置时，这将自动为您启用。

指定桶#

每种对象类型应存储在不同的桶中。默认情况下，极狐GitLab 使用以下桶名称：

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

shell
1--set global.appConfig.artifacts.bucket=<BUCKET NAME> \
2--set global.appConfig.lfs.bucket=<BUCKET NAME> \
3--set global.appConfig.packages.bucket=<BUCKET NAME> \
4--set global.appConfig.uploads.bucket=<BUCKET NAME> \
5--set global.appConfig.externalDiffs.bucket=<BUCKET NAME> \
6--set global.appConfig.terraformState.bucket=<BUCKET NAME> \
7--set global.appConfig.ciSecureFiles.bucket=<BUCKET NAME> \
8--set global.appConfig.dependencyProxy.bucket=<BUCKET NAME>

storage_options#

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

在 S3 桶上设置默认加密是启用加密的最简单方法，但您可能希望设置桶策略以确保只上传加密对象。为此，您必须在 storage_options 配置部分中配置 GitLab 以发送正确的加密标头：

示例：

yaml
1  enabled: true
2  proxy_download: true
3  connection:
4    secret: gitlab-rails-storage
5    key: connection
6  storage_options:
7    server_side_encryption: aws:kms
8    server_side_encryption_kms_key_id: arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

LFS、产物、上传、软件包、外部 MR 差异和依赖代理#

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

yaml
1  enabled: true
2  proxy_download: true
3  bucket:
4  connection:
5    secret:
6    key:

connection#

connection 属性已过渡到 Kubernetes Secret。此密钥的内容应为 YAML 格式的文件。如果 global.minio.enabled 为 true，则默认为 {} 并将被忽略。

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

• secret 是一个 Kubernetes Secret 的名称。要使用外部对象存储，此值是必需的。
• key 是密钥中包含 YAML 块的名称。默认为 connection。

有效的配置键可以在极狐GitLab 作业产物管理文档中找到。

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

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

when（仅适用于外部 MR 差异）#

externalDiffs 设置有一个附加键 when，用于有条件地将特定差异存储在对象存储中。此设置在 chart 中默认留空，以便由 Rails 代码分配默认值。

cdn（仅适用于 CI 产物）#

artifacts 设置有一个附加键 cdn，用于在 Google Cloud Storage 桶前配置 Google CDN。

传入电子邮件设置#

传入电子邮件设置在命令行选项页面中解释。

KAS 设置#

自定义密钥#

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

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

或通过配置您的 values.yaml：

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

如果您想自定义密钥值，请参阅密钥文档。

自定义 URL#

GitLab 后端使用的 KAS URL 可以通过 Helm 的 --set variable 选项进行自定义：

shell
--set global.appConfig.gitlab_kas.externalUrl="wss://custom-kas-url.example.com" \
--set global.appConfig.gitlab_kas.internalUrl="grpc://custom-internal-url" \
--set global.appConfig.gitlab_kas.clientTimeoutSeconds=10 # 可选，默认为 5 秒

或通过配置您的 values.yaml：

yaml
1global:
2  appConfig:
3    gitlab_kas:
4      externalUrl: "wss://custom-kas-url.example.com"
5      internalUrl: "grpc://custom-internal-url"
6      clientTimeoutSeconds: 10 # 可选，默认为 5 秒

外部 KAS#

可以通过显式启用外部 KAS 服务器（即不由 chart 管理）并配置所需的 URL，使 GitLab 后端感知到外部 KAS 服务器。您可以通过 Helm 的 --set variable 选项进行设置：

shell
--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" \
--set global.appConfig.gitlab_kas.clientTimeoutSeconds=10 # 可选，默认为 5 秒

或通过配置您的 values.yaml：

yaml
1global:
2  appConfig:
3    gitlab_kas:
4      enabled: true
5      externalUrl: "wss://custom-kas-url.example.com"
6      internalUrl: "grpc://custom-internal-url"
7      clientTimeoutSeconds: 10 # 可选，默认为 5 秒

TLS 设置#

KAS 支持其 kas pods 与其他 GitLab chart 组件之间的 TLS 通信。

前提条件：

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

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

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

yaml
1.internal-ca: &internal-ca gitlab-internal-tls-ca # 您用来共享 TLS CA 的密钥名称。
2.internal-tls: &internal-tls gitlab-internal-tls # 您用来共享 TLS 证书的密钥名称。
3
4global:
5  certificates:
6    customCAs:
7    - secret: *internal-ca
8  hosts:
9    domain: gitlab.example.com # 您的 gitlab 域名
10  kas:
11    tls:
12      enabled: true
13      secretName: *internal-tls
14      caSecretName: *internal-ca

建议的审阅者设置#

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

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

或通过配置您的 values.yaml：

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

如果您想自定义密钥值，请参阅密钥文档。

LDAP#

ldap.servers 设置允许配置 LDAP 用户身份验证。它以映射的形式呈现，将被转换为 gitlab.yml 中的适当 LDAP 服务器配置，就像从源代码安装一样。

可以通过提供一个包含密码的 secret 来配置密码。然后将在运行时将此密码注入 GitLab 配置中。

示例配置片段：

yaml
1ldap:
2  preventSignin: false
3  servers:
4    # 'main' 是此 LDAP 服务器的 GitLab 'provider ID'
5    main:
6      label: 'LDAP'
7      host: '_your_ldap_server'
8      port: 636
9      uid: 'sAMAccountName'
10      bind_dn: 'cn=administrator,cn=Users,dc=domain,dc=net'
11      base: 'dc=domain,dc=net'
12      password:
13        secret: my-ldap-password-secret
14        key: the-key-containing-the-password

使用全局 chart 时的示例 --set 配置项：

shell
1--set global.appConfig.ldap.servers.main.label='LDAP' \
2--set global.appConfig.ldap.servers.main.host='your_ldap_server' \
3--set global.appConfig.ldap.servers.main.port='636' \
4--set global.appConfig.ldap.servers.main.uid='sAMAccountName' \
5--set global.appConfig.ldap.servers.main.bind_dn='cn=administrator\,cn=Users\,dc=domain\,dc=net' \
6--set global.appConfig.ldap.servers.main.base='dc=domain\,dc=net' \
7--set global.appConfig.ldap.servers.main.password.secret='my-ldap-password-secret' \
8--set global.appConfig.ldap.servers.main.password.key='the-key-containing-the-password'

禁用 LDAP Web 登录#

当首选 SAML 等替代方案时，禁用通过 Web UI 使用 LDAP 凭据可能很有用。这允许将 LDAP 用于群组同步，同时还允许您的 SAML 身份提供者处理其他检查，例如自定义 2FA。

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

要禁用通过 Web 登录使用 LDAP，请设置 global.appConfig.ldap.preventSignin: true。

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

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

1. 确保自定义 CA/自签名证书已在集群/命名空间中作为密钥或配置映射创建：

   shell
   # 密钥
   kubectl -n gitlab create secret generic my-custom-ca-secret --from-file=unique_name.crt=my-custom-ca.pem
   
   # 配置映射
   kubectl -n gitlab create configmap my-custom-ca-configmap --from-file=unique_name.crt=my-custom-ca.pem

2. 然后，指定：

   shell
   1# 从密钥配置自定义 CA
   2--set global.certificates.customCAs[0].secret=my-custom-ca-secret
   3
   4# 或从配置映射
   5--set global.certificates.customCAs[0].configMap=my-custom-ca-configmap
   6
   7# 配置 LDAP 集成以信任自定义 CA
   8--set global.appConfig.ldap.servers.main.ca_file=/etc/ssl/certs/unique_name.pem

这确保 CA 证书被挂载在相关的 pod 中，路径为 /etc/ssl/certs/unique_name.pem，并在 LDAP 配置中指定其使用。

有关更多信息，请参阅自定义证书颁发机构。

OmniAuth#

极狐GitLab 可以利用 OmniAuth 允许用户使用 GitHub、Google 和其他流行服务登录。有关详细文档，请参阅 OmniAuth 文档。

yaml
1omniauth:
2  enabled: false
3  autoSignInWithProvider:
4  syncProfileFromProvider: []
5  syncProfileAttributes: ['email']
6  allowSingleSignOn: ['saml']
7  blockAutoCreatedUsers: true
8  autoLinkLdapUser: false
9  autoLinkSamlUser: false
10  autoLinkUser: ['openid_connect']
11  externalProviders: []
12  allowBypassTwoFactor: []
13  providers: []
14  # - secret: gitlab-google-oauth2
15  #   key: provider
16  # - name: group_saml

提供者设置#

providers 以数组形式呈现，作为用于填充 gitlab.yml 的映射数组，就像从源代码安装时一样。请参阅极狐 GitLab 文档中可用的 支持的提供者 选择。默认值为 []。

此属性有两个子键：secret 和 key：

1. secret: (必需) 包含提供者块的 Kubernetes Secret 的名称。
2. key: (可选) Secret 中包含提供者块的键名。默认为 provider。

或者，如果提供者除了其名称之外没有其他配置，您可以使用仅包含 'name' 属性的第二种形式，还可以选择添加 label 或 icon 属性。合格的提供者包括：

• group_saml
• kerberos

这些条目的 Secret 包含 YAML 或 JSON 格式的块，具体描述请见 OmniAuth Providers。要创建此 secret，请按照适当的说明检索这些项目，并创建一个 YAML 或 JSON 文件。

Google OAuth2 配置示例：

yaml
1name: google_oauth2
2label: Google
3app_id: 'APP ID'
4app_secret: 'APP SECRET'
5args:
6  access_type: offline
7  approval_prompt: ''

SAML 配置示例：

yaml
1name: saml
2label: 'SAML'
3args:
4  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback'
5  idp_cert_fingerprint: 'xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
6  idp_sso_target_url: 'https://SAML_IDP/app/xxxxxxxxx/xxxxxxxxx/sso/saml'
7  issuer: 'https://gitlab.example.com'
8  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'

Microsoft Azure OAuth 2.0 OmniAuth 提供者配置示例：

yaml
1name: azure_activedirectory_v2
2label: Azure
3args:
4  client_id: '<CLIENT_ID>'
5  client_secret: '<CLIENT_SECRET>'
6  tenant_id: '<TENANT_ID>'

此内容可以保存为 provider.yaml，然后从中创建一个 secret：

shell
kubectl create secret generic -n NAMESPACE SECRET_NAME --from-file=provider=provider.yaml

创建后，通过在配置中提供映射来启用 providers，如下所示：

yaml
1omniauth:
2  providers:
3    - secret: gitlab-google-oauth2
4    - secret: azure_activedirectory_v2
5    - secret: gitlab-azure-oauth2
6    - secret: gitlab-cas3

群组 SAML 配置示例：

yaml
omniauth:
  providers:
    - name: group_saml

使用全局 chart 时，--set 项目的示例配置：

shell
--set global.appConfig.omniauth.providers[0].secret=gitlab-google-oauth2 \

由于使用 --set 参数的复杂性，用户可能希望使用 YAML 片段，通过 -f omniauth.yaml 传递给 helm。

定时任务相关设置#

Sidekiq 包含可配置为使用 cron 样式计划定期运行的维护任务。以下是几个示例。有关更多任务示例，请参阅示例 gitlab.yml 中的 cron_jobs 和 ee_cron_jobs 部分。

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

yaml
1global:
2  appConfig:
3    cron_jobs:
4      stuck_ci_jobs_worker:
5        cron: "0 * * * *"
6      pipeline_schedule_worker:
7        cron: "3-59/10 * * * *"
8      expire_build_artifacts_worker:
9        cron: "*/7 * * * *"

Sentry 设置#

使用这些设置来启用 极狐GitLab 与 Sentry 的错误报告。

yaml
1global:
2  appConfig:
3    sentry:
4      enabled:
5      dsn:
6      clientside_dsn:
7      environment:

gitlab_docs 设置#

使用这些设置启用 gitlab_docs。

yaml
global:
  appConfig:
    gitlab_docs:
      enabled:
      host:

OpenID Connect 令牌过期#

配置 OpenID Connect (OIDC) 提供者令牌过期时间。

yaml
global:
  appConfig:
    oidcProvider:
      openidIdTokenExpireInSeconds: 120

智能卡认证设置#

yaml
1global:
2  appConfig:
3    smartcard:
4      enabled: false
5      CASecret:
6      clientCertificateRequiredHost:
7      sanExtensions: false
8      requiredForGitAccess: false

Sidekiq 路由规则设置#

极狐GitLab 支持在作业被安排之前将其从工作者路由到所需队列。Sidekiq 客户端根据配置的路由规则列表匹配作业。规则从头到尾进行评估，一旦找到匹配的工作者，便停止对该工作者的处理（第一个匹配项获胜）。如果工作者不匹配任何规则，则返回到从工作者名称生成的队列名称。

默认情况下，路由规则未配置（或表示为空数组），所有作业都路由到从工作者名称生成的队列。

路由规则列表是查询和相应队列的有序数组：

• 查询遵循 worker 匹配查询 语法。
• <queue_name> 必须匹配在 sidekiq.pods 下定义的有效 Sidekiq 队列名称 sidekiq.pods[].queues。如果队列名称为 nil 或为空字符串，则工作者路由到由工作者名称生成的队列。参考 Sidekiq 配置完整示例。

查询支持通配符匹配 *，它匹配所有工作者。因此，通配符查询必须位于列表末尾，否则后面的规则会被忽略：

yaml
1global:
2  appConfig:
3    sidekiq:
4      routingRules:
5      - ["resource_boundary=cpu", "cpu-boundary"]
6      - ["feature_category=pages", null]
7      - ["feature_category=search", "search"]
8      - ["feature_category=memory|resource_boundary=memory", "memory-bound"]
9      - ["*", "default"]

配置 Rails 设置#

极狐GitLab 套件的大部分基于 Rails。因此，项目中的许多容器都使用此技术栈。这些设置适用于所有这些容器，并提供了一种简便的方法来全局设置它们，而不是单独设置。

yaml
global:
  rails:
    bootsnap:
      enabled: true

配置 Workhorse 设置#

极狐GitLab 套件的多个组件通过极狐GitLab Workhorse 访问 API。目前，它是 Webservice chart 的一部分。这些设置由需要联系极狐GitLab Workhorse 的所有 chart 使用，提供了一种简便的方法来全局设置它们，而不是单独设置。

yaml
global:
  workhorse:
    serviceName: webservice-default
    host: api.example.com
    port: 8181

Bootsnap 缓存#

我们的 Rails 代码库使用 Shopify 的 Bootsnap Gem。此处的设置用于配置该行为。

bootsnap.enabled 控制此功能的激活。默认为 true。

测试表明，启用 Bootsnap 可以提升整体应用程序性能。当可用预编译缓存时，某些应用程序容器的增益超过 33%。目前，极狐GitLab 未将此预编译缓存与其容器一起发布，导致增益“仅”为 14%。在没有预编译缓存的情况下，这种增益的代价是每个 Pod 初始启动时会出现小 IO 的剧烈峰值。因此，我们提供了一种方法，可以在此对性能有影响的环境中禁用 Bootsnap。

如果可能，我们建议保持启用。

配置极狐GitLab Shell#

有几个项目用于 极狐GitLab Shell chart 的全局配置。

yaml
1global:
2  shell:
3    port:
4    authToken: {}
5    hostKeys: {}
6    tcp:
7      proxyProtocol: false

端口#

您可以控制 Ingress 用于传递 SSH 流量的端口，以及极狐GitLab 提供的 SSH URL 中使用的端口。此设置反映在服务监听的端口以及项目 UI 中提供的 SSH 克隆 URL 中。

yaml
global:
  shell:
    port: 32022

您可以结合使用 global.shell.port 和 nginx-ingress.controller.service.type=NodePort 来为 NGINX 控制器服务对象设置 NodePort。请注意，如果设置了 nginx-ingress.controller.service.nodePorts.gitlab-shell，则在为 NGINX 设置 NodePort 时，它将覆盖 global.shell.port。

yaml
1global:
2  shell:
3    port: 32022
4
5nginx-ingress:
6  controller:
7    service:
8      type: NodePort

TCP 代理协议#

您可以启用对 SSH Ingress 上的代理协议的处理，以正确处理来自添加代理协议头的上游代理的连接。这样做将防止 SSH 接收额外的头信息，并且不会破坏 SSH。

一个常见的环境是，当使用 AWS 和 ELB 处理集群的入站连接时，需要启用代理协议的处理。

yaml
global:
  shell:
    tcp:
      proxyProtocol: true # 默认 false

配置极狐GitLab Pages#

其他 chart 使用的全局极狐GitLab Pages 设置记录在 global.pages 键下。

yaml
1global:
2  pages:
3    enabled:
4    accessControl:
5    path:
6    host:
7    port:
8    https:
9    externalHttp:
10    externalHttps:
11    artifactsServer:
12    objectStore:
13      enabled:
14      bucket:
15      proxy_download: true
16      connection: {}
17        secret:
18        key:
19    localStore:
20      enabled: false
21      path:
22    apiSecret: {}
23      secret:
24      key:
25    namespaceInPath: false

配置 Webservice#

其他 chart 使用的全局 Webservice 设置位于 global.webservice 键下。

yaml
global:
  webservice:
    workerTimeout: 60

workerTimeout#

配置请求超时（以秒为单位），在此之后 Webservice 主进程会杀死 Webservice 工作进程。默认值为 60 秒。

global.webservice.workerTimeout 设置不会影响最大请求持续时间。要设置最大请求持续时间，请设置以下环境变量：

yaml
1gitlab:
2  webservice:
3    workerTimeout: 60
4    extraEnv:
5      GITLAB_RAILS_RACK_TIMEOUT: "60"
6      GITLAB_RAILS_WAIT_TIMEOUT: "90"

自定义证书颁发机构#

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

要创建 Secret 或 ConfigMap：

shell
# 从证书文件创建 Secret
kubectl create secret generic secret-custom-ca --from-file=unique_name.crt=/path/to/cert

# 从证书文件创建 ConfigMap
kubectl create configmap cm-custom-ca --from-file=unique_name.crt=/path/to/cert

要配置 Secret 或 ConfigMap，或两者，请在 globals 中指定它们：

yaml
1global:
2  certificates:
3    customCAs:
4      - secret: secret-custom-CAs           # 挂载 Secret 的所有键
5      - secret: secret-custom-CAs           # 仅挂载 Secret 的指定键
6        keys:
7          - unique_name.crt
8      - configMap: cm-custom-CAs            # 挂载 ConfigMap 的所有键
9      - configMap: cm-custom-CAs            # 仅挂载 ConfigMap 的指定键
10        keys:
11          - unique_name_1.crt
12          - unique_name_2.crt

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

应用程序资源#

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

要启用，请将 global.application.create 设置为 true：

yaml
global:
  application:
    create: true

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

yaml
1global:
2  application:
3    allowClusterRoles: false
4nginx:
5  controller:
6    scope:
7      enabled: true
8gitlab-runner:
9  rbac:
10    clusterWideAccess: false
11certmanager:
12  install: false

极狐GitLab 基础镜像#

极狐GitLab Helm chart 使用通用极狐GitLab 基础镜像进行各种初始化任务。此镜像支持 UBI 构建，并与其他镜像共享层。

服务账户#

极狐GitLab Helm chart 允许 pod 使用自定义 服务账户。通过 global.serviceAccount 中的以下设置进行配置：

yaml
1global:
2  serviceAccount:
3    enabled: false
4    create: true
5    annotations: {}
6    automountServiceAccountToken: false
7    ## 用于 serviceAccount 的名称，否则默认为 chart 全名
8    # name:

• 设置 global.serviceAccount.enabled 控制每个组件通过 spec.serviceAccountName 引用服务账户。
• 设置 global.serviceAccount.create 控制通过 Helm 创建服务账户对象。
• 设置 global.serviceAccount.name 控制服务账户对象的名称以及每个组件引用的名称。
• 设置 global.serviceAccount.automountServiceAccountToken 控制是否应在 pod 中挂载默认服务账户访问令牌。除非某些 sidecars 需要它才能正常工作（例如 Istio），否则您不应启用此选项。

注解#

自定义注解可以应用于 Deployment、Service 和 Ingress 对象。

yaml
1global:
2  deployment:
3    annotations:
4      environment: production
5
6  service:
7    annotations:
8      environment: production
9
10  ingress:
11    annotations:
12      environment: production

节点选择器#

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

yaml
global:
  nodeSelector:
    disktype: ssd

标签#

公共标签#

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

yaml
1global:
2  common:
3    labels:
4      environment: production
5gitlab:
6  gitlab-shell:
7    common:
8      labels:
9        foo: bar

在上述示例配置中，Helm chart 部署的几乎所有组件将获得标签集 environment: production。极狐GitLab Shell chart 的所有组件将收到标签集 foo: bar。某些 chart 允许额外的嵌套。例如，Sidekiq 和 Webservices chart 根据您的配置需求允许额外的部署：

yaml
1gitlab:
2  sidekiq:
3    pods:
4      - name: pod-0
5        common:
6          labels:
7            baz: bat

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

我们依赖的某些 chart 不包括在此标签配置中。只有 极狐GitLab 组件子 chart 将接收这些额外标签。

Pod#

自定义标签可以应用于各种 Deployment 和 Job。这些标签是对由此 Helm chart 构建的现有或预配置标签的补充。这些补充标签将 不 用于 matchSelectors。

yaml
global:
  pod:
    labels:
      environment: production

服务#

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

yaml
global:
  service:
    labels:
      environment: production

跟踪#

极狐GitLab Helm chart 支持跟踪，您可以通过以下方式进行配置：

yaml
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 用于配置跟踪跨度将被发送到的位置。您可以在极狐GitLab 跟踪文档中了解更多信息。
• global.tracing.urlTemplate 用作极狐GitLab 性能栏中跟踪信息 URL 呈现的模板。

extraEnv#

extraEnv 允许您在通过极狐GitLab chart 部署的 pod 中的所有容器中公开其他环境变量（charts/gitlab/charts）。全局级别设置的额外环境变量将与在 chart 级别提供的变量合并，优先级给予 chart 级别提供的变量。

以下是 extraEnv 的示例用法：

yaml
global:
  extraEnv:
    SOME_KEY: some_value
    SOME_OTHER_KEY: some_other_value

extraEnvFrom#

extraEnvFrom 允许从其他数据源中在所有容器中公开额外的环境变量。可以在 global 级别（global.extraEnvFrom）和子 chart 级别（<subchart_name>.extraEnvFrom）设置额外的环境变量。

Sidekiq 和 Webservice chart 支持额外的本地覆盖。请参阅它们的文档以获取更多详细信息。

以下是 extraEnvFrom 的示例用法：

yaml
1global:
2  extraEnvFrom:
3    MY_NODE_NAME:
4      fieldRef:
5        fieldPath: spec.nodeName
6    MY_CPU_REQUEST:
7      resourceFieldRef:
8        containerName: test-container
9        resource: requests.cpu
10gitlab:
11  kas:
12    extraEnvFrom:
13      CONFIG_STRING:
14        configMapKeyRef:
15          name: useful-config
16          key: some-string
17          # optional: boolean

配置 OAuth 设置#

OAuth 集成已为支持它的服务开箱即用地配置。global.oauth 中指定的服务将在部署期间自动注册为极狐GitLab 中的 OAuth 客户端应用程序。默认情况下，此列表包括极狐GitLab Pages（如果启用了访问控制）。

yaml
1global:
2  oauth:
3    gitlab-pages: {}
4    # secret
5    # appid
6    # appsecret
7    # redirectUri
8    # authScope

有关 secret 的详细信息，请查看 secrets 文档。

Kerberos#

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

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

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

通过设置 global.appConfig.kerberos.enabled=true 启用 Git 的 Kerberos 集成。这还将 kerberos 提供者添加到启用的 OmniAuth 提供者列表中，以用于浏览器中的基于票证的身份验证。

如果设置为 false，Helm chart 仍会将 keytab 挂载到 toolbox、Sidekiq 和 webservice pod 中，可以与 Kerberos 手动配置的 OmniAuth 设置 一起使用。

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

yaml
1global:
2  appConfig:
3    kerberos:
4      enabled: true
5      keytab:
6        secret: gitlab-kerberos-keytab
7        key: keytab
8      servicePrincipalName: ""
9      krb5Config: |
10        [libdefaults]
11            default_realm = EXAMPLE.COM
12      dedicatedPort:
13        enabled: false
14        port: 8443
15        https: true
16      simpleLdapLinkingAllowedRealms:
17        - example.com

有关更多详细信息，请查看 Kerberos 文档。

Kerberos 专用端口#

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

使用极狐GitLab CI/CD 时，当前需要使用专用端口，因为极狐GitLab Runner 帮助程序依赖于 URL 中的凭据从极狐GitLab 克隆。

可以通过 global.appConfig.kerberos.dedicatedPort 设置启用此功能：

yaml
1global:
2  appConfig:
3    kerberos:
4      [...]
5      dedicatedPort:
6        enabled: true
7        port: 8443
8        https: true

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

LDAP 自定义允许域#

global.appConfig.kerberos.simpleLdapLinkingAllowedRealms 可用于指定一组域，用于在用户的 LDAP DN 与用户的 Kerberos 领域不匹配时将 LDAP 和 Kerberos 身份关联在一起。有关更多详细信息，请参阅 Kerberos 集成文档中的自定义允许域部分。

发件邮件#

发件邮件配置可通过 global.smtp.*、global.appConfig.microsoft_graph_mailer.* 和 global.email.* 获得。

yaml
1global:
2  email:
3    display_name: 'GitLab'
4    from: 'gitlab@example.com'
5    reply_to: 'noreply@example.com'
6  smtp:
7    enabled: true
8    address: 'smtp.example.com'
9    tls: true
10    authentication: 'plain'
11    user_name: 'example'
12    password:
13      secret: 'smtp-password'
14      key: 'password'
15  appConfig:
16    microsoft_graph_mailer:
17      enabled: false
18      user_id: "YOUR-USER-ID"
19      tenant: "YOUR-TENANT-ID"
20      client_id: "YOUR-CLIENT-ID"
21      client_secret:
22        secret:
23        key: secret
24      azure_ad_endpoint: "https://login.microsoftonline.com"
25      graph_endpoint: "https://graph.microsoft.com"

有关可用配置选项的更多信息，请参阅 发件邮件文档。

有关更详细的示例，请参阅 Linux 软件包 SMTP 设置文档。

平台#

platform 键保留用于特定平台（如 GKE 或 EKS）上的特定功能。

亲和性#

可以通过 global.antiAffinity 和 global.affinity 获得亲和性配置。亲和性允许您根据节点标签或节点上已运行的 pod 的标签约束您的 pod 可以调度的节点。这允许在集群中分布 pod 或选择特定节点，以确保在节点故障时提高弹性。

yaml
global:
  antiAffinity: soft
  affinity:
    podAntiAffinity:
      topologyKey: "kubernetes.io/hostname"

• global.antiAffinity 可以取两个值：
  • soft：定义 preferredDuringSchedulingIgnoredDuringExecution 反亲和性，其中 Kubernetes 调度程序将尝试强制执行规则，但不保证结果。
  • hard：定义 requiredDuringSchedulingIgnoredDuringExecution 反亲和性，其中规则 必须 满足才能将 pod 调度到节点上。
• global.affinity.podAntiAffinity.topologyKey 定义用于将节点分为逻辑区域的节点属性。最常见的 topologyKey 值是：
  • kubernetes.io/hostname
  • topology.kubernetes.io/zone
  • topology.kubernetes.io/region

Kubernetes 关于 Pod 间亲和性和反亲和性 的参考。

Pod 优先级和抢占#

Pod 优先级可以通过 global.priorityClassName 或每个子 chart 的 priorityClassName 配置。设置 pod 优先级可以让调度器驱逐低优先级 pod，以使待处理的 pod 能够调度。

yaml
global:
  priorityClassName: system-cluster-critical

日志轮转#

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

要启用日志轮转，请将 GITLAB_LOGGER_TRUNCATE_LOGS 环境变量设置为 true。

Jobs#

最初，极狐GitLab 中的作业后缀为 Helm .Release.Revision，这并不理想，因为它总是会在运行 helm upgrade --install 时导致作业更新，即使没有变化。这也阻碍了基于 helm template 的工作流的正常工作，例如使用 ArgoCD 时。使用 .Release.Revision 作为名称后缀的决定基于作业可能只执行一次的前提，并且 helm uninstall 不会删除作业，这些前提（现在）都是错误的。

从极狐GitLab Helm chart 7.9 及更高版本开始，作业名称默认后缀为基于 chart 应用程序版本和 chart 值的哈希，还可能包含 global.gitlabVersion。这种方法确保作业名称在多个 helm template 和 helm upgrade --install 执行中保持稳定（如果没有变化），甚至可以在不影响部署期间更改作业的不可变字段的值（作业由于新名称而被替换）。

可以通过设置 global.job.nameSuffixOverride 覆盖默认生成的哈希以使用自定义后缀。该字段支持模板化，因此可以再现使用 .Release.Revision 作为名称后缀的旧行为：

yaml
global:
  job:
    nameSuffixOverride: '{{ .Release.Revision }}'

如果您有意总是想触发更改，例如因为您使用浮动标签（如 latest）作为所有版本，可以使用动态值（如时间戳）覆盖默认生成的哈希：

yaml
global:
  job:
    nameSuffixOverride: '{{ dateInZone "2006-01-02-15-04-05" (now) "UTC" }}'

或者，您可以在命令行中与 helm 一起使用它：

shell
helm <command> <options> --set global.job.nameSuffixOverride=$(date +%Y-%m-%d-%H-%M-%S)

Traefik#

可以通过 globals.traefik 配置 Traefik 设置。

yaml
global:
  traefik:
    apiVersion: ""