14.4. Red Hat Quay Operator を使用した Geo レプリケーション
上記の例では、Red Hat Quay Operator は、共通のデータベースと共通の Redis インスタンスを使用して、2 つの別々のリージョンにデプロイされています。ローカライズされたイメージストレージは各リージョンで提供され、最も近くにある利用可能なストレージエンジンからイメージプルが提供されます。コンテナーイメージのプッシュは、Quay インスタンスの推奨ストレージエンジンに書き込まれ、次にバックグラウンドで他のストレージエンジンに複製されます。
Operator は現在、Clair セキュリティースキャナーとそのデータベースを別々に管理しているため、Geo レプリケーションの設定を活用して、Clair データベースを管理しないようにできます。代わりに、外部共有データベースが使用されます。Red Hat Quay と Clair は、PostgreSQL のいくつかのプロバイダーとベンダーをサポートします。これらは Red Hat Quay 3.x test matrix にあります。さらに、Operator は、デプロイメントに挿入できるカスタム Clair 設定もサポートします。これにより、ユーザーは外部データベースの接続認証情報を使用して Clair を設定できます。
14.4.1. OpenShift Container Platform での Geo レプリケーションのセットアップ
OpenShift Container Platform で Geo レプリケーションを設定するには、次の手順を実行します。
手順
- Red Hat Quay の postgres インスタンスをデプロイします。
次のコマンドを入力してデータベースにログインします。
psql -U <username> -h <hostname> -p <port> -d <database_name>
quay
という名前で Red Hat Quay のデータベースを作成します。以下に例を示します。CREATE DATABASE quay;
データベース内で pg_trm 拡張機能を有効にします。
\c quay; CREATE EXTENSION IF NOT EXISTS pg_trgm;
Redis インスタンスをデプロイします。
注記- クラウドプロバイダーに独自のサービスが含まれている場合は、Redis インスタンスをデプロイする必要がない可能性があります。
- Builder を利用している場合は、Redis インスタンスをデプロイする必要があります。
- Redis 用の VM をデプロイします。
- Red Hat Quay が実行されているクラスターからアクセスできることを確認します。
- ポート 6379/TCP が開いている必要があります。
インスタンス内で Redis を実行します。
sudo dnf install -y podman podman run -d --name redis -p 6379:6379 redis
- クラスターごとに 1 つずつ、2 つのオブジェクトストレージバックエンドを作成します。1 つのオブジェクトストレージバケットが最初のクラスター (プライマリークラスター) の近くにあり、もう 1 つが 2 番目のクラスター (セカンダリークラスター) の近くにあると理想的です。
- 環境変数のオーバーライドを使用して、同じ設定バンドルでクラスターをデプロイし、個々のクラスターに適切なストレージバックエンドを選択します。
- クラスターへの単一のエントリーポイントを提供するように、ロードバランサーを設定します。
14.4.1.1. OpenShift Container Platform 上の Red Hat Quay Operator での Geo レプリケーションの設定
Red Hat Quay Operator の Geo レプリケーションを設定するには、次の手順を実行します。
手順
クラスター間で共有される
config.yaml
ファイルを作成します。このconfig.yaml
ファイルには、一般的な PostgreSQL、Redis、ストレージバックエンドの詳細が含まれています。Geo レプリケーションの
config.yaml
ファイルSERVER_HOSTNAME: <georep.quayteam.org or any other name> 1 DB_CONNECTION_ARGS: autorollback: true threadlocals: true DB_URI: postgresql://postgres:password@10.19.0.1:5432/quay 2 BUILDLOGS_REDIS: host: 10.19.0.2 port: 6379 USER_EVENTS_REDIS: host: 10.19.0.2 port: 6379 DISTRIBUTED_STORAGE_CONFIG: usstorage: - GoogleCloudStorage - access_key: GOOGQGPGVMASAAMQABCDEFG bucket_name: georep-test-bucket-0 secret_key: AYWfEaxX/u84XRA2vUX5C987654321 storage_path: /quaygcp eustorage: - GoogleCloudStorage - access_key: GOOGQGPGVMASAAMQWERTYUIOP bucket_name: georep-test-bucket-1 secret_key: AYWfEaxX/u84XRA2vUX5Cuj12345678 storage_path: /quaygcp DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: - usstorage - eustorage DISTRIBUTED_STORAGE_PREFERENCE: - usstorage - eustorage FEATURE_STORAGE_REPLICATION: true
- 1
- ルートには適切な
SERVER_HOSTNAME
を使用する必要があり、グローバルロードバランサーのホスト名と一致する必要があります。 - 2
- OpenShift Container Platform Operator を使用してデプロイされた Clair インスタンスの設定ファイルを取得するには、Clair 設定の取得 を参照してください。
次のコマンドを入力して、
configBundleSecret
を作成します。$ oc create secret generic --from-file config.yaml=./config.yaml georep-config-bundle
各クラスターで、
configBundleSecret
を設定し、QUAY_DISTRIBUTED_STORAGE_PREFERENCE
環境変数のオーバーライドを使用して、そのクラスターに適切なストレージを設定します。以下に例を示します。注記両方のデプロイメント間の
config.yaml
ファイルは一致する必要があります。一方のクラスターに変更を加える場合は、もう一方のクラスターでも変更する必要があります。US クラスター
QuayRegistry
の例apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: georep-config-bundle components: - kind: objectstorage managed: false - kind: route managed: true - kind: tls managed: false - kind: postgres managed: false - kind: clairpostgres managed: false - kind: redis managed: false - kind: quay managed: true overrides: env: - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE value: usstorage - kind: mirror managed: true overrides: env: - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE value: usstorage
注記SSL/TLS は管理されておらず、ルートは管理されているため、設定ツールを使用するか、設定バンドルで直接、証明書を提供する必要があります。詳細は、TLS およびルートの設定 を参照してください。
ヨーロッパのクラスター
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: georep-config-bundle components: - kind: objectstorage managed: false - kind: route managed: true - kind: tls managed: false - kind: postgres managed: false - kind: clairpostgres managed: false - kind: redis managed: false - kind: quay managed: true overrides: env: - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE value: eustorage - kind: mirror managed: true overrides: env: - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE value: eustorage
注記SSL/TLS は管理されておらず、ルートは管理されているため、設定ツールを使用するか、設定バンドルで直接、証明書を提供する必要があります。詳細は、TLS およびルートの設定 を参照してください。
14.4.2. Red Hat Quay Operator デプロイメントから geo レプリケートされたサイトを削除する
以下の手順を使用すると、Red Hat Quay 管理者は geo レプリケートされたセットアップ内のサイトを削除できます。
前提条件
- OpenShift Container Platform にログインしている。
-
少なくとも 2 つのサイト (例:
usstorage
とeustorage
) を使用して Red Hat Quay geo レプリケーションを設定している。 - 各サイトに、独自の組織、リポジトリー、およびイメージタグがある。
手順
次のコマンドを実行して、定義されたすべてのサイト間で BLOB を同期します。
$ python -m util.backfillreplication
警告Red Hat Quay
config.yaml
ファイルからストレージエンジンを削除する前に、定義されているすべてのサイト間ですべての BLOB が同期されていることを確認する 必要があります。このコマンドを実行すると、レプリケーションワーカーによって取得されるレプリケーションジョブが作成されます。レプリケートする必要がある Blob がある場合、スクリプトはレプリケートされる Blob の UUID を返します。このコマンドを複数回実行したときに、スクリプトから返された出力が空であっても、レプリケーションプロセスが完了したことを意味するわけではありません。それはレプリケーションのためにキューに入れる Blob が残っていないことを意味します。レプリケーションにかかる割り当て時間は検出された Blob の数によって異なるため、次のステップに進む前に適切に評価してください。
または、Microsoft Azure などのサードパーティーのクラウドツールを使用して、同期ステータスを確認することもできます。
このステップは次に進む前に完了する必要があります。
-
サイト
usstorage
の Red Hat Quayconfig.yaml
ファイルで、eustorage
サイトのDISTRIBUTED_STORAGE_CONFIG
エントリーを削除します。 次のコマンドを入力して、
Quay
アプリケーション Pod を識別します。$ oc get pod -n <quay_namespace>
出力例
quay390usstorage-quay-app-5779ddc886-2drh2 quay390eustorage-quay-app-66969cd859-n2ssm
以下のコマンドを入力して、
usstorage
Pod でインタラクティブシェルセッションを開きます。$ oc rsh quay390usstorage-quay-app-5779ddc886-2drh2
次のコマンドを入力して、
eustorage
サイトを完全に削除します。重要次の操作は元に戻すことができません。注意して使用してください。
sh-4.4$ python -m util.removelocation eustorage
出力例
WARNING: This is a destructive operation. Are you sure you want to remove eustorage from your storage locations? [y/n] y Deleted placement 30 Deleted placement 31 Deleted placement 32 Deleted placement 33 Deleted location eustorage