Red Hat Quay の設定


Red Hat Quay 3.14

設定オプションを使用した Red Hat Quay のカスタマイズ

Red Hat OpenShift Documentation Team

概要

Red Hat Quay の設定

第1章 Red Hat Quay 設定の開始

Red Hat Quay は、セルフマネージドインストールとして、または OpenShift Container Platform Operator の Red Hat Quay でデプロイできるセキュアなアーティファクトレジストリーです。デプロイメントタイプによって設定や管理には異なるアプローチがありますが、それぞれは同じ設定パラメーターセットに依存してレジストリーの動作を制御します。一般的な設定パラメーターを使用すると、管理者はレジストリーがユーザー、ストレージバックエンド、認証プロバイダー、セキュリティーポリシー、およびその他の統合サービスと対話する方法を定義できます。

デプロイメントタイプに応じて Red Hat Quay を設定するには、次の 2 つの方法があります。

  • 事前に Red Hat Quay の場合:Red Hat Quay の前に、レジストリー管理者は、必要なすべてのパラメーターを含む config.yaml ファイルを提供します。このデプロイメントタイプでは、有効な設定がないとレジストリーを起動することができません。
  • Red Hat Quay Operator: デフォルトでは、Red Hat Quay Operator は、最低限必要な値を生成し、必要なコンポーネントをデプロイして Red Hat Quay デプロイメントを自動的に設定します。初回のデプロイメント後に、QuayRegistry カスタムリソースを変更するか、OpenShift Container Platform Web コンソール を使用してレジストリーの動作をカスタマイズできます。

本ガイドでは、以下の設定の概念の概要を説明します。

  • prem および Operator ベースの Red Hat Quay デプロイメントタイプの両方に対して現在の設定を取得、検査、および変更する方法。
  • 起動に最低限必要な設定フィールド。
  • 利用可能なすべての Red Hat Quay 設定フィールドと、これらのフィールドの YAML サンプルの概要。

第2章 Red Hat Quay 設定の免責事項

一部の機能と設定パラメーターは、Red Hat Quay のスタンドアロンデプロイメントでも Operator ベースのデプロイメントでも、積極的には使用または実装されていません。そのため、特定の機能を有効または無効にするフラグや、Red Hat サポートのドキュメントが明示的に文書化またはサポートされていない設定パラメーターなど、一部の機能フラグは注意して変更する必要があります。

未使用または文書化されていない機能は、Red Hat Quay と完全にテスト、サポートされていない、または互換性がない可能性があります。これらの設定を変更すると、予期しない動作が発生したり、デプロイメントが中断される可能性があります。

第3章 Red Hat Quay 設定ファイルについて

Red Hat Quay on OpenShift Container Platform Operator によってデプロイされたオンプレミスに関わらず、レジストリーの動作は config.yaml ファイルによって定義されます。レジストリーを起動するには、config.yaml ファイルに必要なすべての設定フィールドを含める必要があります。Red Hat Quay 管理者は、認証パラメーター、ストレージパラメーター、プロキシーキャッシュパラメーターなどのレジストリーをカスタマイズするオプションのパラメーターを定義することもできます。

config.yaml ファイルは有効な YAML (YAML Ain't Markup Language)構文を使用して記述する必要があります。また、ファイル自体にフォーマットエラーが含まれる場合、または必須フィールドがない場合は Red Hat Quay を起動できません。デプロイメントタイプに関係なく、Operator によって設定されている OpenShift Container Platform 上のオンプレミスまたは Red Hat Quay であるかに関係なく、YAML の原則は、必要な設定フィールドが若干異なる場合でも同じままになります。

次のセクションでは、Red Hat Quay config.yaml ファイルの作成および編集に関連する基本的な YAML 構文の概要を説明します。YAML の詳細な概要は、What is YAML を参照してください。

3.1. キーと値のペア。

config.yaml ファイル内の設定フィールドは、以下の形式でキーと値のペアとして記述されます。

# ... 
1

EXAMPLE_FIELD_NAME: <value>
# ... 
2
Copy to Clipboard
1 2
この特定のフィールドの前後にフィールドがあることを示します。# またはハッシュ記号を指定することで、コメントを YAML ファイル内に提供できることに注意してください。

config.yaml ファイル内の各行には、フィールド名、次にコロン、スペース、キーと一致する適切な値が含まれます。以下の例は、AUTHENTICATION_TYPE 設定フィールドを config.yaml ファイルでフォーマットする必要がある方法を示しています。

AUTHENTICATION_TYPE: Database 
1

# ...
Copy to Clipboard
1
クレデンシャル認証に使用する認証エンジン。

上記の例では、AUTHENTICATION_TYPEDatabase に設定されていますが、デプロイメントタイプごとに異なる値が必要になります。以下の例は、LDAP または Lightweight Directory Access Protocol が認証に使用される場合に config.yaml ファイルがどのようになるかを示しています。

AUTHENTICATION_TYPE: LDAP
# ...
Copy to Clipboard

3.2. インデントとネスト

多くの Red Hat Quay 設定フィールドでは、ネストされた構造を示すためにインデントが必要です。インデントは、空白またはリテラル 空白 文字を使用して行う必要があります。タブ文字は、設計的には使用できません。インデントは、ファイル全体で一貫している必要があります。以下の YAML スニペットは、BUILDLOGS_REDIS フィールドが必要な ホストパスワード、 および ポート フィールドにインデントを使用する方法を示しています。

# ...
BUILDLOGS_REDIS:
    host: quay-server.example.com
    password: example-password
    port: 6379
# ...
Copy to Clipboard

3.3. リスト

場合によっては、Red Hat Quay 設定フィールドはリストに依存して特定の値を定義します。リストは、ハイフン(-)とそれに続くスペースを使用してフォーマットされます。次の例は、SUPER_USERS 設定フィールドがリストを使用してスーパーユーザーを定義する方法を示しています。

# ...
SUPER_USERS:
- quayadmin
# ...
Copy to Clipboard

3.4. 引用符で囲まれた値

一部の Red Hat Quay 設定フィールドでは、変数を適切に定義するために引用符("")を使用する必要があります。通常、これは必須ではありません。次の例は、FOOTER_LINKS 設定フィールドで引用符を使用して TERMS_OF_SERVICE_URLPRIVACY_POLICY_URLSECURITY_URL、および ABOUT_URL を定義する方法を示しています。

FOOTER_LINKS:
  "TERMS_OF_SERVICE_URL": "https://www.index.hr"
  "PRIVACY_POLICY_URL": "https://www.jutarnji.hr"
  "SECURITY_URL": "https://www.bug.hr"
  "ABOUT_URL": "https://www.zagreb.hr"
Copy to Clipboard

3.5. コメント

ハッシュ記号または # は、コメントを追加したり、設定フィールドを一時的に無効にするために行頭に配置できます。これらは設定パーサーで無視され、レジストリーの動作には影響しません。以下に例を示します。

# ...
# FEATURE_UI_V2: true
# ...
Copy to Clipboard

この例では、FEATURE_UI_V2 設定がパーサーによって無視され、v2 UI を使用するオプションが無効になります。必要な設定フィールドに # 記号を使用すると、レジストリーが起動しなくなります。

第4章 事前に設定されている Red Hat Quay 設定の概要

Red Hat Quay のオンプレミスデプロイメントの場合、管理者が管理する config.yaml ファイルは起動時にコンテナーにマウントされ、初期化中に Red Hat Quay によって読み取られます。config.yaml ファイルは動的にリロードされません。つまり、ファイルに変更を加えるには、レジストリーコンテナーを再起動する必要があります。

本章では、以下の概念の概要を説明します。

  • 最低限必要な設定フィールド。
  • デプロイメント後に設定を編集および管理する方法。

このセクションは、特にオンプレミスの Red Hat Quay デプロイメントタイプに適用されます。OpenShift Container Platform での Red Hat Quay の設定は、Red Hat Quay on OpenShift Container Platform 設定の概要 を参照してください。

4.1. 必須の設定フィールド

Red Hat Quay のオンプレミスデプロイメントには、以下の設定フィールドが必要です。

フィールド

説明

AUTHENTICATION_TYPE
(必須)

String

認証情報の認証に使用する認証エンジン。

値:
DatabaseLDAPJWTKeystoneOIDC のいずれか。

デフォルト: Database

BUILDLOGS_REDIS
(必須)

Object

ビルドログキャッシュ用の Redis 接続の詳細。

.host
(必須)

String

Redis にアクセスできるホスト名。

.password

String

Redis インスタンスに接続するためのパスワード。

DATABASE_SECRET_KEY
(必須)

String

データベース内で機密フィールドを暗号化するのに使用されるキー。この値は、一度設定したら変更しないでください。変更すると、リポジトリーのミラーユーザー名やパスワード設定など、すべての信頼できるフィールドが無効になります。
この値は、Operator ベースのデプロイメントの場合、Red Hat Quay Operator によって自動的に設定されます。スタンドアロンデプロイメントの場合、管理者は Open SSL または同様のツールを使用して独自のキーを提供できます。キーの長さが 63 文字を超えないようにしてください。

DB_URI
(必須)

String

認証情報を含む、データベースにアクセスするための URI。

DISTRIBUTED_STORAGE_CONFIG
(必須)

Object

Red Hat Quay で使用するストレージエンジンの設定。各キーは、ストレージエンジンの一意の ID を表します。この値は、ストレージエンジンパラメーターを記述するオブジェクトのタプル (キー、値) で構成されます。

デフォルト: []

SECRET_KEY
(必須)

String

ユーザーセッションを正しく解釈するために必要なセッション Cookie と CSRF トークンを暗号化するために使用されるキー。設定時に値を変更しないでください。すべての Red Hat Quay インスタンスで永続的である必要があります。すべてのインスタンスで永続的でない場合、ログインの失敗やセッションの永続性に関連するその他のエラーが発生する可能性があります。

SERVER_HOSTNAME
(必須)

String

スキームなしで Red Hat Quay にアクセスできる URL。

SETUP_COMPLETE
(必須)

Boolean

これは、以前のバージョンのソフトウェアからそのまま残っているアーティファクトです。現時点では値を true に指定する 必要があります

USER_EVENTS_REDIS
(必須)

Object

ユーザーイベント処理の Redis 接続の詳細。

.host
(必須)

String

Redis にアクセスできるホスト名。

.port
(必須)

数値

Redis にアクセスできるポート。

.password

String

Redis インスタンスに接続するためのパスワード。

4.1.1. 最小設定ファイルの例

このセクションでは、最小設定ファイルの例を 2 つ示します。1 つはローカルストレージを使用する例で、もう 1 つは Google Cloud Platform でクラウドベースのストレージを使用する別の例です。

4.1.1.1. ローカルストレージを使用した最小設定

次の例は、イメージにローカルストレージを使用する最小限の設定ファイルの例を示しています。

重要

概念実証のためにレジストリーをデプロイする場合は、ローカルストレージのみを使用してください。これは実稼働環境での使用を目的としていません。ローカルストレージを使用する場合は、レジストリーの起動時に、レジストリーをコンテナー内の datastorage パスにマップする必要があります。詳細は、概念実証 - Red Hat Quay のデプロイ を参照してください。

ローカルストレージの最小設定

AUTHENTICATION_TYPE: Database
BUILDLOGS_REDIS:
    host: <quay-server.example.com>
    password: <password>
    port: <port>
DATABASE_SECRET_KEY: <example_database_secret_key>
DB_URI: postgresql://<username>:<password>@<registry_url>.com:<port>/quay
DISTRIBUTED_STORAGE_CONFIG:
  default:
    - LocalStorage
    - storage_path: /datastorage/registry
SECRET_KEY: <example_secret_key>
SERVER_HOSTNAME: <server_host_name>
SETUP_COMPLETE: true
USER_EVENTS_REDIS:
  host: <redis_events_url>
  password: <password>
  port: <port>
Copy to Clipboard

4.1.1.2. クラウドベースのストレージを使用した最小設定

ほとんどの実稼働環境では、Red Hat Quay 管理者は、サポートされるベンダーが提供するクラウドまたはエンタープライズレベルのストレージバックエンドを使用します。次の例は、イメージストレージに Google Cloud Platform を使用するように Red Hat Quay を設定する方法を示しています。サポート対象のストレージプロバイダーの完全なリストは、イメージストレージ を参照 てください。

注記

クラウドまたはエンタープライズレベルのストレージバックエンドを使用する場合、レジストリーをローカルディレクトリーにマッピングするなどの追加設定は必要ありません。

クラウドストレージの最小設定

AUTHENTICATION_TYPE: Database
BUILDLOGS_REDIS:
    host: <quay-server.example.com>
    password: <password>
    port: <port>
DATABASE_SECRET_KEY: <example_database_secret_key>
DB_URI: postgresql://<username>:<password>@<registry_url>.com:<port>/quay
DISTRIBUTED_STORAGE_CONFIG:
    default:
        - GoogleCloudStorage
        - access_key: <access_key>
          bucket_name: <bucket_name>
          secret_key: <secret_key>
          storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
SECRET_KEY: <example_secret_key>
SERVER_HOSTNAME: <server_host_name>
SETUP_COMPLETE: true
USER_EVENTS_REDIS:
  host: <redis_events_url>
  password: <password>
  port: <port>
Copy to Clipboard

4.2. デプロイメント後の設定ファイルの変更

初期 config.yaml ファイルを使用して Red Hat Quay レジストリーをデプロイした後、Red Hat Quay 管理者は設定ファイルを更新して、必要に応じて機能を有効または無効にすることができます。このような柔軟性により、管理者はレジストリーを調整して、特定の環境のニーズに合わせてしたり、特定のセキュリティーポリシーを満たしたりできます。

注記

config.yaml ファイルは動的に再読み込みされないため、Red Hat Quay コンテナーを再起動してから再起動する必要があります。

以下の手順では、quay-registry コンテナーから config.yaml ファイルを取得する方法、その機能の設定フィールドをファイルに追加することで新機能を有効にする方法、Podman を使用して quay-registry コンテナーを再起動する方法を紹介します。

前提条件

  • Red Hat Quay をデプロイしている。
  • レジストリーの管理者である。

手順

  1. config.yaml ファイルにアクセスできる場合:

    1. config.yaml ファイルを保存するディレクトリーに移動します。以下に例を示します。

      $ cd /home/<username>/<quay-deployment-directory>/config
      Copy to Clipboard
    2. 新しい機能フラグを追加して config.yaml ファイルに変更を加えます。以下の例では、v2 UI を有効にします。

      # ...
      FEATURE_UI_V2: true
      # ...
      Copy to Clipboard
    3. config.yaml ファイルへの変更を保存します。
    4. 次のコマンドを入力して、quay-registry Pod を再起動します。

      $ podman restart <container_id>
      Copy to Clipboard
  2. config.yaml ファイルへのアクセスがなく、同じ認証情報を維持しながら新規ファイルを作成する必要がある場合:

    1. 次のコマンドを入力して、quay-registry Pod のコンテナー ID を取得します。

      $ podman ps
      Copy to Clipboard

      出力例

      CONTAINER ID  IMAGE                                                                     COMMAND         CREATED       STATUS       PORTS                                                                       NAMES
      5f2297ef53ff  registry.redhat.io/rhel8/postgresql-13:1-109                              run-postgresql  20 hours ago  Up 20 hours  0.0.0.0:5432->5432/tcp                                                      postgresql-quay
      3b40fb83bead  registry.redhat.io/rhel8/redis-5:1                                        run-redis       20 hours ago  Up 20 hours  0.0.0.0:6379->6379/tcp                                                      redis
      0b4b8fbfca6d  registry-proxy.engineering.redhat.com/rh-osbs/quay-quay-rhel8:v3.14.0-14  registry        20 hours ago  Up 20 hours  0.0.0.0:80->8080/tcp, 0.0.0.0:443->8443/tcp, 7443/tcp, 9091/tcp, 55443/tcp  quay
      Copy to Clipboard

    2. 次のコマンドを入力して、config.yaml ファイルを quay-registry Pod からディレクトリーにコピーします。

      $ podman cp <container_id>:/quay-registry/conf/stack/config.yaml ./config.yaml
      Copy to Clipboard
    3. 新しい機能フラグを追加して config.yaml ファイルに変更を加えます。以下の例では、AUTHENTICATION_TYPELDAPに設定します。

      # ...
      AUTHENTICATION_TYPE: LDAP
      # ...
      Copy to Clipboard
    4. 次のコマンドを入力して、レジストリーを再デプロイし、config.yaml ファイルを quay-registry 設定ボリュームにマウントします。

      $ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
         --name=quay \
         -v /home/<username>/<quay-deployment-directory>/config:/conf/stack:Z \
         registry.redhat.io/quay/quay-rhel8:v3.14.0
      Copy to Clipboard

4.3. 設定のトラブルシューティング

すべての必要な設定フィールドを追加したり、一部のパラメーターに適切な情報を提供したりしないと、quay-registry コンテナーのデプロイに失敗する場合があります。以下の手順に従って、失敗したオンプレミスのデプロイメントタイプを表示し、トラブルシューティングします。

前提条件

  • 最小限の設定ファイルを作成している。

手順

  • 次のコマンドを入力して、quay-registry コンテナーのデプロイを試みます。このコマンドは、デバッグ情報を表示する -it を使用することに注意してください。

    $ podman run -it --rm -p 80:8080 -p 443:8443 --name=quay -v /home/<username>/<quay-deployment-directory>/config:/conf/stack:Z    -v /home/<username>/<quay-deployment-directory>/storage:/datastorage:Z 33f1c3dc86be
    Copy to Clipboard

    出力例

    ---
    +------------------------+-------+--------+
    | LDAP                   | -     | X      |
    +------------------------+-------+--------+
    | LDAP_ADMIN_DN is required      | X      |
    +-----------------------------------------+
    | LDAP_ADMIN_PSSWD is required   | X      |
    +-----------------------------------------+
    | . . . Connection refused       | X      |
    +-----------------------------------------+
    ---
    Copy to Clipboard

    この例では、quay-registry コンテナーは不適切な LDAP 認証情報が指定されたためにデプロイできませんでした。

第5章 OpenShift Container Platform 上の Red Hat Quay 設定の概要

Operator を使用して Red Hat Quay を OpenShift Container Platform にデプロイする場合、設定は QuayRegistry カスタムリソース(CR)を使用して宣言的に管理されます。このモデルを使用すると、クラスター管理者は、有効なコンポーネント、ストレージバックエンド、SSL/TLS 設定、他のコア機能など、必要な Red Hat Quay デプロイメントの必要な状態を定義できます。

Operator を使用して OpenShift Container Platform に Red Hat Quay をデプロイした後に、管理者は config.yaml ファイルを更新し、Kubernetes シークレットで参照することで、レジストリーをさらにカスタマイズできます。この設定バンドルは、configBundleSecret フィールドを使用して QuayRegistry CR にリンクされます。

Operator は、QuayRegistry CR およびその関連設定で定義される状態を調整し、必要に応じてレジストリーコンポーネントを自動的にデプロイまたは更新します。

このガイドでは、QuayRegistry CR の背後にある基本的な概念と、OpenShift Container Platform デプロイメントの Red Hat Quay での config.yaml ファイルの変更について説明します。QuayRegistry CR 内で管理対象外コンポーネントを使用するなどの高度なトピックは、Red Hat Quay Operator の OpenShift Container Platform へのデプロイ を参照してください。

5.1. QuayRegistry CR について

デフォルトでは、QuayRegistry CR には以下のキーフィールドが含まれます。

  • configBundleSecret: 追加の設定パラメーターを定義する config.yaml ファイルを含む Kubernetes シークレットの名前。
  • Name: Red Hat Quay レジストリーの名前。
  • namespace: レジストリーが作成された namespace またはプロジェクト。
  • spec.components: Operator が自動的に管理するコンポーネントの一覧。それぞれの spec.component フィールドには 2 つのフィールドが含まれます。

    • Name: コンポーネントの名前。
    • Managed: コンポーネントのライフサイクルが Red Hat Quay Operator によって処理されるかどうかに対応するブール値。managed: trueQuayRegistry CR のコンポーネントに設定すると、Operator がコンポーネントを管理します。

すべての QuayRegistry コンポーネントは、特に指定されていない限り、調整時に自動的に管理され、自動入力されます。以下のセクションでは、主要な QuayRegistry コンポーネントを説明し、デフォルト設定を示す YAML ファイルのサンプルを提供します。

5.2. 管理対象コンポーネント

デフォルトで、Operator は Red Hat Quay の管理コンポーネントに必要なすべての必要な設定およびインストールを処理します。

Red Hat Quay Operator が実行するデプロイが環境に適さない場合は、Red Hat Quay Operator に unmanaged リソース (オーバーライド) を指定できます。これは、次のセクションで説明します。

表5.1 QuayRegistry 必須フィールド
フィールド説明

quay

Boolean

環境変数やレプリカの数など、OpenShift Container Platform で Red Hat Quay のデプロイメントのオーバーライドを保持します。このコンポーネントは、管理対象外(managed: false)に設定することはできません。

postgres

Boolean

レジストリーメタデータの保存に使用されます。現在、PostgreSQL バージョン 13 が使用されています。

clair

Boolean

clair: イメージの脆弱性スキャンを提供します。

redis

Boolean

ストレージライブビルダーログ、およびガベージコレクションに必要なロックメカニズム。

HorizontalPodAutoscaler

Boolean

メモリーおよび CPU の消費に応じて quay Pod の数を調整します。

ObjectStorage

Boolean

イメージレイヤー Blob を格納します。managed: true に設定すると、NooBaa または Red Hat OpenShift Data Foundation によって提供される ObjectBucketClaim Kubernetes API を使用します。このフィールドを managed: false に設定するには、独自のオブジェクトストレージを指定する必要があります。

route

Boolean

route: OpenShift Container Platform の外部から Red Hat Quay レジストリーへの外部エントリーポイントを提供します。

mirror

Boolean

mirror: オプションのリポジトリーミラーリングをサポートするようにリポジトリーミラーワーカーを設定します。

monitoring

Boolean

monitoring: Grafana ダッシュボード、個々のメトリクスへのアクセス、Quay Pod の頻繁な再起動に関する通知などの機能があります。

tls

Boolean

SSL/TLS を自動的に処理するかどうかを設定します。

clairpostgres

Boolean

マネージド Clair データベースを設定します。これは、Red Hat Quay のデプロイに使用される PostgreSQL データベースとは別のデータベースです。

次の例は、Red Hat Quay Operator が提供する QuayRegistry カスタムリソースのデフォルト設定を示しています。これは OpenShift Container Platform Web コンソールで利用できます。

QuayRegistry カスタムリソースの例

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: <example_registry>
  namespace: <namespace>
  spec:
    configBundleSecret: config-bundle-secret
    components:
    - kind: quay
      managed: true
    - kind: postgres
      managed: true
    - kind: clair
      managed: true
    - kind: redis
      managed: true
    - kind: horizontalpodautoscaler
      managed: true
    - kind: objectstorage
      managed: true
    - kind: route
      managed: true
    - kind: mirror
      managed: true
    - kind: monitoring
      managed: true
    - kind: tls
      managed: true
    - kind: clairpostgres
      managed: true
Copy to Clipboard

5.3. デプロイメント後の QuayRegistry CR の変更

Red Hat Quay Operator をインストールして初期デプロイメントを作成した後、QuayRegistry カスタムリソース(CR)を変更して Red Hat Quay 環境の要素をカスタマイズまたは再設定できます。

Red Hat Quay 管理者は、次の理由により QuayRegistry CR を変更する場合があります。

  • 独自のインフラストラクチャーを使用 するには、コンポーネント管理: コンポーネントを managed: true から managed: false に切り替えます。たとえば、kind: objectstorage を unmanaged に設定して、Google Cloud Storage や Nutanix などの外部オブジェクトストレージプラットフォームを統合することができます。
  • カスタム設定を適用する: configBundleSecret を更新または置き換えて、認証プロバイダー、外部の SSL/TLS 設定、機能フラグなどの新しい設定を適用します。
  • 機能を有効または無効 にする: spec.components リストを変更して、リポジトリーのミラーリング、Clair スキャン、水平 Pod 自動スケーリングなどの機能を切り替えます。
  • デプロイメントをスケーリングするに は、Quay アプリケーションの環境変数またはレプリカ数を調整します。
  • 外部サービスと統合する:外部 PostgreSQL、Redis、または Clair データベースの設定を提供し、エンドポイントまたは認証情報を更新します。

5.3.1. OpenShift Container Platform Web コンソールを使用した QuayRegistry CR の変更

QuayRegistry は、OpenShift Container Platform Web コンソールを使用して変更できます。これにより、マネージドコンポーネントを管理対象外(managed: false)に設定し、独自のインフラストラクチャーを使用できます。

前提条件

  • admin 権限を持つユーザーとして OpenShift Container Platform にログインしている。
  • Red Hat Quay Operator をインストールしている。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators をクリックします。
  2. Red Hat Quay をクリックします。
  3. Quay Registry をクリックします。
  4. Red Hat Quay レジストリーの名前をクリックします(例: example-registry )。
  5. YAML をクリックします。
  6. 目的のコンポーネントの マネージド フィールドを true または false に調整します。
  7. Save をクリックします。

    注記

    コンポーネントを管理対象外(managed: false)に設定すると、追加の設定が必要になる場合があります。QuayRegistry CR で管理対象外コンポーネントを設定する方法は、依存関係への管理対象外コンポーネントの使用 を 参照してください。

5.3.2. CLI を使用した QuayRegistry CR の変更

QuayRegistry CR は CLI を使用して変更できます。これにより、マネージドコンポーネントを管理対象外(managed: false)に設定し、独自のインフラストラクチャーを使用できます。

前提条件

  • cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている。

手順

  1. 次のコマンドを入力して、QuayRegistry CR を編集します。

    $ oc edit quayregistry <registry_name> -n <namespace>
    Copy to Clipboard
  2. QuayRegistry CR に必要な変更を加えます。

    注記

    コンポーネントを管理対象外(managed: false)に設定すると、追加の設定が必要になる場合があります。QuayRegistry CR で管理対象外コンポーネントを設定する方法は、依存関係への管理対象外コンポーネントの使用 を 参照してください。

  3. 変更を保存します。

5.3.3. configBundleSecret について

spec.configBundleSecret フィールドは、QuayRegistry リソースと同じ namespace にある Secret の metadata.name への参照です。この Secret には config.yaml のキー/値のペアが含まれる必要があります。この値は Red Hat Quay 設定ファイルです。

configBundleSecret は、config.yaml ファイルを保存します。Red Hat Quay 管理者は、config.yaml ファイルを使用して以下の設定を定義できます。

  • 認証バックエンド(OIDC、LDAP など)
  • 外部 TLS ターミネーションの設定
  • リポジトリー作成ポリシー
  • 機能フラグ
  • 通知設定

Red Hat Quay は、次の理由でこのシークレットを更新する場合があります。

  • 新しい認証方法を有効にする
  • カスタム SSL/TLS 証明書 UI
  • 機能の有効化
  • セキュリティースキャン設定の変更

このフィールドを省略すると、Red Hat Quay Operator はデフォルト値と管理コンポーネント設定に基づいて設定シークレットを自動的に生成します。フィールドを指定すると、config.yaml の内容は基本設定として使用され、マネージドコンポーネントの値にマージされ、quay アプリケーション Pod にマウントされる最終的な設定を形成します。

QuayRegistry CR の設定方法によって、OpenShift Container Platform の Red Hat Quay の configBundleSecrets にどのフィールドを含める必要があるかが決まります。次の例は、すべてのコンポーネントが Operator によって管理されている場合のデフォルトの config.yaml ファイルを示しています。この例は、コンポーネントが管理対象か管理対象外か(managed: false)によって異なることに注意してください。

Operator によって管理されるすべてのコンポーネントを含む YAML の例

ALLOW_PULLS_WITHOUT_STRICT_LOGGING: false
AUTHENTICATION_TYPE: Database
DEFAULT_TAG_EXPIRATION: 2w
ENTERPRISE_LOGO_URL: /static/img/RH_Logo_Quay_Black_UX-horizontal.svg
FEATURE_BUILD_SUPPORT: false
FEATURE_DIRECT_LOGIN: true
FEATURE_MAILING: false
REGISTRY_TITLE: Red Hat Quay
REGISTRY_TITLE_SHORT: Red Hat Quay
SETUP_COMPLETE: true
TAG_EXPIRATION_OPTIONS:
- 2w
TEAM_RESYNC_STALE_TIME: 60m
TESTING: false
Copy to Clipboard

場合によっては、オブジェクトストレージなど、特定のコンポーネントを独自に管理することもできます。このシナリオでは、QuayRegistry CR を次のように変更します。

管理対象外のオブジェクトストレージコンポーネント

# ...
    - kind: objectstorage
      managed: false
# ...
Copy to Clipboard

独自のコンポーネントを管理する場合は、そのコンポーネントに必要な情報またはリソースを含めるようにデプロイメントを設定する必要があります。たとえば、objectstorage コンポーネントが managed: false に設定されている場合は、config.yaml ファイル内にストレージプロバイダーに応じて関連情報が含まれます。次の例は、Google Cloud Storage を使用した分散ストレージ設定を示しています。

objectstorage が管理対象外の場合に必要な情報

# ...
DISTRIBUTED_STORAGE_CONFIG:
    default:
        - GoogleCloudStorage
        - access_key: <access_key>
          bucket_name: <bucket_name>
          secret_key: <secret_key>
          storage_path: /datastorage/registry
# ...
Copy to Clipboard

同様に、Horizontalpodautoscaler コンポーネントを管理する場合は、付随する HorizontalPodAutoscaler カスタムリソース を作成する必要があります。

5.3.3.1. OpenShift Container Platform Web コンソールを使用した設定ファイルの変更

以下の手順を使用して、OpenShift Container Platform Web コンソールを使用して configBundleSecret によって保存される config.yaml ファイルを変更します。

前提条件

  • cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorInstalled OperatorQuay Registry をクリックします。
  2. Quay Registry をクリックします。
  3. Red Hat Quay レジストリーの名前をクリックします(例: example-registry )。
  4. QuayRegistry details ページで、Config Bundle Secret の名前をクリックします(例: example-registry-config-bundle )。
  5. ActionsEdit Secret をクリックします。
  6. Value ボックスに、必要なキー/値のペアを追加します。たとえば、OpenShift Container Platform デプロイメントの Red Hat Quay にスーパーユーザーを追加するには、以下のリファレンスを追加します。

    SUPER_USERS:
    - quayadmin
    Copy to Clipboard
  7. Save をクリックします。

検証

  1. 変更が受け入れられたことを確認します。

    1. OpenShift Container Platform Web コンソールで、OperatorInstalled OperatorQuay Registry をクリックします。
    2. Quay Registry をクリックします。
    3. Red Hat Quay レジストリーの名前をクリックします(例: example-registry )。
    4. Events をクリックします。成功すると、次のメッセージが表示されます。

      All objects created/updated successfully
      Copy to Clipboard
注記

シークレットに配置する前に、更新された config.yaml を base64 でエンコードする必要があります。Secret 名が spec.configBundleSecret で指定された値と一致することを確認します。Secret が更新されると、Operator は変更を検出し、Red Hat Quay Pod に更新を自動的にロールアウトします。

詳細な手順については、Red Hat Quay UI での設定シークレットの更新を参照してください。

5.3.3.2. CLI を使用した設定ファイルの変更

CLI を使用して既存の設定をダウンロードし、configBundleSecret によって保存される config.yaml ファイルを変更できます。変更後に、configBundleSecret リソースを再アップロードして、Red Hat Quay レジストリーに変更を加えることができます。

注記

configBundleSecret リソースによって保存される config.yaml ファイルの変更は、既存の設定ファイルのデコードと変更のアップロードが必要な複数ステップの手順です。ほとんどの場合、OpenShift Container Platform Web コンソールを使用して config.yaml ファイルに変更を加える方が簡単です。

前提条件

  • cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている。

手順

  1. 次のコマンドを入力して、QuayRegistry リソースを記述します。

    $ oc describe quayregistry -n <quay_namespace>
    Copy to Clipboard
    # ...
      Config Bundle Secret:  example-registry-config-bundle-v123x
    # ...
    Copy to Clipboard
  2. 次のコマンドを入力してシークレットデータを取得します。

    $ oc get secret -n <quay_namespace> <example-registry-config-bundle-v123x> -o jsonpath='{.data}'
    Copy to Clipboard

    出力例

    {
        "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo="
    }
    Copy to Clipboard

  3. >> config.yaml フラグを渡すことで、データを現在のディレクトリーの YAML ファイルにエクスポートできます。以下に例を示します。

    $ echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode >> config.yaml
    Copy to Clipboard
  4. config.yaml ファイルに必要な変更を加え、ファイルを config.yaml として保存します。
  5. 次のコマンドを入力して、新しい configBundleSecret YAML を作成します。

    $ touch <new_configBundleSecret_name>.yaml
    Copy to Clipboard
  6. 次のコマンドを入力して、新しい configBundleSecret リソースを作成し、config.yaml ファイルを渡します。

    $ oc -n <namespace> create secret generic <secret_name> \
      --from-file=config.yaml=</path/to/config.yaml> \ 
    1
    
      --dry-run=client -o yaml > <new_configBundleSecret_name>.yaml
    Copy to Clipboard
    1
    <config.yaml>base64 でデコード された config.yaml ファイルです。
  7. 次のコマンドを入力して、configBundleSecret リソースを作成します。

    $ oc create -n <namespace> -f <new_configBundleSecret_name>.yaml
    Copy to Clipboard

    出力例

    secret/config-bundle created
    Copy to Clipboard

  8. 次のコマンドを入力して、QuayRegistry YAML ファイルを更新して、新しい configBundleSecret オブジェクトを参照します。

    $ oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":{"configBundleSecret":"<new_configBundleSecret_name>"}}'
    Copy to Clipboard

    出力例

    quayregistry.quay.redhat.com/example-registry patched
    Copy to Clipboard

検証

  1. QuayRegistry CR が新規の configBundleSecret で更新されていることを確認します。

    $ oc describe quayregistry -n <quay_namespace>
    Copy to Clipboard

    出力例

    # ...
      Config Bundle Secret: <new_configBundleSecret_name>
    # ...
    Copy to Clipboard

    レジストリーにパッチを適用した後、Red Hat Quay Operator は変更を自動的に調整します。

第6章 Red Hat Quay 3.14 の新しい設定フィールド

以下のセクションでは、Red Hat Quay 3.14 で追加された新しい設定フィールドを詳しく説明します。

6.1. モデルカードレンダリング設定フィールド

v2 UI でのモデルカードのレンダリングをサポートするために、次の設定フィールドが追加されました。

フィールド説明

FEATURE_UI_MODELCARD

Boolean

UI で Model card イメージタブを有効にします。デフォルトは true です。

UI_MODELCARD_ARTIFACT_TYPE

String

モデルカードアーティファクトタイプを定義します。

UI_MODELCARD_ANNOTATION

Object

このオプションフィールドは、OCI イメージに格納されているモデルカードのレイヤーアノテーションを定義します。

UI_MODELCARD_LAYER_ANNOTATION

Object

このオプションフィールドは、OCI イメージに格納されているモデルカードのレイヤーアノテーションを定義します。

モデルカード YAML の例

FEATURE_UI_MODELCARD: true 
1

UI_MODELCARD_ARTIFACT_TYPE: application/x-mlmodel 
2

UI_MODELCARD_ANNOTATION: 
3

  org.opencontainers.image.description: "Model card metadata"
UI_MODELCARD_LAYER_ANNOTATION: 
4

  org.opencontainers.image.title: README.md
Copy to Clipboard

1
UI で Model Card イメージタブを有効にします。
2
モデルカードアーティファクトタイプを定義します。この例では、アーティファクトタイプは application/x-mlmodel です。
3
オプション: イメージに artifactType が定義されていない場合、このフィールドはマニフェストレベルでチェックされます。一致するアノテーションが見つかった場合、システムは UI_MODELCARD_LAYER_ANNOTATION に一致するアノテーションを持つレイヤーを検索します。
4
オプション: イメージに artifactType が定義されており、レイヤーが複数ある場合、このフィールドを使用して、モデルカードを含む特定のレイヤーを検索します。

第7章 必須の設定フィールド

Red Hat Quay では、Operator に正しく設定フィールドの最小セットが必要です。これらのフィールドは、レジストリーへのアクセス方法、イメージコンテンツの保存方法、メタデータの永続化方法、ログなどのバックグラウンドサービスの管理方法など、デプロイメントの重要な側面を定義します。

必要な設定フィールドは 5 つの主要なカテゴリーに分類されます。

  • 一般的な必須フィールド。本セクションでは、認証タイプ、URL スキーム、サーバーのホスト名、データベースシークレットキー、およびシークレットキーなどのコアフィールドについて説明します。
  • データベース設定フィールド。Red Hat Quay には、リポジトリー、ユーザー、チーム、およびタグに関するメタデータを保存するために、PostgreSQL リレーショナルデータベースが必要です。
  • オブジェクトストレージ設定フィールド。オブジェクトストレージは、コンテナーイメージ Blob とマニフェストの保存先のバックエンドを定義します。ストレージバックエンドは、Ceph/RadosGW、AWS S3 ストレージ、Google Cloud Storage、Nutanix などの Red Hat Quay でサポートされている必要があります。
  • Redis 設定フィールド。Redis は、プッシュログ、ユーザー通知、その他の操作などのデータのバックエンドとして使用されます。

7.1. 一般的な必須フィールド

以下の表は、Red Hat Quay デプロイメントの必須設定フィールドを説明しています。

表7.1 一般的な必須フィールド
フィールド説明

AUTHENTICATION_TYPE
(必須)

String

認証情報の認証に使用する認証エンジン。

値:
DatabaseLDAPJWTKeystoneOIDC のいずれか。

デフォルト: Database

PREFERRED_URL_SCHEME
(必須)

String

Red Hat Quay へのアクセスに使用する URL スキーム。

値:
http, https のいずれか。

デフォルト: http

SERVER_HOSTNAME
(必須)

String

スキームなしで Red Hat Quay にアクセスできる URL。

例:
quay-server.example.com

DATABASE_SECRET_KEY
(必須)

String

データベース内で機密フィールドを暗号化するのに使用されるキー。この値は、一度設定したら変更しないでください。変更すると、リポジトリーのミラーユーザー名やパスワード設定など、すべての信頼できるフィールドが無効になります。
この値は、Operator ベースのデプロイメントの場合、Red Hat Quay Operator によって自動的に設定されます。スタンドアロンデプロイメントの場合、管理者は Open SSL または同様のツールを使用して独自のキーを提供できます。キーの長さが 63 文字を超えないようにしてください。

SECRET_KEY
(必須)

String

ユーザーセッションを正しく解釈するために必要なセッション Cookie と CSRF トークンを暗号化するために使用されるキー。設定時に値を変更しないでください。すべての Red Hat Quay インスタンスで永続的である必要があります。すべてのインスタンスで永続的でない場合、ログインの失敗やセッションの永続性に関連するその他のエラーが発生する可能性があります。

SETUP_COMPLETE
(必須)

Boolean

これは、以前のバージョンのソフトウェアからそのまま残っているアーティファクトです。現時点では値を true に指定する 必要があります

一般的な必須フィールドの例

AUTHENTICATION_TYPE: Database
PREFERRED_URL_SCHEME: https
SERVER_HOSTNAME: <quay-server.example.com>
SECRET_KEY: <secret_key_value>
DATABASE_SECRET_KEY: <database_secret_key_value>
SETUP_COMPLETE: true
# ...
Copy to Clipboard

7.2. データベース設定フィールド

このセクションでは、Red Hat Quay デプロイメントで利用可能なデータベース設定フィールドを説明します。

7.2.1. データベース URI

Red Hat Quay では、必要な DB_URI フィールドを使用してデータベースへの接続を設定します。

以下の表は DB_URI 設定フィールドを説明します。

表7.2 データベース URI
フィールド説明

DB_URI
(必須)

String

認証情報を含む、データベースにアクセスするための URI。

DB_URI フィールドの例:

postgresql://quayuser:quaypass@quay-server.example.com:5432/quay

データベース URI の例

# ...
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
# ...
Copy to Clipboard

7.2.2. データベース接続引数

オプションの接続引数は、DB_CONNECTION_ARGS パラメーターで設定されます。DB_CONNECTION_ARGS で定義されたキーと値のペアの一部は汎用的なものも、データベース固有のものもあります。

表7.3 データベース接続引数
フィールド説明

DB_CONNECTION_ARGS

Object

タイムアウトや SSL/TLS などのデータベースの任意の接続引数。

.autorollback

Boolean

スレッドローカル接続を使用するかどうか。
true である必要があります。

.threadlocals

Boolean

自動ロールバック接続を使用するかどうか。
true である必要があります。

データベース接続引数の例

# ...
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
DB_CONNECTION_ARGS:
  autorollback: true
  threadlocals: true
# ...
Copy to Clipboard

7.2.2.1. SSL/TLS 接続引数

SSL/TLS では、設定はデプロイするデータベースによって異なります。

sslmode オプションは、セキュアな SSL/TLS TCP/IP 接続がサーバーにネゴシエートされるかどうか、その優先度を決定します。モードは 6 つあります。

表7.4 sslmode options
モード説明

sslmode

セキュアな SSL/TLS または TCP/IP 接続がサーバーにネゴシエートされるかどうか、またはその優先度を決定します。

   *: 無効

この設定では、非 SSL/TLS 接続のみが試行されます。

   *: 許可

設定では、まず非 SSL/TLS 接続が試行されます。失敗すると、SSL/TLS 接続が試行されます。

*: 優先
(デフォルト)

設定では、まず SSL/TLS 接続が試行されます。失敗すると、非 SSL/TLS 接続が試行されます。

   *: 必須

設定では SSL/TLS 接続のみが試行されます。ルート CA ファイルが存在する場合は、verify-ca が指定されているのと同じ方法で証明書が検証されます。

   *: verify-ca

設定では SSL/TLS 接続のみが試行され、サーバー証明書が信頼された認証局 (CA) によって発行されたかどうかが検証されます。

   *: verify-full

SSL/TLS 接続のみを試行し、サーバー証明書が信頼できる CA によって発行されていること、および要求されたサーバーのホスト名が証明書内のホスト名と一致することが確認されます。

PostgreSQL の有効な引数の詳細は、Database Connection Control Functions を参照してください。

PostgreSQL SSL/TLS 設定

# ...
DB_CONNECTION_ARGS:
  sslmode: <value>
  sslrootcert: path/to/.postgresql/root.crt
# ...
Copy to Clipboard

7.3. ストレージオブジェクト設定フィールド

ストレージフィールドは、コンテナーイメージ Blob とマニフェストの保存先のバックエンドを定義します。Red Hat Quay では、次のストレージプロバイダーがサポートされています。

  • Amazon Web Services (AWS) S3
  • AWS STS S3 (セキュリティートークンサービス)
  • AWS CloudFront (CloudFront S3Storage)
  • Google Cloud Storage
  • Microsoft Azure Blob Storage
  • Swift Storage
  • Nutanix オブジェクトストレージ
  • IBM Cloud Object Storage
  • NetApp ONTAP S3 オブジェクトストレージ
  • Hitachi Content Platform (HCP)オブジェクトストレージ
注記

S3 互換 API により、サポートされているストレージプロバイダーの多くは RadosGWStorage ドライバーを使用します。

7.3.1. ストレージ設定フィールド

以下の表は、Red Hat Quay のストレージ設定フィールドを説明しています。バックエンドストレージの設定時に、これらのフィールドが必要です。

表7.5 ストレージ設定フィールド
フィールド説明

DISTRIBUTED_STORAGE_CONFIG
(必須)

Object

Red Hat Quay で使用するストレージエンジンの設定。各キーは、ストレージエンジンの一意の ID を表します。この値は、ストレージエンジンパラメーターを記述するオブジェクトのタプル (キー、値) で構成されます。

デフォルト: []

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS
(必須)

文字列の配列

イメージをデフォルトで他のすべてのストレージエンジンに対して完全にレプリケートする必要のあるストレージエンジンの一覧 (DISTRIBUTED_STORAGE_CONFIG の ID 別)。

DISTRIBUTED_STORAGE_PREFERENCE
(必須)

文字列の配列

使用する優先ストレージエンジン (DISTRIBUTED_STORAGE_CONFIG の ID 別)。優先エンジンとは、プルする必要がないかを先にチェックしてから、イメージがプッシュされることを意味します。

デフォルト: false

MAXIMUM_LAYER_SIZE
(オプション)

String

イメージレイヤーの最大許容サイズ。

パターン: ^[0-9]+(G|M)$

: 100G

デフォルト: 20G

ストレージ設定の例

DISTRIBUTED_STORAGE_CONFIG:
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
MAXIMUM_LAYER_SIZE: 100G
Copy to Clipboard

7.3.2. ローカルストレージ

以下の YAML は、ローカルストレージを使用した設定例を示しています。

重要

概念実証の ためにレジストリーをデプロイする場合は、ローカルストレージのみを使用してください。これは実稼働環境での使用を目的としていません。ローカルストレージを使用する場合は、レジストリーの起動時に、レジストリーをコンテナー内の datastorage パスにマップする必要があります。詳細は、Proof of Concept - Deploying Red Hat Quayを参照してください。

ローカルストレージの例

DISTRIBUTED_STORAGE_CONFIG:
  default:
    - LocalStorage
    - storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
Copy to Clipboard

7.3.3. Red Hat OpenShift Data Foundation

以下の YAML は、Red Hat OpenShift Data Foundation を使用した設定のサンプルを示しています。

DISTRIBUTED_STORAGE_CONFIG:
  rhocsStorage:
    - RHOCSStorage
    - access_key: <access_key_here>
      secret_key: <secret_key_here>
      bucket_name: <bucket_name>
      hostname: <hostname>
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry
      maximum_chunk_size_mb: 100 
1

      server_side_assembly: true 
2
Copy to Clipboard
1
最終コピーの最大チャンクサイズ (MB 単位) を定義します。server_side_assemblyfalse に設定されている場合、効果はありません。
2
オプション: Red Hat Quay がクライアントアセンブリーではなく、サーバー側アセンブリーと最終的なチャンクコピーの使用を試みるかどうか指定します。デフォルトは true です。

7.3.4. Ceph オブジェクトゲートウェイ(RadosGW)ストレージの例

Red Hat Quay は、Ceph Object Gateway (RadosGW)をオブジェクトストレージのバックエンドとして使用することをサポートします。radosgw は、プライベートアーキテクチャー用のストレージプラットフォームである Red Hat Ceph Storage のコンポーネントです。Red Hat Ceph Storage は、Ceph と対話するための S3 互換の REST API を提供します。

注記

radosgw は、オンプレミスの S3 互換ストレージソリューションです。S3 API を実装し、access_keysecret_keybucket_name などの同じ認証フィールドを必要とします。Ceph Object Gateway および S3 API の詳細は、Ceph Object Gateway を参照してください。

以下の YAML は、RadosGW を使用した設定例を示しています。

一般的な s3 アクセスの例

DISTRIBUTED_STORAGE_CONFIG:
  radosGWStorage: 
1

    - RadosGWStorage
    - access_key: <access_key_here>
      bucket_name: <bucket_name_here>
      hostname: <hostname_here>
      is_secure: true
      port: '443'
      secret_key: <secret_key_here>
      storage_path: /datastorage/registry
      maximum_chunk_size_mb: 100 
2

      server_side_assembly: true 
3
Copy to Clipboard

1
一般的な s3 アクセスに使用します。一般的な s3 アクセスは、厳密には Amazon Web Services (AWS) s3 に限定されず、RadosGW または他のストレージサービスでも使用できることに注意してください。AWS S3 ドライバーを使用した一般的な s3 アクセスの例は、「AWS S3 ストレージ」を参照してください。
2
オプション: 最終コピーの最大チャンクサイズ (MB 単位) を定義します。server_side_assemblyfalse に設定されている場合、効果はありません。
3
オプション: Red Hat Quay がクライアントアセンブリーではなく、サーバー側アセンブリーと最終的なチャンクコピーの使用を試みるかどうか指定します。デフォルトは true です。

7.3.5. サポートされている AWS ストレージバックエンド

Red Hat Quay は、複数の Amazon Web Services (AWS)ストレージバックエンドをサポートします。

  • S3 ストレージ: AWS のネイティブオブジェクトストレージサービスを使用する AWS S3 バケットの標準サポート。
  • STS S3 ストレージ: IAM ロールを引き受けるための AWS Security Token Service (STS)のサポートにより、よりセキュアな S3 操作が可能になります。
  • CloudFront S3 ストレージ: AWS CloudFront と統合して、AWS S3 をオリジンとして使用しながらコンテンツの高可用性ディストリビューションを有効にします。

以下のセクションでは、YAML の例と各 AWS ストレージバックエンドに関する追加情報を提供します。

7.3.5.1. Amazon Web Services S3 ストレージ

Red Hat Quay は、AWS S3 をオブジェクトストレージのバックエンドとして使用することをサポートします。AWS S3 は、データの可用性、スケーラビリティー、セキュリティー、およびパフォーマンスのために設計されたオブジェクトストレージサービスです。以下の YAML は、AWS S3 を使用した設定例を示しています。

AWS S3 の例

# ...
DISTRIBUTED_STORAGE_CONFIG:
  default:
    - S3Storage 
1

    - host: s3.us-east-2.amazonaws.com
      s3_access_key: ABCDEFGHIJKLMN
      s3_secret_key: OL3ABCDEFGHIJKLMN
      s3_bucket: quay_bucket
      s3_region: <region> 
2

      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
# ...
Copy to Clipboard

1
S3Storage ストレージドライバーは、AWS S3 バケットにのみ使用してください。これは、RadosGW ドライバーや他のストレージサービスを使用できる一般的な S3 アクセスとは異なることに注意してください。例は、「例 B: 一般的な S3 アクセスで RadosGW を使用する」を参照してください。
2
Amazon Web Services のリージョン。デフォルトは us-east-1 です。
7.3.5.2. Amazon Web Services STS S3 ストレージ

AWS Security Token Service (STS)は、AWS リソースにアクセスするための一時的な制限付き権限の認証情報を提供し、長期アクセスキーを保存する必要性を回避してセキュリティーを強化します。これは、IAM ロールで認証情報をローテーションしたり、管理できる OpenShift Container Platform などの環境で役立ちます。

以下の YAML は、OpenShift Container Platform 設定で AWS STS を Red Hat Quay で使用する設定例を示しています。

AWS STS S3 ストレージの例

# ...
DISTRIBUTED_STORAGE_CONFIG:
   default:
    - STSS3Storage
    - sts_role_arn: <role_arn> 
1

      s3_bucket: <s3_bucket_name>
      storage_path: <storage_path>
      sts_user_access_key: <s3_user_access_key> 
2

      sts_user_secret_key: <s3_user_secret_key> 
3

      s3_region: <region> 
4

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
# ...
Copy to Clipboard

1
一意の Amazon Resource Name (ARN)。
2
生成された AWS S3 ユーザーアクセスキー。
3
生成された AWS S3 ユーザー秘密鍵。
4
Amazon Web Services のリージョン。デフォルトは us-east-1 です。
7.3.5.3. AWS CloudFront ストレージ

AWS CloudFront はコンテンツ配信ネットワーク(CDN)サービスで、ユーザーにコンテンツをキャッシュして配信し、パフォーマンスを向上させ、レイテンシーを短縮します。Red Hat Quay は、CloudFrontedS3Storage ドライバーを介して CloudFront をサポートします。これにより、CloudFront ディストリビューションを介した S3 バケットへの安全で署名されたアクセスが可能になります。

Red Hat Quay デプロイメント用に AWS CloudFront を設定する場合は、次の例を使用します。

注記
  • AWS Cloudfront ストレージを設定する場合、Red Hat Quay を適切に使用するには次の条件を満たす必要があります。

    • config.yaml ファイルで定義されている Red Hat Quay のストレージパスと一致するように Origin パス を設定する必要があります。この要件を満たさない場合、イメージを取得するときに 403 エラーが発生します。詳細は、Origin path を参照してください。
    • Bucket policyCross-origin resource sharing (CORS) ポリシーを設定する必要があります。

Cloudfront S3 の YAML 例

DISTRIBUTED_STORAGE_CONFIG:
    default:
      - CloudFrontedS3Storage
      - cloudfront_distribution_domain: <CLOUDFRONT_DISTRIBUTION_DOMAIN>
        cloudfront_key_id: <CLOUDFRONT_KEY_ID>
        cloudfront_privatekey_filename: <CLOUDFRONT_PRIVATE_KEY_FILENAME>
        host: <S3_HOST>
        s3_access_key: <S3_ACCESS_KEY>
        s3_bucket: <S3_BUCKET_NAME>
        s3_secret_key: <S3_SECRET_KEY>
        storage_path: <STORAGE_PATH>
        s3_region: <S3_REGION>
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
  - default
DISTRIBUTED_STORAGE_PREFERENCE:
  - default
Copy to Clipboard

バケットポリシーの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>" 
1
 
2

            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>/*" 
3

        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>" 
4
 
5

            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>"
        }
    ]
}
Copy to Clipboard

1 4
CloudFront OAI および S3 バケットを所有する AWS アカウントの識別子またはアカウント ID。
2 5
S3 バケットにアクセスする CloudFront Origin Access Identity (OAI)。
3
CloudFront が S3 バケット内のすべてのオブジェクト (/*) にアクセスできることを指定します。

7.3.6. Google Cloud Storage

Red Hat Quay は、Google Cloud Storage (GCS)をオブジェクトストレージバックエンドとして使用することをサポートします。Red Hat Quay で使用すると、コンテナーイメージとアーティファクトを保存するためのクラウドネイティブソリューションが提供されます。

以下の YAML は、Google Cloud Storage を使用した設定例を示しています。

Google Cloud Storage の例

DISTRIBUTED_STORAGE_CONFIG:
    googleCloudStorage:
        - GoogleCloudStorage
        - access_key: <access_key>
          bucket_name: <bucket_name>
          secret_key: <secret_key>
          storage_path: /datastorage/registry
          boto_timeout: 120 
1

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - googleCloudStorage
Copy to Clipboard

1
オプション: 接続から読み取ろうとしたときにタイムアウト例外が出力されるまでの時間 (秒単位)。デフォルトは 60 秒です。また、接続を試行するときにタイムアウト例外が出力されるまでの時間 (秒単位) も含まれます。デフォルトは 60 秒です。

7.3.7. Microsoft Azure Blob Storage

Red Hat Quay は、Microsoft Azure Blob Storage をオブジェクトストレージのバックエンドとして使用することをサポートします。Azure Blob Storage を使用すると、コンテナーイメージ、メタデータ、およびその他のアーティファクトを安全でクラウドネイティブな方法で永続化できます。

以下の YAML は、Azure Storage を使用した設定のサンプルを示しています。

Microsoft Azure Blob Storage の例

DISTRIBUTED_STORAGE_CONFIG:
  azureStorage:
    - AzureStorage
    - azure_account_name: <azure_account_name>
      azure_container: <azure_container_name>
      storage_path: /datastorage/registry
      azure_account_key: <azure_account_key>
      sas_token: some/path/
      endpoint_url: https://[account-name].blob.core.usgovcloudapi.net 
1

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - azureStorage
Copy to Clipboard

1
Azure ストレージの endpoint_url パラメーターは任意であり、Microsoft Azure Government (MAG) エンドポイントで使用できます。空白のままにすると、endpoint_url は通常の Azure リージョンに接続します。

Red Hat Quay 3.7 以降では、MAG Blob サービスのプライマリーエンドポイントを使用する必要があります。MAG Blob サービスのセカンダリーエンドポイントを使用すると、AuthenticationErrorDetail:Cannot find the claimed account when trying to GetProperties for the account whusc8-secondary エラーが発生します。

7.3.8. Swift オブジェクトストレージ

Red Hat Quay は、Red Hat OpenStack Platform (RHOSP) Object Storage サービス(Swift) をオブジェクトストレージバックエンドとして使用することをサポートします。Swift は、独自の API と認証メカニズムで S3 のような機能を提供します。

以下の YAML は、Swift ストレージを使用した設定のサンプルを示しています。

Swift オブジェクトストレージの例

DISTRIBUTED_STORAGE_CONFIG:
  swiftStorage:
    - SwiftStorage
    - swift_user: <swift_username>
      swift_password: <swift_password>
      swift_container: <swift_container>
      auth_url: https://example.org/swift/v1/quay
      auth_version: 3
      os_options:
        tenant_id: <osp_tenant_id>
        user_domain_name: <osp_domain_name>
      ca_cert_path: /conf/stack/swift.cert"
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - swiftStorage
Copy to Clipboard

7.3.9. Nutanix オブジェクトストレージ

Red Hat Quay は、Nutanix Objects Storage をオブジェクトストレージバックエンドとしてサポートします。Nutanix Object Storage は、Nutanix を使用してプライベートクラウドインフラストラクチャーを実行している組織に適しています。

以下の YAML は、Nutanix オブジェクトストレージを使用した設定例を示しています。

Nutanix Objects ストレージの例

DISTRIBUTED_STORAGE_CONFIG:
  nutanixStorage: # storage config name
    - RadosGWStorage # actual driver
    - access_key: <access_key>
      secret_key: <secret_key>
      bucket_name: <bucket_name>
      hostname: <hostname>
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE: # must contain name of the storage config
    - nutanixStorage
Copy to Clipboard

7.3.10. IBM Cloud Object Storage

Red Hat Quay は、IBM Cloud Object Storage をオブジェクトストレージバックエンドとしてサポートします。IBM Cloud Object Storage は、IBM Cloud 上のスケーラブルで安全なストレージを必要とするクラウドネイティブアプリケーションに適しています。

以下の YAML は、IBM Cloud Object Storage を使用した設定例を示しています。

IBM Cloud Object Storage

DISTRIBUTED_STORAGE_CONFIG:
  default:
  - IBMCloudStorage # actual driver
  - access_key: <access_key> # parameters
    secret_key: <secret_key>
    bucket_name: <bucket_name>
    hostname: <hostname>
    is_secure: 'true'
    port: '443'
    storage_path: /datastorage/registry
    maximum_chunk_size_mb: 100mb 
1

    minimum_chunk_size_mb: 5mb 
2

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- default
DISTRIBUTED_STORAGE_PREFERENCE:
- default
Copy to Clipboard

1
オプション: 100mb に設定することを推奨します。
2
オプション: デフォルトは 5mb です。このフィールドは、Red Hat サポート に相談せずに調整しないでください。意図しない結果が生じる可能性があるためです。

7.3.11. NetApp ONTAP S3 オブジェクトストレージ

Red Hat Quay は、NetApp ONTAP S3 をオブジェクトストレージバックエンドとして使用することをサポートしています。

次の YAML は、NetApp ONTAP S3 を使用したサンプル設定を示しています。

NetApp ONTAP S3 の例

DISTRIBUTED_STORAGE_CONFIG:
  local_us:
  - RadosGWStorage
  - access_key: <access_key>
    bucket_name: <bucket_name>
    hostname: <host_url_address>
    is_secure: true
    port: <port>
    secret_key: <secret_key>
    storage_path: /datastorage/registry
    signature_version: v4
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- local_us
DISTRIBUTED_STORAGE_PREFERENCE:
- local_us
Copy to Clipboard

7.3.12. Hitachi Content Platform オブジェクトストレージ

Red Hat Quay は、オブジェクトストレージバックエンドとしての Hitachi Content Platform (HCP) の使用をサポートします。

次の YAML は、オブジェクトストレージに HCP を使用するサンプル設定を示しています。

HCP ストレージ設定の例

DISTRIBUTED_STORAGE_CONFIG:
  hcp_us:
  - RadosGWStorage
  - access_key: <access_key>
    bucket_name: <bucket_name>
    hostname: <hitachi_hostname_example>
    is_secure: true
    secret_key: <secret_key>
    storage_path: /datastorage/registry
    signature_version: v4
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- hcp_us
DISTRIBUTED_STORAGE_PREFERENCE:
- hcp_us
Copy to Clipboard

7.4. Redis 設定フィールド

Redis は、ビルドトリガーや通知などのバックエンドタスクおよびサービスをサポートするために Red Hat Quay によって使用されます。Redis に関連する設定タイプ(ビルドログおよびユーザーイベント)があります。以下のセクションでは、各タイプで利用可能な設定フィールドについて詳しく説明します。

7.4.1. ビルドログ

ビルドログは、イメージのビルドプロセス中に生成され、デバッグと監査の洞察を提供します。Red Hat Quay は Redis を使用して、ユーザーインターフェイスまたは API 経由でアクセスする前に、これらのログを一時的に保存します。

Redis デプロイメントには、以下のビルドログ設定フィールドを使用できます。

表7.6 ビルドログ設定フィールド
フィールド説明

BUILDLOGS_REDIS
(必須)

Object

ビルドログキャッシュ用の Redis 接続の詳細。

.host
(必須)

String

Redis にアクセスできるホスト名。
例:
quay-server.example.com

.port
(必須)

数値

Redis にアクセスできるポート。
例:
6379

.password

String

Redis インスタンスに接続するためのパスワード。
例:
strongpassword

.ssl
(オプション)

Boolean

Redis と Quay 間の TLS 通信を有効にするかどうか。デフォルトは false です。

ビルドログ設定の例

# ...
BUILDLOGS_REDIS:
  host: <quay-server.example.com>
  password: <example_password>
  port: 6379 
1

  ssl: true 
2

# ...
Copy to Clipboard

1 2
デプロイで Azure Cache for Redis を使用し、ssltrue に設定されていると、ポートはデフォルトで 6380 になります。

7.4.2. ユーザーイベント

ユーザーイベントは、リポジトリーのプッシュ、タグの作成、削除、パーミッションの変更などの Red Hat Quay 全体のアクティビティーを追跡します。これらのイベントは、アクティビティーストリームの一部として Redis に記録され、API または Web インターフェイスからアクセスできます。

Redis デプロイメントには、以下のユーザーイベントフィールドを使用できます。

表7.7 ユーザーイベント設定
フィールド説明

USER_EVENTS_REDIS
(必須)

Object

ユーザーイベント処理の Redis 接続の詳細。

.host
(必須)

String

Redis にアクセスできるホスト名。
例:
quay-server.example.com

.port
(必須)

数値

Redis にアクセスできるポート。
例:
6379

.password

String

Redis インスタンスに接続するためのパスワード。
例:
strongpassword

.ssl

Boolean

Redis と Quay 間の TLS 通信を有効にするかどうか。デフォルトは false です。

.ssl_keyfile
(オプション)

String

使用するクライアント証明書を格納する鍵データベースファイルの名前。
例:
ssl_keyfile:/path/to/server/privatekey.pem

.ssl_certfile
(オプション)

String

SSL 証明書のファイルパスを指定するために使用されます。
例:
ssl_certfile:/path/to/server/certificate.pem

.ssl_cert_reqs
(オプション)

String

SSL/TLS ハンドシェーク中に実行される証明書検証のレベルを指定するために使用されます。
例:
ssl_cert_reqs: CERT_REQUIRED

.ssl_ca_certs
(オプション)

String

信頼された認証局 (CA) 証明書のリストを含むファイルへのパスを指定するために使用されます。
例:
ssl_ca_certs:/path/to/ca_certs.pem

.ssl_ca_data
(オプション)

String

信頼できる CA 証明書を含む文字列を PEM 形式で指定するために使用されます。
例:
ssl_ca_data: <certificate>

.ssl_check_hostname
(オプション)

Boolean

サーバーへの SSL/TLS 接続をセットアップするときに使用されます。サーバーの SSL/TLS 証明書のホスト名が、接続先のサーバーのホスト名と一致することをクライアントが確認する必要があるかどうかを指定します。
例:
ssl_check_hostname: true

Redis ユーザーイベントの例

# ...
USER_EVENTS_REDIS:
  host: <quay-redis.example.com>
  port: 6379
  password: <example_password>
  ssl: true
  ssl_keyfile: /etc/ssl/private/redis-client.key
  ssl_certfile: /etc/ssl/certs/redis-client.crt
  ssl_cert_reqs: <required_certificate>
  ssl_ca_certs: /etc/ssl/certs/ca-bundle.crt
  ssl_check_hostname: true
# ...
Copy to Clipboard

第8章 自動化設定オプション

Red Hat Quay は、デプロイメントと設定を自動化するさまざまなメカニズムをサポートしています。これにより、Red Hat Quay を GitOps および CI/CD パイプラインに統合することができます。これらのオプションを定義し、API を利用することで、Red Hat Quay は UI を使用せずに初期化および管理できます。

注記

Red Hat Quay Operator は configBundleSecret カスタムリソース(CR)で config.yaml ファイルを管理するため、OpenShift Container Platform で Red Hat Quay を事前に設定するには、管理者が必要な設定で有効な config.yaml ファイルを手動で作成する必要があります。次に、このファイルを新規の Kubernetes Secret にバンドルし、QuayRegistry CR によって参照されるデフォルトの configBundleSecret CR を置き換えるために使用される必要があります。これにより、Web ベースの設定 UI をバイパスして、OpenShift Container Platform 上の Red Hat Quay を完全に自動化された方法でデプロイできます。詳細は、QuayRegistry CR after deployment を 参照してください。

オンプレミスの Red Hat Quay デプロイメントの場合、事前設定は有効な config.yaml ファイルを作成し、レジストリーをデプロイすることで行われます。

自動化オプションは、切断されたクラスターやエアギャップクラスターなどの宣言型 Red Hat Quay デプロイメントを必要とする環境に最適です。

8.1. 自動化用の事前設定オプション

Red Hat Quay には、レジストリー管理者が早期セットアップタスクおよび API のアクセシビリティーを自動化できるようにする設定オプションが用意されています。これらのオプションは、新規のデプロイメントや、API 呼び出しの作成方法の制御に役立ちます。次のオプションは、自動化および管理の制御をサポートしています。

表8.1 自動化設定フィールド
フィールド説明

FEATURE_USER_INITIALIZE

Boolean

新しくデプロイされた Red Hat Quay レジストリーで最初のユーザーブートストラップを有効にします。デプロイ前に config.yaml ファイルでこのフィールドを true に設定すると、管理者は api/v1/user/initialize エンドポイントを呼び出して最初のユーザー を作成できます。

注記

既存の組織の OAuth アプリケーションによって生成された OAuth 2 アクセストークン を必要とする他のすべてのレジストリー API 呼び出しとは異なり、api/v1/user/initialize エンドポイントには認証は必要ありません。

BROWSER_API_CALLS_XHR_ONLY

Boolean

レジストリー API がブラウザーへの呼び出しのみを受け入れるかどうかを制御します。通常、ブラウザーベースで API にアクセスできるようにするには、管理者はこのフィールドを false に設定する必要があります。true に設定すると、API 呼び出しがブロックされ、管理者とユーザーの両方が API と対話できなくなります。

SUBNET_USER

String

レジストリーへの完全な特権と無制限のアクセス権を持つ管理者ユーザーまたはスーパーユーザーの一覧を定義します。Red Hat Quay 管理者は、デプロイ前に config.yamlSUPER_USERS を設定し、再デプロイの必要なしに直ちに管理アクセスを確保する必要があります。デプロイ後にこのフィールドを設定するには、レジストリーを再起動する必要があります。

FEATURE_USER_CREATION

Boolean

このフィールドが false に設定されている場合にのみ、新規ユーザーの作成をスーパーユーザーにのみ付けます。この設定は、管理者がユーザーアクセスを手動でプロビジョニングする必要がある制御された環境で役立ちます。

次の YAML は、自動化の推奨設定を示しています。

自動化の推奨設定

# ...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
# ...
Copy to Clipboard

第9章 コンポーネントおよび機能設定フィールド

Component and Feature Configuration セクションでは、さまざまなサブシステム間で Red Hat Quay を微調整するために使用できる設定可能なフィールドを説明します。これらのフィールドを使用すると、管理者はレジストリーの動作をカスタマイズしたり、特定の機能を有効にしたり、外部サービスやインフラストラクチャーと統合したりできます。基本的なデプロイメントには必要ありませんが、これらのオプションはセキュリティー、自動化、スケーラビリティー、コンプライアンス、およびパフォーマンスに関連する高度なユースケースをサポートします。

9.1. コア設定の概要

これらのコアフィールドを使用して、ホスト名、プロトコル、認証設定など、レジストリーの基本動作を設定します。

9.1.1. レジストリーブランディングおよびアイデンティティーフィールド

次の設定フィールドを使用すると、Red Hat Quay デプロイメントに表示されるブランディング、アイデンティティー、および連絡先情報を変更できます。これらのフィールドを使用すると、UI 全体に表示されるタイトル、ヘッダー、フッター、および組織連絡先リンクを指定して、レジストリーがユーザーに表示される方法をカスタマイズできます。

注記

以下のフィールドの一部は、Red Hat Quay v2 UI では利用できません。

表9.1 レジストリーブランディングおよびアイデンティティー設定フィールド
フィールド説明

REGISTRY_TITLE

String

指定されている場合、レジストリーの長いタイトル。Red Hat Quay デプロイメントのフロントエンド (組織のサインインページなど) に表示されます。35 文字を超えないようにしてください。
デフォルト:
Red Hat Quay

REGISTRY_TITLE_SHORT

String

指定されている場合は、省略形式のレジストリーのタイトル。タイトルは、組織のさまざまなページに表示されます。たとえば、組織の Tutorial ページのチュートリアルのタイトルとして表示されます。
デフォルト:
Red Hat Quay

CONTACT_INFO

文字列の配列

指定されている場合は、連絡先ページに表示される連絡先情報。連絡先が 1 つしか指定されていない場合は、連絡先のフッターが直接リンクされます。

[0]

String

電子メールを送信するためのリンクを追加します。

パターン:
^mailto:(.)+$
例:
mailto:support@quay.io

[1]

String

IRC チャットルームにアクセスするためのリンクを追加します。

パターン:
^irc://(.)+$
例:
irc://chat.freenode.net:6665/quay

[2]

String

電話番号を呼び出すリンクを追加します。

パターン:
^tel:(.)+$
例:
tel:+1-888-930-3475

[3]

String

定義された URL へのリンクを追加します。

パターン:
^http(s)?://(.)+$
Example:
https://twitter.com/quayio

表9.2 ブランディング設定フィールド
フィールド説明

BRANDING

Object

Red Hat Quay UI のロゴおよび URL のカスタムブランディング

.logo
(必須)

String

メインのロゴイメージ URL。

ヘッダーロゴのデフォルトは 205x30 PX です。Web UI の Red Hat Quay サインイン画面のフォームロゴは、デフォルトで 356.5x39.7 PX です。
例:
/static/img/quay-horizontal-color.svg

.footer_img

String

UI フッターのロゴ。デフォルトは 144x34 ピクセルです。

例:
/static/img/RedHat.svg

.footer_url

String

フッターイメージへのリンク。

例:
https://redhat.com

表9.3 フッターリンク設定フィールド
フィールド説明

FOOTER_LINKS

Object

オンプレミスインストールの Red Hat Quay の UI でフッターリンクのカスタマイズを有効にします。

.TERMS_OF_SERVICE_URL

String

オンプレミスインストール用のカスタム利用規約。

例:
https://index.hr

.PRIVACY_POLICY_URL

String

オンプレミスインストール用のカスタムプライバシーポリシー。

例:
https://example.hr

.SECURITY_URL

String

オンプレミスインストール用のカスタムセキュリティーページ。

例:
https://example.hr

.ABOUT_URL

String

オンプレミスインストール用のカスタムの概要ページ。

例:
https://example.hr

レジストリーのブランディングおよびアイデンティティーの例の YAML

# ...
REGISTRY_TITLE: "Example Container Registry"
REGISTRY_TITLE_SHORT: "Example Quay"
CONTACT_INFO:
  - mailto:support@example.io
  - irc://chat.freenode.net:6665/examplequay
  - tel:+1-800-555-1234
  - https://support.example.io
BRANDING:
    logo: https://www.mend.io/wp-content/media/2020/03/5-tips_small.jpg
    footer_img: https://www.mend.io/wp-content/media/2020/03/5-tips_small.jpg
    footer_url: https://opensourceworld.org/
FOOTER_LINKS:
  "TERMS_OF_SERVICE_URL": "https://www.index.hr"
  "PRIVACY_POLICY_URL": "https://www.example.hr"
  "SECURITY_URL": "https://www.example.hr"
  "ABOUT_URL": "https://www.example.hr"
# ...
Copy to Clipboard

9.1.2. SSL/TLS 設定フィールド

このセクションでは、Red Hat Quay デプロイメントで SSL/TLS 暗号化を有効にして管理するために使用できる設定フィールドについて説明します。

表9.4 SSL 設定フィールド
フィールド説明

PREFERRED_URL_SCHEME

String

http または https のいずれか。クライアントから Quay への通信パスに TLS 暗号化がない場合に限り、ユーザーは PREFERRED_URL_SCHEMEhttp に設定することに注意してください。
TLS を終了するロードバランサー、リバースプロキシー (Nginx など) を使用する場合、またはカスタム SSL 証明書で Quay を直接使用する場合、ユーザーは PREFERRED_URL_SCHEME を https に設定する必要があります。ほとんどの場合、PREFERRED_URL_SCHEMEhttps である必要があります。
デフォルト: http

SERVER_HOSTNAME
(必須)

String

スキームなしで Red Hat Quay にアクセスできる URL。

例:
quay-server.example.com

SSL_CIPHERS

文字列の配列

指定した場合、nginx で定義された SSL 暗号のリストが有効または無効になります。

例:
[ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-GCM-SHA384, DHE-RSA-AES128-GCM-SHA256, DHE-DSS-AES128-GCM-SHA256, kEDH+AESGCM, ECDHE-RSA-AES128-SHA256, ECDHE-ECDSA-AES128-SHA256, ECDHE-RSA-AES128-SHA, ECDHE-ECDSA-AES128-SHA, ECDHE-RSA-AES256-SHA384, ECDHE-ECDSA-AES256-SHA384, ECDHE-RSA-AES256-SHA, ECDHE-ECDSA-AES256-SHA, DHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA, DHE-DSS-AES128-SHA256, DHE-RSA-AES256-SHA256, DHE-DSS-AES256-SHA, DHE-DSS-AES256-SHA, AES128-GCM-SHA256, AES256-GCM-SHA384, AES128-SHA256, AES256-SHA256, AES128-SHA, AES256-SHA, AES, !3DES", !aNULL, !eNULL, !EXPORT, DES, !RC4, MD5, !PSK, !aECDH, !EDH-DSS-DES-CBC3-SHA, !EDH-RSA-DES-CBC3-SHA, !KRB5-DES-CBC3-SHA]

SSL_PROTOCOLS

文字列の配列

指定されている場合、nginx は、リストで定義される SSL プロトコルのリストを有効にするように設定されます。リストから SSL プロトコルを削除すると、Red Hat Quay の起動時にそのプロトコルが無効になります。

例:
['TLSv1','TLSv1.1','TLSv1.2', `TLSv1.3]`

SESSION_COOKIE_SECURE

Boolean

セッションクッキーに secure プロパティーを設定するべきであるかどうか。

デフォルト:
False

推奨:
SSL を使用するインストールの場合はすべて、True に n 設定します。

EXTERNAL_TLS_TERMINATION

Boolean

TLS がサポートされていても、Quay の前の層で終了する場合は true に設定します。独自の SSL 証明書を使用して Quay を実行しており、TLS トラフィックを直接受信している場合は、false に設定します。

SSL 設定例の YAML

# ...
PREFERRED_URL_SCHEME: https
SERVER_HOSTNAME: quay-server.example.com
SSL_CIPHERS:
  - ECDHE-RSA-AES128-GCM-SHA256
SSL_PROTOCOLS:
  - TLSv1.3
SESSION_COOKIE_SECURE: true
EXTERNAL_TLS_TERMINATION: true
# ...
Copy to Clipboard

9.1.3. IPv6 設定フィールド

FEATURE_LISTEN_IP_VERSION 設定フィールドを使用して、Red Hat Quay がリッスンする IP プロトコルファミリー(IPv4、IPv6、またはその両方(デュアルスタック))を指定できます。このフィールドは、レジストリーが IPv6 のみのネットワークまたはデュアルスタックネットワークで動作する必要がある環境では重要です。

表9.5 IPv6 設定フィールド
フィールド説明

FEATURE_LISTEN_IP_VERSION

String

IPv4、IPv6、またはデュアルスタックプロトコルファミリーを有効にします。この設定フィールドは正しく設定する必要があります。そうしないと、Red Hat Quay は起動に失敗します。デフォルト: IPv4追加の設定: IPv6デュアルスタック

IPv6 サンプル YAML

# ...
FEATURE_LISTEN_IP_VERSION: dual-stack
# ...
Copy to Clipboard

9.1.4. ロギング変数およびデバッグ変数

以下の変数は、Red Hat Quay のイベントをログに記録し、デバッグ情報を公開し、システムヘルスチェックと対話する方法を制御します。これらの設定は、レジストリーのトラブルシューティングおよびモニタリングに役立ちます。

表9.6 ロギングおよびデバッグ設定変数
変数説明

DEBUGLOG

Boolean

デバッグログを有効または無効にするかどうか。

USERS_DEBUG

整数。0 または 1 のいずれか。

パスワードを含むクリアテキストで LDAP 操作をデバッグするために使用されます。DEBUGLOG=TRUE とともに使用する必要があります。

重要

USERS_DEBUG=1 を設定すると、認証情報がクリアテキストで公開されます。この変数は、デバッグ後に Red Hat Quay デプロイメントから削除する必要があります。この環境変数を使用して生成されたログファイルは精査する必要があり、他のユーザーに送信する前にパスワードを削除する必要があります。注意して使用してください。

ALLOW_PULLS_WITHOUT_STRICT_LOGGING

String

true に指定すると、プルの監査ログのエントリーに書き込みできない場合でも、プルは成功します。これは、データベースが読み取り専用の状態にフォールバックし、その間プルを続行する必要がある場合に便利です。

デフォルト: False

ENABLE_HEALTH_DEBUG_SECRET

String

指定していると、スーパーユーザーとして認証されていない場合に詳細なデバッグ情報を表示するために正常性エンドポイントに指定できるシークレット。

HEALTH_CHECKER

String

設定済みのヘルスチェック。

例: ('RDSAwareHealthCheck', {'access_key': 'foo', 'secret_key': 'bar'})

FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL

Boolean

集計されたログ数の取得を許可するかどうか。

デフォルト: True

ロギングとデバッグの例の YAML

#...
DEBUGLOG: true
USERS_DEBUG: 1
ALLOW_PULLS_WITHOUT_STRICT_LOGGING: "true"
ENABLE_HEALTH_DEBUG_SECRET: "<secret_value>"
HEALTH_CHECKER: "('RDSAwareHealthCheck', {'access_key': 'foo', 'secret_key': 'bar'})"
FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL: true
# ...
Copy to Clipboard

9.1.5. レジストリーの状態およびシステム動作の設定フィールド

次の設定フィールドは、Red Hat Quay レジストリーの運用状態と、それが外部システムと対話する方法を制御します。これらの設定により、管理者はレジストリーをメンテナンス目的で制限された読み取り専用モードに配置し、特定のホスト名が Webhook がターゲットであることをブロックして追加のセキュリティーを適用できます。

表9.7 レジストリーの状態およびシステム動作の設定フィールド
フィールド説明

REGISTRY_STATE

String

レジストリーの状態

値: normal または read-only

WEBHOOK_HOSTNAME_BLACKLIST

文字列の配列

検証時に、ローカルホスト以外に Webhook から禁止するホスト名のセット。

レジストリーの状態とシステム動作の例(YAML)

# ...
REGISTRY_STATE: normal
WEBHOOK_HOSTNAME_BLACKLIST:
  - "169.254.169.254"
  - "internal.example.com"
  - "127.0.0.2"
# ...
Copy to Clipboard

9.2. User Experience and Interface

これらのフィールドでは、ユーザーが UI と対話する方法を設定します。これには、ブランド、ページネーション、ブラウザーの動作、recaptcha などのアクセシビリティオプションが含まれます。また、ユーザー向けのパフォーマンスと表示の設定も説明します。

9.2.1. Web UI およびユーザーエクスペリエンスの設定フィールド

これらの設定フィールドは、Red Hat Quay Web インターフェイスと全体的なユーザーエクスペリエンスの動作と外観を制御します。このセクションのオプションを使用すると、管理者はログイン動作、アバターディスプレイ、ユーザーの自動補完、セッション処理、およびカタログ可視性をカスタマイズできます。

表9.8 Web UI および UX 設定フィールド
フィールド説明

AVATAR_KIND

String

表示する avatar のタイプ。インライン(ローカル)または Gravatar (gravatar)。

値: local,gravatar

FRESH_LOGIN_TIMEOUT

String

新規ログイン時にユーザーがパスワードの再入力を要求されるまでの時間。

例: 5m

FEATURE_UI_V2

Boolean

設定すると、ユーザーは v2 ベータ UI 環境を試すことができます。

デフォルト: True

FEATURE_UI_V2_REPO_SETTINGS

Boolean

True に設定すると、Red Hat Quay v2 UI でリポジトリー設定が有効になります。

+ デフォルト: False

FEATURE_DIRECT_LOGIN

Boolean

ユーザーが UI に直接ログインできるかどうか

デフォルト: True

FEATURE_PARTIAL_USER_AUTOCOMPLETE

Boolean

true に設定すると、オートコンプリートは部分的なユーザー名に適用されます。
デフォルト: True

FEATURE_LIBRARY_SUPPORT

Boolean

Docker からプルおよびプッシュするときに "名前空間のない" リポジトリーを許可するかどうか。

デフォルト: True

FEATURE_PERMANENT_SESSIONS

Boolean

セッションが永続的かどうか。

デフォルト: True

FEATURE_PUBLIC_CATALOG

Boolean

true に設定すると、_catalog エンドポイントはパブリックリポジトリーを返します。それ以外では、プライベートリポジトリーのみが返されます。

デフォルト: False

サンプル YAML

# ...
AVATAR_KIND: local
FRESH_LOGIN_TIMEOUT: 5m
FEATURE_UI_V2: true
FEATURE_UI_V2_REPO_SETTINGS: false
FEATURE_DIRECT_LOGIN: true
FEATURE_PARTIAL_USER_AUTOCOMPLETE: true
FEATURE_LIBRARY_SUPPORT: true
FEATURE_PERMANENT_SESSIONS: true
FEATURE_PUBLIC_CATALOG: false
# ...
Copy to Clipboard

9.2.1.1. v2 ユーザーインターフェイス設定

FEATURE_UI_V2 を有効にすると、現在のバージョンのユーザーインターフェイスと新しいバージョンのユーザーインターフェイスを切り替えることができます。

重要
  • この UI は現在ベータ版であり、変更される可能性があります。現在の状態では、ユーザーは組織、リポジトリー、およびイメージタグのみを作成、表示、および削除できます。
  • 古い UI で Red Hat Quay を実行している場合にセッションがタイムアウトになると、ユーザーはポップアップウィンドウでパスワードを再度入力する必要がありました。新しい UI では、ユーザーはメインページに戻り、ユーザー名とパスワードの認証情報を入力する必要があります。これは既知の問題であり、新しい UI の今後のバージョンで修正される予定です。
  • 従来の UI と新しい UI の間で、イメージマニフェストのサイズが報告される方法に違いがあります。従来の UI では、イメージマニフェストはメビバイト単位で報告されていました。新しい UI では、Red Hat Quay はメガバイト (MB) の標準定義を使用して、イメージマニフェストのサイズを報告します。

9.2.2. セッションタイムアウト設定フィールド

次の設定フィールドは、同じ名前の Flask API 設定フィールドに依存しています。

重要

セッションの有効期間を変更することは推奨できません。管理者は、セッションタイムアウトを設定するときに、割り当てられた時間を認識する必要があります。時間が早すぎると、ワークフローが中断する可能性があります。

表9.9 セッションログアウト設定フィールド
フィールド説明

PERMANENT_SESSION_LIFETIME

Integer

永続セッションの有効期限を設定するために使用される timedelta。デフォルトは 31 日で、永続セッションは約 1 か月間存続します。

デフォルト: 2678400

セッションタイムアウトの例 YAML

# ...
PERMANENT_SESSION_LIFETIME: 3000
# ...
Copy to Clipboard

9.3. ユーザーおよびアクセス管理

これらのフィールドを使用して、ユーザーの作成、認証、および管理方法を設定します。これには、スーパーユーザー、アカウントリカバリー、アプリケーション固有のトークン、ログイン動作、LDAP、OAuth、OIDC などの外部 ID プロバイダーの設定が含まれます。

9.3.1. ユーザー設定フィールド

ユーザー設定フィールドは、Red Hat Quay デプロイメントでのユーザーアカウントの動作を定義します。これらのフィールドを使用すると、ユーザーの作成、アクセスレベル、メタデータ追跡、リカバリーオプション、および名前空間管理の制御が可能になります。また、所属組織のガバナンスおよびセキュリティーポリシーに一致するように、招待のみの作成またはスーパーユーザー権限などの制限を適用することもできます。

表9.10 ユーザー設定フィールド
フィールド説明

FEATURE_SUPER_USERS

Boolean

スーパーユーザーがサポートされるかどうか。

デフォルト: true

FEATURE_USER_CREATION

Boolean

ユーザーを作成できるようにするかどうか (スーパーユーザー以外が)。

デフォルト: true

FEATURE_USER_LAST_ACCESSED

Boolean

ユーザーが最後にアクセスした時間を記録するかどうか。

デフォルト: true

FEATURE_USER_LOG_ACCESS

Boolean

true に設定すると、ユーザーは namespace の監査ログにアクセスできます

デフォルト: false

FEATURE_USER_METADATA

Boolean

ユーザーメタデータを収集してサポートするかどうか。

デフォルト: false

FEATURE_USERNAME_CONFIRMATION

Boolean

true に設定すると、OpenID Connect (OIDC) または LDAP などのデータベース以外の認証プロバイダーでログインする場合に、初期ユーザー名を確認および変更できます。
デフォルト: true

FEATURE_USER_RENAME

Boolean

true に設定すると、ユーザーは独自の namespace の名前を変更できます。

デフォルト: false

FEATURE_INVITE_ONLY_USER_CREATION

Boolean

作成するユーザーは別のユーザーから招待を受ける必要があります。

デフォルト: false

FRESH_LOGIN_TIMEOUT

String

新規ログイン時にユーザーがパスワードの再入力を要求されるまでの時間。

: 5m

USERFILES_LOCATION

String

ユーザーがアップロードしたファイルを配置するストレージエンジンの ID。

: s3_us_east

USERFILES_PATH

String

ユーザーがアップロードしたファイルを配置するストレージの下のパス。

: userfiles

USER_RECOVERY_TOKEN_LIFETIME

String

ユーザーアカウントを復元するためのトークンが有効な期間。

パターン: ^[0-9]+(w|m|d|h|s)$
デフォルト: 30m

FEATURE_SUPERUSERS_FULL_ACCESS

Boolean

スーパーユーザーが所有していない名前空間、または明示的なアクセス許可を持っていない名前空間内の他のリポジトリーからコンテンツを読み取り、書き込み、削除する機能をスーパーユーザーに付与します。

デフォルト: False

FEATURE_SUPERUSERS_ORG_CREATION_ONLY

Boolean

スーパーユーザーのみに組織の作成を許可するかどうか。

デフォルト: False

FEATURE_RESTRICTED_USERS

Boolean

RESTRICTED_USERS_WHITELISTTrue に設定した場合:

  • すべての通常ユーザーとスーパーユーザーは、RESTRICTED_USERS_WHITELIST によって許可リストに登録されていない限り、独自の namespace に組織またはコンテンツを作成することが制限されます。
  • 制限されたユーザーは、チームメンバーシップに基づいて組織内で通常の権限を保持します。

デフォルト: False

RESTRICTED_USERS_WHITELIST

String

FEATURE_RESTRICTED_USERS: true を設定すると、特定のユーザーが FEATURE_RESTRICTED_USERS 設定から除外されます。

GLOBAL_READONLY_SUPER_USERS

String

設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。SUPER_USERS 設定フィールドで定義されたスーパーユーザーでのみ機能します。

ユーザー例の YAML

# ...
FEATURE_SUPER_USERS: true
FEATURE_USER_CREATION: true
FEATURE_INVITE_ONLY_USER_CREATION: false
FEATURE_USER_RENAME: true
FEATURE_SUPERUSERS_FULL_ACCESS: true
FEATURE_SUPERUSERS_ORG_CREATION_ONLY: false
FEATURE_RESTRICTED_USERS: true
RESTRICTED_USERS_WHITELIST: 
1

      - user1
GLOBAL_READONLY_SUPER_USERS:
      - quayadmin
FRESH_LOGIN_TIMEOUT: "5m"
USER_RECOVERY_TOKEN_LIFETIME: "30m"
USERFILES_LOCATION: "s3_us_east"
USERFILES_PATH: "userfiles"
# ...
Copy to Clipboard

1
RESTRICTED_USERS_WHITELIST フィールドが設定されている場合、ホワイトリストに登録されたユーザーは、FEATURE_RESTRICTED_USERStrue に設定されていても、組織を作成したり、リポジトリーからコンテンツを読み書きしたりできます。user2user3、および user4 などの他のユーザーは、組織の作成、コンテンツの読み取りまたは書き込みが制限されます。

9.3.2. ロボットアカウント設定フィールド

以下の設定フィールドを使用すると、ロボットアカウントの作成および対話をグローバルに拒否できます。

表9.11 ロボットアカウント設定フィールド
フィールド説明

ROBOTS_DISALLOW

Boolean

true に設定すると、ロボットアカウントの作成だけでなく、すべてのインタラクションが禁止されます。
デフォルト: False

Robot account disallow example YAML

# ...
ROBOTS_DISALLOW: true
# ...
Copy to Clipboard

9.3.3. LDAP 設定フィールド

以下の設定フィールドを使用すると、管理者は Red Hat Quay と LDAP ベースの認証システムを統合できます。AUTHENTICATION_TYPELDAP に設定されている場合、Red Hat Quay は LDAP ディレクトリーに対してユーザーを認証し、チームの同期、スーパーユーザーアクセス制御、制限付きユーザーロール、セキュアな接続パラメーターなどのオプション機能をサポートします。

このセクションでは、以下の LDAP シナリオの YAML の例を紹介します。

  • 基本的な LDAP 設定
  • LDAP 制限付きユーザー設定
  • LDAP スーパーユーザー設定
表9.12 LDAP の設定
フィールド説明

AUTHENTICATION_TYPE
(必須)

String

LDAP に設定する必要があります。

FEATURE_TEAM_SYNCING

Boolean

認証エンジン (OIDC、LDAP または Keystone) のバッキンググループからのチームメンバーシップの同期を許可するかどうか。

デフォルト: true

FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP

Boolean

有効にすると、スーパーユーザー以外のユーザーもチームの同期を設定できます。

デフォルト: false

LDAP_ADMIN_DN

String

LDAP 認証の管理 DN。

LDAP_ADMIN_PASSWD

String

LDAP 認証の管理パスワード。

LDAP_ALLOW_INSECURE_FALLBACK

Boolean

LDAP 認証で SSL の非セキュアなフォールバックを許可するかどうか。

LDAP_BASE_DN

文字列の配列

LDAP 認証のベース DN。

LDAP_EMAIL_ATTR

String

LDAP 認証のメール属性。

LDAP_UID_ATTR

String

LDAP 認証の uid 属性。

LDAP_URI

String

LDAP URI。

LDAP_USER_FILTER

String

LDAP 認証のユーザーフィルター。

LDAP_USER_RDN

文字列の配列

LDAP 認証のユーザー RDN。

LDAP_SECONDARY_USER_RDNS

文字列の配列

ユーザーオブジェクトが存在する組織単位が複数ある場合は、Secondary User Relative DNs を指定します。

TEAM_RESYNC_STALE_TIME

String

チームでチーム同期が有効になっている場合は、そのメンバーシップを確認し、必要に応じて再同期する頻度。

パターン:
^[0-9]+(w|m|d|h|s)$
例:
2h
デフォルト:
30m

LDAP_SUPERUSER_FILTER

String

LDAP_USER_FILTER 設定フィールドのサブセット。設定すると、Red Hat Quay 管理者は、Red Hat Quay が認証プロバイダーとして LDAP を使用する場合に、Lightweight Directory Access Protocol (LDAP) ユーザーをスーパーユーザーとして設定できます。

このフィールドを使用すると、管理者は Red Hat Quay 設定ファイルを更新してデプロイメントを再起動することなく、スーパーユーザーを追加または削除できます。

このフィールドでは、AUTHENTICATION_TYPELDAP に設定されている必要があります。

LDAP_GLOBAL_READONLY_SUPERUSER_FILTER

String

設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。LDAP_SUPERUSER_FILTER 設定フィールドで定義されたスーパーユーザーでのみ機能します。

LDAP_RESTRICTED_USER_FILTER

String

LDAP_USER_FILTER 設定フィールドのサブセット。設定すると、Red Hat Quay 管理者は、Red Hat Quay が認証プロバイダーとして LDAP を使用する場合に、Lightweight Directory Access Protocol (LDAP) ユーザーを制限付きユーザーとして設定できます。

このフィールドでは、AUTHENTICATION_TYPELDAP に設定されている必要があります。

FEATURE_RESTRICTED_USERS

Boolean

LDAP_RESTRICTED_USER_FILTER をアクティブにして True に設定すると、定義された LDAP グループにリストされているユーザーのみが制限されます。

デフォルト: False

LDAP_TIMEOUT

Integer

LDAP 操作の時間制限を秒単位で指定します。これにより、LDAP 検索、バインド、またはその他の操作にかかる時間が制限されます。ldapsearch-l オプションと同様に、クライアント側の操作のタイムアウトを設定します。

デフォルト: 10

LDAP_NETWORK_TIMEOUT

Integer

LDAP サーバーへの接続を確立するための時間制限を秒単位で指定します。これは、ldapsearch-o nettimeout オプションと同様に、ネットワーク操作中に Red Hat Quay が応答を待機する最大時間です。

デフォルト: 10

基本的な LDAP 設定例

# ...
AUTHENTICATION_TYPE: LDAP 
1

# ...
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com 
2

LDAP_ADMIN_PASSWD: ABC123 
3

LDAP_ALLOW_INSECURE_FALLBACK: false 
4

LDAP_BASE_DN: 
5

  - dc=example
  - dc=com
LDAP_EMAIL_ATTR: mail 
6

LDAP_UID_ATTR: uid 
7

LDAP_URI: ldap://<example_url>.com 
8

LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,dc=<domain_name>,dc=com) 
9

LDAP_USER_RDN: 
10

  - ou=people
LDAP_SECONDARY_USER_RDNS: 
11

    - ou=<example_organization_unit_one>
    - ou=<example_organization_unit_two>
    - ou=<example_organization_unit_three>
    - ou=<example_organization_unit_four>
Copy to Clipboard

1
必須。LDAP に設定する必要があります。
2
必須。LDAP 認証の管理 DN。
3
必須。LDAP 認証の管理パスワード。
4
必須。LDAP 認証に SSL/TLS の安全でないフォールバックを許可するかどうか。
5
必須。LDAP 認証のベース DN。
6
必須。LDAP 認証のメール属性。
7
必須。LDAP 認証の UID 属性。
8
必須。LDAP URI。
9
必須。LDAP 認証のユーザーフィルター。
10
必須。LDAP 認証のユーザー RDN。
11
オプション: ユーザーオブジェクトが存在する組織単位が複数ある場合の Secondary User Relative DN。

LDAP 制限付きユーザー設定の例 YAML

# ...
AUTHENTICATION_TYPE: LDAP
# ...
FEATURE_RESTRICTED_USERS: true 
1

# ...
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com
LDAP_ADMIN_PASSWD: ABC123
LDAP_ALLOW_INSECURE_FALLBACK: false
LDAP_BASE_DN:
    - o=<organization_id>
    - dc=<example_domain_component>
    - dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldap://<example_url>.com
LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,o=<example_organization_unit>,dc=<example_domain_component>,dc=com)
LDAP_RESTRICTED_USER_FILTER: (<filterField>=<value>) 
2

LDAP_USER_RDN:
    - ou=<example_organization_unit>
    - o=<organization_id>
    - dc=<example_domain_component>
    - dc=com
# ...
Copy to Clipboard

1
LDAP 制限ユーザーを設定する場合は true に設定する必要があります。
2
指定されたユーザーを制限されたユーザーとして設定します。

LDAP スーパーユーザー設定参照の例

# ...
AUTHENTICATION_TYPE: LDAP
# ...
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com
LDAP_ADMIN_PASSWD: ABC123
LDAP_ALLOW_INSECURE_FALLBACK: false
LDAP_BASE_DN:
    - o=<organization_id>
    - dc=<example_domain_component>
    - dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldap://<example_url>.com
LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,o=<example_organization_unit>,dc=<example_domain_component>,dc=com)
LDAP_SUPERUSER_FILTER: (<filterField>=<value>) 
1

LDAP_USER_RDN:
    - ou=<example_organization_unit>
    - o=<organization_id>
    - dc=<example_domain_component>
    - dc=com
# ...
Copy to Clipboard

1
指定されたユーザーをスーパーユーザーとして設定します。

9.3.4. OAuth 設定フィールド

以下のフィールドは、OAuth を使用して外部 ID プロバイダーによる認証を処理する際の Red Hat Quay の動作を定義します。トークンの割り当てやホワイトリスト化されたクライアント ID、GitHub および Google のプロバイダー固有の設定などのグローバル OAuth オプションを設定できます。

表9.13 OAuth フィールド
フィールド説明

DIRECT_OAUTH_CLIENTID_WHITELIST

文字列の配列

ユーザーの承認なしに直接 OAuth 承認を実行できる Quay 管理 アプリケーションのクライアント ID のリスト。

FEATURE_ASSIGN_OAUTH_TOKEN

Boolean

組織管理者が他のユーザーに OAuth トークンを割り当てることを許可します。

グローバル OAuth の例の YAML

# ...
DIRECT_OAUTH_CLIENTID_WHITELIST:
  - <quay_robot_client>
  - <quay_app_token_issuer>
FEATURE_ASSIGN_OAUTH_TOKEN: true
# ...
Copy to Clipboard

表9.14 GitHub OAuth 設定フィールド
フィールド説明

FEATURE_GITHUB_LOGIN

Boolean

GitHub ログインがサポートされるかどうか。

**デフォルト: False

GITHUB_LOGIN_CONFIG

Object

外部ログインプロバイダーとして GitHub (Enterprise) を使用するための設定。

   .ALLOWED_ORGANIZATIONS

文字列の配列

ORG_RESTRICT オプションを使用するためにホワイトリスト化された GitHub (Enterprise) 組織の名前。

   .API_ENDPOINT

String

使用する GitHub (Enterprise) API のエンドポイント。github.com に対してオーバーライドする必要があります。

例: https://api.github.com/

   .CLIENT_ID
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアント ID。GITHUB_TRIGGER_CONFIG とは共有できません。

例: < client_id>

   .CLIENT_SECRET
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアントシークレット。

例: &lt ;client_secret>

   .GITHUB_ENDPOINT
(必須)

String

GitHub (Enterprise) のエンドポイント。

: https://github.com/

   .ORG_RESTRICT

Boolean

true の場合は、組織のホワイトリスト内のユーザーのみが、このプロバイダーを使用してログインできます。

GitHub OAth のサンプル YAML

# ...
FEATURE_GITHUB_LOGIN: true
GITHUB_LOGIN_CONFIG:
  ALLOWED_ORGANIZATIONS:
    - <myorg>
    - <dev-team>
  API_ENDPOINT: <https://api.github.com/>
  CLIENT_ID: <client_id>
  CLIENT_SECRET: <client_secret>
  GITHUB_ENDPOINT: <https://github.com/>
  ORG_RESTRICT: true
# ...
Copy to Clipboard

表9.15 Google OAuth 設定フィールド
フィールド説明

FEATURE_GOOGLE_LOGIN

Boolean

Google ログインがサポートされるかどうか。

**デフォルト: False

GOOGLE_LOGIN_CONFIG

Object

外部認証に Google を使用するための設定。

   .CLIENT_ID
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアント ID。

例: &lt ;client_id>

   .CLIENT_SECRET
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアントシークレット。

例: &lt ;client_secret>

Google OAuth の例 YAML

# ...
FEATURE_GOOGLE_LOGIN: true
GOOGLE_LOGIN_CONFIG:
  CLIENT_ID: <client_id>
  CLIENT_SECRET: <client_secret>
# ...
Copy to Clipboard

9.3.5. OIDC 設定フィールド

Azure Entra ID (以前の Azure AD)、Okta、Keycloak など、OpenID Connect (OIDC)互換アイデンティティープロバイダーを介してユーザーを認証するように Red Hat Quay を設定できます。これらのフィールドは、OIDC ログインフロー時に使用される必要なクライアント認証情報、エンドポイント、およびトークンの動作を定義します。

表9.16 OIDC フィールド
フィールド説明

<文字列>_LOGIN_CONFIG
(必須)

String

OIDC 設定を保持する親キー。通常は、OIDC プロバイダーの名前 (AZURE_LOGIN_CONFIG など) ですが、任意の文字列も受け入れられます。

.CLIENT_ID
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアント ID。

例: 0e8dbe15c4c7630b6780

.CLIENT_SECRET
(必須)

String

Red Hat Quay インスタンスの登録クライアントシークレット。

例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

   .LOGIN_BINDING_FIELD

String

内部承認が LDAP に設定されている場合に使用されます。Red Hat Quay はこのパラメーターを読み取り、このユーザー名でユーザーの LDAP ツリーで検索を試みます。存在する場合は、その LDAP アカウントへのリンクが自動的に作成されます。

   .LOGIN_SCOPES

Object

Red Hat Quay が OIDC プロバイダーとの通信に使用するスコープを追加します。

   .OIDC_ENDPOINT_CUSTOM_PARAMS

String

OIDC エンドポイントでのカスタムクエリーパラメーターのサポートを追加しました。エンドポイント authorization_endpointtoken_endpoint、および user_endpoint がサポートされています。

   .OIDC_ISSUER

String

ユーザーが検証する発行者を定義できます。たとえば、JWT トークンは、トークンを発行したユーザーを定義する iss と呼ばれるパラメーターをコンテナー化します。デフォルトでは、これはすべての OIDC プロバイダーによって公開される .well-know/openid/configuration エンドポイントから読み込まれます。この検証に失敗すると、ログインはありません。

.OIDC_SERVER
(必須)

String

認証に使用される OIDC サーバーのアドレス。

例: https://sts.windows.net/6c878…​/

   .PREFERRED_USERNAME_CLAIM_NAME

String

優先ユーザー名をトークンのパラメーターに設定します。

   .SERVICE_ICON

String

ログイン画面のアイコンを変更します。

.SERVICE_NAME
(必須)

String

認証されているサービスの名前。

例: Microsoft Entra ID

   .VERIFIED_EMAIL_CLAIM_NAME

String

ユーザーの電子メールアドレスを確認するために使用されるクレームの名前。

   .PREFERRED_GROUP_CLAIM_NAME

String

ユーザーのグループメンバーシップに関する情報を保持する OIDC トークンペイロード内のキー名。

   .OIDC_DISABLE_USER_ENDPOINT

Boolean

/userinfo エンドポイントを許可するか無効にするかを指定します。Azure Entra ID を使用する場合、Azure は /userinfo エンドポイントを呼び出す代わりにトークンからユーザーの情報を取得するため、このフィールドを true に設定する必要があります。

デフォルト: false

OIDC 例の YAML

AUTHENTICATION_TYPE: OIDC
# ...
<oidc_provider>_LOGIN_CONFIG:
  CLIENT_ID: <client_id>
  CLIENT_SECRET: <client_secret>
  LOGIN_BINDING_FIELD: <login_binding_field>
  LOGIN_SCOPES:
    - openid
    - email
    - profile
  OIDC_ENDPOINT_CUSTOM_PARAMS:
    authorization_endpoint:
      some: "param"
    token_endpoint:
      some: "param"
    user_endpoint:
      some: "param"
  OIDC_ISSUER: <oidc_issuer_url>
  OIDC_SERVER: <oidc_server_address>
  PREFERRED_USERNAME_CLAIM_NAME: <preferred_username_claim>
  SERVICE_ICON: <service_icon_url>
  SERVICE_NAME: <service_name>
  VERIFIED_EMAIL_CLAIM_NAME: <verified_email_claim>
  PREFERRED_GROUP_CLAIM_NAME: <preferred_group_claim>
  OIDC_DISABLE_USER_ENDPOINT: true
# ...
Copy to Clipboard

9.3.6. Recaptcha 設定フィールド

Red Hat Quay インスタンスで Recaptcha サポートを有効にすると、自動システムによるユーザーのログインおよびアカウントの回復フォームの保護に役立ちます。

表9.17 Recaptcha 設定フィールド
フィールド説明

FEATURE_RECAPTCHA

Boolean

ユーザーログインおよびリカバリーに Recaptcha が必要かどうか

デフォルト: False

RECAPTCHA_SECRET_KEY

String

recaptcha が有効になっている場合は、Recaptcha サービスの秘密鍵

RECAPTCHA_SITE_KEY

String

recaptcha が有効になっている場合は、Recaptcha サービスのサイトキー

reCAPTCHA の例の YAML

# ...
FEATURE_RECAPTCHA: true
RECAPTCHA_SITE_KEY: "<site_key>"
RECAPTCHA_SECRET_KEY: "<secret_key>"
# ...
Copy to Clipboard

9.3.7. JWT 設定フィールド

Red Hat Quay は、JSON Web Token (JWT)を使用して外部認証をサポートするように設定できます。このインテグレーションにより、サードパーティーのアイデンティティープロバイダーまたはトークン発行者は、トークンの検証、ユーザールックアップ、およびパーミッションクエリーを処理する特定のエンドポイントを呼び出して、ユーザーを認証および承認できます。

表9.18 JWT 設定フィールド
フィールド説明

JWT_AUTH_ISSUER

String

JWT ユーザーのエンドポイント

パターン: ^http(s)?://(.)+$
: http://192.168.99.101:6060

JWT_GETUSER_ENDPOINT

String

JWT ユーザーのエンドポイント
パターン: ^http(s)?://(.)+$
: http://192.168.99.101:6060

JWT_QUERY_ENDPOINT

String

JWT クエリーのエンドポイント

パターン: ^http(s)?://(.)+$
: http://192.168.99.101:6060

JWT_VERIFY_ENDPOINT

String

JWT 検証のエンドポイント

パターン: ^http(s)?://(.)+$
: http://192.168.99.101:6060

JWT 例の YAML

# ...
JWT_AUTH_ISSUER: "http://192.168.99.101:6060"
JWT_GETUSER_ENDPOINT: "http://192.168.99.101:6060/getuser"
JWT_QUERY_ENDPOINT: "http://192.168.99.101:6060/query"
JWT_VERIFY_ENDPOINT: "http://192.168.99.101:6060/verify"
# ...
Copy to Clipboard

9.3.8. アプリケーショントークン設定フィールド

アプリケーション固有のトークンにより、ユーザーはトークンベースの認証情報を使用して Red Hat Quay で認証できるようになります。これらのフィールドは、Docker などの CLI ツールに役に立ちます。

表9.19 アプリケーショントークン設定フィールド
フィールド説明

FEATURE_APP_SPECIFIC_TOKENS

Boolean

有効な場合、ユーザーは Docker CLI で使用するトークンを作成できます。

デフォルト: True

APP_SPECIFIC_TOKEN_EXPIRATION

String

外部アプリトークンの有効期限。

デフォルト: なし
パターン: ^[0-9]+(w|m|d|h|s)$

EXPIRED_APP_SPECIFIC_TOKEN_GC

String

期限切れとなった外部アプリケーションがガべージコレクションが行われるまでに留まる期間

デフォルト:
1d

アプリケーショントークンの例 YAML

# ...
FEATURE_APP_SPECIFIC_TOKENS: true
APP_SPECIFIC_TOKEN_EXPIRATION: "30d"
EXPIRED_APP_SPECIFIC_TOKEN_GC: "1d"
# ...
Copy to Clipboard

9.4. セキュリティーおよびパーミッション

このセクションでは、Red Hat Quay 内のコアセキュリティー動作およびアクセスポリシーを管理する設定フィールドについて説明します。

9.4.1. 名前空間およびリポジトリー管理設定フィールド

次の設定フィールドは、自動イメージのプッシュ中の動作、可視性のデフォルト、およびレート制限例外を含む、Red Hat Quay による namespace とリポジトリーの管理方法を管理します。

表9.20 名前空間およびリポジトリー管理設定フィールド
フィールド説明

DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT

数値

namespace でキューに入れることができるデフォルトの最大ビルド数です。

デフォルト: None

CREATE_PRIVATE_REPO_ON_PUSH

Boolean

プッシュで作成された新規リポジトリーがプライベート表示に設定されているかどうか。

デフォルト: True

CREATE_NAMESPACE_ON_PUSH

Boolean

既存の組織への新規プッシュで namespace を作成するかどうか。

デフォルト: False

PUBLIC_NAMESPACES

文字列の配列

名前空間がパブリック名前空間リストで定義されている場合、ユーザーが名前空間のメンバーであるかどうかに関係なく、その名前空間は すべて のユーザーのリポジトリーリストページに表示されます。一般的には、企業のお客様が "よく知られた" 名前空間のセットを設定する際に使用されます。

NON_RATE_LIMITED_NAMESPACES

文字列の配列

FEATURE_RATE_LIMITS を使用してレートの制限が有効で、特定の namespace で無制限のアクセス権が必要な場合に、オーバーライドできます。

DISABLE_PUSHES

Boolean

他のすべての機能を維持しながら、レジストリーへの新しいコンテンツのプッシュを無効にします。データベースが read-only として設定されていないため、read-only モードとは異なります。DISABLE_PUSHEStrue に設定されていると、Red Hat Quay ガベージコレクターは無効になります。その結果、PERMANENTLY_DELETE_TAGS が有効になっていると、Red Hat Quay UI を使用してタグを永久に削除しても、タグはすぐに削除されません。代わりに、DISABLE_PUSHESfalse に設定され、ガベージコレクターが再度有効になるまで、イメージはバックエンドストレージに残ります。Red Hat Quay 管理者は、DISABLE_PUSHESPERMANENTLY_DELETE_TAGS を一緒に使用する場合、この項目に注意する必要があります。

デフォルト: False

namespace とリポジトリー管理の例 YAML

# ...
DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT: 10
CREATE_PRIVATE_REPO_ON_PUSH: true
CREATE_NAMESPACE_ON_PUSH: false
PUBLIC_NAMESPACES:
  - redhat
  - opensource
  - infra-tools
NON_RATE_LIMITED_NAMESPACES:
  - ci-pipeline
  - trusted-partners
DISABLE_PUSHES: false
# ...
Copy to Clipboard

9.4.2. ネストされたリポジトリー設定フィールド

ネストされたリポジトリーパス名のサポートが FEATURE_EXTENDED_REPOSITORY_NAMES プロパティーに追加されました。このオプションの設定は、デフォルトで config.yaml に追加されます。有効にすると、リポジトリー名で / を使用できます。

表9.21 ネストされたリポジトリー設定フィールド
フィールド説明

FEATURE_EXTENDED_REPOSITORY_NAMES

Boolean

ネストされたリポジトリーのサポートを有効にします。

デフォルト: True

ネストされたリポジトリーの例 YAML

# ...
FEATURE_EXTENDED_REPOSITORY_NAMES: true
# ...
Copy to Clipboard

9.5. 追加のセキュリティー設定フィールド

以下の設定フィールドは、Red Hat Quay デプロイメントの追加のセキュリティー制御を提供します。これらのオプションにより、管理者は、認証プラクティスの適用、コンテンツへの匿名アクセスの制御、チームの招待が必要、セキュリティー要件が強化された環境で FIPS 準拠の暗号化機能を有効にすることができます。

表9.22 追加のセキュリティー設定フィールド
機能説明

FEATURE_REQUIRE_TEAM_INVITE

Boolean

ユーザーをチームに追加するときに招待を必要とするかどうか。

デフォルト: True

FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH

Boolean

(暗号化されたトークンではなく) 暗号化されていないパスワードを Basic 認証に使用できるかどうか

デフォルト: False

FEATURE_ANONYMOUS_ACCESS

Boolean

匿名ユーザーにパブリックリポジトリーの参照とプルを許可するかどうか。

デフォルト: True

FEATURE_FIPS

Boolean

true に設定すると、Red Hat Quay は FIPS 準拠のハッシュ関数を使用して実行されます。

デフォルト: False

追加のセキュリティー例 YAML

# ...
FEATURE_REQUIRE_TEAM_INVITE: true
FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH: false
FEATURE_ANONYMOUS_ACCESS: true
FEATURE_FIPS: false
# ...
Copy to Clipboard

9.6. レート制限およびパフォーマンス設定フィールド

以下のフィールドは、Red Hat Quay デプロイメントのレート制限およびパフォーマンス関連の動作を制御します。

表9.23 レート制限およびパフォーマンス設定フィールド
フィールド説明

FEATURE_RATE_LIMITS

Boolean

API およびレジストリーエンドポイントでレート制限を有効にするかどうか。FEATURE_RATE_LIMITS を true に設定すると、nginx は特定の API 呼び出しを 1 秒あたり 30 回に制限します。この機能が設定されていないと、API コールは 1 秒間に 300 回に制限されます (事実上無制限)。

デフォルト: false

PROMETHEUS_NAMESPACE

String

公開されているすべての Prometheus メトリクスに適用される接頭辞。

デフォルト: quay

レート制限とパフォーマンスの例 YAML

# ...
FEATURE_RATE_LIMITS: false
PROMETHEUS_NAMESPACE: quay
# ...
Copy to Clipboard

9.8. ストレージおよびデータ管理

このセクションでは、Red Hat Quay がデータを保存、管理、および監査する方法を管理する設定フィールドについて説明します。

9.8.1. イメージストレージ機能

Red Hat Quay は、コンテナーイメージデータの管理におけるスケーラビリティー、耐障害性、および柔軟性を強化するイメージストレージ機能をサポートしています。この機能により、Red Hat Quay はリポジトリーをミラーリングし、NGINX を介したプロキシーストレージアクセスを提供し、複数のストレージエンジン間でデータを複製できます。

表9.25 ストレージ設定機能
フィールド説明

FEATURE_REPO_MIRROR

Boolean

true に設定されている場合は、リポジトリーのミラーリングを有効にします。

デフォルト: false

FEATURE_PROXY_STORAGE

Boolean

NGINX を使用してストレージ内のすべての直接ダウンロード URL をプロキシーするかどうか。

デフォルト: false

FEATURE_STORAGE_REPLICATION

Boolean

ストレージエンジン間で自動的にレプリケートするかどうか。

のデフォルト: false

イメージストレージの例 YAML

# ...
FEATURE_REPO_MIRROR: true
FEATURE_PROXY_STORAGE: false
FEATURE_STORAGE_REPLICATION: true
# ...
Copy to Clipboard

9.8.2. アクションログストレージ設定フィールド

Red Hat Quay は、リポジトリーイベント、認証アクション、イメージ操作など、ユーザーおよびシステムアクティビティーを追跡する詳細なアクションログを維持します。デフォルトでは、このログデータはデータベースに保存されますが、管理者は高度な分析、監査、またはコンプライアンスのために Elasticsearch や Splunk などの外部システムにログをエクスポートまたは転送するようにデプロイメントを設定できます。

表9.26 アクションログストレージ設定フィールド
フィールド説明

FEATURE_LOG_EXPORT

Boolean

アクションログのエクスポートを許可するかどうか。

デフォルト: True

LOGS_MODEL

String

ログデータを処理するための推奨される方法を指定します。

値: databasetransition_reads_both_writes_eselasticsearchsplunk のいずれか。
デフォルト: database

LOGS_MODEL_CONFIG

Object

アクションログのログモデル設定。

ALLOW_WITHOUT_STRICT_LOGGING

Boolean

True に設定すると、Splunk や ElasticSearch などの外部ログシステムが断続的に利用できなくなる場合でも、ユーザーが通常どおりイメージをプッシュできます。代わりに、イベントは stdout に記録されます。設定されている場合は、ALLOW_PULLS_WITHOUT_STRICT_LOGGING をオーバーライドします。

デフォルト: False

アクションログストレージ YAML の例

# ...
FEATURE_LOG_EXPORT: true
LOGS_MODEL: elasticsearch
LOGS_MODEL_CONFIG:
  elasticsearch:
    endpoint: http://elasticsearch.example.com:9200
    index_prefix: quay-logs
    username: elastic
    password: changeme
ALLOW_WITHOUT_STRICT_LOGGING: true
# ...
Copy to Clipboard

9.8.2.1. アクションログのローテーションおよびアーカイブ設定

このセクションでは、Red Hat Quay でのアクションログのローテーションおよびアーカイブに関連する設定フィールドについて説明します。これを有効にすると、古いログを自動的にローテーションおよびアーカイブして、指定されたストレージの場所にアーカイブすることができ、ログの保持とストレージの使用率を効率的に管理できるようになります。

表9.27 アクションログのローテーションおよびアーカイブ設定
フィールド説明

FEATURE_ACTION_LOG_ROTATION

Boolean

ログローテーションおよび archival を有効にすると、30 日以上経過したすべてのログをストレージに移動します。

デフォルト: false

ACTION_LOG_ARCHIVE_LOCATION

String

アクションログのアーカイブが有効な場合は、アーカイブされたデータを配置するストレージエンジン。

例: s3_us_east

ACTION_LOG_ARCHIVE_PATH

String

アクションログのアーカイブが有効な場合は、アーカイブされたデータを配置するストレージのパス。

例: archives/actionlogs

ACTION_LOG_ROTATION_THRESHOLD

String

ログをローテーションする間隔。

例: 30d

アクションログのローテーションおよびアーカイブ例の YAML

# ...
FEATURE_ACTION_LOG_ROTATION: true
ACTION_LOG_ARCHIVE_LOCATION: s3_us_east
ACTION_LOG_ARCHIVE_PATH: archives/actionlogs
ACTION_LOG_ROTATION_THRESHOLD: 30d
# ...
Copy to Clipboard

9.8.2.2. アクションログの監査設定

このセクションでは、Red Hat Quay 内の監査ログの設定フィールドを説明します。有効にすると、監査ログは、通常のユーザー、ロボットアカウント、トークンベースのアカウントの UI ログイン、ログアウト、Docker ログインなど、詳細なユーザーアクティビティーを追跡します。

表9.28 監査ログ設定フィールド
フィールド説明

ACTION_LOG_AUDIT_LOGINS

Boolean

True に設定すると、UI へのログインとログアウトや、通常のユーザー、ロボットアカウント、アプリケーション固有のトークンアカウントによる Docker を使用したログインなど、詳細なイベントが追跡されます。

デフォルト: True

監査ログ設定の例の YAML

# ...
ACTION_LOG_AUDIT_LOGINS: true
# ...
Copy to Clipboard

9.8.3. Elasticsearch 設定フィールド

以下の設定フィールドを使用して、Red Hat Quay を外部 Elasticsearch サービスと統合します。これにより、アクションログ、リポジトリーイベント、内部データベース外のその他の運用レコードなど、構造化データを保存およびクエリーできます。

表9.29 ログモデル設定(LOGS_MODEL_CONFIG)フィールド
フィールド説明

LOGS_MODEL_CONFIG.elasticsearch_config.access_key

String

Elasticsearch ユーザー(AWS ES の場合は IAM キー)。
:some_string

.elasticsearch_config.host

String

Elasticsearch クラスターのエンドポイント。
:host.elasticsearch.example

.elasticsearch_config.index_prefix

String

Elasticsearch インデックスの接頭辞。
:logentry_

.elasticsearch_config.index_settings

Object

Elasticsearch のインデックス設定。

LOGS_MODEL_CONFIG.elasticsearch_config.use_ssl

Boolean

Elasticsearch に SSL を使用するかどうか
デフォルト
:True
:True

.elasticsearch_config.secret_key

String

Elasticsearch パスワード(AWS ES の場合は IAM シークレット)。
:some_secret_string

.elasticsearch_config.aws_region

String

AWS リージョン。
:us-east-1

.elasticsearch_config.port

数値

Elasticsearch クラスターのポート。
:1234

.kinesis_stream_config.aws_secret_key

String

AWS secret key。
:some_secret_key

.kinesis_stream_config.stream_name

String

アクションログの送信先となる AWS Kinesis ストリーム。
:logentry-kinesis-stream

.kinesis_stream_config.aws_access_key

String

AWS アクセスキー。
:some_access_key

.kinesis_stream_config.retries

数値

1 回のリクエストの最大再試行回数。
:5

.kinesis_stream_config.read_timeout

数値

読み取りタイムアウト(秒単位)。
:5

.kinesis_stream_config.max_pool_connections

数値

プールの最大接続数。
:10

.kinesis_stream_config.aws_region

String

AWS リージョン。
:us-east-1

.kinesis_stream_config.connect_timeout

数値

接続タイムアウト(秒単位)。
:5

.producer

String

プロデューサータイプをログに記録します。
許可される値 は、kafkaelasticsearchkinesis_stream
:kafka

.kafka_config.topic

String

ログエントリーの公開に使用される Kafka トピック。
:logentry

.kafka_config.bootstrap_servers

アレイ

クライアントのブートストラップに使用される Kafka ブローカーのリスト。

.kafka_config.max_block_seconds

数値

send () 操作中にブロックする最大秒数。
:10

Elasticsearch の例の YAML

# ...
FEATURE_LOG_EXPORT: true
LOGS_MODEL: elasticsearch
LOGS_MODEL_CONFIG:
  producer: elasticsearch
  elasticsearch_config:
    access_key: elastic_user
    secret_key: elastic_password
    host: es.example.com
    port: 9200
    use_ssl: true
    aws_region: us-east-1
    index_prefix: logentry_
    index_settings:
      number_of_shards: 3
      number_of_replicas: 1
ALLOW_WITHOUT_STRICT_LOGGING: true
# ...
Copy to Clipboard

9.8.3.1. Splunk 設定フィールド

次のフィールドを使用して、アクションログを Splunk エンドポイントにエクスポートするように Red Hat Quay を設定します。この設定により、監査ログとイベントログを外部 Splunk サーバーに送信して、集中分析、検索、および長期保存を行うことができます。

表9.30 Splunk 設定フィールド
フィールド説明

producer

String

Splunk をログエクスポーターとして設定する場合は、splunk に設定する必要があります。

splunk_config

Object

Splunk アクションログまたは Splunk クラスター設定のログモデル設定。

.host

String

Splunk クラスターのエンドポイント。

.port

Integer

Splunk 管理クラスターエンドポイントのポート番号。

.BEARER_TOKEN

String

Splunk での認証に使用されるベアラートークン。

.verify_ssl

Boolean

HTTPS 接続の TLS/SSL 検証を有効(True)または無効(False)にします。

.index_prefix

String

Splunk によって使用されるインデックス接頭辞。

.ssl_ca_path

String

SSL 検証用の認証局(CA)を含む .pem ファイルへの相対コンテナーパス。

Splunk 設定例の YAML

# ...
LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
    producer: splunk
    splunk_config:
        host: http://<user_name>.remote.csb
        port: 8089
        bearer_token: <bearer_token>
        url_scheme: <http/https>
        verify_ssl: False
        index_prefix: <splunk_log_index_name>
        ssl_ca_path: <location_to_ssl-ca-cert.pem>
# ...
Copy to Clipboard

9.8.3.1.1. Splunk HEC 設定フィールド

Red Hat Quay 用に Splunk HTTP Event Collector (HEC) を設定する場合は、次のフィールドを使用できます。

表9.31 Splunk HEC 設定フィールド
フィールド説明

producer

String

Splunk HTTP Event Collector (HEC)を設定する場合は、splunk_hec に設定する必要があります。

splunk_hec_config

Object

Splunk HTTP Event Collector アクションログのログモデル設定。

.host

String

Splunk クラスターのエンドポイント。

.port

Integer

Splunk 管理クラスターのエンドポイントポート。

.hec_token

String

Splunk での認証に使用される HEC トークン。

.url_scheme

String

Splunk サービスにアクセスするための URL スキーム。Splunk が SSL/TLS の背後にある場合は、https を使用します。

.verify_ssl

Boolean

HTTPS 接続の SSL/TLS 検証を有効(true)または無効(false)にします。

.index

String

ログストレージに使用する Splunk インデックス。

.splunk_host

String

ログに記録されたイベントに割り当てるホスト名。

.splunk_sourcetype

String

イベントに関連付ける Splunk ソースタイプ

Splunk HEC 例 YAML

# ...
LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
  producer: splunk_hec
  splunk_hec_config:
    host: prd-p-aaaaaq.splunkcloud.com
    port: 8088
    hec_token: 12345678-1234-1234-1234-1234567890ab
    url_scheme: https
    verify_ssl: False
    index: quay
    splunk_host: quay-dev
    splunk_sourcetype: quay_logs
# ...
Copy to Clipboard

9.9. ビルドと自動化

このセクションでは、Red Hat Quay 内で自動ビルドを管理するために利用できる設定オプションを説明します。これらの設定は、Dockerfile のビルドのトリガー、処理、保存方法、およびビルドログの管理およびアクセス方法を制御します。

これらのフィールドを使用すると、以下のことができます。

  • ソースリポジトリーからの自動ビルドを有効または無効にします。
  • ビルドマネージャーの動作およびリソース管理を設定します。
  • 監査またはデバッグ目的で、ビルドログへのアクセスおよび保持を制御します。

これらのオプションにより、CI/CD パイプラインを合理化し、ビルドポリシーの適用、レジストリー全体でビルド履歴の可視性を維持するのに役立ちます。

9.9.1. Dockerfile ビルドトリガーフィールド

このセクションでは、Dockerfiles およびソースコードリポジトリーから Red Hat Quay での自動ビルドを有効にし、管理するために使用される設定フィールドについて説明します。これらのフィールドでは、ビルドの動作を定義し、GitHub、GitLab、および Bitbucket トリガーのサポートを有効にし、各 SCM プロバイダーの OAuth 認証情報およびエンドポイントを指定できます。

表9.32 Dockerfile ビルドのサポート
フィールド説明

FEATURE_BUILD_SUPPORT

Boolean

Dockerfile ビルドをサポートするかどうか

デフォルト: False

SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD

数値

None に設定されていない場合、ビルドトリガーが自動的に無効にされる前に、連続で失敗できる回数。

デフォルト: 100

SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD

数値

None に設定されていない場合、ビルドトリガーが自動的に無効にされる前に、連続で発生可能な内部エラーの回数。

デフォルト: 5

Dockerfile ビルドのサポートサンプル YAML

# ...
FEATURE_BUILD_SUPPORT: true
SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD: 100
SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD: 5
# ...
Copy to Clipboard

表9.33 GitHub ビルドトリガー
フィールド説明

FEATURE_GITHUB_BUILD

Boolean

GitHub ビルドトリガーをサポートするかどうか。

デフォルト: False

GITHUB_TRIGGER_CONFIG

Object

ビルドトリガーに GitHub Enterprise を使用するための設定。

   .GITHUB_ENDPOINT
(必須)

String

GitHub Enterprise のエンドポイント。

例: https://github.com/

   .API_ENDPOINT

String

使用する GitHub Enterprise API のエンドポイント。github.com に対してオーバーライドする必要があります。

: https://api.github.com/

   .CLIENT_ID
(必須)

String

この Red Hat Quay インスタンスの登録済みクライアント ID。これを GITHUB_LOGIN_CONFIG と共有することはできません。

   .CLIENT_SECRET
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアントシークレット。

GitHub ビルドトリガーの例 YAML

# ...
FEATURE_GITHUB_BUILD: true
GITHUB_TRIGGER_CONFIG:
  GITHUB_ENDPOINT: https://github.com/
  API_ENDPOINT: https://api.github.com/
  CLIENT_ID: your-client-id
  CLIENT_SECRET: your-client-secret
# ...
Copy to Clipboard

表9.34 BitBucket ビルドトリガー
フィールド説明

FEATURE_BITBUCKET_BUILD

Boolean

Bitbucket ビルドトリガーをサポートするかどうか。

デフォルト: False

BITBUCKET_TRIGGER_CONFIG

Object

ビルドトリガーに BitBucket を使用するための設定。

   .CONSUMER_KEY
(必須)

String

この Red Hat Quay インスタンスの登録済みコンシューマーキー (クライアント ID)。

   .CONSUMER_SECRET
(必須)

String

この Red Hat Quay インスタンスの登録済みコンシューマーシークレット (クライアントシークレット)。

Bitbucket ビルドトリガーの例 YAML

# ...
FEATURE_BITBUCKET_BUILD: true
BITBUCKET_TRIGGER_CONFIG:
  CONSUMER_KEY: <your_consumer_key>
  CONSUMER_SECRET: <your-consumer-secret>
# ...
Copy to Clipboard

表9.35 GitLab ビルドトリガー
フィールド説明

FEATURE_GITLAB_BUILD

Boolean

GitLab ビルドトリガーをサポートするかどうか。

デフォルト: False

GITLAB_TRIGGER_CONFIG

Object

ビルドトリガーに Gitlab を使用するための設定。

   .GITLAB_ENDPOINT
(必須)

String

Gitlab Enterprise が実行されているエンドポイント。

   .CLIENT_ID
(必須)

String

この Red Hat Quay インスタンスの登録済みクライアント ID。

   .CLIENT_SECRET
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアントシークレット。

GitLab ビルドトリガーの例 YAML

# ...
FEATURE_GITLAB_BUILD: true
GITLAB_TRIGGER_CONFIG:
  GITLAB_ENDPOINT: https://gitlab.example.com/
  CLIENT_ID: <your_gitlab_client_id>
  CLIENT_SECRET: <your_gitlab_client_secret>
# ...
Copy to Clipboard

9.9.2. ビルドマネージャー設定フィールド

以下の設定フィールドは、Red Hat Quay のビルドマネージャーコンポーネントがコンテナーイメージのビルドをオーケストレーションおよび管理する方法を制御します。これには、Redis の調整、Kubernetes、EC2、ビルダーイメージ設定などのエグゼキューターバックエンド、高度なスケジューリングおよび再試行ポリシーの設定が含まれます。

これらのフィールドは、インフラストラクチャー環境およびワークロードの要件に合わせて設定する必要があります。

表9.36 ビルドマネージャー設定フィールド
フィールド説明

ALLOWED_WORKER_COUNT

String

Red Hat Quay Pod ごとにインスタンス化される Build Worker の数を定義します。通常は 1 に設定します。

ORCHESTRATOR_PREFIX

String

すべての Redis キーに追加する一意の接頭辞を定義します。これは、オーケストレーターの値を他の Redis キーから分離するのに役立ちます。

REDIS_HOST

Object

Redis サービスのホスト名。

REDIS_PASSWORD

String

Redis サービスへの認証に使用するパスワード。

REDIS_SSL

Boolean

Redis の接続に SSL/TLS を使用するかどうかを定義します。

REDIS_SKIP_KEYSPACE_EVENT_SETUP

Boolean

デフォルトでは、Red Hat Quay はランタイム時のキーイベントに必要なキースペースイベントを設定しません。これを行うには、REDIS_SKIP_KEYSPACE_EVENT_SETUPfalse に設定します。

EXECUTOR

String

このタイプのエグゼキュータの定義を開始します。有効な値は kubernetes および ec2 です。

BUILDER_NAMESPACE

String

Red Hat Quay のビルドが行われる Kubernetes 名前空間。

K8S_API_SERVER

Object

ビルドが行われる OpenShift Container Platform クラスターの API サーバーのホスト名。

K8S_API_TLS_CA

Object

API 呼び出しの実行時に Quay アプリケーションが信頼するビルドクラスターの CA 証明書の Quay コンテナーのファイルパス。

KUBERNETES_DISTRIBUTION

String

使用している Kubernetes の種類を示します。有効な値は openshift および k8s です。

CONTAINER_*

Object

build Pod のリソース要求および制限を定義します。

NODE_SELECTOR_*

Object

build Pod がスケジューリングされるノードセレクターラベル名と値のペアを定義します。

CONTAINER_RUNTIME

Object

ビルダーが dockerpodman のどちらを実行するかを指定します。Red Hat の quay-builder イメージを使用しているお客様は、これを podman に設定してください。

SERVICE_ACCOUNT_NAME/SERVICE_ACCOUNT_TOKEN

Object

build Pod で使用されるサービスアカウント名またはトークンを定義します。

QUAY_USERNAME/QUAY_PASSWORD

Object

WORKER_IMAGE フィールドで指定された Red Hat Quay ビルドワーカーイメージをプルするために必要なレジストリー認証情報を定義します。お客様は、registry.redhat.io に対して https://access.redhat.com/RegistryAuthentication の記事の「レジストリーサービスアカウントの作成」セクションで定義されている Red Hat Service Account の認証情報を提供する必要があります。

WORKER_IMAGE

Object

Red Hat Quay ビルダーイメージのイメージ参照 (registry.redhat.io/quay/quay-builder)。

WORKER_TAG

Object

希望するビルダーイメージのタグ。最新バージョンは 3.14 です。

BUILDER_VM_CONTAINER_IMAGE

Object

各 Red Hat Quay ビルドの実行に必要な内部仮想マシンを保持するコンテナーイメージの完全な参照 (registry.redhat.io/quay/quay-builder-qemu-rhcos:3.14)。

SETUP_TIME

String

ビルドがまだビルドマネージャーに登録されていない場合に、タイムアウトする秒数を指定します。デフォルトは 500 秒です。タイムアウトしたビルドは、3 回再起動が試みられます。3 回試してもビルドが登録されない場合は、失敗とみなされます。

MINIMUM_RETRY_THRESHOLD

String

この設定は、複数のエグゼキューターで使用されます。別のエグゼキューターを選択するまでに、ビルドの開始を何回再試行するかを示します。0 に設定すると、ビルドジョブの試行回数に制限がなくなります。この値を意図的に小さく (3 以下) しておくことで、インフラストラクチャーに障害が発生した際に迅速にフェイルオーバーを行うことができます。この設定には値を指定する必要があります。たとえば、Kubernetes を第 1 のエグゼキューター、EC2 を第 2 のエグゼキューターとして設定します。ジョブ実行の最後の試行を常に Kubernetes ではなく EC2 で実行する場合は、Kubernetes のエグゼキューターの MINIMUM_RETRY_THRESHOLD1 に、EC2 の MINIMUM_RETRY_THRESHOLD0 に設定します (設定していない場合はデフォルトで 0 になります)。この場合、Kubernetes の MINIMUM_RETRY_THRESHOLD retries_remaining(1)False と評価され、設定された 2 番目のエクゼキュータにフォールバックされます。

SSH_AUTHORIZED_KEYS

Object

ignition 設定でブートストラップする SSH 鍵のリスト。これにより、他の鍵を使用して EC2 インスタンスや QEMU 仮想マシン (VM) に SSH 接続できます。

ビルドマネージャー設定フィールド

# ...
ALLOWED_WORKER_COUNT: "1"
ORCHESTRATOR_PREFIX: "quaybuild:"
REDIS_HOST: redis.example.com
REDIS_PASSWORD: examplepassword
REDIS_SSL: true
REDIS_SKIP_KEYSPACE_EVENT_SETUP: false
EXECUTOR: kubernetes
BUILDER_NAMESPACE: quay-builder
K8S_API_SERVER: https://api.openshift.example.com:6443
K8S_API_TLS_CA: /etc/ssl/certs/ca.crt
KUBERNETES_DISTRIBUTION: openshift
CONTAINER_RUNTIME: podman
CONTAINER_MEMORY_LIMITS: 2Gi
NODE_SELECTOR_ROLE: quay-build-node
SERVICE_ACCOUNT_NAME: quay-builder-sa
QUAY_USERNAME: quayuser
QUAY_PASSWORD: quaypassword
WORKER_IMAGE: quay.io/quay/quay-builder
WORKER_TAG: latest
BUILDER_VM_CONTAINER_IMAGE: quay.io/quay/vm-builder:latest
SETUP_TIME: "500"
MINIMUM_RETRY_THRESHOLD: "1"
SSH_AUTHORIZED_KEYS:
  - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsomekey user@example.com
  - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAnotherkey user2@example.com
# ...
Copy to Clipboard

9.9.3. ビルドログ設定フィールド

このセクションでは、Red Hat Quay でビルドログを管理するための使用可能な設定フィールドを説明します。これらの設定は、ビルドログをアーカイブする場所、そのログにアクセスできるユーザー、および保存方法を決定します。

表9.37 ビルドログ設定フィールド
フィールド説明

FEATURE_READER_BUILD_LOGS

Boolean

true に設定すると、write アクセス権や admin アクセス権だけでなく、リポジトリーへの read アクセス権を持つユーザーもビルドログを読み取ることができます。

デフォルト:False

LOG_ARCHIVE_LOCATION

String

アーカイブされたビルドログを配置する、DISTRIBUTED_STORAGE_CONFIG で定義されたストレージの場所。

例: s3_us_east

LOG_ARCHIVE_PATH

String

アーカイブされたビルドログを .JSON 形式で配置する、設定されたストレージエンジンの下のパス。

例: archives/buildlogs

ビルドログ YAML の例

# ...
FEATURE_READER_BUILD_LOGS: true
LOG_ARCHIVE_LOCATION: s3_us_east
LOG_ARCHIVE_PATH: archives/buildlogs
# ...
Copy to Clipboard

9.10. タグおよびイメージ管理

このセクションでは、タグとイメージを Red Hat Quay 内で管理する方法を制御する設定フィールドについて説明します。これらの設定は、イメージのクリーンアップの自動化、リポジトリーミラーの管理、およびキャッシュによるパフォーマンスの向上に役立ちます。

これらのフィールドを使用すると、以下のことができます。

  • タグ付けされていないイメージまたは古いイメージの有効期限ポリシーを定義します。
  • 外部リポジトリーのミラーリングをレジストリーへの有効にし、スケジュールします。
  • モデルキャッシュを活用して、タグとリポジトリー操作のパフォーマンスを最適化します。

これらのオプションは、最新のイメージレジストリー環境を維持するのに役立ちます。

9.10.1. タグの有効期限の設定フィールド

次の設定オプションを使用して、タグの有効期限とガベージコレクションを自動化できます。これらの機能は、定義されたポリシーに基づいて未使用タグまたは期限切れのタグのクリーンアップを有効にすることで、ストレージの使用を管理するのに役立ちます。

表9.38 タグの有効期限の設定フィールド
フィールド説明

FEATURE_GARBAGE_COLLECTION

Boolean

リポジトリーのガベージコレクションを有効にするかどうか。

デフォルト: True

TAG_EXPIRATION_OPTIONS
(必須)

文字列の配列

有効にすると、ユーザーが namespace 内のタグの有効期限を選択できるオプション。

パターン:
^[0-9]+(y|w|m|d|h|s)$

DEFAULT_TAG_EXPIRATION
(必須)

String

タイムマシンのデフォルトの設定可能なタグ有効期限。

パターン:
^[0-9]+(y\w|m|d|h|s)$
デフォルト: 2w

FEATURE_CHANGE_TAG_EXPIRATION

Boolean

ユーザーおよび組織が namespace のタグの有効期限を変更できるかどうか。

デフォルト: True

FEATURE_AUTO_PRUNE

Boolean

True に設定すると、タグの自動プルーニングに関連する機能が有効になります。
デフォルト: False

NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES

Integer

有効期限が切れるイメージに関する通知を再実行する頻度を定義する間隔 (分単位)。

デフォルト: 300

DEFAULT_NAMESPACE_AUTOPRUNE_POLICY

Object

組織全体のデフォルトの自動プルーニングポリシー。

    .method: number_of_tags

Object

保持するタグの数を指定するオプション。

    .value: <integer>

Integer

method: number_of_tags と一緒に使用した場合に、保持するタグの数を示します。

たとえば、2 つのタグを保持するには、2 を指定します。

    .creation_date

Object

タグを保持する期間を指定するオプション。

    .value: <integer>

Integer

creation_date と一緒に使用した場合に、タグを保持する期間を示します。

秒 (s)、日 (d)、月 (m)、週 (w)、または年 (y) に設定できます。有効な整数を含める必要があります。たとえば、タグを 1 年間保持するには、1y を指定します。

AUTO_PRUNING_DEFAULT_POLICY_POLL_PERIOD

Integer

自動プルーナーワーカーをレジストリーレベルで実行する期間。デフォルトでは、1 日に 1 回 (24 時間に 1 回) 実行されるように設定されています。値は秒単位で指定する必要があります。

FEATURE_IMAGE_EXPIRY_TRIGGER

Boolean

ユーザーがイメージの有効期限の通知を設定できます。

デフォルト:
False

タグの有効期限の例の YAML

# ...
FEATURE_GARBAGE_COLLECTION: true
TAG_EXPIRATION_OPTIONS:
  - 1w
  - 2w
  - 1m
  - 90d
DEFAULT_TAG_EXPIRATION: 2w
FEATURE_CHANGE_TAG_EXPIRATION: true
FEATURE_AUTO_PRUNE: true
NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES: 300
DEFAULT_NAMESPACE_AUTOPRUNE_POLICY:
  method: number_of_tags
  value: 10 
1

AUTO_PRUNING_DEFAULT_POLICY_POLL_PERIOD: 86400
FEATURE_IMAGE_EXPIRY_TRIGGER: false
# ...
Copy to Clipboard

1
残すタグ 10 個を指定します。

作成日のサンプル YAML によるレジストリーの自動プルーニングポリシー

# ...
DEFAULT_NAMESPACE_AUTOPRUNE_POLICY:
  method: creation_date
  value: 1y 
1

# ...
Copy to Clipboard

1
作成日から 1 年後にプルーニングするタグを指定します。

9.10.2. 設定フィールドのミラーリング

Red Hat Quay のミラーリングにより、リポジトリーとアップストリームソースの自動同期が可能になります。この機能は、リモートコンテナーイメージのローカルミラーを維持して、切断された環境での可用性を確保したり、キャッシュによってパフォーマンスを向上したりするのに役立ちます。

表9.39 ミラーリング設定
フィールド説明

FEATURE_REPO_MIRROR

Boolean

リポジトリーミラーリングを有効または無効にします。

デフォルト: false

REPO_MIRROR_INTERVAL

数値

次にリポジトリーミラー候補をチェックするまでの秒数。
デフォルト: 30

REPO_MIRROR_SERVER_HOSTNAME

String

SERVER_HOSTNAME は、ミラーリングの宛先に置き換えます。

デフォルト: None

:
openshift-quay-service

REPO_MIRROR_TLS_VERIFY

Boolean

HTTPS を必要とし、ミラー時に Quay レジストリーの証明書を検証します。

デフォルト: true

REPO_MIRROR_ROLLBACK

Boolean

true に設定されている場合、リポジトリーはミラー試行の失敗後にロールバックします。

デフォルト: false

ミラーリング設定例の YAML

# ...
FEATURE_REPO_MIRROR: true
REPO_MIRROR_INTERVAL: 30
REPO_MIRROR_SERVER_HOSTNAME: "openshift-quay-service"
REPO_MIRROR_TLS_VERIFY: true
REPO_MIRROR_ROLLBACK: false
# ...
Copy to Clipboard

9.10.3. ModelCache 設定フィールド

ModelCache は、アクセスデータを保存し、データベースの負荷を軽減するために Red Hat Quay が使用するキャッシュメカニズムです。Quay は、デフォルトの Memcache、Redis および Redis クラスターなど、キャッシュ用の複数のバックエンドをサポートします。

  • memcache (デフォルト): 追加の設定は必要ありません。
  • Redis: 単一のインスタンスまたは読み取り専用レプリカとして設定できます。
  • Redis クラスター: 大規模なデプロイメント用に高可用性およびシャーディングを提供します。
表9.40 ModelCache 設定フィールド
フィールド説明

DATA_MODEL_CACHE_CONFIG.engine

String

キャッシュバックエンドエンジン。
値:
memcacheredisrediscluster
デフォルト: memcache

.redis_config.primary.host

String

redis エンジンを使用する場合のプライマリー Redis インスタンスのホスト名。

.redis_config.primary.port

数値

プライマリー Redis インスタンスが使用するポート。

.redis_config.primary.password

String

プライマリー Redis インスタンスで認証するためのパスワード。ssltrue に設定されている場合にのみ必要です。

.redis_config.primary.ssl

Boolean

プライマリー Redis 接続に SSL/TLS を使用するかどうか。

.redis_config.startup_nodes

マップの配列

rediscluster エンジン用。ホスト および ポート を持つ初期 Redis クラスターノードの一覧。

redis_config.password

String

Redis クラスターでの認証に使用されるパスワード。ssltrue の場合に必要です。

.redis_config.read_from_replicas

Boolean

Redis クラスターレプリカからの読み取り操作を許可するかどうか。

.redis_config.skip_full_coverage_check

Boolean

true に設定した場合は、Redis クラスターのフルカバレッジチェックを省略します。

.redis_config.ssl

Boolean

Redis クラスターの通信に SSL/TLS を使用するかどうか。

.replica.host

String

Redis レプリカインスタンスのホスト名。オプション:

.replica.port

数値

Redis レプリカインスタンスによって使用されるポート。

.replica.password

String

Redis レプリカのパスワード。ssltrue の場合に必要です。

.replica.ssl

Boolean

Redis レプリカ接続に SSL/TLS を使用するかどうか。

オプションのレプリカサンプル YAML を備えた単一の Redis

# ...
DATA_MODEL_CACHE_CONFIG:
  engine: redis
  redis_config:
    primary:
      host: <redis-primary.example.com>
      port: 6379
      password: <redis_password>>
      ssl: true
    replica:
      host: <redis-replica.example.com>
      port: 6379
      password: <redis_password>
      ssl: true
# ...
Copy to Clipboard

クラスター化された Redis サンプル YAML

# ...
DATA_MODEL_CACHE_CONFIG:
  engine: <rediscluster>
  redis_config:
    startup_nodes:
      - host: <redis-node-1.example.com>
        port: 6379
      - host: <redis-node-2.example.com>
        port: 6379
    password: <cluster_password>
    read_from_replicas: true
    skip_full_coverage_check: true
    ssl: true
# ...
Copy to Clipboard

9.11. スキャナーおよびメタデータ

このセクションでは、Red Hat Quay 内のセキュリティースキャン、メタデータの提示、およびアーティファクト関係に関連する設定フィールドを説明します。

これらの設定により、Red Hat Quay を次のように実行できるようにすることで可視性とセキュリティーが強化されます。

  • 脆弱性スキャナーと統合して、既知の CVE のコンテナーイメージを評価します。
  • レジストリーに保存されているモデルカードを使用して、AI/ML モデルのメタデータをレンダリングします。
  • OCI アーティファクト仕様に合わせて、参照元 API を使用してコンテナーアーティファクト間の関係を公開します。

これらの機能を組み合わせることで、ソフトウェアサプライチェーンの透過性が向上し、セキュリティーポリシーを実施し、メタデータ駆動型のワークフローをサポートできるようになります。

9.11.1. Clair セキュリティースキャナー設定フィールド

Red Hat Quay は、Clair セキュリティースキャナー を利用して、コンテナーイメージの脆弱性を検出できます。これらの設定フィールドは、スキャナーを有効にする方法、新しいコンテンツをインデックス化する頻度、使用されるエンドポイント、および通知の処理方法を制御します。

表9.41 セキュリティースキャナーの設定
フィールド説明

FEATURE_SECURITY_SCANNER

Boolean

セキュリティースキャナー。

デフォルト: false

FEATURE_SECURITY_NOTIFICATIONS

Boolean

セキュリティースキャナーが有効になっている場合、セキュリティー通知を有効にするか、オフにします

デフォルト値: false

SECURITY_SCANNER_V4_REINDEX_THRESHOLD

String

このパラメーターは、最終のインデックス作成から状態が変更されたか、以前に失敗したマニフェストのインデックスをもう一度作成するまで待機する最小時間を判断するのに使用します。データは manifestsecuritystatus テーブルの last_indexed datetime から計算されます。インデックス作成実行時に必ず、失敗したマニフェストのインデックスを再度作成しないように、このパラメーターを使用します。再インデックスのデフォルト時間は 300 秒です。

SECURITY_SCANNER_V4_ENDPOINT

String

V4 セキュリティースキャナーのエンドポイント。

パターン:
^http(s)?://(.)+$

例:
http://192.168.99.101:6060

SECURITY_SCANNER_V4_PSK

String

Clair 用に生成された共有キー (PSK)。

SECURITY_SCANNER_ENDPOINT

String

V2 セキュリティースキャナーのエンドポイント。

パターン:
^http(s)?://(.)+$

例:
http://192.168.99.100:6060

SECURITY_SCANNER_INDEXING_INTERVAL

Integer

このパラメーターは、セキュリティースキャナーのインデックス作成の間隔 (秒単位) を決定するために使用されます。インデックスのトリガーが発生すると、Red Hat Quay は、Clair でインデックス化する必要のあるマニフェストに対してそのデータベースをクエリーします。これには、インデックス付けされていないマニフェストや、以前にインデックス付けに失敗したマニフェストが含まれます。

デフォルト: 30

FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX

Boolean

新しいプッシュの脆弱性に関する通知の送信を許可するかどうか。
デフォルト: True

SECURITY_SCANNER_V4_MANIFEST_CLEANUP

Boolean

Red Hat Quay ガベージコレクターが、他のタグまたはマニフェストによって参照されていないマニフェストを削除するかどうか。
デフォルト: True

NOTIFICATION_MIN_SEVERITY_ON_NEW_INDEX

String

検出された脆弱性に関する新しい通知の最低セキュリティーレベルを設定します。最初のインデックスの後に大量の通知が作成されるのを回避します。定義されていない場合は、デフォルトで High になります。使用可能なオプションには、CriticalHighMediumLowNegligibleUnknown があります。

SECURITY_SCANNER_V4_INDEX_MAX_LAYER_SIZE

String

インデックス化に許可される最大レイヤーサイズ。レイヤーサイズが設定済みのサイズを超えると、Red Hat Quay UI は、The manifest for this tag has layer(s) that are too large to index by the Quay Security Scanner メッセージを返します。デフォルトは 8G で、推奨される最大値は 10G です。受け入れられる値は、BKMT、および G です。
デフォルト: 8G

セキュリティースキャナーの YAML 設定

# ...
FEATURE_SECURITY_NOTIFICATIONS: true
FEATURE_SECURITY_SCANNER: true
FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX: true
...
SECURITY_SCANNER_INDEXING_INTERVAL: 30
SECURITY_SCANNER_V4_MANIFEST_CLEANUP: true
SECURITY_SCANNER_V4_ENDPOINT: http://quay-server.example.com:8081
SECURITY_SCANNER_V4_PSK: MTU5YzA4Y2ZkNzJoMQ==
SERVER_HOSTNAME: quay-server.example.com
SECURITY_SCANNER_V4_INDEX_MAX_LAYER_SIZE: 8G 
1

# ...
Copy to Clipboard

1
推奨される最大値は 10G です。
9.11.1.1. Clair v4 によるインデックスの再作成

Clair v4 がマニフェストをインデックス化する場合は、結果として、決定論的なものである必要があります。たとえば、同じマニフェストが同じインデックスレポートを生成する必要があります。これは、異なるスキャナーを使用するとレポートで返される特定のマニフェストに関連して異なる情報を生成するため、スキャナーが変更されるまで True となります。そのため、Clair v4 はインデックスエンジン (/indexer/api/v1/index_state) の状態表現を公開し、スキャナー設定が変更されたかどうかを判別します。

Red Hat Quay は、Quay のデータベースの解析時にこれをインデックスレポートに保存し、このインデックス状態を活用します。以前にスキャンされてからこの状態が変更された場合、Red Hat Quay は定期的なインデックスプロセス時にマニフェストの再作成を試行します。

デフォルトでは、このパラメーターは 30 秒に設定されています。インデックス作成のプロセスをより頻繁に実行する場合は、時間を短縮します。たとえば、新規タグをプッシュしてから、30 秒待たずに、UI でセキュリティースキャンの結果を表示する場合などです。また、ユーザーは要求パターンを Clair に制御し、Red Hat Quay データベースで実行されるデータベース操作のパターンをより詳細に制御する必要がある場合にパラメーターを変更することもできます。

9.11.2. モデルカードレンダリング設定フィールド

Red Hat Quay は、機械学習ワークフローで一般的に使用されるモデルカード -a 形式のメタデータドキュメントのレンダリングをサポートしています。これにより、OCI 準拠のイメージ内のモデル関連のコンテンツの可視性と管理が向上します。

表9.42 モデルカードレンダリング設定フィールド
フィールド説明

FEATURE_UI_MODELCARD

Boolean

UI で Model card イメージタブを有効にします。デフォルトは true です。

UI_MODELCARD_ARTIFACT_TYPE

String

モデルカードアーティファクトタイプを定義します。

UI_MODELCARD_ANNOTATION

Object

このオプションフィールドは、OCI イメージに格納されているモデルカードのレイヤーアノテーションを定義します。

UI_MODELCARD_LAYER_ANNOTATION

Object

このオプションフィールドは、OCI イメージに格納されているモデルカードのレイヤーアノテーションを定義します。

モデルカードの例 YAML

FEATURE_UI_MODELCARD: true 
1

UI_MODELCARD_ARTIFACT_TYPE: application/x-mlmodel 
2

UI_MODELCARD_ANNOTATION: 
3

  org.opencontainers.image.description: "Model card metadata"
UI_MODELCARD_LAYER_ANNOTATION: 
4

  org.opencontainers.image.title: README.md
Copy to Clipboard

1
UI で Model Card イメージタブを有効にします。
2
モデルカードアーティファクトタイプを定義します。この例では、アーティファクトタイプは application/x-mlmodel です。
3
オプション: イメージに artifactType が定義されていない場合、このフィールドはマニフェストレベルでチェックされます。一致するアノテーションが見つかった場合、システムは UI_MODELCARD_LAYER_ANNOTATION に一致するアノテーションを持つレイヤーを検索します。
4
オプション: イメージに artifactType が定義されており、レイヤーが複数ある場合、このフィールドを使用して、モデルカードを含む特定のレイヤーを検索します。

9.11.3. Open Container Initiative referrers API 設定フィールド

Open Container Initiative (OCI)参照者 API は、参照者の取得と管理を支援することで、コンテナーイメージ管理を改善するのに役立ちます。

表9.43 参照元 API 設定フィールド
フィールド説明

FEATURE_REFERRERS_API

Boolean

OCI 1.1 のリファラー API を有効にします。

OCI 参照者の有効化 YAML の例

# ...
FEATURE_REFERRERS_API: True
# ...
Copy to Clipboard

9.12. クォータ管理およびプロキシーキャッシュ機能

このセクションでは、ストレージ制限の実施と、プロキシーのキャッシュによるイメージの可用性の向上に関連する設定フィールドの概要を説明します。

これらの機能は、レジストリー管理者に役立ちます。

  • 設定可能なクォータで、ユーザーが消費するストレージアカウントおよびユーザーの量を制御します。
  • リモートコンテンツをプロキシーキャッシュでローカルにキャッシュすることで、アップストリームのイメージへのアクセスを改善します。
  • 分散環境全体でリソース消費と可用性を監視および管理します。

全体的に、これらの機能により、コンテナーイメージワークフローの管理におけるパフォーマンス、ガバナンス、および回復性が向上します。

9.12.1. クォータ管理設定フィールド

次の設定フィールドは、Red Hat Quay のクォータ管理機能を有効にし、カスタマイズします。クォータ管理は、管理者が使用制限の設定、ブロブサイズの算出、およびタグ削除の動作の制御を許可することで、組織レベルでストレージ使用状況ポリシーを実施するのに役立ちます。

表9.44 クォータ管理設定
フィールド説明

FEATURE_QUOTA_MANAGEMENT

Boolean

クォータ管理機能の設定、キャッシュ、検証を有効にします。

**Default:** `False`
Copy to Clipboard

DEFAULT_SYSTEM_REJECT_QUOTA_BYTES

String

すべての組織に対してシステムのデフォルトクォータ拒否バイト許容量を有効にします。

デフォルトでは、制限は設定されていません。

QUOTA_BACKFILL

Boolean

クォータバックフィルワーカーが既存の Blob のサイズを計算できるようにします。

デフォルト: True

QUOTA_TOTAL_DELAY_SECONDS

String

クォータバックフィルを開始するまでの遅延時間。ローリングデプロイメントでは、合計が不正確になる可能性があります。このフィールドは、ローリングデプロイメントが完了するまでにかかる時間よりも長い時間を設定する 必要があります

デフォルト: 1800

PERMANENTLY_DELETE_TAGS

Boolean

タイムマシンウィンドウからのタグの削除に関連する機能を有効にします。

デフォルト:False

RESET_CHILD_MANIFEST_EXPIRATION

Boolean

子マニフェストを対象とする一時タグの有効期限をリセットします。この機能を True に設定すると、子マニフェストはすぐにガベージコレクションされます。

デフォルト:False

クォータ管理の例 YAML

# ...
FEATURE_QUOTA_MANAGEMENT: true
DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: "100gb"
QUOTA_BACKFILL: true
QUOTA_TOTAL_DELAY_SECONDS: "3600"
PERMANENTLY_DELETE_TAGS: true
RESET_CHILD_MANIFEST_EXPIRATION: true
# ...
Copy to Clipboard

9.12.2. プロキシーキャッシュ設定フィールド

Red Hat Quay のプロキシーキャッシュ設定により、Red Hat Quay はアップストリームコンテナーレジストリーのプルスルーキャッシュとして機能できます。FEATURE_PROXY_CACHE が有効になっている場合、Red Hat Quay は外部レジストリーからプルしたイメージをキャッシュし、帯域幅の消費を減らし、後続の要求におけるイメージの取得速度を向上させることができます。

表9.45 プロキシーキャッシュ設定フィールド
フィールド説明

FEATURE_PROXY_CACHE

Boolean

Red Hat Quay がアップストリームレジストリーのプルスルーキャッシュとして機能できるようにします。

デフォルト: false

プロキシーキャッシュの例 YAML

# ...
FEATURE_PROXY_CACHE: true
# ...
Copy to Clipboard

9.13. QuayIntegration 設定フィールド

QuayIntegration カスタムリソースを使用すると、OpenShift Container Platform クラスターと Red Hat Quay レジストリーインスタンス間の統合が可能になります。

表9.46 QuayIntegration 設定フィールド
名前説明スキーマ

allowlistNamespaces
(オプション)

含める namespace のリスト。

アレイ

clusterID
(必須)

このクラスターに関連付けられている ID。

String

credentialsSecret.key
(必須)

Quay レジストリーと通信するための認証情報を含む秘密。

Object

denylistNamespaces
(オプション)

除外する namespace のリスト。

アレイ

insecureRegistry
(オプション)

Quay レジストリーへの TLS 検証をスキップするかどうか

Boolean

quayHostname
(必須)

Quay レジストリーのホスト名。

String

scheduledImageStreamImport
(オプション)

イメージストリームのインポートを有効にするかどうか。

Boolean

QuayIntegration の例の CR

apiVersion: quay.redhat.com/v1
kind: QuayIntegration
metadata:
  name: example-quayintegration
spec:
  clusterID: 1df512fc-bf70-11ee-bb31-001a4a160100
  quayHostname: quay.example.com
  credentialsSecret:
    name: quay-creds-secret
    key: token
  allowlistNamespaces:
    - dev-team
    - prod-team
  denylistNamespaces:
    - test
  insecureRegistry: false
  scheduledImageStreamImport: true
Copy to Clipboard

9.14. メール設定フィールド

アカウントの確認、パスワードのリセット、セキュリティーアラートなどの Red Hat Quay インスタンスからのメール通知を有効にするには、以下を実行します。この設定により、Red Hat Quay は SMTP サーバーに接続し、レジストリーの代わりにアウトバウンドメッセージを送信できます。

表9.47 メール設定フィールド
フィールド説明

FEATURE_MAILING

Boolean

メールが有効かどうか

デフォルト: False

MAIL_DEFAULT_SENDER

String

指定されている場合、Red Hat Quay がメールを送信する際の from として使用されるメールアドレス。何も指定されていない場合は、support@quay.io にデフォルト設定されます。

例: support@example.com

MAIL_PASSWORD

String

メールの送信時に使用する SMTP パスワード。

MAIL_PORT

数値

使用する SMTP ポート。指定されていない場合は、デフォルトの 587 になります。

MAIL_SERVER

String

メールの送信に使用する SMTP サーバー。FEATURE_MAILING が true に設定されている場合にのみ必要です。

例: smtp.example.com

MAIL_USERNAME

String

メールの送信時に使用する SMTP ユーザー名。

MAIL_USE_TLS

Boolean

指定されている場合は、電子メールの送信に TLS を使用するかどうか。

デフォルト: True

メールの例 YAML

# ...
FEATURE_MAILING: true
MAIL_DEFAULT_SENDER: "support@example.com"
MAIL_SERVER: "smtp.example.com"
MAIL_PORT: 587
MAIL_USERNAME: "smtp-user@example.com"
MAIL_PASSWORD: "your-smtp-password"
MAIL_USE_TLS: true
# ...
Copy to Clipboard

第10章 環境変数の設定

Red Hat Quay は、ランタイムの動作とパフォーマンスチューニングを制御する限定された環境変数のセットをサポートします。これらの値で、プロセスごとの動作、接続数、または地域の設定を動的に調整する必要がある特定のシナリオで柔軟性が得られます。

環境変数の使用には注意が必要です。これらのオプションは通常、既存の設定メカニズムを上書きまたは拡張します。

このセクションでは、以下のコンポーネントに関連する環境変数について説明します。

  • Geo レプリケーションの設定
  • データベース接続プール
  • HTTP 接続コンカレンシー。
  • ワーカープロセスのスケーリング

10.1. Geo レプリケーション

Red Hat Quay は、複数のインスタンスが地理的に分散したサイトで動作するマルチリージョンデプロイメントをサポートします。これらのシナリオでは、各サイトは同じ設定とメタデータを共有しますが、ストレージバックエンドはリージョンによって異なる場合があります。

これに対応するために、Red Hat Quay では、環境変数を使用してデプロイメントごとに優先されるストレージエンジンを指定できます。これにより、メタデータはすべてのリージョンで同期されますが、各リージョンは個別の設定ファイルを必要とせずに最適化された独自のストレージバックエンドを使用できます。

DISTRIBUTED_STORAGE_CONFIG で定義されているように、QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数を使用して、ID によって優先されるストレージエンジンを明示的に設定します。

表10.1 Geo レプリケーションの設定
変数説明

QUAY_DISTRIBUTED_STORAGE_PREFERENCE

String

使用する優先されるストレージ (DISTRIBUTED_STORAGE_CONFIG の ID 別)

10.2. データベース接続プール

Red Hat Quay は、すべてが同じコンテナー内で実行する多くの異なるプロセスで構成されています。これらのプロセスの多くは、データベースと連動しています。

データベース接続プールはデフォルトで有効になっており、データベースと対話する各プロセスには接続プールが含まれます。これらのプロセスごとのコネクションプールは、最大 20 個の接続を維持するように設定されています。高負荷時には、Red Hat Quay コンテナー内のすべてのプロセスの接続プールを満たすことが可能です。特定のデプロイメントおよび負荷では、Red Hat Quay が設定されたデータベースの最大接続数を超えないようにするための分析が必要になる場合があります。

時間が経つと、接続プールはアイドル状態の接続を解放します。すべての接続をすぐに解除するには、Red Hat Quay の再起動が必要です。

表10.2 データベース接続プールの設定
変数説明

DB_CONNECTION_POOLING

String

データベース接続プールを有効にするか無効にするかを指定します。デフォルトは true です。使用可能な値は "true" または "false" です。

データベース接続プーリングが有効な場合は、接続プールの最大サイズを変更することができます。これは、以下の config.yaml オプションを使用して実行できます。

データベース接続プールの例

# ...
DB_CONNECTION_ARGS:
  max_connections: 10
# ...
Copy to Clipboard

10.2.1. スタンドアロンデプロイメントでのデータベースプールの無効化

スタンドアロンの Red Hat Quay デプロイメントの場合、デプロイメントの開始時にデータベース接続プールをオフに切り替えることができます。以下に例を示します。

$ sudo podman run -d --rm -p 80:8080 -p 443:8443  \
   --name=quay \
   -v $QUAY/config:/conf/stack:Z \
   -v $QUAY/storage:/datastorage:Z \
   -e DB_CONNECTION_POOLING=false
   registry.redhat.io/quay/quay-rhel8:v3.12.1
Copy to Clipboard

10.2.2. OpenShift Container Platform での Red Hat Quay のデータベースプールの無効化

Red Hat Quay on OpenShift Container Platform では、QuayRegistry カスタムリソース定義 (CRD) を変更することでデータベース接続プールを設定できます。以下に例を示します。

QuayRegistry CRD の例

spec:
  components:
  - kind: quay
    managed: true
    overrides:
      env:
      - name: DB_CONNECTION_POOLING
        value: "false"
Copy to Clipboard

10.3. HTTP 接続回数

環境変数を使用して、Red Hat Quay が処理する同時 HTTP 接続の数を制御できます。これらの制限は、グローバルに適用されるか、個々のコンポーネント(レジストリー、Web UI、またはセキュリティースキャン)に限定することができます。デフォルトでは、各ワーカープロセスでは最大 50 個の並列接続が許可されます。

この設定は ワーカープロセスの数とは異なります

これらの接続関連の環境変数は、デプロイメントの種類に応じて異なる方法で設定できます。

  • スタンドアロンデプロイメント では、config.yaml ファイルで接続数を設定します。
  • OpenShift Container Platform デプロイメントの Red Hat Quay で、QuayRegistry CR の env ブロックに 値を定義します。
表10.3 HTTP 接続数設定変数
変数説明

WORKER_CONNECTION_COUNT

数値

ワーカープロセスごとの HTTP 接続の最大数のグローバルデフォルト。

デフォルト: 50

WORKER_CONNECTION_COUNT_REGISTRY

数値

レジストリーワーカーごとの HTTP 接続。

デフォルト:
WORKER_CONNECTION_COUNT

WORKER_CONNECTION_COUNT_WEB

数値

Web UI ワーカーごとの HTTP 接続。

デフォルト:
WORKER_CONNECTION_COUNT

WORKER_CONNECTION_COUNT_SECSCAN

数値

Clair セキュリティースキャナーワーカーごとの HTTP 接続。

デフォルト:
WORKER_CONNECTION_COUNT

スタンドアロン Red Hat Quay デプロイメントの HTTP 接続設定

WORKER_CONNECTION_COUNT: 10
WORKER_CONNECTION_COUNT_REGISTRY: 10
WORKER_CONNECTION_COUNT_WEB: 10
WORKER_CONNECTION_COUNT_SECSCAN: 10
Copy to Clipboard

OpenShift Container Platform での Red Hat Quay の HTTP 接続設定

env:
  - name: WORKER_CONNECTION_COUNT
    value: "10"
  - name: WORKER_CONNECTION_COUNT_REGISTRY
    value: "10"
  - name: WORKER_CONNECTION_COUNT_WEB
    value: "10"
  - name: WORKER_CONNECTION_COUNT_SECSCAN
    value: "10"
Copy to Clipboard

10.4. ワーカープロセス数

環境変数を使用して、Red Hat Quay で受信リクエストを処理するワーカープロセスの数を制御できます。これらの値は、レジストリー、Web UI、セキュリティースキャンなど、システムのさまざまなコンポーネントのタスクを処理するために開始する並列プロセスの数を定義します。

明示的に設定されていない場合、Red Hat Quay は利用可能な CPU コアの数に基づいてワーカープロセスの数を自動的に計算します。この動的スケーリングにより、大規模なマシンでパフォーマンスを最適化できますが、小規模な環境で不要なリソース使用量が生じる可能性もあります。

OpenShift Container Platform デプロイメントの Red Hat Quay では、Operator は以下のデフォルト値を設定します。

  • WORKER_COUNT_REGISTRY: 8
  • WORKER_COUNT_WEB: 4
  • WORKER_COUNT_SECSCAN: 2
表10.4 ワーカーカウント変数
変数説明

WORKER_COUNT

数値

プロセス数の汎用上書き

WORKER_COUNT_REGISTRY

数値

Quay コンテナー内のレジストリー要求を処理するプロセス数を指定します。

値: 8 から 64 までの整数

WORKER_COUNT_WEB

数値

コンテナー内の UI/Web リクエストを処理するプロセス数を指定します。

値: 2 から 32 までの整数

WORKER_COUNT_SECSCAN

数値

コンテナー内のセキュリティースキャン (Clair など) の統合を処理するプロセス数を指定します。

値: 整数。Operator がリソースの要求と制限に 2 vCPU を指定するため、この値は 2 から 4 に設定するのが安全です。ただし、ユーザーは、保証があれば、それ以上 (たとえば 16) 実行できます。

スタンドアロン Red Hat Quay デプロイメントのワーカー数の設定

WORKER_COUNT: 10
WORKER_COUNT_REGISTRY: 16
WORKER_COUNT_WEB: 8
WORKER_COUNT_SECSCAN: 4
Copy to Clipboard

OpenShift Container Platform での Red Hat Quay のワーカー数の設定

env:
  - name: WORKER_COUNT
    value: "10"
  - name: WORKER_COUNT_REGISTRY
    value: "16"
  - name: WORKER_COUNT_WEB
    value: "8"
  - name: WORKER_COUNT_SECSCAN
    value: "4"
Copy to Clipboard

第11章 Clair セキュリティースキャナー

Clair の設定フィールドは、Clair 設定の概要 に移動されました。この章は、Red Hat Quay の今後のバージョンでは削除される予定です。

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat