- 设计选择
- 配置
- 安装命令行选项
- Chart 配置示例
- 启用子 chart
- 配置
image
- 配置
service
- 配置
ingress
-
配置
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.19.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
storage:
secret:
key: storage
extraKey:
compatibility:
schema1:
enabled: false
validation:
disabled: true
manifests:
referencelimit: 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: []
如果您选择将此 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
| Debug 端口和 Prometheus 指标 | |
deployment.terminationGracePeriodSeconds
| 30
| Pod 需要优雅终止的可选持续时间(以秒为单位)。 |
deployment.strategy
| {}
| 允许配置部署使用的更新策略 |
draintimeout
| '0'
| 收到 SIGTERM 信号后等待 HTTP 连接耗尽的时间(例如 10s )
|
relativeurls
| false
| 启用 registry 在位置 header 中返回相对 URL。 |
enabled
| true
| 启用 registry 标志 |
hpa.cpu.targetAverageUtilization
| 75
| 管理 HPA 的所有相关 pod 的资源指标平均值的目标值 |
hpa.customMetrics
| []
| autoscaling/v2beta1 Metrics 包含用于计算期望副本数的规范(覆盖在 targetAverageUtilization 中配置的平均 CPU 利用率的默认值)
|
hpa.minReplicas
| 2
| 最小副本数 |
hpa.maxReplicas
| 10
| 最大副本数 |
httpSecret
| Https secret | |
image.pullPolicy
| 仓库中镜像的拉取策略 | |
image.pullSecrets
| 用于镜像仓库的 secret | |
image.repository
| registry
| Registry 镜像 |
image.tag
| v3.19.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
| 只清除上传的列表而不删除 |
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
| 允许已迁移到数据库的仓库使用单独的存储路径。使用与主存储驱动程序配置不同的根目录允许在线迁移。这是一项实验性功能,不得在生产环境中使用。 | |
securityContext.fsGroup
| 1000
| 应该在其下启动 pod 的 Group ID |
securityContext.runAsUser
| 1000
| Pod 应该在其下启动的 user ID |
serviceLabels
| {}
| 补充服务标签 |
tokenService
| container_registry
| JWT 令牌服务 |
tokenIssuer
| gitlab-issuer
| JWT 令牌发行者 |
tolerations
| []
| Pod 分配的容忍标签 |
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.19.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 。 默认为未设置。
|
配置 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 以帮助管理主站点和辅助站点之间的同步容器镜像库数据。
如果未提供,则在启用 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 (默认)时,此验证被禁用。
|
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
如果您选择使用 filesystem
驱动程序:
- 您将需要为此数据提供持久卷。
-
hpa.minReplicas
应设置为1
-
hpa.maxReplicas
应设置为1
为了弹性和简易性,建议使用外部服务,例如 s3
、gcs
、azure
或其它兼容的对象存储。
delete.enabled: true
填入到此配置中。这使预期行为与 MinIO 的默认使用以及 Omnibus GitLab 保持一致。 任何用户提供的值都将取代此默认值。debug
默认情况下启用 debug 端口并用于 liveness/readiness 探测。 此外,可以启用 Prometheus 指标。
debug:
addr:
port: 5001
prometheus:
enabled: true
path: '/metrics'
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:
disablemirrorfs: true
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/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/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
有关更多详细信息和其他可用命令,请参阅相关文档: