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 での Geo レプリケーションの設定 リンクのコピーリンクがクリップボードにコピーされました!
手順
Quaypostgres インスタンスをデプロイします。
- データベースにログインします。
Quay のデータベースを作成します。
CREATE DATABASE quay;
CREATE DATABASE quay;
Copy to Clipboard Copied! Toggle word wrap Toggle overflow データベース内で pg_trm 拡張機能を有効にします。
\c quay; CREATE EXTENSION IF NOT EXISTS pg_trgm;
\c quay; CREATE EXTENSION IF NOT EXISTS pg_trgm;
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Redis インスタンスをデプロイします。
注記- クラウドプロバイダーに独自のサービスがある場合は、Redis インスタンスをデプロイする必要がない場合があります。
- Builder を利用している場合は、Redis インスタンスをデプロイする必要があります。
- Redis 用の VM をデプロイします。
- Quay が実行されているクラスターからアクセスできることを確認してください。
- ポート 6379/TCP が開いている必要があります。
インスタンス内で Redis を実行します。
sudo dnf install -y podman podman run -d --name redis -p 6379:6379 redis
sudo dnf install -y podman podman run -d --name redis -p 6379:6379 redis
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスターごとに 1 つずつ、2 つのオブジェクトストレージバックエンドを作成します。
理想的には、一方のオブジェクトストレージバケットは 1 番目のクラスター (プライマリー) の近くにあり、もう一方は 2 番目のクラスター (セカンダリー) の近くにあります。
- 環境変数のオーバーライドを使用して、同じ設定バンドルでクラスターをデプロイし、個々のクラスターに適切なストレージバックエンドを選択します。
- クラスターへの単一のエントリーポイントを提供するように、ロードバランサーを設定します。
14.4.1.1. 設定 リンクのコピーリンクがクリップボードにコピーされました!
config.yaml
ファイルはクラスター間で共有され、一般的な PostgreSQL、Redis、およびストレージバックエンドの詳細が含まれます。
config.yaml
- 1
- ルートには適切な
SERVER_HOSTNAME
を使用する必要があり、グローバルロードバランサーのホスト名と一致する必要があります。 - 2
- OpenShift Operator を使用してデプロイされた Clair インスタンスの設定ファイルを取得するには、Retrieving the Clair config 参照してください。
configBundleSecret
を作成します。
oc create secret generic --from-file config.yaml=./config.yaml georep-config-bundle
$ oc create secret generic --from-file config.yaml=./config.yaml georep-config-bundle
各クラスターで、configBundleSecret
を設定し、QUAY_DISTRIBUTED_STORAGE_PREFERENCE
環境変数のオーバーライドを使用して、そのクラスターに適切なストレージを設定します。
両方のデプロイメント間の config.yaml
ファイルは一致する必要があります。一方のクラスターに変更を加える場合は、もう一方のクラスターでも変更する必要があります。
米国のクラスター
+
TLS は管理されておらず、ルートは管理されているため、設定ツールを使用するか、設定バンドルで直接証明書を提供する必要があります。詳細は、Configuring TLS and routes を参照してください。
ヨーロッパのクラスター
+
TLS は管理されておらず、ルートは管理されているため、設定ツールを使用するか、設定バンドルで直接証明書を提供する必要があります。詳細は、Configuring TLS and routes を参照してください。
14.4.2. Geo レプリケーションのための複合ストレージ リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Quay の Geo レプリケーションは、異なる複数のレプリケーションターゲットの使用をサポートしています。たとえば、パブリッククラウドの AWS S3 ストレージとオンプレミスの Ceph ストレージを使用する、などです。これは、すべての Red Hat Quay Pod とクラスターノードからすべてのストレージバックエンドへのアクセスを許可するという重要な要件を複雑にします。その結果、以下が推奨されています。
- VPN を使用して、内部ストレージの可視化を防ぐ。または
- Quay が使用する指定のバケットへのアクセスのみを許可するトークンペアを使用する。
これにより、Red Hat Quay のパブリッククラウドインスタンスはオンプレミスのストレージにアクセスできるようになりますが、ネットワークは暗号化され、保護され、ACL を使用することで、セキュリティー要件を満たすことができます。
これらのセキュリティー対策を実施できない場合は、2 つの異なる Red Hat Quay レジストリーをデプロイし、Geo レプリケーションの代わりにリポジトリーミラーリングを使用することが推奨されます。