升级 Red Hat Quay
第 1 章 升级概述
Red Hat Quay 的升级过程取决于您使用的安装类型。
Red Hat Quay Operator 提供了部署和管理 Red Hat Quay 集群的简单方法。这是在 OpenShift 上部署 Red Hat Quay 的首选步骤。
Red Hat Quay Operator 应该使用 Operator Lifecycle Manager (OLM) 升级,如"使用 Quay Operator 更新 Quay"一节中所述。
升级 Red Hat Quay 和 Clair 的概念验证或高可用性安装的步骤包括在"独立升级"部分中。
第 2 章 升级 Red Hat Quay Operator 概述
Red Hat Quay Operator 遵循一个 同步的版本 方案,这意味着每个 Operator 版本都绑定到 Red Hat Quay 的版本及其管理的组件。QuayRegistry 自定义资源中没有字段,它设置要部署的 Red Hat Quay 版本 ; Operator 只能部署所有组件的单一版本。选择这个方案来确保所有组件都可以正常工作,并降低 Operator 的复杂性,了解如何管理 Kubernetes 上不同版本的 Red Hat Quay 的生命周期。
2.1. Operator Lifecycle Manager
Red Hat Quay Operator 应使用 Operator Lifecycle Manager (OLM) 来安装和升级。当使用默认 approvalStrategy: Automatic 创建订阅时,每当有新版本可用时,OLM 将自动升级 Red Hat Quay Operator。
当 Operator Lifecycle Manager 安装 Red Hat Quay Operator 时,可能会将其配置为支持自动或手动升级。这个选项在安装过程中显示在 Red Hat Quay Operator 的 Operator Hub 页面中。它还可以通过 approvalStrategy 字段在 Red Hat Quay Operator Subscription 对象中找到。选择 Automatic 意味着,当发布新的 Operator 版本时,您的 Red Hat Quay Operator 将自动升级。如果这不必要,则应选择 Manual 批准策略。
2.2. 升级 Quay Operator
在 OpenShift Container Platform 上升级已安装的 Operator 的标准方法包括在 升级安装的 Operator 中。
通常,Red Hat Quay 仅支持从之前的(N-1)次版本进行升级。例如,不支持直接从 Red Hat Quay 3.0.5 升级到 3.5 的最新版本。用户必须按如下方式升级:
- 3.0.5 → 3.1.3
- 3.1.3 → 3.2.2
- 3.2.2 → 3.3.4
- 3.3.4 → 3.4.z
- 3.4.z → 3.5.z
这需要确保正确完成任何必要的数据库迁移,并在升级过程中按正确顺序完成。
在某些情况下,Red Hat Quay 支持从之前(N-2、N-3)次版本直接进行单步骤升级。这简化了旧版本客户的升级过程。支持以下升级路径:
- 3.3.z → 3.6.z
- 3.4.z → 3.6.z
- 3.4.z → 3.7.z
- 3.5.z → 3.7.z
- 3.7.z → 3.8.z
- 3.6.z → 3.9.z
- 3.7.z → 3.9.z
- 3.8.z → 3.9.z
有关 Red Hat Quay 的 独立部署的用户,请参阅 独立升级指南。
2.2.1. 升级 Quay
要将 Red Hat Quay 从一个次版本升级到下一个次版本,如 3.4 → 3.5,您必须更改 Red Hat Quay Operator 的更新频道。
对于 z 流升级,如 3.4.2 → 3.4.3,更新会在安装过程中在最初选择的主频道中发布。执行 z 流升级的步骤取决于以上所述的 approvalStrategy。如果批准策略被设置为 Automatic,则 Quay Operator 将自动升级到最新的 z 流。这会导致自动的、滚动式的到较新的 z 流的 Quay 更新,几乎没有或只有非常短的停机时间。否则,在开始安装前,必须手动批准更新。
2.2.2. 从 3.8 → 3.9 更新 Red Hat Quay
如果您的 Red Hat Quay 部署从一个 y-stream 升级到下一个(例如从 3.8.10 → 3.8.11),则不得将升级频道从 stable-3.8 切换到 stable-3.9。在 y-stream 升级过程中更改升级频道将不允许 Red Hat Quay 升级到 3.9。这是一个已知问题,并将在以后的 Red Hat Quay 版本中解决。
更新 Red Hat Quay 3.8 → 3.9 时,Operator 会自动为 Clair 和 Red Hat Quay 从版本 10 升级到 13 的现有 PostgreSQL 数据库。
- 这个升级不可逆。强烈建议您升级到 PostgreSQL 13。PostgreSQL 10 在 2022 年 11 月 10 日有其最终发行版本,不再被支持。如需更多信息,请参阅 PostgreSQL 版本策略。
-
默认情况下,Red Hat Quay 配置为从 PostgreSQL 10 中删除旧的持久性卷声明(PVC)。要禁用此设置和备份旧的 PVC,您必须在
quay-operatorSubscription对象中将POSTGRES_UPGRADE_RETAIN_BACKUP设置为True。
先决条件
- 您已在 OpenShift Container Platform 上安装了 Red Hat Quay 3.8。
100 GB 可用,额外存储.
在升级过程中,会置备额外的持久性卷声明(PVC)来存储迁移的数据。这有助于防止对用户数据进行破坏性操作。升级过程为 Red Hat Quay 数据库升级和 Clair 数据库升级推出 50 GB 的 PVC。
步骤
可选。通过将
POSTGRES_UPGRADE_RETAIN_BACKUP设置为Trueyourquay-operatorSubscription对象,从 PostgreSQL 10 备份旧的 PVC。例如:apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: quay-operator namespace: quay-enterprise spec: channel: stable-3.8 name: quay-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: POSTGRES_UPGRADE_RETAIN_BACKUP value: "true"- 在 OpenShift Container Platform Web 控制台中,进入到 Operators → Installed Operators。
- 点 Red Hat Quay Operator。
- 进入 Subscription 选项卡。
- 在 Subscription details 下点 Update channel。
- 选择 stable-3.9 并保存更改。
- 在 Upgrade status 下检查新安装的进度。等待升级状态更改为 1, 然后继续。
- 在 OpenShift Container Platform 集群中,进入到 Workloads → Pods。现有 pod 应该被终止,或者在终止过程中终止。
-
等待以下 pod (负责升级现有数据的数据库和 alembic 迁移)以加速:
clair-postgres-upgrade、quay-postgres-upgrade和quay-app-upgrade。 -
在
clair-postgres-upgrade、quay-postgres-upgrade和quay-app-upgradepod 标记为 Completed 后,您的 Red Hat Quay 部署的剩余 pod 会启动。这大约需要十分钟。 -
验证
quay-database和clair-postgres容器集现在是否使用postgresql-13镜像。 -
在
quay-apppod 标记为 Running 后,您可以访问 Red Hat Quay registry。
2.2.3. 直接从 3.3.z 或 3.4.z 升级到 3.6
下面的部分提供了在从 Red Hat Quay 3.3.z 或 3.4.z 升级到 3.6 时的重要信息。
2.2.3.1. 启用边缘路由升级
- 在以前的版本中,当运行启用了边缘路由的 Red Hat Quay 的 3.3.z 版本时,用户无法升级到 3.4.z 版本的 Red Hat Quay。这个问题已在 Red Hat Quay 3.6 发行版本中解决。
当从 3.3.z 升级到 3.6 时,如果在 Red Hat Quay 3.3.z 部署中将
tls.termination设置为none,它将改为使用 TLS 边缘终止的 HTTPS,并使用默认集群通配符证书。例如:apiVersion: redhatcop.redhat.io/v1alpha1 kind: QuayEcosystem metadata: name: quay33 spec: quay: imagePullSecretName: redhat-pull-secret enableRepoMirroring: true image: quay.io/quay/quay:v3.3.4-2 ... externalAccess: hostname: quayv33.apps.devcluster.openshift.com tls: termination: none database: ...
2.2.3.2. 使用自定义 SSL/TLS 证书/密钥对升级,而无需 Subject Alternative Names
从 Red Hat Quay 3.3.4 直接升级到 Red Hat Quay 3.6 时,客户使用自己的 SSL/TLS 证书/密钥对没有 Subject Alternative Names (SAN)。在升级到 Red Hat Quay 3.6 时,部署会被阻止,并显示 Red Hat Quay Operator pod 日志中的错误消息,表示 Red Hat Quay SSL/TLS 证书必须具有 SANs。
如果可能,您应该使用 SAN 中的正确主机名重新生成 SSL/TLS 证书。可能的临时解决方案包括在升级后在 quay-app、quay-upgrade 和 quay-config-editor pod 中定义环境变量,以启用 CommonName 匹配:
GODEBUG=x509ignoreCN=0
GODEBUG=x509ignoreCN=0 标志允许在没有 SANs 时将 X.509 证书上的 CommonName 字段视为主机名。但不建议使用这个临时解决方案,因为它不会在重新部署中保留。
2.2.3.3. 使用 Red Hat Quay Operator 从 3.3.z 或 3.4.z 升级到 3.6 时配置 Clair v4
要在 OpenShift Container Platform 上的新 Red Hat Quay 部署上设置 Clair v4,强烈建议您使用 Red Hat Quay Operator。默认情况下,Red Hat Quay Operator 将安装和升级 Clair 部署,以及您的 Red Hat Quay 部署并自动配置 Clair。
有关在断开连接的 OpenShift Container Platform 集群中设置 Clair v4 的说明,请参阅在 Red Hat Quay OpenShift 部署中设置 Clair。
2.2.4. 从 3.3.z 升级到 3.6 时的 Swift 配置
当从 Red Hat Quay 3.3.z 升级到 3.6.z 时,一些用户可能会收到以下错误: Switch auth v3 requires tenant_id (字符串)在 os_options 中。作为临时解决方案,您可以手动更新 DISTRIBUTED_STORAGE_CONFIG 以添加 os_options 和 tenant_id 参数:
DISTRIBUTED_STORAGE_CONFIG:
brscale:
- SwiftStorage
- auth_url: http://****/v3
auth_version: "3"
os_options:
tenant_id: ****
project_name: ocp-base
user_domain_name: Default
storage_path: /datastorage/registry
swift_container: ocp-svc-quay-ha
swift_password: *****
swift_user: *****2.2.5. 更改 Red Hat Quay Operator 的更新频道
已安装的 Operator 的订阅指定一个更新频道,用于跟踪和接收 Operator 的更新。要升级 Red Hat Quay Operator 以开始跟踪并从更新频道接收更新,请更改安装的 Red Hat Quay Operator 的 Subscription 选项卡中的更新频道。对于带有 自动批准策略 的订阅,升级会自动开始,并可以在列出 Installed Operator 的页面中监控。
2.2.6. 手动批准待处理的 Operator 升级
如果已安装的 Operator 的订阅设置为 Manual,则当其当前更新频道中发布新更新时,在开始安装前必须手动批准更新。如果 Red Hat Quay Operator 有一个待处理的升级,这个状态将显示在 Installed Operators 列表中。在 Red Hat Quay Operator 的 Subscription 选项卡中,您可以预览安装计划并查看列出可用于升级的资源。如果满意,点 Approve 并返回到列出 Installed Operators 的页面来监控升级的进度。
下图显示了 UI 中的 Subscription 选项卡,包括 更新频道、批准策略、升级状态 和 InstallPlan :
Installed Operators 列表提供当前 Quay 安装的高级概述:
2.3. 升级 QuayRegistry
当 Red Hat Quay Operator 启动时,它会立即查找它被配置为监视的命名空间中找到的任何 QuayRegistries。找到时,会使用以下逻辑:
-
如果未设置
status.currentVersion,请正常协调。 -
如果
status.currentVersion等于 Operator 版本,请正常协调。 -
如果
status.currentVersion不等于 Operator 版本,请检查是否可以升级它。如果它可以执行升级任务,并在完成后将status.currentVersion设置为 Operator 的版本。如果无法升级,请返回错误,并只保留QuayRegistry及其部署的 Kubernetes 对象。
2.4. 升级 QuayEcosystem
从以前的 Operator 版本支持升级,该 Operator 将 QuayEcosystem API 用于有限的配置集合。为确保迁移不会意外发生,需要将特殊标签应用到 QuayEcosystem,以便迁移它。将创建一个新的 QuayRegistry 以供 Operator 管理,但旧的 QuayEcosystem 将保留下来,直到手动删除为止,以确保在出现错误时回滚并仍然可以访问 Quay。要将现有的 QuayEcosystem 迁移到新的 QuayRegistry,请使用以下步骤。
步骤
将
"quay-operator/migrate": "true"添加到QuayEcosystem的metadata.labels中。$ oc edit quayecosystem <quayecosystemname>
metadata: labels: quay-operator/migrate: "true"-
等待与
QuayEcosystem相同的metadata.name创建QuayRegistry。QuayEcosystem将标记为标签"quay-operator/migration-complete": "true"。 -
设置了新的
QuayRegistry的status.registryEndpoint后,访问 Red Hat Quay 并确认所有数据和设置都已成功迁移。 -
如果一切都正常工作,您可以删除
QuayEcosystem和 Kubernetes 垃圾回收会清理所有旧资源。
2.4.1. 恢复 QuayEcosystem 升级
如果在从 QuayEcosystem 升级到 QuayRegistry 时出现错误,请按照以下步骤恢复回使用 QuayEcosystem :
步骤
使用 UI 或
kubectl删除QuayRegistry:$ kubectl delete -n <namespace> quayregistry <quayecosystem-name>
-
如果使用
Route提供外部访问,将Route更改为指回原始的Service(使用 UI 或kubectl)。
如果您的 QuayEcosystem 管理 PostgreSQL 数据库,升级过程会将您的数据迁移到升级的 Operator 管理的新 PostgreSQL 数据库。旧数据库不会被更改或删除,但 Red Hat Quay 在迁移完成后将不再使用它。如果在数据迁移过程中出现问题,升级过程会退出,建议您继续将数据库作为非受管组件使用。
2.4.2. 支持的升级 QuayEcosystem 配置
如果迁移 QuayEcosystem 组件失败或不受支持,Red Hat Quay Operator 会在其日志中报告错误,并处于 status.conditions 中。所有非受管组件都应成功迁移,因为不需要采用 Kubernetes 资源,并且 Red Hat Quay 的 config.yaml 文件中已提供了所有必需的值。
数据库
不支持临时数据库(必须设置volumeSize 字段)。
Redis
不需要特殊要求。
外部访问
自动迁移只支持 passthrough Route 访问。其他方法需要手动迁移。
-
没有自定义主机名的
LoadBalancer:当QuayEcosystem使用标签"quay-operator/migration-complete": "true"标记后,在删除QuayEcosystem前需要从现存的Service中删除metadata.ownerReferences字段,这可以防止 Kubernetes 对Service进行垃圾回收并并删除负载均衡器。一个新的Service将被创建,带有metadata.name格式<QuayEcosystem-name>-quay-app。编辑现有Service的spec.selector,使其与新Service的spec.selector匹配,以便进入旧负载均衡器端点的流量现在会被定向到新的 pod。旧的Service将会被您管理; Quay Operator 将不再管理它。 -
带有自定义主机名的
LoadBalancer/NodePort/Ingress:将创建一个类型为LoadBalancer的新的Service,带有metadata.name格式<QuayEcosystem-name>-quay-app。将您的 DNS 设置更改为指向由新Service提供的status.loadBalancer端点。
Clair
不需要特殊要求。
对象存储
QuayEcosystem 没有受管对象存储组件,因此对象存储始终被标记为非受管组件。不支持本地存储。
存储库镜像
不需要特殊要求。
第 3 章 独立升级
通常,Red Hat Quay 仅支持从之前的(N-1)次版本进行升级。例如,不支持直接从 Red Hat Quay 3.0.5 升级到 3.5 的最新版本。用户必须按如下方式升级:
- 3.0.5 → 3.1.3
- 3.1.3 → 3.2.2
- 3.2.2 → 3.3.4
- 3.3.4 → 3.4.z
- 3.4.z → 3.5.z
这需要确保正确完成任何必要的数据库迁移,并在升级过程中按正确顺序完成。
在某些情况下,Red Hat Quay 支持从之前(N-2、N-3)次版本直接进行单步骤升级。这个例外是正常的、只使用次版本的次版本,升级简化了在旧版本上客户进行升级。支持以下升级路径:
- 3.3.z → 3.6.z
- 3.4.z → 3.6.z
- 3.4.z → 3.7.z
- 3.5.z → 3.7.z
- 3.7.z → 3.9.z
有关希望升级 Red Hat Quay Operator 的用户,请参阅升级 Red Hat Quay Operator 概述。
本文档描述了执行每个升级所需的步骤。确定您当前的版本,然后按照顺序的步骤,从您当前的版本开始,并处理所需的目标版本。
有关单个版本的功能的信息,请参阅 Red Hat Quay 发行注记。
手动升级的一般步骤包括以下步骤:
- 停止 Quay 和 Clair 容器。
- 备份数据库和镜像存储(可选,但推荐)。
- 使用镜像的新版本启动 Clair。
- 等待 Clair 准备好接受连接,然后再启动新版本的 Quay。
3.1. 访问镜像
Quay 3.4.0 及更新版本的镜像位于 registry.redhat.io 和 registry.access.redhat.com 中,身份验证设置如 Red Hat Container Registry Authentication 所述。
Quay 3.3.4 及更早版本的镜像位于 quay.io 中,身份验证设置如 在没有 CoreOS 登录的情况下访问 Red Hat Quay 所述。
3.2. 从 3.8.z 升级到 3.9.z
如果您要从 3.8.z → 3.9 升级独立 Red Hat Quay 部署,则强烈建议您从版本 10 → 13 升级 PostgreSQL。要从 10 → 13 升级 PostgreSQL,您必须关闭 PostgreSQL 10 数据库并运行迁移脚本来启动此过程。
使用以下步骤在独立 Red Hat Quay 部署中将 PostgreSQL 从 10 → 13 升级。
步骤
输入以下命令缩减 Red Hat Quay 容器:
$ sudo podman stop <quay_container_name>
可选。如果使用 Clair,输入以下命令来停止 Clair 容器:
$ sudo podman stop <clair_container_id>
从 SCLOrg 的数据迁移流程运行 Podman 进程,允许从远程 PostgreSQL 服务器迁移数据: https://github.com/sclorg/postgresql-container/tree/master/13#data-migration
$ sudo podman run -d --name <migration_postgresql_database> 1 -e POSTGRESQL_MIGRATION_REMOTE_HOST=172.17.0.2 \ 2 -e POSTGRESQL_MIGRATION_ADMIN_PASSWORD=remoteAdminP@ssword \ -v </host/data/directory:/var/lib/pgsql/data:Z> 3 [ OPTIONAL_CONFIGURATION_VARIABLES ] rhel8/postgresql-13
$ mkdir -p /host/data/directory
$ setfacl -m u:26:-wx /host/data/directory
这可防止数据被新容器覆盖。
- 可选。如果使用 Clair,请为 Clair PostgreSQL 数据库容器重复上一步。
停止 PostgreSQL 10 容器:
$ sudo podman stop <postgresql_container_name>
完成 PostgreSQL 迁移后,使用步骤 3 中的新数据卷挂载运行 PostgreSQL 13 容器,例如: </
host/data/directory:/var/lib/postgresql/data> :$ sudo podman run -d --rm --name postgresql-quay \ -e POSTGRESQL_USER=<username> \ -e POSTGRESQL_PASSWORD=<password> \ -e POSTGRESQL_DATABASE=<quay_database_name> \ -e POSTGRESQL_ADMIN_PASSWORD=<admin_password> \ -p 5432:5432 \ -v </host/data/directory:/var/lib/pgsql/data:Z> \ registry.redhat.io/rhel8/postgresql-13:1-109- 可选。如果使用 Clair,请为 Clair PostgreSQL 数据库容器重复上一步。
启动 Red Hat Quay 容器:
$ sudo podman run -d --rm -p 80:8080 -p 443:8443 --name=quay \ -v /home/<quay_user>/quay-poc/config:/conf/stack:Z \ -v /home/<quay_user>/quay-poc/storage:/datastorage:Z \ {productrepo}/{quayimage}:{productminv}可选。重启 Clair 容器,例如:
$ sudo podman run -d --name clairv4 \ -p 8081:8081 -p 8088:8088 \ -e CLAIR_CONF=/clair/config.yaml \ -e CLAIR_MODE=combo \ registry.redhat.io/quay/clair-rhel8:v3.9.0
如需更多信息,请参阅 数据迁移。
3.2.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.9.0
- Clair: registry.redhat.io/quay/clair-rhel8:4.9.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.3. 从 3.7.z 升级到 3.9.z
如果您要从 3.8.z → 3.9 升级独立 Red Hat Quay 部署,则强烈建议您从版本 10 → 13 升级 PostgreSQL。要从 10 → 13 升级 PostgreSQL,您必须关闭 PostgreSQL 10 数据库并运行迁移脚本来启动此过程:
-
当从 Red Hat Quay 3.7 升级到 3.9 时,您可能会收到以下错误:
pg_dumpall: error: query failed: ERROR: xlog flush request 1/B446CCD8 不满足 --- flushed to 1/B0013858。这个问题的一个临时解决方案是,您可以在 OpenShift Container Platform 部署中删除quayregistry-clair-postgres-upgrade作业,这应该解决这个问题。
3.3.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.9.0
- Clair: registry.redhat.io/quay/clair-rhel8:4.9.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.4. 从 3.7.z 升级到 3.8.z
3.4.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.8.0
- Clair: registry.redhat.io/quay/clair-rhel8:4.9.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.5. 从 3.6.z 升级到 3.7.z
3.5.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.7.0
- Clair: registry.redhat.io/quay/clair-rhel8:4.9.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.6. 从 3.5.z 升级到 3.7.z
3.6.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.7.0
- Clair: registry.redhat.io/quay/clair-rhel8:4.9.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.7. 从 3.4.z 升级到 3.7.z
3.7.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.7.0
- Clair: registry.redhat.io/quay/clair-rhel8:4.9.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.8. 从 3.3.z 升级到 3.7.z
不支持从 3.3 升级到 Red Hat Quay 3.7。用户必须首先从 3.3 升级到 3.6,然后升级到 3.7。如需更多信息,请参阅从 3.3.z 升级到 3.6.z。
3.9. 从 3.5.z 升级到 3.6.z
3.9.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.6.0
- Clair: registry.redhat.io/quay/clair-rhel8:4.9.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.10. 从 3.4.z 升级到 3.6.z
Red Hat Quay 3.6 支持从 3.4.z 直接升级。这个例外是正常的、只使用次版本的次版本,升级简化了在旧版本上客户进行升级。
从 3.4.z 升级到 Red Hat Quay 3.6 需要数据库迁移,它不支持降级到以前的 Red Hat Quay 版本。在执行此迁移前,请备份您的数据库。
用户还需要配置完全新的 Clair v4 实例,以便在从 3.4.z 升级时替换旧的 Clair v2。有关配置 Clair v4 的说明,请参阅 在非 OpenShift Red Hat Quay 部署上设置 Clair。
3.10.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.6.0
- Clair: registry.redhat.io/quay/clair-rhel8:v3.6.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.11. 从 3.3.z 升级到 3.6.z
Red Hat Quay 3.6 支持从 3.3.z 直接升级。这个例外是正常的、只使用次版本的次版本,升级简化了在旧版本上客户进行升级。
从 3.3.z 升级到 Red Hat Quay 3.6.z 需要数据库迁移,它不支持降级到以前的 Red Hat Quay 版本。在执行此迁移前,请备份您的数据库。
用户还需要配置完全新的 Clair v4 实例,以便在从 3.3.z 升级时替换旧的 Clair v2。有关配置 Clair v4 的说明,请参阅 在非 OpenShift Red Hat Quay 部署上设置 Clair。
3.11.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.6.0
- Clair: registry.redhat.io/quay/clair-rhel8:v3.6.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.11.2. 从 3.3.z 升级到 3.6 时的 Swift 配置
当从 Red Hat Quay 3.3.z 升级到 3.6.z 时,一些用户可能会收到以下错误: Switch auth v3 requires tenant_id (字符串)在 os_options 中。作为临时解决方案,您可以手动更新 DISTRIBUTED_STORAGE_CONFIG 以添加 os_options 和 tenant_id 参数:
DISTRIBUTED_STORAGE_CONFIG:
brscale:
- SwiftStorage
- auth_url: http://****/v3
auth_version: "3"
os_options:
tenant_id: ****
project_name: ocp-base
user_domain_name: Default
storage_path: /datastorage/registry
swift_container: ocp-svc-quay-ha
swift_password: *****
swift_user: *****3.12. 从 3.4.z 升级到 3.5.7
3.12.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.5.7
- Clair: registry.redhat.io/quay/clair-rhel8:v3.9.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.13. 从 3.3.z 升级到 3.4.6
升级到 Quay 3.4 需要数据库迁移,它不支持降级到以前的 Quay 版本。在执行此迁移前,请备份您的数据库。
3.13.1. 目标镜像
- quay : registry.redhat.io/quay/quay-rhel8:v3.4.6
- Clair: registry.redhat.io/quay/clair-rhel8:v3.9.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- redis : registry.redhat.io/rhel8/redis-6:1-110)
3.14. 从 3.2.z 升级到 3.3.4
3.14.1. 目标镜像
- quay : quay.io/redhat/quay:v3.3.4
- Clair: registry.redhat.io/quay/clair-rhel8:v3.9.0
- postgresql: RHSCL/postgresql-96-rhel7
- redis : registry.access.redhat.com/RHSCL/redis-32-rhel7
3.15. 从 3.1.z 升级到 3.2.2
集群运行任何 Red Hat Quay 3.1.z 版本后,要将集群升级到 3.2.2,您必须关闭整个集群,并在使用 3.2.2 版本备份前对配置进行小更改。
在此流程中设置 DATABASE_SECRET_KEY 值后,请勿更改它。如果您这样做,则无法使用现有的机器帐户、API 令牌等。您必须创建新的机器帐户和 API 令牌,以用于 Quay。
- 使 Red Hat Quay 集群中的所有主机都超出服务。
生成一些随机数据,以用作数据库机密密钥。例如:
$ openssl rand -hex 48 2d023adb9c477305348490aa0fd9c
在您的
config.yaml文件中添加新的 DATABASE_SECRET_KEY 字段。例如:DATABASE_SECRET_KEY: "2d023adb9c477305348490aa0fd9c"
注意对于 OpenShift 安装,
config.yaml文件存储为一个 secret。-
启动一个
Quay容器以完成到 3.2.2 的迁移。 -
完成迁移后,确保所有节点上都提供了相同的
config.yaml,并在这些节点上启动新的 quay 3.2.2 服务。 - 启动 quay-builder 和 Clair 的 3.0.z 版本,以替换您要返回到集群的容器的任何实例。
3.15.1. 目标镜像
- quay : quay.io/redhat/quay:v3.2.2
- Clair: registry.redhat.io/quay/clair-rhel8:v3.9.0
- postgresql: RHSCL/postgresql-96-rhel7
- redis : registry.access.redhat.com/RHSCL/redis-32-rhel7
3.16. 从 3.0.z 升级到 3.1.3
3.16.1. 目标镜像
- quay: quay.io/redhat/quay:v3.1.3
- Clair: registry.redhat.io/quay/clair-rhel8:v3.9.0
- postgresql: RHSCL/postgresql-96-rhel7
- redis : registry.access.redhat.com/RHSCL/redis-32-rhel7
3.17. 从 2.9.5 升级到 3.0.5
对于 2.9.5 到 3.0.5 升级,您可以使用 Red Hat Quay 关闭(同步升级)进行整个升级(同步升级),或者仅关闭 Red Hat Quay 几分钟,并使升级批量继续运行(background 升级)。
根据需要处理的数量,后台升级可能需要更长时间才能运行升级。但是,停机时间会减少。后台升级的情况是,在升级完成前,您将无法访问最新的功能。集群在 v2 兼容性模式中从 Quay v3 容器运行,直到升级完成为止。
3.17.1. 升级概述
如果您从 Red Hat Quay 2.y.z 集群开始,请按照以下步骤操作。在升级到最新的 Red Hat Quay 3.x 版本前,您必须首先将该集群迁移到 3.0.5,如下所述。集群正在运行 3.0.5 后,您可以通过按顺序升级到每个次版本来升级到最新的 3.x 版本。例如:
- 3.0.5 → 3.1.3
- 3.1.3 → 3.2.2
- 3.2.2 → 3.3.4
- 3.3.4 → 3.4.z
在开始 Red Hat Quay 2.y.z 到 3.0 升级前,请注意以下几点:
- 同步升级 :对于同步升级,小安装需要一小时少于一小时。考虑一个小安装,使其包含几千个容器镜像标签或更少。对于该大小安装,您可能会有几小时的调度停机时间。整个 Red Hat Quay 服务在持续时间内停机,因此如果您尝试在具有数百万标签的 registry 上尝试同步升级,则可能会在几天内停机。
- 后台升级 :对于后台升级(也称为兼容性模式升级),在短暂关闭 Red Hat Quay 集群升级后在后台运行。对于大型 Red Hat Quay registry,这可能需要几周才能完成,但集群在升级期间仍然以 v2 模式运行。作为一个参考点,一个 Red Hat Quay v3 升级需要 4 天时间来处理跨六个机器的约 3,000 万个标签。
- 完成的完整功能:在访问与 Docker 版本 2 相关的功能 之前,模式 2 更改(如对不同架构容器的支持)必须完成。当您切换时,其它 v3 功能可以立即使用。
-
升级完整 :升级完成后,您需要在 Red Hat Quay
config.yaml文件中设置 V3_UPGRADE_MODE: 完成,以便新功能可用。所有新的 Red Hat Quay v3 安装都会自动设置。
3.17.2. 先决条件
为确保最佳结果,我们推荐以下先决条件:
- 在开始升级前备份 Red Hat Quay 数据库(执行常规备份是常规最佳实践)。在进入 Red Hat Quay 集群以进行升级后,最好这样做。
- 备份存储(也是常规最佳实践)。
在开始 v3 升级前,将当前的 Red Hat Quay 2.y.z 设置升级到最新的 2.9.z 版本(当前为 2.9.5))。要做到这一点:
-
虽然 Red Hat Quay 集群仍在运行,但需要一个节点,并将该系统上的
Quay容器改为运行最新 2.9.z 版本的Quay容器。 - 等待所有数据库迁移运行,将数据库启动到最新的 2.9.z 版本。这应该需要几分钟才能一小时。
-
完成后,将所有现有节点上的
Quay容器替换为同一最新的 2.9.z 版本。使用新版本上的整个 Red Hat Quay 集群,您可以继续 v3 升级。
-
虽然 Red Hat Quay 集群仍在运行,但需要一个节点,并将该系统上的
3.17.3. 选择升级类型
在同步升级间(在停机内完成升级)和后台升级(在 Red Hat Quay 仍在运行时完成升级)。这两个主版本升级都需要 Red Hat Quay 集群至少停机。
无论您选择什么升级类型,在 Red Hat Quay 集群停机期间,如果使用 builder 和 Clair 镜像,您还需要升级到这些新镜像:
- Builder: quay.io/redhat/quay-builder:v3.0.5
- Clair: quay.io/redhat/clair-jwt:v3.0.5
这两个镜像都可从 registry.redhat.io/quay 存储库中获得。
3.17.4. 运行同步升级
要运行同步升级,在整个升级的情况下关闭整个集群,请执行以下操作:
- 关闭整个 Red Hat Quay 集群,包括任何 quay-builder 和 Clair 容器。
在所有节点上的
config.yaml文件中添加以下设置:V3_UPGRADE_MODE: complete
在单一节点上拉取并启动 v3 容器,并等待执行升级所需的时间(需要几分钟)。使用以下容器或更新版本:
quay : quay.io/redhat/quay:v3.0.5
请注意,
Quay容器在 Red Hat Quay 3 的端口 8080 和 8443 上包括,而不是 80 和 443,因为它们用于 Red Hat Quay 2。因此,我们建议分别将 8080 和 8443 重新映射到 80 和 443,如下例所示:
# docker run --restart=always -p 80:8080 -p 443:8443 \ --sysctl net.core.somaxconn=4096 \ --privileged=true \ -v /mnt/quay/config:/conf/stack:Z \ -v /mnt/quay/storage:/datastorage:Z \ -d quay.io/redhat/quay:v3.0.5
- 升级完成后,在所有其他节点上启动 Red Hat Quay 3 容器。
- 启动 quay-builder 和 Clair 的 3.0.z 版本,以替换您要返回到集群的容器的任何实例。
- 验证 Red Hat Quay 正常工作,包括推送和拉取与 Docker 版本 2, schema 2 兼容的容器。这包括不同计算机架构(arm、ppc 等)的窗口容器镜像和镜像。
3.17.5. 运行后台升级
要运行后台升级,您需要在两个短时间内关闭集群。当您在第一次停机后集群备份时,quay v3 容器以 v2 兼容性模式运行,因为它会回填数据库。完成此后台进程可能需要几小时甚至天数。对于停机的时间超过几小时的大型安装,建议使用后台升级。
对于这种升级,您可以将 Red Hat Quay 置于兼容性模式,在其中运行 Quay 3 容器,但在升级完成后在旧数据模型上运行。以下是您做什么:
将 Red Hat Quay 3 容器拉取到所有节点。使用以下容器或更新版本:
quay.io/redhat/quay:v3.0.5
- 关闭整个 Red Hat Quay 集群,包括任何 quay-builder 和 Clair 容器。
编辑每个节点上的
config.yaml文件,并将升级模式设置为背景,如下所示:V3_UPGRADE_MODE: background
在单一节点上启动 Red Hat Quay 3 容器并等待迁移完成(最多需要几分钟)。以下是该命令的示例:
请注意,
Quay容器在 Red Hat Quay 3 的端口 8080 和 8443 上包括,而不是 80 和 443,因为它们用于 Red Hat Quay 2。因此,我们建议分别将 8080 和 8443 重新映射到 80 和 443,如下例所示:# docker run --restart=always -p 80:8080 -p 443:8443 \ --sysctl net.core.somaxconn=4096 \ --privileged=true \ -v /mnt/quay/config:/conf/stack:Z \ -v /mnt/quay/storage:/datastorage:Z \ -d quay.io/redhat/quay:v3.0.5
- 在所有其他节点上启动 Red Hat Quay 3 容器。
-
监控
/upgradeprogressAPI 端点,直到报告足以移至下一步(状态达到 95%)。例如,查看https://myquay.example.com/upgradeprogress或使用其他工具查询 API。 - 后台进程完成后,您必须计划另一个维护窗口。
- 在调度的维护过程中,关闭整个 Red Hat Quay 集群。
编辑每个节点上的
config.yaml文件,并将升级模式设置为完成,如下所示:V3_UPGRADE_MODE: complete
- 在一个节点上重新启动 Red Hat Quay,使其进行最终检查。
- 完成最后的检查后,在所有其他节点上启动 Red Hat Quay v3。
- 启动 quay-builder 和 Clair 的 3.0.z 版本,以替换您要返回到集群的容器的任何实例。
- 验证 Quay 正常工作,包括推送和拉取与 Docker 版本 2, schema 2 兼容的容器。这包括不同计算机架构(arm、ppc 等)的窗口容器镜像和镜像。
3.17.6. 目标镜像
- quay: quay.io/redhat/quay:v3.0.5
- Clair: quay.io/redhat/clair-jwt:v3.0.5
- redis : registry.access.redhat.com/RHSCL/redis-32-rhel7
- postgresql: RHSCL/postgresql-96-rhel7
- builder : quay.io/redhat/quay-builder:v3.0.5
3.18. 升级 Red Hat Quay 的地理复制部署
使用以下步骤升级您的 geo-replication Red Hat Quay 部署。
- 当将 geo-replication Red Hat Quay 部署升级到下一个 y-stream 版本(例如,Red Hat Quay 3.7 → Red Hat Quay 3.8)或 geo-replication 部署时,您必须在升级前停止操作。
- 故障时间从一个 y-stream 版本升级到下一个版本会间歇性。
- 在升级前,强烈建议您备份 Red Hat Quay 部署。
先决条件
-
已登录到
registry.redhat.io
此流程假设您在三个(或更多)系统上运行 Red Hat Quay 服务。如需更多信息,请参阅准备 Red Hat Quay 高可用性。
获取运行 Red Hat Quay 实例的每个系统上所有 Red Hat Quay 实例的列表。
在 System A 中输入以下命令来显示 Red Hat Quay 实例:
$ sudo podman ps
输出示例
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ec16ece208c0 registry.redhat.io/quay/quay-rhel8:v3.7.0 registry 6 minutes ago Up 6 minutes ago 0.0.0.0:80->8080/tcp, 0.0.0.0:443->8443/tcp quay01
在 System B 中输入以下命令来显示 Red Hat Quay 实例:
$ sudo podman ps
输出示例
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7ae0c9a8b37d registry.redhat.io/quay/quay-rhel8:v3.7.0 registry 5 minutes ago Up 2 seconds ago 0.0.0.0:82->8080/tcp, 0.0.0.0:445->8443/tcp quay02
在 System C 中输入以下命令来显示 Red Hat Quay 实例:
$ sudo podman ps
输出示例
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e75c4aebfee9 registry.redhat.io/quay/quay-rhel8:v3.7.0 registry 4 seconds ago Up 4 seconds ago 0.0.0.0:84->8080/tcp, 0.0.0.0:447->8443/tcp quay03
在每个系统中临时关闭所有 Red Hat Quay 实例。
在 System A 中输入以下命令来关闭 Red Hat Quay 实例:
$ sudo podman stop ec16ece208c0
在 System B 中输入以下命令来关闭 Red Hat Quay 实例:
$ sudo podman stop 7ae0c9a8b37d
在 System C 中输入以下命令来关闭 Red Hat Quay 实例:
$ sudo podman stop e75c4aebfee9
在每个系统上获取最新的 Red Hat Quay 版本,如 Red Hat Quay 3.9。
在 System A 中输入以下命令来获取最新的 Red Hat Quay 版本:
$ sudo podman pull registry.redhat.io/quay/quay-rhel8:v3.8.0
在 System B 中输入以下命令来获取最新的 Red Hat Quay 版本:
$ sudo podman pull registry.redhat.io/quay/quay-rhel8:v3.8.0
在 System C 中输入以下命令来获取最新的 Red Hat Quay 版本:
$ sudo podman pull registry.redhat.io/quay/quay-rhel8:v3.8.0
在高可用性 Red Hat Quay 部署的系统 A 上,运行新镜像版本,如 Red Hat Quay 3.9 :
# sudo podman run --restart=always -p 443:8443 -p 80:8080 \ --sysctl net.core.somaxconn=4096 \ --name=quay01 \ -v /mnt/quay/config:/conf/stack:Z \ -v /mnt/quay/storage:/datastorage:Z \ -d registry.redhat.io/quay/quay-rhel8:v3.8.0
等待新的 Red Hat Quay 容器在 System A 上完全正常工作。您可以输入以下命令检查容器的状态:
$ sudo podman ps
输出示例
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 70b9f38c3fb4 registry.redhat.io/quay/quay-rhel8:v3.8.0 registry 2 seconds ago Up 2 seconds ago 0.0.0.0:82->8080/tcp, 0.0.0.0:445->8443/tcp quay01
- 可选:通过进入到 Red Hat Quay UI 来确保 Red Hat Quay 已完全操作。
确保 System A 上的 Red Hat Quay 完全正常工作后,在 System B 和 System C 上运行新镜像版本。
在高可用性 Red Hat Quay 部署的 System B 上,运行新镜像版本,如 Red Hat Quay 3.9 :
# sudo podman run --restart=always -p 443:8443 -p 80:8080 \ --sysctl net.core.somaxconn=4096 \ --name=quay02 \ -v /mnt/quay/config:/conf/stack:Z \ -v /mnt/quay/storage:/datastorage:Z \ -d registry.redhat.io/quay/quay-rhel8:v3.8.0
在高可用性 Red Hat Quay 部署的系统 C 上,运行新镜像版本,如 Red Hat Quay 3.9 :
# sudo podman run --restart=always -p 443:8443 -p 80:8080 \ --sysctl net.core.somaxconn=4096 \ --name=quay03 \ -v /mnt/quay/config:/conf/stack:Z \ -v /mnt/quay/storage:/datastorage:Z \ -d registry.redhat.io/quay/quay-rhel8:v3.8.0
您可以输入以下命令来检查 System B 和 System C 中的容器状态:
$ sudo podman ps
第 4 章 升级 Quay Bridge Operator
要升级 Quay Bridge Operator (QBO),请将 Subscription 选项卡中的 Channel Subscription 更新频道改为所需的频道。
当将 QBO 从版本 3.5 升级到 3.7 时,需要一些额外的步骤:
您需要创建新的
QuayIntegration自定义资源。这可以在 Web 控制台或命令行完成。upgrade-quay-integration.yaml
- apiVersion: quay.redhat.com/v1 kind: QuayIntegration metadata: name: example-quayintegration-new spec: clusterID: openshift 1 credentialsSecret: name: quay-integration namespace: openshift-operators insecureRegistry: false quayHostname: https://registry-quay-quay35.router-default.apps.cluster.openshift.com- 1
- 确保
clusterID与现有QuayIntegration资源的值匹配。
创建新的
QuayIntegration自定义资源:$ oc create -f upgrade-quay-integration.yaml
-
删除旧的
QuayIntegration自定义资源。 删除旧的变异
Webhook 配置:$ oc delete mutatingwebhookconfigurations.admissionregistration.k8s.io quay-bridge-operator
4.1. 升级 Red Hat Quay Operator 的 geo-replication 部署
使用以下步骤升级地理复制的 Red Hat Quay Operator。
- 当将 geo-replicated Red Hat Quay Operator 部署升级到下一个 y-stream 版本(例如,Red Hat Quay 3.7 → Red Hat Quay 3.8),您必须在升级前停止操作。
- 故障时间从一个 y-stream 版本升级到下一个版本会间歇性。
- 在升级前,强烈建议您备份 Red Hat Quay Operator 部署。
此流程假设您在三个(或更多)系统上运行 Red Hat Quay Operator。对于此过程,我们将假设三个名为 System A、 System B 和 System C 的系统。系统 A 将充当部署 Red Hat Quay Operator 的主要系统。
在 System B 和 System C 上,缩减您的 Red Hat Quay Operator 部署。这可以通过禁用自动扩展并覆盖 Red Hat Quay、镜像 worker 和 Clair 的副本计数(如果被管理)来实现。使用以下
quayregistry.yaml文件作为参考:apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: registry namespace: ns spec: components: … - kind: horizontalpodautoscaler managed: false 1 - kind: quay managed: true overrides: 2 replicas: 0 - kind: clair managed: true overrides: replicas: 0 - kind: mirror managed: true overrides: replicas: 0 …注意您必须保留在 System A 上运行的 Red Hat Quay Operator。不要更新 System A 上的
quayregistry.yaml文件。等待
registry-quay-app、registry-quay-mirror和registry-clair-apppod 消失。输入以下命令检查其状态:oc get pods -n <quay-namespace>
输出示例
quay-operator.v3.7.1-6f9d859bd-p5ftc 1/1 Running 0 12m quayregistry-clair-postgres-7487f5bd86-xnxpr 1/1 Running 1 (12m ago) 12m quayregistry-quay-app-upgrade-xq2v6 0/1 Completed 0 12m quayregistry-quay-config-editor-6dfdcfc44f-hlvwm 1/1 Running 0 73s quayregistry-quay-redis-84f888776f-hhgms 1/1 Running 0 12m
- 在 System A 上,启动 Red Hat Quay Operator 升级到最新的 y-stream 版本。这是手动过程。有关升级安装的 Operator 的更多信息,请参阅 升级已安装的 Operator。如需有关 Red Hat Quay 升级路径的更多信息,请参阅升级 Red Hat Quay Operator。
-
安装新的 Red Hat Quay Operator 后,集群上所需的升级会自动完成。之后,新的 Red Hat Quay pod 会使用最新的 y-stream 版本启动。另外,还会调度并启动新的
Quaypod。 通过进入到 Red Hat Quay UI 确认更新是否正常工作:
在 OpenShift 控制台中,导航到 Operators → Installed Operators,然后点击 Registry Endpoint 链接。
重要在 Red Hat Quay UI 可用前,不要执行以下步骤。在系统 A 上提供 UI 前,不要升级 System B 和 System C 上的 Red Hat Quay Operator。
确认更新在 System A 上正常工作后,在 System B 和 System C 上启动 Red Hat Quay Operator。Operator 升级会导致升级的 Red Hat Quay 安装,并重启 pod。
注意因为数据库架构对于新的 y-stream 安装正确,System B 和 System C 上的新 pod 应该快速启动。
第 5 章 降级 Red Hat Quay
Red Hat Quay 只支持回滚到以前的 z-stream 版本,如 3.7.2 → 3.7.1。不支持回滚到以前的 y-stream 版本(3.7.0 → 3.6.0)。这是因为 Red Hat Quay 更新可能包含在升级到 Red Hat Quay 的新版本时应用的数据库 schema 升级。数据库架构升级不被视为向后兼容。
基于 Operator 的部署或基于虚拟机的部署不支持降级到以前的 z-streams。降级应只在极端情况下进行。回滚 Red Hat Quay 部署的决定必须与 Red Hat Quay 支持和开发团队一起做出。如需更多信息,请联系红帽 Quay 支持。