- 设计选择
- 配置
- 安装参数
- Chart 配置示例
- 启用子 chart
- 配置
image
- 配置
service
- 配置
ingress
- 配置 TLS
-
配置
networkpolicy
- 定义 Registry 配置
- 垃圾收集
使用容器镜像库
registry
子 chart 为在 Kubernetes 上的完整云原生 GitLab 部署提供了 Registry 组件。该子 chart 使用了上游中包含 Docker Distribution 的 registry 容器。该 chart 由 3 个主要部分组成:Service、Deployment 和 ConfigMap。
所有配置都根据官方 Registry 配置文档处理,使用提供变量给 Deployment
的 /etc/docker/registry/config.yml
,从 ConfigMap
填充的。 ConfigMap
覆盖上游默认值,但基于配置文件。
获取更多细节,参阅下述示例:
设计选择
选择 Kubernetes Deployment
作为此 chart 的部署方法,以允许简单的实例扩展,同时允许滚动更新。
该 chart 使用了两个必需的 secret 和一个可选的 secret:
必需
-
global.registry.certificate.secret
:包含公共证书包的全局 secret,用于验证关联的 GitLab 实例提供的身份验证令牌。有关使用 GitLab 作为身份验证端点,请查看文档。 -
global.registry.httpSecret.secret
:包含 registry pod 之间共享 secret 的全局 secret。
可选
-
profiling.stackdriver.credentials.secret
:如果启用了 Stackdriver 分析并且您需要提供显式服务帐户凭据,则此密钥中的值(默认情况下在credentials
键中)是 GCP 服务帐户 JSON 凭据。如果您使用 GKE 并使用 Workload Identity(或节点服务帐户,尽管不推荐这样做),那么这个 secret 不是必需的,也不应该提供。 无论哪种情况,服务帐户都需要角色roles/cloudprofiler.agent
或等效的 手动权限
配置
我们将在下面描述配置的所有主要部分。从父 chart 配置时,这些值将是:
registry:
enabled:
maintenance:
readOnly:
enabled: false
uploadpurging:
enabled: true
age: 168h
interval: 24h
dryrun: false
image:
tag: 'v3.51.1-gitlab'
pullPolicy: IfNotPresent
annotations:
service:
type: ClusterIP
name: registry
httpSecret:
secret:
key:
authEndpoint:
tokenIssuer:
certificate:
secret: gitlab-registry
key: registry-auth.crt
deployment:
terminationGracePeriodSeconds: 30
draintimeout: '0'
hpa:
minReplicas: 2
maxReplicas: 10
cpu:
targetAverageUtilization: 75
behavior:
scaleDown:
stabilizationWindowSeconds: 300
storage:
secret:
key: storage
extraKey:
compatibility:
schema1:
enabled: false
validation:
disabled: true
manifests:
referencelimit: 0
payloadsizelimit: 0
urls:
allow: []
deny: []
notifications: {}
tolerations: []
ingress:
enabled: false
tls:
enabled: true
secretName: redis
annotations:
configureCertmanager:
proxyReadTimeout:
proxyBodySize:
proxyBuffering:
networkpolicy:
enabled: false
egress:
enabled: false
rules: []
ingress:
enabled: false
rules: []
tls:
enabled: false
secretName:
verify: true
caSecretName:
如果您选择将此 chart 作为独立部署,请删除顶层的 registry
。
安装参数
参数 | 默认值 | 说明 |
---|---|---|
annotations
| Pod annotations | |
podLabels
| 补充 Pod 标签。 不会用于选择器。 | |
common.labels
| 应用于此 chart 创建的所有对象的补充标签。 | |
authAutoRedirect
| true
| 身份验证自动重定向(必须为 Windows 客户端才能工作) |
authEndpoint
| global.hosts.gitlab.name
| 身份验证端点(仅主机和端口) |
certificate.secret
| gitlab-registry
| JWT 证书 |
compatiblity
| 兼容性设置的配置 | |
debug.addr.port
| 5001
| Debug 端口 |
debug.prometheus.enabled
| false
|
已废弃 使用 metrics.enabled
|
debug.prometheus.path
| ""
|
已废弃 使用 metrics.path
|
metrics.enabled
| false
| 指标端点是否可用于抓取 |
metrics.path
| /metrics
| 指标端点路径 |
metrics.serviceMonitor.enabled
| false
| 是否创建 ServiceMonitor 使 Prometheus Operator 能够管理指标抓取,请注意启用此功能会删除 prometheus.io 抓取注释
|
metrics.serviceMonitor.additionalLabels
| {}
| 要添加到 ServiceMonitor 的其它标签 |
metrics.serviceMonitor.endpointConfig
| {}
| ServiceMonitor 的附加端点配置 |
deployment.terminationGracePeriodSeconds
| 30
| Pod 需要优雅终止的可选持续时间(以秒为单位)。 |
deployment.strategy
| {}
| 允许配置部署使用的更新策略 |
draintimeout
| '0'
| 收到 SIGTERM 信号后等待 HTTP 连接耗尽的时间(例如 10s )
|
relativeurls
| false
| 启用 registry 在位置 header 中返回相对 URL。 |
enabled
| true
| 启用 registry 标志 |
hpa.behavior
| {scaleDown: {stabilizationWindowSeconds: 300 }}
| 包含放大和缩小行为的规范(需要 autoscaling/v2beta2 或更高版本)
|
hpa.customMetrics
| []
| 自定义指标包含用于计算所需副本数的规范(覆盖在 targetAverageUtilization 中配置的平均 CPU 利用率的默认使用值)
|
hpa.cpu.targetType
| Utilization
| 设置自动缩放 CPU 目标类型,必须是 Utilization 或 AverageValue
|
hpa.targetAverageValue
| 75
| 设置自动扩缩容目标值 |
hpa.cpu.targetAverageUtilization
| 设置自动缩放 CPU 目标利用率 | |
hpa.memory.targetType
| 设置自动缩放内存目标类型,必须是 Utilization 或 AverageValue
| |
hpa.memory.targetAverageValue
| 设置自动缩放内存目标值 | |
hpa.memory.targetAverageUtilization
| 设置自动缩放内存目标利用率 | |
hpa.minReplicas
| 2
| 最小副本数 |
hpa.maxReplicas
| 10
| 最大副本数 |
httpSecret
| Https secret | |
extraEnvFrom
| 要暴露的其它数据源的额外环境变量列表 | |
image.pullPolicy
| 仓库中镜像的拉取策略 | |
image.pullSecrets
| 用于镜像仓库的 secret | |
image.repository
| registry
| Registry 镜像 |
image.tag
| v3.51.1-gitlab
| 要使用的镜像版本 |
init.image.repository
| initContainer 镜像 | |
init.image.tag
| initContainer 镜像标签 | |
log
| {level: info, fields: {service: registry}}
| 配置日志选项 |
minio.bucket
| global.registry.bucket
| 使用的 Legacy 存储桶名称 |
maintenance.readonly.enabled
| false
| 启用仓库的只读模式 |
maintenance.uploadpurging.enabled
| true
| 启用上传清除 |
maintenance.uploadpurging.age
| 168h
| 清除早于指定时间的上传 |
maintenance.uploadpurging.interval
| 24h
| 执行上传清除的频率 |
maintenance.uploadpurging.dryrun
| false
| 只清除上传的列表而不删除 |
reporting.sentry.enabled
| false
| 启用 Sentry 报告 |
reporting.sentry.dsn
| Sentry DSN (Data Source Name) | |
reporting.sentry.environment
| Sentry 环境 | |
profiling.stackdriver.enabled
| false
| 使用 Stackdriver 启用连续分析 |
profiling.stackdriver.credentials.secret
| gitlab-registry-profiling-creds
| 包含凭据的 secret 名称 |
profiling.stackdriver.credentials.key
| credentials
| 存储凭据的密钥 |
profiling.stackdriver.service
|
RELEASE-registry (模板化服务名称)
| 用于记录下配置文件的 Stackdriver 服务的名称 |
profiling.stackdriver.projectid
| 运行的 GCP 项目 | 将配置文件报告给的 GCP 项目 |
database.enabled
| false
| 启用元数据数据库。 这是一项实验性功能,不得在生产环境中使用。 |
database.host
| global.psql.host
| 数据库服务器主机名。 |
database.port
| global.psql.port
| 数据库服务器端口 |
database.user
| 数据库用户名 | |
database.password.secret
| RELEASE-registry-database-password
| 包含数据库密码的 secret 名称。 |
database.password.key
| password
| 存储数据库密码的 secret key |
database.name
| 数据库名称 | |
database.sslmode
| SSL 模式。可以是 disable 、allow 、prefer 、require 、verify-ca 或 verify-full 之一。
| |
database.ssl.secret
| global.psql.ssl.secret
| 包含客户端证书、密钥和证书颁发机构的机密。 默认为主要的 PostgreSQL SSL 机密。 |
database.ssl.clientCertificate
| global.psql.ssl.clientCertificate
| 引用客户端证书的 secret 中的 key。 |
database.ssl.clientKey
| global.psql.ssl.clientKey
| 引用客户端密钥的 secret 中的 key。 |
database.ssl.serverCA
| global.psql.ssl.serverCA
| 引用证书颁发机构(CA)的 secret 中的 key。 |
database.connecttimeout
| 0
| 等待连接的最长时间。0 或未指定表示无限期地等待。 |
database.draintimeout
| 0
| 在关闭时等待耗尽所有连接的最长时间。0 或未指定意味着无限期地等待。 |
database.preparedstatements
| false
| 启用预编译语句。默认情况下禁用以与 PgBouncer 兼容。 |
database.pool.maxidle
| 0
| 空闲连接池中的最大连接数。如果 maxopen 小于 maxidle ,那么 maxidle 就会减少以匹配 maxopen 限制。0 或未指定意味着没有空闲连接.
|
database.pool.maxopen
| 0
| 数据库的最大打开连接数。 如果 maxopen 小于maxidle ,那么 maxidle 就会减少以匹配 maxopen 限制。0 或未指定意味着无限制的打开连接。
|
database.pool.maxlifetime
| 0
| 连接可以重用的最长时间。 过期的连接可能会在重用之前延迟关闭。0 或未指定意味着无限重用。 |
database.migrations.enabled
| true
| 启用迁移作业以在 Chart 的初始部署和升级时自动运行迁移。请注意,也可以从任何正在运行的 Registry pod 中手动运行迁移。 |
database.migrations.activeDeadlineSeconds
| 3600
| 在迁移作业上设置 activeDeadlineSeconds。 |
database.migrations.backoffLimit
| 6
| 在迁移作业上设置 backoffLimit。 |
gc.disabled
| true
| 当设置为 true 时,在线 GC workers 被禁用。
|
gc.maxbackoff
| 24h
| 发生错误时,用于在 worker 运行之间休眠的最大指数补偿时间。 除非 gc.noidlebackoff 为 true ,否则也适用于没有任务要处理的情况。 请注意,这不是绝对最大值,因为始终会添加高达 33% 的随机抖动因子。
|
gc.noidlebackoff
| false
| 设置为 true 时,在没有要处理的任务时,禁用 worker 运行之间的指数补偿。
|
gc.transactiontimeout
| 10s
| 每个 worker 运行的工作事务超时。每个 worker 在开始时启动一个数据库事务。如果超过此超时,则取消 worker run 以避免停滞或长时间运行的事务。 |
gc.blobs.disabled
| false
| 当设置为“true”时,blob 的 GC 工作线程被禁用。 |
gc.blobs.interval
| 5s
| 每个 worker run 之间的初始睡眠间隔。 |
gc.blobs.storagetimeout
| 5s
| 存储操作的超时时间。用于限制在存储后端删除悬空 blob 的请求的持续时间。 |
gc.manifests.disabled
| false
| 当设置为 true 时,manifest 的 GC worker 被禁用。
|
gc.manifests.interval
| 5s
| 每个 worker run 之间的初始睡眠间隔。 |
gc.reviewafter
| 24h
| 垃圾收集器应拾取记录以供审查的最短时间。 -1 表示无需等待。
|
migration.enabled
| false
| 当设置为 true 时,启用迁移模式。新的仓库将被添加到数据库中,而现有的仓库将继续使用文件系统。 这是一项实验性功能,不得在生产环境中使用。
|
migration.disablemirrorfs
| false
| 当设置为 true 时,registry 不会将元数据写入文件系统。必须与元数据数据库结合使用。这是一项实验性功能,不得在生产环境中使用。
|
migration.rootdirectory
| 允许已迁移到数据库的仓库使用单独的存储路径。使用与主存储驱动程序配置不同的根目录允许在线迁移。这是一项实验性功能,不得在生产环境中使用。 | |
migration.importtimeout
| 5m
| 导入作业在中止之前完成的最长持续时间。这是一项实验性功能,不得在生产环境中使用。 |
migration.preimporttimeout
| 1h
| 预导入作业在中止之前完成的最长持续时间。这是一项实验性功能,不得在生产环境中使用。 |
migration.tagconcurrency
| 1
| 此参数确定对文件系统后端的并发标记详细信息请求数,可以大大减少成功预导入完成后,导入仓库所花费的时间。预导入不受此参数影响。这是一项实验性功能,不得在生产环境中使用。 |
migration.maxconcurrentimports
| 1
| 此参数确定每个镜像库实例允许的最大并发导入数,有助于减少启用迁移模式时,镜像库所需的资源数量。这是一项实验性功能,不得在生产环境中使用。 |
migration.importnotification.enabled
| false
| 当设置为 true 时,将启用导入通知功能,需要配置以下参数。这是一项实验性功能,不得在生产环境中使用。
|
migration.importnotification.url
| '<GitLab URL>/api/v4/internal/registry/repositories/{path}/migration/status'
| 通知将发送到的 URL 端点,启用 importnotification 时需要,必须是有效的 URL,包括 scheme。可以将占位符定义为 {path} ,在 URL 中添加仓库路径。
|
migration.importnotification.timeout
| 5s
| 导入通知的 HTTP 超时值。 这是一项实验性功能,不得在生产环境中使用。 |
migration.importnotification.secret
| ''
| 如果未提供,将在启用 shared-secrets 功能时自动创建。这是一项实验性功能,不得在生产环境中使用。
|
securityContext.fsGroup
| 1000
| 应该在其下启动 pod 的 Group ID |
securityContext.runAsUser
| 1000
| Pod 应该在其下启动的 user ID |
serviceLabels
| {}
| 补充服务标签 |
tokenService
| container_registry
| JWT 令牌服务 |
tokenIssuer
| gitlab-issuer
| JWT 令牌发行者 |
tolerations
| []
| Pod 分配的容忍标签 |
middleware.storage
| 中间件存储配置层 |
Chart 配置示例
pullSecrets
pullSecrets
允许您对私有仓库进行身份验证,以拉取 pod 的镜像。
有关私有仓库及其身份验证方法的其它详细信息,请参见 Kubernetes 文档。
下面是一个使用 pullSecrets
的例子:
image:
repository: my.registry.repository
tag: latest
pullPolicy: Always
pullSecrets:
- name: my-secret-name
- name: my-secondary-secret-name
tolerations
tolerations
允许您调度 Pod 到受污染的工作节点上。
下面是一个使用 tolerations
的例子:
tolerations:
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoSchedule"
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoExecute"
annotations
annotations
允许您向 registry pod 添加 annotation。
下面是 annotations
的一个使用示例:
annotations:
kubernetes.io/example-annotation: annotation-value
启用子 chart
我们选择实现划分子 chart 的方式包括禁用给定部署中您可能不需要的组件的能力。 因此,您应该决定的第一个设置是 enabled
。
默认情况下,注册表是开箱即用的。 如果你想禁用它,设置 enabled: false
。
配置 image
这部分控制子 chart 的 Deployment 使用的容器镜像的设置。
您可以更改 Registry 和pullPolicy
的包含版本。
默认设置:
tag: 'v3.51.1-gitlab'
pullPolicy: 'IfNotPresent'
配置 service
此部分控制 Service 的名称和类型。
这些设置将由 values.yaml
填充。
默认情况下,服务配置为:
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
name
| String | registry
| 配置 Service 的名称 |
type
| String | ClusterIP
| 配置 Service 的类型 |
externalPort
| Int | 5000
| Service 暴露的端口 |
internalPort
| Int | 5000
| Pod 用来接受来自 Service 的请求的端口 |
clusterIP
| String | null
| 允许根据需要配置自定义集群 IP |
loadBalancerIP
| String | null
| 允许根据需要配置自定义 LoadBalancer IP 地址 |
配置 ingress
此部分控制 registry Ingress.
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
apiVersion
| String | 在 apiVersion 字段中使用的值。
| |
annotations
| String | 此字段与 Kubernetes Ingress 的标准 annotations 完全匹配。
| |
configureCertmanager
| Boolean | 切换 Ingress 注释 cert-manager.io/issuer 。有关更多信息,请参阅 GitLab Pages 的 TLS 要求。
| |
enabled
| Boolean | false
| 控制是否为支持它们的服务创建 Ingress 对象的设置。 当 false 时,使用 global.ingress.enabled 设置。
|
tls.enabled
| Boolean | true
| 当设置为 false 时,禁用 Registry 子 chart 的 TLS。主要用于无法在 ingress-level 使用 TLS 终止的情况,例如在 Ingress Controller 之前有 TLS 终止代理时。
|
tls.secretName
| String | Kubernetes TLS Secret 的名称,其中包含 registry URL 的有效证书和密钥。如果未设置,则使用 global.ingress.tls.secretName 。 默认为未设置。
|
配置 TLS
Registry 支持 TLS,将保护它与其他组件的通信,包括 nginx-ingress
。TLS 证书应在通用名称 (CN) 或主题备用名称 (SAN) 中包含 Registry Service 主机名(例如 RELEASE-registry.default.svc
)。
生成 TLS 证书后,为其创建一个 Kubernetes TLS Secret。您还需要创建另一个 Secret,它只包含 TLS 证书的 CA 证书和 ca.crt
密钥。
可以通过将 registry.tls.enabled
设置为 true
来启用 TLS。您还需要通过将 global.hosts.registry.protocol
设置为 https
来告诉其他组件 Registry 正在使用 HTTPS。 您还需要将 Secret 名称相应地传递给 registry.tls.secretName
和 global.certificates.customCAs
。
当 registry.tls.verify
为 true
时,需要将CA证书 Secret 名称传递给 registry.tls.caSecretName
。这是自签名证书和自定义 CA 所必需的。NGINX 使用这个 Secret 来验证 Registry 的 TLS 证书。
global:
certificates:
customCAs:
- secret: registry-tls-ca
hosts:
registry:
protocol: https
registry:
tls:
enabled: true
secretName: registry-tls
verify: true
caSecretName: registry-tls-ca
配置 networkpolicy
此部分控制 registry NetworkPolicy。 该设置可选,用于限制 registry 的 egress and Ingress 到特定端点。
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
enabled
| Boolean | false
| 此设置为 registry 启用 NetworkPolicy
|
ingress.enabled
| Boolean | false
| 当设置为 true 时,将激活 Ingress 网络策略。 除非指定规则,否则这将阻止所有 Ingress 连接。
|
ingress.rules
| Array | []
| Ingress 策略规则,详见 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 和下面的例子。 |
egress.enabled
| Boolean | false
| 当设置为 true 时,将激活 Egress 网络策略。 除非指定规则,否则这将阻止所有出口连接。
|
egress.rules
| Array | []
| 出口策略规则,详细信息参见 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource 和下面的例子 |
防止连接到所有内部端点的示例策略
Registry 服务通常需要到对象存储的 egress 连接、来自 Docker 客户端的 ingress 连接,以及用于 DNS 查找的 kube-dns。 这会向 Registry 服务添加以下网络限制:
- 允许在
10.0.0.0/8
端口 53 上对本地网络的所有出口请求(对于 kubeDNS) - 对
10.0.0.0/8
上本地网络的其他出口请求受到限制 - 允许在
10.0.0.0/8
之外的出口请求
请注意,Registry 服务需要到公共互联网的出站连接才能获取 外部对象存储 上的镜像
networkpolicy:
enabled: true
egress:
enabled: true
# The following rules enable traffic to all external
# endpoints, except the local
# network (except DNS requests)
rules:
- to:
- ipBlock:
cidr: 10.0.0.0/8
ports:
- port: 53
protocol: UDP
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.0.0.0/8
定义 Registry 配置
此 chart 的以下属性与底层 registry 容器的配置有关。仅公开与 GitLab 集成的最关键值。 对于这种集成,我们利用 Docker Distribution 的 auth.token.x
设置,通过 JWT 身份验证令牌。
httpSecret
字段 httpSecret
是一个包含 secret
和 key
的映射。
引用的密钥内容与 registry 的 http.secret
值相关。 这个值应该用加密生成的随机字符串填充。
如果未提供,shared-secrets
作业将自动创建此密钥。它将填充一个安全生成的 128 个字符(含字母和数字)字符串,该字符串是 base64 编码的。
要手动创建此密钥:
kubectl create secret generic gitlab-registry-httpsecret --from-literal=secret=strongrandomstring
Notification Secret
Notification Secret 用于以各种方式回调 GitLab 应用程序,例如 Geo 以帮助管理主站点和辅助站点之间的同步容器镜像库数据。 如果启用了 migration 并且配置了端点,它还用于发送导入通知。
如果未提供,则在启用 shared-secrets
功能时,将自动创建 notificationSecret
secret 对象。
要手动创建此密钥:
kubectl create secret generic gitlab-registry-notification --from-literal=secret=[\"strongrandomstring\"]
然后继续设置
global:
# To provide your own secret
registry:
notificationSecret:
secret: gitlab-registry-notification
key: secret
# If utilising Geo, and wishing to sync the container registry
geo:
registry:
replication:
enabled: true
primaryApiUrl: <URL to primary registry>
确保将 secret
值设置为上面创建的 secret 的名称。
authEndpoint
authEndpoint
字段是一个字符串,提供 registry 将验证到的 GitLab 实例的 URL。
该值应仅包含协议和主机名。chart 模板将自动附加必要的请求路径。结果值将填入到容器内的 auth.token.realm
。例如:authEndpoint: "https://gitlab.example.com"
默认情况下,此字段使用 GitLab 主机名配置填充全局设置。
certificate
certificate
字段是一个包含 secret
和 key
的映射。
secret
是一个字符串,包含 Kubernetes Secret 的名称,其中包含用于验证 GitLab 实例创建的令牌的证书包。
key
是 Secret
中包含提供给 registry 容器的证书包,作为 auth.token.rootcertbundle
。
默认示例:
certificate:
secret: gitlab-registry
key: registry-auth.crt
compatibility
compatibility
字段是与配置文件的 compatibility 部分直接相关的映射。
默认内容:
compatibility:
schema1:
enabled: false
readiness and liveness 探针
默认情况下,有一个 readiness and liveness 探针配置为检查调试端口 5001
上的 /debug/health
。
schema1
schema1
部分控制服务与 Docker manifest schema 1 的兼容性。此设置是作为支持早于 1.10 的 Docker 客户端的一种方式提供的,之后默认使用架构 v2。
如果您_必须_支持旧版本的 Docker 客户端,您可以通过设置 registry.compatbility.schema1.enabled: true
来实现。
validation
validation
字段是一个映射,用于控制 registry 中的 Docker 镜像验证过程。启用镜像验证后,registry 会拒绝带有外部层的 Windows 镜像, 除非 validation stanza 中的 manifests.urls.allow
字段明确设置为允许这些层 url。
验证仅在 manifest push 期间发生,因此已存在于镜像库中的镜像不受本部分中值更改的影响。
镜像验证默认关闭。
要启用镜像验证,您需要显式设置 registry.validation.disabled: false
。
manifests
manifests
字段允许配置特定于清单的验证策略。
urls
部分包含 allow
和 deny
字段。对于包含要通过验证的 URL 的 manifest 层,该层必须匹配 allow
字段中的正则表达式之一,而不匹配 deny
字段中的任何正则表达式。
名称 | 类型 | 默认值 | 描述 |
---|---|---|---|
referencelimit
| Int | 0
| 单个 manifest 可能具有的最大引用数,例如层、镜像配置和其他 manifests。当设置为 0 (默认)时,此验证被禁用。
|
payloadsizelimit
| Int | 0
| manifest 有效负载的最大数据大小(以字节为单位)。当设置为 0 (默认)时,此验证被禁用。
|
urls.allow
| Array | []
| 在 manifest 层中启用 URL 的正则表达式列表。如果留空(默认),带有任何 URL 的层都将被拒绝。 |
urls.deny
| Array | []
| 限制 manifest 层中的 URL 的正则表达式列表。当留空(默认)时,没有通过 urls.allow 列表的 URL 层将被拒绝。
|
notifications
notifications
字段用于配置 Registry 通知。
它有一个空 hash 作为默认值。
名称 | 类型 | 默认值 | 说明 |
---|---|---|---|
endpoints
| Array | []
| 列表中的每一项对应一个端点 |
events
| Hash | {}
| 事件 通知中提供的信息 |
设置示例如下:
notifications:
endpoints:
- name: FooListener
url: https://foolistener.com/event
timeout: 500ms
threshold: 10
backoff: 1s
- name: BarListener
url: https://barlistener.com/event
timeout: 100ms
threshold: 3
backoff: 1s
events:
includereferences: true
hpa
hpa
字段是一个对象,控制 registry作为集合的一部分创建的实例数量。minReplicas
的默认值为 2
,maxReplicas
的默认值为 10,并将 cpu.targetAverageUtilization
配置为 75%。
storage
storage:
secret:
key: config
extraKey:
storage
字段引用 Kubernetes Secret 和关联的 key。这个 secret 的内容直接取自 Registry Configuration:storage
。
有关更多详细信息,请参阅该文档。
AWS s3 和 Google GCS 驱动程序可以在 examples/objectstorage
中找到:
对于 S3,请确保您给出正确的 registry 存储权限。有关存储配置的更多信息,请参阅管理文档中的容器镜像库存储驱动程序。
将 storage
块的 contents 放入 secret 中,并将以下事项提供给 storage
映射:
-
secret
:包含 YAML 块的 Kubernetes Secret 的名称。 -
key
:要使用的 secret 中的 key 名称。 默认为config
。 -
extraKey
: (可选) secret 中额外 key 的名称,将挂载到容器内的/etc/docker/registry/storage/${extraKey}
。这可用于为gcs
驱动程序提供keyfile
。
# Example using S3
kubectl create secret generic registry-storage \
--from-file=config=registry-storage.yaml
# Example using GCS with JSON key
# - Note: `registry.storage.extraKey=gcs.json`
kubectl create secret generic registry-storage \
--from-file=config=registry-storage.yaml \
--from-file=gcs.json=example-project-382839-gcs-bucket.json
您可以禁用存储驱动程序的重定向,确保所有流量都流经 Registry 服务,而不是重定向到另一个后端:
storage:
secret: example-secret
key: config
redirect:
disable: true
如果您选择使用 filesystem
驱动程序:
- 您将需要为此数据提供持久卷。
-
hpa.minReplicas
应设置为1
-
hpa.maxReplicas
应设置为1
为了弹性和简易性,建议使用外部服务,例如 s3
、gcs
、azure
或其它兼容的对象存储。
delete.enabled: true
填入到此配置中。这使预期行为与 MinIO 的默认使用以及 Omnibus GitLab 保持一致。 任何用户提供的值都将取代此默认值。middleware.storage
middleware.storage
的配置遵循上游约定:
配置相当通用,并遵循类似的模式:
middleware:
# See https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#middleware
storage:
- name: cloudfront
options:
baseurl: https://abcdefghijklmn.cloudfront.net/
# `privatekey` is auto-populated with the content from the privatekey Secret.
privatekeySecret:
secret: cloudfront-secret-name
# "key" value is going to be used to generate file name for PEM storage:
# /etc/docker/registry/middleware.storage/<index>/<key>
key: private-key-ABC.pem
keypairid: ABCEDFGHIJKLMNOPQRST
在上面的代码中 options.privatekeySecret
是一个 generic
Kubernetes secret 内容,它对应于 PEM 文件内容:
kubectl create secret generic cloudfront-secret-name --type=kubernetes.io/ssh-auth --from-file=private-key-ABC.pem=pk-ABCEDFGHIJKLMNOPQRST.pem
上游使用的 privatekey
由来自 privatekey Secret 的 chart 自动填充,如果指定,将被忽略。
keypairid
变体
不同的供应商对相同的结构使用不同的字段名称:
供应商 | 字段名称 |
---|---|
Google CDN | keyname
|
CloudFront | keypairid
|
middleware.storage
部分的配置。debug
默认情况下启用 debug 端口并用于 liveness/readiness 探测。 此外,Prometheus 指标可以通过 metrics
值启用。
debug:
addr:
port: 5001
metrics:
enabled: true
health
health
属性是可选的,包含对存储驱动程序的后端存储进行定期健康检查的首选项。
更多详细信息,请参阅 Docker 的配置文档。
health:
storagedriver:
enabled: false
interval: 10s
threshold: 3
reporting
reporting
属性是可选的,可以启用 reporting。
reporting:
sentry:
enabled: true
dsn: 'https://<key>@sentry.io/<project>'
environment: 'production'
profiling
profiling
属性是可选的,可以启用连续分析。
profiling:
stackdriver:
enabled: true
credentials:
secret: gitlab-registry-profiling-creds
key: credentials
service: gitlab-registry
database
database
属性是可选的,可以启用元数据数据库。
database:
enabled: true
host: registry.db.example.com
port: 5432
user: registry
password:
secret: gitlab-postgresql-password
key: postgresql-registry-password
dbname: registry
sslmode: verify-full
ssl:
secret: gitlab-registry-postgresql-ssl
clientKey: client-key.pem
clientCertificate: client-cert.pem
serverCA: server-ca.pem
connecttimeout: 5s
draintimeout: 2m
preparedstatements: false
pool:
maxidle: 25
maxopen: 25
maxlifetime: 5m
migrations:
enabled: true
activeDeadlineSeconds: 3600
backoffLimit: 6
创建数据库
如果启用了 Registry 数据库,Registry 将使用自己的数据库来跟踪其状态。
按照以下步骤手动创建数据库和角色。
-
使用数据库密码创建 secret:
kubectl create secret generic RELEASE_NAME-registry-database-password --from-literal=password=randomstring
-
登录到您的数据库实例:
kubectl exec -it $(kubectl get pods -l app=postgresql -o custom-columns=NAME:.metadata.name --no-headers) -- bash
PGPASSWORD=$(cat $POSTGRES_POSTGRES_PASSWORD_FILE) psql -U postgres -d template1
-
创建数据库用户:
CREATE ROLE registry WITH LOGIN;
-
设置数据库用户密码。
-
获取密码:
kubectl get secret RELEASE_NAME-registry-database-password -o jsonpath="{.data.password}" | base64 --decode
-
在
psql
提示符中设置密码:\password registry
-
-
创建数据库:
CREATE DATABASE registry WITH OWNER registry;
-
从 PostgreSQL 命令行安全退出,然后使用
exit
从容器中退出:template1=# exit ...@gitlab-postgresql-0/$ exit
migration
migration
属性是可选的,它提供了与将元数据从文件系统迁移到元数据数据库相关的选项。
migration:
enabled: true
disablemirrorfs: true
rootdirectory: gitlab
importtimeout: 5m
preimporttimeout: 1h
tagconcurrency: 10
maxconcurrentimports: 10
importnotification:
enabled: true
url: 'https://example.com/notification/{path}/status'
timeout: 5s
secret:
secret: gitlab-registry-notification
key: secret
gc
gc
属性是可选的,并提供与在线垃圾收集相关的选项。
gc:
disabled: false
maxbackoff: 24h
noidlebackoff: false
transactiontimeout: 10s
reviewafter: 24h
manifests:
disabled: false
interval: 5s
blobs:
disabled: false
interval: 5s
storagetimeout: 5s
垃圾收集
Docker Registry 会随着时间的推移建立无关的数据,可以使用垃圾收集释放这些数据。
截至现在,没有使用 chart 完全自动化的运行垃圾收集的方式。
手动垃圾收集
手动垃圾收集首先要求 registry 处于只读模式。假设您已经使用 Helm 安装了 GitLab Chart,将其命名为 mygitlab
,并安装在命名空间 gitlabns
中。
根据您的实际配置替换以下命令中的这些值。
# Because of https://github.com/helm/helm/issues/2948 we can't rely on --reuse-values, so let's get our current config.
helm get values mygitlab > mygitlab.yml
# Upgrade Helm installation and configure the registry to be read-only.
# The --wait parameter makes Helm wait until all ressources are in ready state, so we are safe to continue.
helm upgrade mygitlab gitlab-jh/gitlab -f mygitlab.yml --set registry.maintenance.readOnly.enabled=true --wait
# Our registry is in r/o mode now, so let's get the name of one of the registry Pods.
# Note down the Pod name and replace the '<registry-pod>' placeholder below with that value.
# Replace the single quotes to double quotes (' => ") if you are using this with Windows' cmd.exe.
kubectl get pods -n gitlabns -l app=registry -o jsonpath='{.items[0].metadata.name}'
# Run the actual garbage collection. Check the registry's manual if you really want the '-m' parameter.
kubectl exec -n gitlabns <registry-pod> -- /bin/registry garbage-collect -m /etc/docker/registry/config.yml
# Reset registry back to original state.
helm upgrade mygitlab gitlab-jh/gitlab -f mygitlab.yml --wait
# All done :)
针对容器镜像库运行管理命令
管理命令只能从 Registry pod 中针对容器镜像库运行,其中 registry
二进制文件以及必要的
配置可用。
要运行管理命令:
-
连接 Registry pod:
kubectl exec -it <registry-pod> -- bash
-
一旦进入 Registry pod,
registry
二进制文件在PATH
中可用并且可以直接使用。 配置文件位于/etc/docker/registry/config.yml
。 以下示例检查数据库迁移的状态:registry database migrate status /etc/docker/registry/config.yml
有关更多详细信息和其他可用命令,请参阅相关文档: