Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

14.4. Red Hat Quay Operator を使用した Geo レプリケーション

Georeplication architecture

上記の例では、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 レプリケーションの設定
リンクのコピー

手順

  1. Quaypostgres インスタンスをデプロイします。

    1. データベースにログインします。

    2. Quay のデータベースを作成します。 

      CREATE DATABASE quay;

    3. データベース内で pg_trm 拡張機能を有効にします。 

      \c quay;
CREATE EXTENSION IF NOT EXISTS pg_trgm;

  2. Redis インスタンスをデプロイします。

    注記
    • クラウドプロバイダーに独自のサービスがある場合は、Redis インスタンスをデプロイする必要がない場合があります。
    • Builder を利用している場合は、Redis インスタンスをデプロイする必要があります。
    1. Redis 用の VM をデプロイします。
    2. Quay が実行されているクラスターからアクセスできることを確認してください。
    3. ポート 6379/TCP が開いている必要があります。

    4. インスタンス内で Redis を実行します。 

      sudo dnf install -y podman
podman run -d --name redis -p 6379:6379 redis

  3. クラスターごとに 1 つずつ、2 つのオブジェクトストレージバックエンドを作成します。

    理想的には、一方のオブジェクトストレージバケットは 1 番目のクラスター (プライマリー) の近くにあり、もう一方は 2 番目のクラスター (セカンダリー) の近くにあります。

  4. 環境変数のオーバーライドを使用して、同じ設定バンドルでクラスターをデプロイし、個々のクラスターに適切なストレージバックエンドを選択します。
  5. クラスターへの単一のエントリーポイントを提供するように、ロードバランサーを設定します。

14.4.1.1. 設定
リンクのコピー

config.yaml ファイルはクラスター間で共有され、一般的な PostgreSQL、Redis、およびストレージバックエンドの詳細が含まれます。

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 Operator を使用してデプロイされた Clair インスタンスの設定ファイルを取得するには、Retrieving the Clair config 参照してください。

configBundleSecret を作成します。 

$ oc create secret generic --from-file config.yaml=./config.yaml georep-config-bundle

各クラスターで、configBundleSecret を設定し、QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数のオーバーライドを使用して、そのクラスターに適切なストレージを設定します。

注記

両方のデプロイメント間の config.yaml ファイルは一致する必要があります。一方のクラスターに変更を加える場合は、もう一方のクラスターでも変更する必要があります。

米国のクラスター

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

+

注記

TLS は管理されておらず、ルートは管理されているため、設定ツールを使用するか、設定バンドルで直接証明書を提供する必要があります。詳細は、Configuring TLS and routes を参照してください。

ヨーロッパのクラスター

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

+

注記

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 レプリケーションの代わりにリポジトリーミラーリングを使用することが推奨されます。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る