5.2. Geo レプリケーションの要件と制約
- Geo レプリケーション設定では、Red Hat Quay で、すべてのリージョンが他の全リージョンのオブジェクトストレージに対して読み取りと書き込みができるようにする必要があります。オブジェクトストレージは、他のすべてのリージョンから地理的にアクセスできる必要があります。
- 1 つの Geo レプリケーションサイトでオブジェクトストレージシステムに障害が発生した場合に、そのサイトの Red Hat Quay デプロイメントをシャットダウンして、クライアントがグローバルロードバランサーにより、ストレージシステムで問題のない残りのサイトにリダイレクトされるようにする必要があります。そうしないと、クライアントでプルとプッシュの失敗が発生します。
- Red Hat Quay は、接続されたオブジェクトストレージシステムの健全性や可用性を内部的に認識しません。分散システムの健全性を監視し、ストレージのステータスに基づいてトラフィックを別のサイトにルーティングするには、ユーザーがグローバルロードバランサー (LB) を設定する必要があります。
-
Geo レプリケーションデプロイメントのステータスを確認するには、
/health/endtoendチェックポイントを使用する必要があります。このチェックポイントは全体的な健全性の監視に使用されます。/health/endtoendエンドポイントを使用してリダイレクトを手動で設定する必要があります。/health/instanceエンドポイントは、ローカルインスタンスの健全性のみをチェックします。 - 1 つのサイトのオブジェクトストレージシステムが利用できなくなった場合に、残りのサイトの残りのストレージシステム (複数可) に自動的にリダイレクトされません。
- Geo レプリケーションは非同期です。サイトが完全に失われると、そのサイトのオブジェクトストレージシステムに保存されていても、障害発生時に残りのサイトに複製されていないデータが失われます。
単一のデータベース、つまりすべてのメタデータと Red Hat Quay 設定がすべてのリージョンで共有されます。
Geo レプリケーションはデータベースをレプリケートしません。障害が発生すると、Geo レプリケーションが有効になっている Red Hat Quay は別のデータベースにフェイルオーバーしません。
- 1 つの Redis キャッシュは Red Hat Quay のセットアップ全体で共有され、すべての Red Hat Quay Pod からアクセスできる必要があります。
-
ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、
QUAY_DISTRIBUTED_STORAGE_PREFERENCE環境変数を使用して明示的に設定できます。 - Geo レプリケーションでは、各リージョンにオブジェクトストレージが必要です。ローカルストレージでは機能しません。
- 各リージョンは、ネットワークパスを必要とする各リージョン内のすべてのストレージエンジンにアクセスできる必要があります。
- また、ストレージプロキシーオプションを使用することもできます。
- ストレージバックエンド全体 (たとえば、すべての Blob) がレプリケートされます。対照的に、リポジトリーミラーリングはリポジトリーまたはイメージに限定できます。
- すべての Red Hat Quay インスタンスは、通常はロードバランサーを介して同じエントリーポイントを共有する必要があります。
- すべての Red Hat Quay インスタンスは、共通の設定ファイル内で定義されているため、スーパーユーザーの同じセットが含まれる必要があります。
geo レプリケーション環境では、Clair 設定を
unmanagedに設定できます。アンマネージド Clair データベースにより、Red Hat Quay オペレーターは、Operator の複数のインスタンスが同じデータベースと通信する必要がある地理的に複製された環境で作業できます。詳細は、Clair の詳細設定 を参照してください。Clair 設定を
managedのままにする場合は、Operator によってデプロイされた Clair インスタンスの設定ファイルを取得する必要があります。詳細は、OpenShift Container Platform での Clair デプロイメントの Clair 設定シークレットの取得とデコード を参照してください。- Geo レプリケーションには SSL/TLS 証明書とキーが必要です。詳細は、「Geo-Replication には SSL/TLS 証明書とキーが必要」を参照してください。詳細は、SSL/TLS 証明書を使用した概念実証のデプロイメント を参照してください。
上記の要件を満たすことができない場合は、代わりに 2 つ以上の異なる Red Hat Quay のデプロイメントを使用し、リポジトリーミラーリング機能を利用する必要があります。
5.2.1. OpenShift Container Platform での Geo レプリケーションのセットアップ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform で Geo レプリケーションを設定するには、次の手順を実行します。
手順
- Red Hat Quay の postgres インスタンスをデプロイします。
次のコマンドを入力してデータベースにログインします。
psql -U <username> -h <hostname> -p <port> -d <database_name>
psql -U <username> -h <hostname> -p <port> -d <database_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow quayという名前で Red Hat 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 をデプロイします。
- Red Hat 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 redisCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- クラスターごとに 1 つずつ、2 つのオブジェクトストレージバックエンドを作成します。1 つのオブジェクトストレージバケットが最初のクラスター (プライマリークラスター) の近くにあり、もう 1 つが 2 番目のクラスター (セカンダリークラスター) の近くにあると理想的です。
- 環境変数のオーバーライドを使用して、同じ設定バンドルでクラスターをデプロイし、個々のクラスターに適切なストレージバックエンドを選択します。
- クラスターへの単一のエントリーポイントを提供するように、ロードバランサーを設定します。
5.2.1.1. Red Hat Quay on OpenShift Container Platform での geo レプリケーションの設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Quay on OpenShift Container Platform の geo レプリケーションを設定するには、次の手順を使用します。
手順
クラスター間で共有される
config.yamlファイルを作成します。このconfig.yamlファイルには、一般的な PostgreSQL、Redis、ストレージバックエンドの詳細が含まれています。Geo レプリケーションの
config.yamlファイルCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ルートには適切な
SERVER_HOSTNAMEを使用する必要があり、グローバルロードバランサーのホスト名と一致する必要があります。
次のコマンドを入力して、
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-bundleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 各クラスターで、
configBundleSecretを設定し、QUAY_DISTRIBUTED_STORAGE_PREFERENCE環境変数のオーバーライドを使用して、そのクラスターに適切なストレージを設定します。以下に例を示します。注記両方のデプロイメント間の
config.yamlファイルは一致する必要があります。一方のクラスターに変更を加える場合は、もう一方のクラスターでも変更する必要があります。US クラスター
QuayRegistryの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SSL/TLS が管理対象であり、ルートが管理対象外であるため、証明書を設定バンドルで直接指定する必要があります。詳細は、SSL/TLS とルートの設定 を参照してください。
ヨーロッパのクラスター
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SSL/TLS が管理対象であり、ルートが管理対象外であるため、証明書を設定バンドルで直接指定する必要があります。詳細は、SSL/TLS とルートの設定 を参照してください。
5.2.2. Geo レプリケーションのための複合ストレージ リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Quay の Geo レプリケーションは、異なる複数のレプリケーションターゲットの使用をサポートしています。たとえば、パブリッククラウドの AWS S3 ストレージとオンプレミスの Ceph ストレージを使用します。これは、すべての Red Hat Quay Pod とクラスターノードからすべてのストレージバックエンドへのアクセスを許可するという重要な要件を複雑にします。そのため、以下を使用することを推奨します。
- 内部ストレージの可視性を防ぐための VPN、または
- Red Hat Quay が使用する特定のバケットへのアクセスのみを許可するトークンペア
これにより、Red Hat Quay のパブリッククラウドインスタンスがオンプレミスのストレージにアクセスできるようになりますが、ネットワークは暗号化され、保護され、ACL を使用するため、セキュリティー要件が満たされます。
これらのセキュリティー対策を実施できない場合は、2 つの異なる Red Hat Quay レジストリーをデプロイし、Geo レプリケーションの代わりにリポジトリーミラーリングを使用することが推奨されます。