Red Hat Quay のアップグレード
第1章 アップグレードの概要
Red Hat Quay のアップグレード手順は、使用しているインストールの種類によって異なります。
Red Hat Quay Operator は、Red Hat Quay クラスターをデプロイし、管理する簡単な方法を提供します。これは、Red Hat Quay の OpenShift へのデプロイで推奨の手順です。
「Quay Operator を使用した Quay のアップグレード」で説明されているように、Red Hat Quay Operator のアップグレードは、Operator Lifecycle Manager (OLM) を使用する必要があります。
Red Hat Quay および Clair の概念実証または高可用性のインストールをアップグレードする手順は、「スタンドアロンでのアップグレード」に記載されています。
第2章 Red Hat Quay Operator のアップグレードの概要
Red Hat Quay Operator は、シンクロナイズドバージョニング スキームに従います。つまり、Red Hat Operator の各バージョンは Quay とその管理するコンポーネントに関連付けられます。QuayRegistry
カスタムリソースには、Red Hat Quay が deploy
するバージョンを設定するフィールドはありません。Operator は、すべてのコンポーネントを 1 つのバージョンのみデプロイできます。このスキームは、すべてのコンポーネントが適切に連携し、Kubernetes で Red Hat Quay の多数に渡るバージョンのライフサイクルを管理する方法を把握する必要がある Operator の複雑性を軽減するために、選択されました。
2.1. Operator Lifecycle Manager
Red Hat Quay Operator は Operator Lifecycle Manager (OLM) を使用してインストールし、アップグレードする必要があります。デフォルトの approvalStrategy: Automatic
で Subscription
を作成する場合、OLM は新規バージョンが利用可能になると常に Red Hat Quay Operator を自動的にアップグレードします。
Red Hat Quay Operator が Operator Lifecycle Manager によってインストールされている場合、自動または手動のアップグレードをサポートするように設定されていることがあります。このオプションは、インストール時に Red Hat Quay Operator の OperatorHub ページに表示されます。これは、Red Hat Quay Operator Subscription
オブジェクトの approvalStrategy
フィールドでも確認できます。Automatic
を選択すると、新規 Operator バージョンがリリースされるたびに Red Hat Quay Operator が自動的にアップグレードされます。これが望ましくない場合は、Manual
承認ストラテジーを選択する必要があります。
2.2. Red Hat Quay Operator のアップグレード
インストールされた Operator を OpenShift Container Platform にアップグレードする一般的な方法については、インストールされた 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) マイナーバージョンからの直接のシングルステップアップグレードをサポートします。これにより、古いリリースを使用している顧客のアップグレード手順が簡素化されます。Red Hat Quay 3.12 では、次のアップグレードパスがサポートされています。
- 3.10.z → 3.11.z
- 3.10.z → 3.11.z
Red Hat Quay のスタンドアロンデプロイメントを 3.12 にアップグレードする場合は、スタンドアロンアップグレード ガイドを参照してください。
2.2.1. Red Hat Quay のバージョン 3.12 へのアップグレード
Red Hat Quay をあるマイナーバージョンから次のマイナーバージョン (たとえば、3.11 → 3.12) に更新するには、Red Hat Quay Operator の更新チャネルを変更する必要があります。
手順
- OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
- Red Hat Quay Operator をクリックします。
- Subscription タブに移動します。
- Subscription details で Update channel をクリックします。
- stable-3.12 → Save を選択します。
- Upgrade status で新規インストールの進行状況を確認します。アップグレードのステータスが 1 installed に変わるまで待ってから続行してください。
- OpenShift Container Platform クラスターで、Workloads → Pod に移動します。既存の Pod は終了するか、終了中である必要があります。
-
データベースのアップグレードと既存データのアレンビック移行を担当する Pod
clair-postgres-upgrade
、quay-postgres-upgrade
、およびquay-app-upgrade
が起動するまで待ちます。 -
clair-postgres-upgrade
、quay-postgres-upgrade
、およびquay-app-upgrade
Pod が Completed としてマークされると、Red Hat Quay デプロイメントの残りの Pod が起動します。これには約 10 分かかります。 -
quay-database
およびclair-postgres
Pod がpostgresql-13
イメージを使用していることを確認します。 -
quay-app
Pod が Running としてマークされると、Red Hat Quay レジストリーにアクセスできるようになります。
2.2.2. 次のマイナーリリースバージョンへのアップグレード
z
ストリームのアップグレード (3.11.1 → 3.11.2 など) の場合、更新は、ユーザーがインストール時に最初に選択したメジャー/マイナーチャネルでリリースされます。z
ストリームのアップグレードを実行する手順は、上記のように approvalStrategy
によって異なります。承認ストラテジーが Automatic
に設定されている場合、Red Hat Quay Operator は自動的に最新の z
ストリームにアップグレードします。この場合、ダウンタイムがほとんどない (またはまったくない) 新しい z
ストリームへの Red Hat Quay の自動ローリング更新が行われます。それ以外の場合は、インストールを開始する前に更新を手動で承認する必要があります。
2.2.3. Red Hat Quay Operator の更新チャネルの変更
インストールされた Operator のサブスクリプションは、Operator の更新を追跡して受け取るために使用される更新チャネルを指定します。Red Hat Quay Operator をアップグレードして新規チャネルからの更新の追跡および受信を開始するには、インストールされた Red Hat Quay Operator の Subscription タブで更新チャネルを変更します。Automatic
承認ストラテジーのあるサブスクリプションの場合、アップグレードは自動的に開始し、インストールされた Operator をリスト表示したページでモニターできます。
2.2.4. 保留中の Operator アップグレードの手動による承認
インストールされた Operator のサブスクリプションの承認ストラテジーが Manual
に設定されている場合は、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。Red Hat Quay Operator に保留中のアップグレードがある場合、このステータスはインストールされた Operator のリストに表示されます。Red Hat Quay Operator の Subscription
タブで、インストール計画をプレビューし、アップグレードに利用可能なリソースとして一覧表示されるリソースを確認できます。問題がなければ、Approve
をクリックし、Installed Operators を一覧表示したページに戻り、アップグレードの進捗を監視します。
以下のイメージには、更新 Channel
、Approval
ストラテジー、Upgrade status
および InstallPlan
などの UI の Subscription タブが表示されています。
Installed Operator のリストは、現在の Quay インストールの概要を提供します。
2.3. QuayRegistry リソースのアップグレード
Red Hat Quay Operator を起動すると、監視するように設定されている namespace にある QuayRegistries
をすぐに検索します。見つかった場合は、次のロジックが使用されます。
-
status.currentVersion
が設定されていない場合は、通常通り調整を行います。 -
status.currentVersion
が Operator のバージョンと等しい場合は、通常通り調整を行います。 -
status.currentVersion
が Operator のバージョンと一致しない場合は、アップグレードできるかどうかを確認します。可能な場合は、アップグレードタスクを実行し、完了後にstatus.currentVersion
を Operator のバージョンに設定します。アップグレードできない場合は、エラーを返し、QuayRegistry
とそのデプロイされた Kubernetes オブジェクトのみを残します。
2.4. QuayEcosystem のアップグレード
アップグレードは、QuayEcosystem
API を使用して限られた設定を行っていた旧バージョンの Operator からサポートされています。移行が予期せず行われるようにするには、移行を行うために特別なラベルを QuayEcosystem
に適用する必要があります。Operator が管理するための新しい QuayRegistry
が作成されますが、古い QuayEcosystem
は手動で削除されるまで残り、何か問題が発生した場合にロールバックして Quay にアクセスできるようになります。既存の QuayEcosystem
を新しい QuayRegistry
に移行するには、次の手順を実行します。
手順
"quay-operator/migrate": "true"
をQuayEcosystem
のmetadata.labels
に追加します。$ oc edit quayecosystem <quayecosystemname>
metadata: labels: quay-operator/migrate: "true"
-
QuayRegistry
がQuayEcosystem
と同じmetadata.name
で作成されるまで待機します。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
を使用して外部アクセスを提供していた場合は、UI やkubectl
を使用して元のService
を指すようにRoute
を変更します。
QuayEcosystem
が PostgreSQL データベースを管理している場合、アップグレードプロセスにより、アップグレードされた Operator が管理する新しい PostgreSQL データベースにデータが以降されます。古いデータベースは変更または削除されませんが、移行が完了すると Quay はこのデータベースを使用しなくなります。データの移行中に問題が発生した場合は、アップグレードプロセスを終了し、データベースをマネージド外コンポーネントとして継続して使用することが推奨されます。
2.4.2. アップグレードでサポートされる QuayEcosystem 設定
QuayEcosystem
コンポーネントの移行が失敗するかサポートされていない場合、Red Hat Quay Operator はログと status.conditions
でエラーを報告します。アンマネージドコンポーネントを移行する場合、Kubernetes リソースを導入する必要がなく、必要な値はすべて Red Hat Quay の config.yaml
で指定されているため、正常に移行できるはずです。
Database
一時データベースはサポートされません (volumeSize
フィールドを設定する必要があります)。
Redis
特別な設定は必要ありません。
External Access
パススルー Route
アクセスのみが自動移行でサポートされます。他の方法には手動移行が必要です。
-
ホスト名のない
LoadBalancer
:QuayEcosystem
にラベル"quay-operator/migration-complete": "true"
が付けられた後、Kubernetes がService
をガベージコレクションしてロードバランサーを削除するのを防ぐため、QuayEcosystem
を削除する 前 に、既存のService
からmetadata.ownerReferences
フィールドを削除します。新規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
で作成されます。新しいService
が提供するstatus.loadBalancer
エンドポイントを指すように、DNS 設定を変更します。
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) マイナーバージョンからの直接のシングルステップアップグレードをサポートします。以前のマイナーバージョンのみをアップグレードする通常のアップグレードに対するこの例外により、古いリリースを使用している顧客のアップグレード手順が簡素化されます。Red Hat Quay 3.12 では、次のアップグレードパスがサポートされています。
- 3.10.z → 3.11.z
- 3.10.z → 3.11.z
Red Hat Quay Operator をアップグレードするユーザーは、Red Hat Quay Operator のアップグレードの概要 を参照してください。
このドキュメントでは、各アップグレードに必要な手順を説明します。現在のバージョンを決定し、現在のバージョンから順に、目標とするバージョンへとステップを踏んで進めていきます。
個々のリリースの機能に関する情報は、Red Hat Quay リリースノート を参照してください。
手動アップグレードの一般的な手順は、以下のとおりです。
- Quay および Clair コンテナーを停止する
- データベースとイメージストレージをバックアップする (任意ではあるが推奨)
- 新バージョンのイメージを使用して Clair を起動する
- Clair が接続を受け入れる準備ができるまで待ってから、新しいバージョンの Quay を起動する
3.1. イメージへのアクセス
バージョン 3.4.0 以降の Red Hat Quay イメージは、registry.redhat.io および registry.access.redhat.com から入手でき、認証は Red Hat Container Registry Authentication で説明されているようにセットアップされます。
3.2. 3.11.z から 3.12.z へのアップグレード
3.2.1. ターゲットイメージ
- Quay: registry.redhat.io/quay/quay-rhel8:v3.12.2
- Clair: registry.redhat.io/quay/clair-rhel8:v3.12.2
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- Redis: registry.redhat.io/rhel8/redis-6:1-110
3.3. 3.10.z から 3.12.z へのアップグレード
3.3.1. ターゲットイメージ
- Quay: registry.redhat.io/quay/quay-rhel8:v3.12.2
- Clair: registry.redhat.io/quay/clair-rhel8:v3.12.2
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- Redis: registry.redhat.io/rhel8/redis-6:1-110
3.4. 3.10.z から 3.11.z へのアップグレード
3.4.1. ターゲットイメージ
- Quay: registry.redhat.io/quay/quay-rhel8:v3.11.0
- Clair: registry.redhat.io/quay/clair-rhel8:v3.11.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- Redis: registry.redhat.io/rhel8/redis-6:1-110
3.5. 3.9.z から 3.11.z へのアップグレード
3.5.1. ターゲットイメージ
- Quay: registry.redhat.io/quay/quay-rhel8:v3.11.0
- Clair: registry.redhat.io/quay/clair-rhel8::v3.11.0
- PostgreSQL: registry.redhat.io/rhel8/postgresql-13:1-109
- Redis: registry.redhat.io/rhel8/redis-6:1-110
第4章 スタンドアロン Red Hat Quay のジオレプリケーションデプロイメントのアップグレード
以下の手順を実行して、Red Hat Quay の Geo レプリケーションデプロイメントをアップグレードします。
- Red Hat Quay の Geo レプリケーションデプロイメントを次の y-stream リリース (例: Red Hat Quay 3.7 → Red Hat Quay 3.8) または Geo レプリケーションデプロイメントにアップグレードする場合は、アップグレードを実行する前に操作を停止する必要があります。
- y-stream リリースを次のリリースにアップグレードする場合は、アップグレード中にダウンタイムが断続的に発生します。
- アップグレードする前に、Red Hat Quay デプロイメントをバックアップすることが強く推奨されます。
前提条件
-
registry.redhat.io
にログインしている。
この手順では、3 つ以上のシステムで Red Hat Quay サービスを実行していることを前提としています。詳細は、Red Hat Quay の高可用性の準備 を参照してください。
Red Hat Quay インスタンスを実行している各システムですべての Red Hat Quay インスタンスのリストを取得します。
システム 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 インスタンスをすべて一時的にシャットダウンします。
システム 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 3 などの最新の Red Hat Quay バージョンを取得します。
システム A で以下のコマンドを入力して、最新の Red Hat Quay バージョンを取得します。
$ sudo podman pull registry.redhat.io/quay/quay-rhel8:v3.8.0
システム B で以下のコマンドを入力して、最新の Red Hat Quay バージョンを取得します。
$ sudo podman pull registry.redhat.io/quay/quay-rhel8:v3.8.0
システム C で以下のコマンドを入力して、最新の Red Hat Quay バージョンを取得します。
$ sudo podman pull registry.redhat.io/quay/quay-rhel8:v3.8.0
高可用性 Red Hat Quay デプロイメントの System A で、Red Hat Quay 3 などの新しいイメージバージョンを実行します。
# 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 コンテナーがシステム 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 が完全に動作していることを確認します。
システム A 上の Red Hat Quay が完全に動作可能であることを確認したら、System B および System C で新しいイメージバージョンを実行します。
高可用性 Red Hat Quay デプロイメントの System B で、Red Hat Quay 3 などの新しいイメージバージョンを実行します。
# 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 デプロイメントの System C で、Red Hat Quay 3 などの新しいイメージバージョンを実行します。
# 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
次のコマンドを入力して、システム B およびシステム C のコンテナーのステータスを確認できます。
$ sudo podman ps
第5章 OpenShift Container Platform 上の Red Hat Quay の Geo レプリケーションデプロイメントのアップグレード
OpenShift Container Platform デプロイメント上の geo レプリケートされた Red Hat Quay をアップグレードするには、次の手順を使用します。
- OpenShift Container Platform デプロイメント上の geo レプリケートされた Red Hat Quay を次の y-stream リリース (例: Red Hat Quay 3.7 → Red Hat Quay 3.8) にアップグレードする場合は、アップグレードする前に操作を停止する必要があります。
- y-stream リリースを次のリリースにアップグレードする場合は、アップグレード中にダウンタイムが断続的に発生します。
- アップグレードする前に、OpenShift Container Platform デプロイメント上の Red Hat Quay をバックアップすることを強く推奨します。
この手順は、3 つ以上のシステムで Red Hat Quay レジストリーを実行していることを前提としています。この手順では、System A
、System B
、および System C
という名前の 3 つのシステムを想定します。System A
は、Red Hat Quay Operator がデプロイされるプライマリーシステムとして機能します。
システム B およびシステム C で、Red Hat Quay レジストリーをスケールダウンします。これを行うには、自動スケーリングを無効にし、Red Hat Quay、ミラーワーカー、および 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 …
注記Red Hat Quay レジストリーがシステム A で実行されている状態を維持する必要があります。システム A の
quayregistry.yaml
ファイルは更新しないでください。registry-quay-app
、registry-quay-mirror
、およびregistry-clair-app
Pod が消えるまで待機します。以下のコマンドを入力してステータスを確認します。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-redis-84f888776f-hhgms 1/1 Running 0 12m
- システム A で、最新の y-stream バージョンへの Red Hat Quay のアップグレードを開始します。これは手動プロセスです。インストールされた Operator のアップグレードの詳細は、インストールされた Operator のアップグレード を参照してください。Red Hat Quay のアップグレードパスの詳細は、Red Hat Quay Operator のアップグレード を参照してください。
-
新しい Red Hat Quay レジストリーがインストールされると、クラスター上で必要なアップグレードが自動的に完了します。その後、新しい Red Hat Quay Pod は、最新の y-stream バージョンで起動します。さらに、新しい
Quay
Pod がスケジュールされ、起動します。 Red Hat Quay UI に移動して、更新が適切に機能していることを確認します。
OpenShift コンソールで Operators → Installed Operators に移動し、Registry Endpoint リンクをクリックします。
重要Red Hat Quay UI が利用可能になるまで、次の手順を実行しないでください。システム A で UI が利用可能になるまで、システム B およびシステム C で Red Hat Quay レジストリーをアップグレードしないでください。
システム A で更新が適切に機能していることを確認し、システム B とシステム C で Red Hat Quay のアップグレードを開始します。Operator のアップグレードにより、Red Hat Quay インストールがアップグレードされ、Pod が再起動されます。
注記データベーススキーマが新しい y-stream インストールに適したものであるため、システム B とシステム C の新しい Pod がすぐに起動します。
更新後、コンポーネントの
overrides
を削除して、この手順のステップ 1 で行った変更を元に戻します。以下に例を示します。apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: registry namespace: ns spec: components: … - kind: horizontalpodautoscaler managed: true 1 - kind: quay managed: true - kind: clair managed: true - kind: mirror managed: true …
- 1
- アップグレード手順の前に、
horizontalpodautoscaler
リソースがtrue
に設定されていた場合、またはリソース不足の際に Red Hat Quay をスケーリングする場合は、これをtrue
に設定します。
第6章 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
カスタムリソースを削除します。 古い
mutatingwebhookconfigurations
を削除します。$ oc delete mutatingwebhookconfigurations.admissionregistration.k8s.io quay-bridge-operator
第7章 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 の新しいバージョンにアップグレードするときに適用されるデータベーススキーマのアップグレードが含まれている可能性があるためです。データベーススキーマのアップグレードでは下位互換性は保証されていません。
以前の z-stream へのダウングレードは、Operator ベースのデプロイメントでも仮想マシンベースのデプロイメントでも推奨もサポートもされていません。ダウングレードは、非常事態でのみ行う必要があります。Red Hat Quay サポートおよび開発チームと協力して Red Hat Quay デプロイメントをロールバックするかどうかを決定する必要があります。詳細は、Red Hat Quay サポートにお問い合わせください。