Red Hat Quay のアップグレード

Quay をあるマイナーバージョンから次のマイナーバージョン (たとえば、3.4 → 3.5) に更新するには、Quay Operator の更新チャネルを変更する必要があります。

3.4.2 → 3.4.3 などの z ストリームのアップグレードの場合、更新は、ユーザーが最初にインストール時に選択した major-minor チャネルでリリースされます。z ストリームのアップグレードを実行する手順は、上記のように approvalStrategy によって異なります。承認ストラテジーが Automatic に設定されている場合、Quay Operator は自動的に最新の z ストリームにアップグレードします。これにより、ダウンタイムがほとんどない (またはまったくない) 新しい z ストリームへの Quay の自動更新が行われます。それ以外の場合は、インストールを開始する前に更新を手動で承認する必要があります。

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: *****

インストールされた Operator のサブスクリプションは、Operator の更新を追跡して受け取るために使用される更新チャネルを指定します。Quay Operator をアップグレードして新規チャネルからの更新の追跡および受信を開始するには、インストールされた Quay Operator の Subscription タブで更新チャネルを変更します。Automatic 承認ストラテジーのあるサブスクリプションの場合、アップグレードは自動的に開始し、インストールされた Operator をリスト表示したページでモニターできます。

インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合は、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。Quay Operator に保留中のアップグレードがある場合、このステータスは Installed Operators のリストに表示されます。Quay Operator の Subscription タブで、インストール計画をプレビューし、アップグレードに利用可能なリソースとしてリスト表示されるリソースを確認できます。問題がなければ、Approve をクリックし、Installed Operators をリスト表示したページに戻り、アップグレードの進捗をモニターします。

以下のイメージには、更新 Channel、Approval ストラテジー、Upgrade status および InstallPlan などの UI の Subscription タブが表示されています。

Installed Operator のリストは、現在の Quay インストールの概要を提供します。

クォータ管理は FEATURE_QUOTA_MANAGEMENT プロパティーでサポートされるようになり、デフォルトでオフになっています。クォータ管理を有効にするには、config.yaml の機能フラグを true に設定します。

FEATURE_QUOTA_MANAGEMENT: true

Red Hat Quay を使用したリモート組織のプロキシーが、FEATURE_PROXY_CACHE プロパティーでサポートされるようになりました。プロキシーキャッシュを有効にするには、confg.yaml の機能フラグを true に設定します。

FEATURE_PROXY_CACHE: true

ビルドは仮想化プラットフォームで実行できます。以前のビルド設定を実行するための下位互換性も利用できます。仮想ビルドを有効にするには、config.yaml の機能フラグを true に設定します。

FEATURE_BUILD_SUPPORT: true

Geo レプリケーションを使用した Red Hat Quay のデプロイメントが、Operator デプロイメントでサポートされるようになりました。ジオレプリケーションを有効にするには、config.yaml の機能フラグを true に設定します。

FEATURE_STORAGE_REPLICATION: true

OpenShift コンソールでの Quay 3.6 のモニタリングのサポートを使用するには、Operator がすべての namespace でインストールされている必要があります。Operator を特定の namespace にインストールしている場合は、Operator 自体を削除し、アップグレードが実行されたら、これをすべての namespace に対して再インストールします。

Helm アーティファクトおよび OCI アーティファクトのサポートが、Red Hat Quay 3.6 でデフォルトで有効にされるようになりました。機能を明示的に有効にする必要がある場合 (機能がデフォルトで有効にされていないバージョンからアップグレードする場合など) は、以下のプロパティーを使用して OCI アーティファクトの使用を有効にするために、Quay デプロイメントを再設定する必要があります。

FEATURE_GENERAL_OCI_SUPPORT: true

QuayEcosystem から QuayRegistry への自動アップグレード時に問題が発生した場合は、以下の手順を実行して QuayEcosystem の使用に戻します。

Quay Operator は、QuayEcosystem コンポーネントの移行に失敗したり、サポートされていない場合は、ログや status.conditions にエラーを報告します。Kubernetes リソースを採用する必要がなく、必要な値がすべて Quay の config.yaml に提供されているため、すべてのアンマネージドコンポーネントは正常に移行されるはずです。

データベース

一時データベースはサポートされません (volumeSize フィールドを設定する必要があります)。

Redis

特別な設定は必要ありません。

External Access

パススルー Route アクセスのみが自動移行でサポートされます。他の方法には手動移行が必要です。

Clair

特別な設定は必要ありません。

オブジェクトストレージ

QuayEcosystem には管理オブジェクトストレージコンポーネントがないため、オブジェクトストレージには常に管理外のマークが付けられます。ローカルストレージはサポートされません。

リポジトリーのミラーリング

特別な設定は必要ありません。

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: *****

Red Hat Quay 2.y.z クラスターで作業を開始する場合は、以下の手順に従います。最新の Red Hat Quay 3.x バージョンにアップグレードする前に、ここ で説明されているように、まずそのクラスターを 3.0.5 に移行する必要があります。クラスターで 3.0.5 が実行されたら、各マイナーバージョンに順番にアップグレードすることで、最新の 3.x バージョンにアップグレードできます。以下に例を示します。

Red Hat Quay 2.y.z から 3.0 へのアップグレードを開始する前に、次の点に注意してください。

最善の結果が得られるように、以下の前提条件を満たすことを推奨します。

同期アップグレード (ダウンタイムでアップグレードを完了) か、バックグラウンドアップグレード (Red Hat Quay の実行中にアップグレードを完了) のいずれかを選択します。これらのメジャーリリースのアップグレードでは、Red Hat Quay クラスターを少なくとも短期間停止する必要があります。

選択したアップグレードのタイプを問わず、ビルダーおよび clair イメージを使用している場合は、Red Hat Quay クラスターが停止している間に、ビルダーおよび Clair を新規イメージにアップグレードする必要があります。

これらのイメージはいずれも registry.redhat.io/quay リポジトリーから入手できます。

同期アップグレード (アップグレード中にクラスター全体が停止する) を実行するには、以下を実行します。

バックグラウンドアップグレードは、2 回ほどクラスターを短時間ダウンさせるだけで実行できます。最初のダウンタイム後にクラスターを再起動すると、データベースをバックフィルするため、quay v3 コンテナーは v2 互換性モードで実行します。このバックグラウンドプロセスが完了するまでに時間または数日かかる場合があります。数時間を超えるダウンタイムが問題となるような大規模なインストールを行う場合は、バックグラオウンドアップグレードが推奨されます。

このタイプのアップグレードでは、Red Hat Quay を互換性モードにします。互換性モードでは、Quay 3 コンテナーが実行しますが、アップグレードが完了するまで以前のデータモデルで実行します。手順は以下のとおりです。