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