15.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 ガベージコレクションによって古いリソースがすべてクリーンアップされます。
15.4.1. QuayEcosystem アップグレードを元に戻す
QuayEcosystem から QuayRegistry への自動アップグレード時に問題が発生した場合は、以下の手順を実行して QuayEcosystem の使用に戻します。
手順
UI または
kubectlのいずれかを使用してQuayRegistryを削除します。$ kubectl delete -n <namespace> quayregistry <quayecosystem-name>
-
Routeを使用して外部アクセスを提供していた場合は、UI やkubectlを使用して元のServiceを指すようにRouteを変更します。
QuayEcosystem が PostgreSQL データベースを管理している場合、アップグレードプロセスにより、アップグレードされた Operator が管理する新しい Postgres データベースにデータが以降されます。古いデータベースは変更または削除されませんが、移行が完了すると Quay はこのデータベースを使用しなくなります。データの移行中に問題が発生した場合は、アップグレードプロセスを終了し、データベースをマネージド外コンポーネントとして継続して使用することが推奨されます。
15.4.2. アップグレードでサポートされる QuayEcosystem 設定
QuayEcosystem コンポーネントの移行が失敗するかサポートされていない場合、Red Hat Quay Operator はログと status.conditions でエラーを報告します。アンマネージドコンポーネントを移行する場合、Kubernetes リソースを導入する必要がなく、必要な値はすべて Red Hat Quay の config.yaml で指定されているため、正常に移行できるはずです。
データベース
一時データベースはサポートされません (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 には管理オブジェクトストレージコンポーネントがないため、オブジェクトストレージには常に管理外のマークが付けられます。ローカルストレージはサポートされません。
リポジトリーのミラーリング
特別な設定は必要ありません。
関連情報
- Red Hat Quay Operator の詳細は、アップストリームの quay-operator プロジェクトを参照してください。
