- Host 配置
- 配置 Horizontal Pod Autoscaler 设置
- 配置 PodDisruptionBudget 设置
- 配置 CronJob 设置
- 配置 Monitoring 设置
- Ingress 配置
- 极狐GitLab 版本
- PostgreSQL 设置
- Redis 配置
- Registry 配置
- Gitaly 配置
- Praefect 配置
- MinIO 配置
- appConfig 配置
- Rails 配置
- Workhorse 配置
- GitLab Shell 配置
- GitLab Pages 配置
- Webservice 配置
- 自定义证书颁发机构
- Application 资源
- GitLab base 镜像
- Service Accounts
- Annotations
- Node Selector
- Labels
- Tracing
- extraEnv
- extraEnvFrom
- OAuth 配置
- Kerberos
- Outgoing email
- Platform
- Affinity
- Pod Priority 和 Preemption
- 日志轮换
使用 Globals 配置 chart
为了在安装 Helm chart 时减少重复配置,可以在 values.yaml
的 global
部分进行一些全局配置。这些全局配置跨多个 chart 使用,其它设置都在各个 chart 自己的范围内。有关全局变量如何工作的更多信息,请查看 Helm 全局配置文档。
- Hosts
- Ingress
- 极狐GitLab 版本
- PostgreSQL
- Redis
- Registry
- Gitaly
- Praefect
- MinIO
- appConfig
- Rails
- Workhorse
- GitLab Shell
- Pages
- Webservice
- 自定义证书颁发机构
- Application 资源
- GitLab base 镜像
- Service Accounts
- Annotations
- Tracing
- extraEnv
- extraEnvFrom
- OAuth
- Kerberos
- Outgoing email
- Platform
- Affinity
- Pod Priority 和 Preemption
- 日志轮换
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 服务器的命名端口。 |
keda.enabled |
Boolean | false |
使用 KEDA ScaledObjects 替代 HorizontalPodAutoscalers
|
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
key 下:
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
apiVersion |
String | 在 HorizontalPodAutoscaler 对象定义中使用的 API 版本。 |
配置 PodDisruptionBudget 设置
PDB 的极狐GitLab 全局 host 设置位于 global.pdb
key 下:
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
apiVersion |
String | PodDisruptionBudget 对象定义中使用的 API 版本。 |
配置 CronJob 设置
CronJobs 的极狐GitLab 全局 host 设置位于 global.batch.cronJob
key 下:
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
apiVersion |
String | CronJob 对象定义中使用的 API 版本。 |
配置 Monitoring 设置
ServiceMonitors 和 PodMonitors 的极狐GitLab 全局设置位于 global.monitoring
key 下:
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
enabled |
Boolean | false |
无论 monitoring.coreos.com/v1 API 是否可用,都启用监控资源。 |
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 版本
可以使用 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
如果要通过双向 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,我们建议使用外部 Redis 实例。
您可以通过设置 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+) 进行身份验证的用户。 | |
auth.enabled |
Boolean | true | 提供了是否在 Redis 实例中使用密码的切换功能。 |
auth.key |
String | 定义 Secret 中包含密码的 key 的名称。 | |
auth.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 |
存储代码库相关数据 |
workhorse |
Workhorse 的 pub/sub 队列后端 |
可以指定任意数量的实例。任何未指定的实例将由指定的主 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
password:
enabled: true
secret: cache-secret
key: cache-password
sharedState:
host: shared.redis.example
port: 6379
password:
enabled: true
secret: shared-secret
key: shared-password
queues:
host: queues.redis.example
port: 6379
password:
enabled: true
secret: queues-secret
key: queues-password
actioncable:
host: cable.redis.example
port: 6379
password:
enabled: true
secret: cable-secret
key: cable-password
traceChunks:
host: traceChunks.redis.example
port: 6379
password:
enabled: true
secret: traceChunks-secret
key: traceChunks-password
rateLimiting:
host: rateLimiting.redis.example
port: 6379
password:
enabled: true
secret: rateLimiting-secret
key: rateLimiting-password
sessions:
host: sessions.redis.example
port: 6379
password:
enabled: true
secret: sessions-secret
key: sessions-password
repositoryCache:
host: repositoryCache.redis.example
port: 6379
password:
enabled: true
secret: repositoryCache-secret
key: repositoryCache-password
workhorse:
host: workhorse.redis.example
port: 6379
password:
enabled: true
secret: workhorse-secret
key: workhorse-password
下表描述了 Redis 实例中的属性。
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
.host |
String | 要使用数据库所在的 Redis 服务器的主机名。 | |
.port |
Integer | 6379 |
连接 Redis 服务器的端口。 |
.password.enabled |
Boolean | 真 | 提供了是否在 Redis 实例中使用密码的切换功能。 |
.password.key |
String | 定义 Secret 中包含密码的 key 的名称。 | |
.password.secret |
String | 定义要拉取的 Kubernetes Secret 的名称。 |
需要定义主 Redis,因为还有未分开的其它持久化类。
每个实例定义也可能使用 Redis Sentinel support。Sentinel 配置不共享,需要为每个使用 Sentinels 的实例指定。关于配置 Sentinel 服务器的属性,请参考 Sentinel 配置文档。
指定 Redis 安全方案 (SSL)
要使用 SSL 连接到 Redis:
- 更新您的配置以使用
rediss
(两个s
)方案参数。 -
在您的配置中,将
authClients
设置为false
:global: redis: scheme: rediss redis: tls: enabled: true authClients: false
此配置是必需的,因为 Redis 默认为双向 TLS,并非所有 chart 组件都支持。
- 遵循 Bitnami 的启用 TLS 的步骤。确保 chart 组件信任用于创建 Redis 证书的证书颁发机构。
- 可选。如果您使用自定义证书颁发机构,请参阅自定义证书颁发机构全局配置。
无密码 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 节点:
-
chart 内部,通过 Gitaly chart 作为
StatefulSet
的一部分。 - chart 外部,作为 external pets。
- 混合环境 同时使用内部和外部节点。
有关管理新项目要使用的节点的详细信息,查看 仓库存储路径文档。
如果提供了 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
定义要拉取的 KubernetesSecret
的名称。 -
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 | (empty) | hook 被认为失败之前的等待时间。 |
graphQlTimeout |
Integer | (empty) | Rails 必须完成 GraphQL 请求的时间(以秒为单位)。 |
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
建议审核者设置
通过使用 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'
--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 证书,您必须:
-
确保将自定义 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
-
然后进行以下配置:
# 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 配置中的使用。
/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 秒。
global.webservice.workerTimeout
设置不会影响最大请求持续时间。要设置最大请求持续时间,请设置以下环境变量:
gitlab:
webservice:
workerTimeout: 60
extraEnv:
GITLAB_RAILS_RACK_TIMEOUT: "60"
GITLAB_RAILS_WAIT_TIMEOUT: "90"
自定义证书颁发机构
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
.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 镜像。
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 对象名称和每个组件引用的名称。
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
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 中终止和配置。
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 文档获取配置项的更多信息。
查看 Linux 软件包 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