14.2. 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) マイナーバージョンからの直接のシングルステップアップグレードをサポートします。これにより、古いリリースを使用している顧客のアップグレード手順が簡素化されます。次のアップグレードパスがサポートされています。
- 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 のスタンドアロンデプロイメントを 3.9 にアップグレードする場合には、スタンドアロンアップグレード ガイドを参照してください。
14.2.1. Quay のアップグレード
Red Hat Quay をあるマイナーバージョンから次のマイナーバージョン (たとえば、3.4 → 3.5) に更新するには、Red Hat Quay Operator の更新チャネルを変更する必要があります。
3.4.2 → 3.4.3 などの z ストリームのアップグレードの場合、更新は、ユーザーが最初にインストール時に選択した major-minor チャネルでリリースされます。z ストリームのアップグレードを実行する手順は、上記のように approvalStrategy によって異なります。承認ストラテジーが Automatic に設定されている場合、Quay Operator は自動的に最新の z ストリームにアップグレードします。これにより、ダウンタイムがほとんどない (またはまったくない) 新しい z ストリームへの Quay の自動更新が行われます。それ以外の場合は、インストールを開始する前に更新を手動で承認する必要があります。
14.2.2. Red Hat Quay を 3.8 → 3.9 に更新する
Red Hat Quay デプロイメントを 1 つの y ストリームから次の y ストリームにアップグレードする場合 (たとえば、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 の既存の PostgreSQL データベースをバージョン 10 からバージョン 13 に自動的にアップグレードします。
- このアップグレードは元に戻すことができません。PostgreSQL 13 にアップグレードすることが強く推奨されます。PostgreSQL 10 は 2022 年 11 月 10 日に最終リリースとなり、サポートされなくなりました。詳細は、PostgreSQL のバージョン管理ポリシー を参照してください。
-
デフォルトでは、Red Hat Quay は PostgreSQL 10 から古い Persistent Volume Claim (PVC) を削除するように設定されています。この設定を無効にして古い PVC をバックアップするには、
quay-operatorサSubscriptionオブジェクトでPOSTGRES_UPGRADE_RETAIN_BACKUPをTrueに設定する必要があります。
前提条件
- OpenShift Container Platform に Red Hat Quay 3.8 がインストールされている。
100 GB の空き容量、追加のストレージ。
アップグレードプロセス中に、移行されたデータを保存するために追加の永続ボリュームクレーム (PVC) がプロビジョニングされる。これにより、ユーザーデータに対する破壊的な操作を防ぐことが可能。アップグレードプロセスでは、Red Hat Quay データベースのアップグレードと Clair データベースのアップグレードの両方で、50 GB の PVC をロールアウト。
手順
オプション。
quay-operatorSubscriptionオブジェクトのPOSTGRES_UPGRADE_RETAIN_BACKUPをTrueに設定して、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 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-upgradePod が Completed としてマークされると、Red Hat Quay デプロイメントの残りの Pod が起動します。これには約 10 分かかります。 -
quay-databaseおよびclair-postgresPod がpostgresql-13イメージを使用していることを確認します。 -
quay-appPod が Running としてマークされると、Red Hat Quay レジストリーにアクセスできるようになります。
14.2.3. 3.3.z または 3.4.z から 3.6 への直接アップグレード
次のセクションでは、Red Hat Quay 3.3.z または 3.4.z から 3.6 にアップグレードする際の重要な情報を説明しています。
14.2.3.1. エッジルーティングを有効にした状態でのアップグレード
- 以前は、エッジルーティングを有効にして 3.3.z バージョンの Red Hat Quay を実行している場合、ユーザーは 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: ...
14.2.3.2. サブジェクト別名のないカスタム SSL/TLS 証明書/キーペアを使用したアップグレード
Red Hat Quay 3.3.4 から Red Hat Quay 3.6 に直接アップグレードするときに、サブジェクト代替名 (SAN) なしで独自の SSL/TLS 証明書/キーペアを使用しているお客様には問題があります。Red Hat Quay 3.6 へのアップグレード中に、デプロイメントがブロックされ、Red Hat Quay Operator Pod ログから Red Hat Quay SSL/TLS 証明書に SAN が必要であることを示すエラーメッセージが表示されます。
可能であれば、SAN 内の正しいホスト名を使用して SSL/TLS 証明書を再生成する必要があります。考えられる回避策には、アップグレード後に quay-app、quay-upgrade、quay-config-editor Pod で環境変数を定義して、CommonName のマッチングを有効にすることが含まれます。
GODEBUG=x509ignoreCN=0
GODEBUG=x509ignoreCN=0 フラグは、SAN が存在しない場合に、X.509 証明書の CommonName フィールドをホスト名として扱うという従来の動作を有効にします。ただし、この回避策は再デプロイメント後も持続しないため、お勧めしません。
14.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 のセットアップ を参照してください。
14.2.4. 3.3.z から 3.6 にアップグレードする際の Swift 設定
Red Hat Quay 3.3.z から 3.6.z にアップグレードすると、ユーザーが Switch auth v3 requires tenant_id (string) in 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: *****14.2.5. Red Hat Quay Operator の更新チャネルの変更
インストールされた Operator のサブスクリプションは、Operator の更新を追跡して受け取るために使用される更新チャネルを指定します。Red Hat Quay Operator をアップグレードして新規チャネルからの更新の追跡および受信を開始するには、インストールされた Red Hat Quay Operator の Subscription タブで更新チャネルを変更します。Automatic 承認ストラテジーのあるサブスクリプションの場合、アップグレードは自動的に開始し、インストールされた Operator を一覧表示したページでモニターできます。
14.2.6. 保留中の 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 インストールの概要を提供します。