使用容器镜像库

registry 子 chart 为在 Kubernetes 上的完整云原生 GitLab 部署提供了 Registry 组件。该子 chart 使用了上游中包含 Docker Distributionregistry 容器。该 chart 由 3 个主要部分组成:ServiceDeploymentConfigMap

所有配置都根据官方 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.61.0-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.tls.enabled false 为调试端口启用 TLS。影响 liveness 和 readiness 探测,以及指标端点(如果启用)
debug.tls.secretName   Kubernetes TLS Secret 的名称,其中包含调试端点的有效证书和密钥。如果未设置且 debug.tls.enabled=true - 调试 TLS 配置将默认为库的 TLS 证书。
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 目标类型,必须是 UtilizationAverageValue
hpa.targetAverageValue 75 设置自动扩缩容目标值
hpa.cpu.targetAverageUtilization   设置自动缩放 CPU 目标利用率
hpa.memory.targetType   设置自动缩放内存目标类型,必须是 UtilizationAverageValue
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.61.0-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 只清除上传的列表而不删除
priorityClassName   指派给 pods 的 Priority class
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 模式。可以是 disableallowpreferrequireverify-caverify-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.noidlebackofftrue,否则也适用于没有任务要处理的情况。 请注意,这不是绝对最大值,因为始终会添加高达 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   中间件存储配置层
redis.cache.enabled false 当设置为 true 时,启用 Redis 缓存。此功能取决于启用的元数据数据库。仓库元数据将缓存在配置的 Redis 实例上。
redis.cache.host <Redis URL> Redis 实例的主机名。如果为空,该值将为 global.redis.host:global.redis.port
redis.cache.port 6379 Redis 实例的端口。
redis.cache.sentinels [] 列出带有主机和端口的 sentinels。
redis.cache.mainname   主服务器名称。仅适用于 sentinels。
redis.cache.password.secret gitlab-redis-secret 包含 Redis 密码的 Secret 名称。
redis.cache.password.key redis-password 存储 Redis 密码的 Secret key。
redis.cache.db 0 用于每个连接的数据库的名称。
redis.cache.dialtimeout 0s 连接 Redis 实例的超时时间。默认为无超时。
redis.cache.readtimeout 0s 从 Redis 实例读取的超时时间。默认为无超时。
redis.cache.writetimeout 0s 写入 Redis 实例的超时时间。默认为无超时。
redis.cache.tls.enabled false 设置为 true 以启用 TLS。
redis.cache.tls.insecure false 设置为 true 以在通过 TLS 连接时禁用服务器名称验证。
redis.cache.pool.size 10 最大 socket 连接数。默认为 10 个连接。
redis.cache.pool.maxlifetime 1h 客户端退出连接的连接时长。默认是不关闭时长过大的连接。
redis.cache.pool.idletimeout 300s 在关闭非活动连接之前等待多长时间。

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.61.0-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

Container Registry 支持 TLS 以保护其与其他组件的通信,包括 nginx-ingress

配置 TLS 的先决条件:

  • TLS 证书必须在 Common Name (CN) 或 Subject Alternate Name (SAN) 中包含 Registry Service 主机名(例如,RELEASE-registry.default.svc)。
  • TLS 证书生成后:
    • 创建一个 Kubernetes TLS Secret
    • 创建另一个仅包含带有 ca.crt 密钥的 TLS 证书的 CA 证书的 Secret。

要启用 TLS:

  1. registry.tls.enabled 设置为 true
  2. global.hosts.registry.protocol 设置为 https
  3. 将 Secret 名称传递给 registry.tls.secretNameglobal.certificates.customCAs

registry.tls.verifytrue 时,必须将 CA 证书 Secret 名称传递给 registry.tls.caSecretName。这是自签名证书和自定义证书颁发机构所必需的。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

为调试端口配置 TLS

Registry 调试端口也支持 TLS。 调试端口用于 Kubernetes 的 liveness 和 readiness 检查,以及为 Prometheus(如果启用)公开一个 /metrics 端点。

可以通过将 registry.debug.tls.enabled 设置为 true 来启用 TLS。 可以在 registry.debug.tls.secretName 中提供一个 Kubernetes TLS Secret,专用于调试端口的 TLS 配置。如果未指定专用密钥,则调试配置将回退到与库的常规 TLS 配置共享 registry.tls.secretName

Prometheus 使用 https 抓取 /metrics/ 端点 - 证书的 CommonName 属性或 SubjectAlternativeName 条目需要额外配置。 有关这些要求,请参阅 配置 Prometheus 以抓取启用 TLS 的端点

配置 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 Distributionauth.token.x 设置,通过 JWT 身份验证令牌

httpSecret

字段 httpSecret 是一个包含 secretkey 的映射。

引用的密钥内容与 registryhttp.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 功能时,将自动创建 notificationSecretsecret 对象。

要手动创建此密钥:

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 的名称。

Redis 缓存 Secret

global.redis.password.enabled 设置为 true 时,使用 Redis 缓存 Secret。

启用 shared-secrets 功能时,如果未提供 gitlab-redis-secret secret 对象,则会自动创建。

要手动创建此密钥,请参阅 Redis 密码说明

authEndpoint

authEndpoint 字段是一个字符串,提供 registry 将验证到的 GitLab 实例的 URL。

该值应仅包含协议和主机名。chart 模板将自动附加必要的请求路径。结果值将填入到容器内的 auth.token.realm。例如:authEndpoint: "https://gitlab.example.com"

默认情况下,此字段使用 GitLab 主机名配置填充全局设置

certificate

certificate 字段是一个包含 secretkey 的映射。

secret 是一个字符串,包含 Kubernetes Secret 的名称,其中包含用于验证 GitLab 实例创建的令牌的证书包。

keySecret 中包含提供给 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 部分包含 allowdeny 字段。对于包含要通过验证的 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 的默认值为 2maxReplicas 的默认值为 10,并将 cpu.targetAverageUtilization 配置为 75%。

storage

storage:
  secret:
  key: config
  extraKey:

storage 字段引用 Kubernetes Secret 和关联的 key。这个 secret 的内容直接取自 Registry Configuration:storage。 有关更多详细信息,请参阅该文档。

AWS s3Google 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 驱动程序:

为了弹性和简易性,建议使用外部服务,例如 s3gcsazure 或其它兼容的对象存储。

note如果用户未指定,chart 默认将 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
note目前仅支持 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 属性是可选的,可以启用元数据数据库。

note元数据数据库是一项实验性功能,不得用于生产。
note该功能要求 PostgreSQL 12 或更新版本。
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 将使用自己的数据库来跟踪其状态。

按照以下步骤手动创建数据库和角色。

note以下说明假设您使用的是捆绑的 PostgreSQL 服务器。如果您使用自己的服务器,则连接方式会有所不同。
  1. 使用数据库密码创建 secret:

    kubectl create secret generic RELEASE_NAME-registry-database-password --from-literal=password=randomstring
    
  2. 登录到您的数据库实例:

    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
    
  3. 创建数据库用户:

    CREATE ROLE registry WITH LOGIN;
    
  4. 设置数据库用户密码。

    1. 获取密码:

      kubectl get secret RELEASE_NAME-registry-database-password -o jsonpath="{.data.password}" | base64 --decode
      
    2. psql 提示符中设置密码:

      \password registry
      
  5. 创建数据库:

    CREATE DATABASE registry WITH OWNER registry;
    
  6. 从 PostgreSQL 命令行安全退出,然后使用 exit 从容器中退出:

    template1=# exit
    ...@gitlab-postgresql-0/$ exit
    

migration

migration 属性是可选的,它提供了与将元数据从文件系统迁移到元数据数据库相关的选项。

caution这是一项实验性功能,不得用于生产。
note此功能需要启用元数据数据库
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 属性是可选的,并提供与在线垃圾收集相关的选项。

caution这是一项实验性功能,不得用于生产。
note此功能需要启用元数据数据库
gc:
  disabled: false
  maxbackoff: 24h
  noidlebackoff: false
  transactiontimeout: 10s
  reviewafter: 24h
  manifests:
    disabled: false
    interval: 5s
  blobs:
    disabled: false
    interval: 5s
    storagetimeout: 5s

Redis 缓存

caution这是一项实验性功能,不得在生产中使用。

redis.cache 属性是可选的,并提供与 Redis 缓存相关的选项。 要将 redis.cache 与仓库一起使用,必须启用元数据数据库

例如:

redis:
  cache:
    enabled: true
    host: localhost
    port: 16379
    password:
      secret: gitlab-redis-secret
      key: redis-password
    db: 0
    dialtimeout: 10ms
    readtimeout: 10ms
    writetimeout: 10ms
    tls:
      enabled: true
      insecure: true
    pool:
      size: 10
      maxlifetime: 1h
      idletimeout: 300s

Sentinels

redis.cache 可以使用 global.redis.sentinels 配置。可以提供局部值并将优先于全局值。例如:

redis:
  cache:
    enabled: true
    host: redis.example.com
    sentinels:
      - host: sentinel1.example.com
        port: 16379
      - host: sentinel2.example.com
        port: 16379

垃圾收集

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 二进制文件以及必要的 配置可用。

要运行管理命令:

  1. 连接 Registry pod:

    kubectl exec -it <registry-pod> -- bash
    
  2. 一旦进入 Registry pod,registry 二进制文件在 PATH 中可用并且可以直接使用。 配置文件位于/etc/docker/registry/config.yml。 以下示例检查数据库迁移的状态:

    registry database migrate status /etc/docker/registry/config.yml
    

有关更多详细信息和其他可用命令,请参阅相关文档: