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

Red Hat Quay の設定

Red Hat Quay 3

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

Red Hat OpenShift Documentation Team

概要

Red Hat Quay の設定

第1章 Red Hat Quay 設定の開始
リンクのコピー

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

デプロイメントタイプに応じて、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 コンソール を使用することで、レジストリーの動作をカスタマイズできます。

このガイドでは、次の設定概念の概要を説明します。

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

第2章 Red Hat Quay 設定の免責事項
リンクのコピー

Red Hat Quay の自己管理型および Operator ベースの両方のデプロイメントでは、特定の機能と設定パラメーターがアクティブに使用または実装されていません。そのため、特定の機能を有効または無効にする機能フラグや、Red Hat Support チームによって明示的に文書化されていない、またはサポートされていない、あるいは Red Hat サポートによってドキュメント化が要求されていない設定パラメーターなどの一部の機能フラグは、慎重に変更する必要があります。

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

第3章 Red Hat Quay 設定ファイルについて
リンクのコピー

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

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

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

3.1. キーと値のペア。
リンクのコピー

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

# ...
1 

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

config.yaml ファイル内の各行には、フィールド名、コロン、スペース、そしてキーに一致する適切な値が続きます。次の例は、config.yaml ファイルで AUTHENTICATION_TYPE 設定フィールドをどのようにフォーマットする必要があるかを示しています。 

AUTHENTICATION_TYPE: Database
1 

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

前の例では、AUTHENTICATION_TYPE は Database に設定されていますが、デプロイメントタイプによって必要な値は異なります。次の例は、認証に LDAP (Lightweight Directory Access Protocol) が使用された場合の config.yaml ファイルを示しています。 

AUTHENTICATION_TYPE: LDAP
# ...
Copy to Clipboard Toggle word wrap

3.2. インデントとネスト
リンクのコピー

多くの Red Hat Quay 設定フィールドでは、ネストされた構造を示すためにインデントが必要です。インデントは 空白 またはリテラルのスペース文字を使用して行う必要があります。タブ文字は設計上許可されていません。インデントはファイル全体で一貫している必要があります。次の YAML スニペットは、BUILDLOGS_REDIS フィールドで必須の host、password、port フィールドにインデントを使用する方法を示しています。 

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

3.3. Lists
リンクのコピー

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

# ...
SUPER_USERS:
- quayadmin
# ...
Copy to Clipboard Toggle word wrap

3.4. 引用符で囲まれた値
リンクのコピー

一部の Red Hat Quay 設定フィールドでは、変数を適切に定義するために引用符 ("") を使用する必要があります。通常、これは必要ありません。次の例は、FOOTER_LINKS 設定フィールドで引用符を使用して TERMS_OF_SERVICE_URL、PRIVACY_POLICY_URL、SECURITY_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 Toggle word wrap

3.5. コメント
リンクのコピー

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

# ...
# FEATURE_UI_V2: true
# ...
Copy to Clipboard Toggle word wrap

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

第4章 オンプレミスの Red Hat Quay 設定の概要
リンクのコピー

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

この章では、次の概念の概要を説明します。

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

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

4.1. 必須の設定フィールド
リンクのコピー

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

Expand

フィールド

タイプ

説明

AUTHENTICATION_TYPE
(必須)

文字列

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

値:
Database、LDAP、JWT、Keystone、OIDC のいずれか。

デフォルト: Database

BUILDLOGS_REDIS
(必須)

Object

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

.host
(必須)

文字列

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

.password

文字列

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

DATABASE_SECRET_KEY
(必須)

文字列

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

DB_URI
(必須)

文字列

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

DISTRIBUTED_STORAGE_CONFIG
(必須)

Object

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

デフォルト: []

SECRET_KEY
(必須)

文字列

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

SERVER_HOSTNAME
(必須)

文字列

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

SETUP_COMPLETE
(必須)

Boolean

これはソフトウェアの以前のバージョンから残されたアーティファクトであり、現在は True の値で指定する 必要があります。

USER_EVENTS_REDIS
(必須)

Object

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

.host
(必須)

文字列

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

.port
(必須)

数値

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

.password

文字列

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 Toggle word wrap

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 Toggle word wrap

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 Toggle word wrap

    2. 新しい機能フラグを追加して、config.yaml ファイルに変更を加えます。次の例では、v2 UI を有効にします。 

      # ...
FEATURE_UI_V2: true
# ...
      Copy to Clipboard Toggle word wrap
    3. config.yaml ファイルに加えた変更を保存します。

    4. 次のコマンドを入力して、quay-registry Pod を再起動します。 

      $ podman restart <container_id>
      Copy to Clipboard Toggle word wrap

  2. config.yaml ファイルへのアクセス権がなく、同じ認証情報を維持しながら新しいファイルを作成する必要がある場合:

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

      $ podman ps
      Copy to Clipboard Toggle word wrap

      出力例

      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 Toggle word wrap

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

      $ podman cp <container_id>:/quay-registry/conf/stack/config.yaml ./config.yaml
      Copy to Clipboard Toggle word wrap

    3. 新しい機能フラグを追加して、config.yaml ファイルに変更を加えます。次の例では、AUTHENTICATION_TYPE を LDAP に設定します。 

      # ...
AUTHENTICATION_TYPE: LDAP
# ...
      Copy to Clipboard Toggle word wrap

    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 Toggle word wrap

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 Toggle word wrap

    出力例

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

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

第5章 Red Hat Quay on OpenShift Container Platform 設定の概要
リンクのコピー

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

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

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

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

5.1. QuayRegistry CR について
リンクのコピー

デフォルトでは、QuayRegistry CR には次の主要なフィールドが含まれています。

  • configBundleSecret: 追加の設定パラメーターを定義する config.yaml ファイルを含む Kubernetes Secret の名前。
  • name: Red Hat Quay レジストリーの名前。
  • namespace: レジストリーが作成された namespace またはプロジェクト。

  • spec.components: Operator が自動的に管理するコンポーネントのリスト。各 spec.component フィールドには、次の 2 つのフィールドが含まれます。

    • kind: コンポーネントの名前。
    • managed: コンポーネントのライフサイクルが Red Hat Quay Operator によって処理されるかどうかを示すブール値。QuayRegistry CR 内のコンポーネントに managed: true を設定すると、Operator がコンポーネントを管理することを意味します。

特に指定がない限り、すべての QuayRegistry コンポーネントは、可視性のために調整の際に自動的に管理および入力されます。次のセクションでは、主要な QuayRegistry コンポーネントについて説明し、デフォルト設定を示す YAML ファイルの例を示します。

5.2. 管理対象コンポーネント
リンクのコピー

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

Red Hat Quay Operator によって実行される独自のデプロイメントが環境に適していない場合、管理対象外コンポーネントの使用 の説明に従って、Red Hat Quay Operator に 管理対象外 リソースまたはオーバーライドを提供できます。

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

quay

Boolean

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

postgres

Boolean

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

clair

Boolean

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

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

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

mirror

Boolean

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

monitoring

Boolean

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 Toggle word wrap

5.3. デプロイメント後の QuayRegistry CR の変更
リンクのコピー

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

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

  • コンポーネント管理を変更する場合: 独自のインフラストラクチャーを導入するために、コンポーネントを managed: true から managed: false に切り替えます。たとえば、Google Cloud Storage や Nutanix などの外部オブジェクトストレージプラットフォームを統合するには、kind: objectstorage を unmanaged に設定できます。
  • カスタム設定を適用する場合: 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) に設定し、独自のインフラストラクチャーを使用できるようになります。

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールで、Operators → Installed 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) に設定し、独自のインフラストラクチャーを使用できるようになります。

前提条件

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

手順

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

    $ oc edit quayregistry <registry_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

  2. QuayRegistry CR に必要な変更を加えます。

    注記

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

  3. 変更を保存します。

5.3.3. configBundleSecret について
リンクのコピー

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

configBundleSecret には config.yaml ファイルが保存されます。Red Hat Quay 管理者は、config.yaml ファイルを通じて次の設定を定義できます。

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

Red Hat Quay は、以下の理由でこのシークレットを更新する可能性があります。

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

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

QuayRegistry CR の設定方法によって、Red Hat Quay on OpenShift Container Platform の configBundleSecret’s `config.yaml ファイルに含める必要があるフィールドが決まります。次の例は、すべてのコンポーネントが 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 Toggle word wrap

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

管理対象外 objectstorage コンポーネント

# ...
    - kind: objectstorage
      managed: false
# ...
Copy to Clipboard Toggle word wrap

独自のコンポーネントを管理している場合は、そのコンポーネントに必要な情報またはリソースが含まれるようにデプロイメントを設定する必要があります。たとえば、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 Toggle word wrap

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

5.3.3.1. OpenShift Container Platform Web コンソールを使用して設定ファイルを変更する
リンクのコピー

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

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators → Red Hat Quay をクリックします。
  2. Quay Registry をクリックします。
  3. Red Hat Quay レジストリーの名前 (例: example-registry) をクリックします。
  4. QuayRegistry details ページで、Config Bundle Secret の名前 (例: example-registry-config-bundle) をクリックします。
  5. Actions → Edit Secret をクリックします。

  6. Value ボックスに、必要なキーと値のペアを追加します。たとえば、Red Hat Quay on OpenShift Container Platform デプロイメントにスーパーユーザーを追加するには、次の参照を追加します。 

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

検証

  1. 変更が承認されたことを確認します。

    1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators → Red Hat Quay をクリックします。
    2. Quay Registry をクリックします。
    3. Red Hat Quay レジストリーの名前 (例: example-registry) をクリックします。

    4. Events をクリックします。成功すると、次のメッセージが表示されます。 

      All objects created/updated successfully
      Copy to Clipboard Toggle word wrap
注記

更新された config.yaml を Secret に配置する前に、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 ファイルを変更するには、既存の設定ファイルを base64 でデコードした後に変更をアップロードするという、複数のステップからなる手順が必要です。ほとんどの場合、OpenShift Container Platform Web コンソールを使用して config.yaml ファイルに変更を加える方が簡単です。

前提条件

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

手順

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

    $ oc describe quayregistry -n <quay_namespace>
    Copy to Clipboard Toggle word wrap 
    # ...
  Config Bundle Secret:  example-registry-config-bundle-v123x
# ...
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力してシークレットデータを取得します。 

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

    出力例

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

  3. >> config.yaml フラグを渡して、データをカレントディレクトリーの YAML ファイルにデコードします。以下に例を示します。 

    $ echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode >> config.yaml
    Copy to Clipboard Toggle word wrap
  4. config.yaml ファイルに必要な変更を加え、ファイルを config.yaml として保存します。

  5. 次のコマンドを入力して、新しい configBundleSecret YAML を作成します。 

    $ touch <new_configBundleSecret_name>.yaml
    Copy to Clipboard Toggle word wrap

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

    $ 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 Toggle word wrap
    1
    <config.yaml> は base64 でデコード された config.yaml ファイルです。

  7. 次のコマンドを入力して、configBundleSecret リソースを作成します。 

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

    出力例

    secret/config-bundle created
    Copy to Clipboard Toggle word wrap

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

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

    出力例

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

検証

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

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

    出力例

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

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

第6章 API を使用して設定を取得する
リンクのコピー

FEATURE_SUPERUSER_CONFIGDUMP 設定フィールドを v1/superuser/config API エンドポイントと一緒に活用することで、CLI で設定を返すことができます。これらを組み合わせることで、Red Hat Quay スーパーユーザーは設定されているすべての Flask 設定フィールドを返すことができ、これを使用して PCI-DSS 4.0 などのさまざまなセキュリティーポリシーへの準拠の証明を示すことができます。

前提条件

  • config.yaml ファイルに FEATURE_SUPERUSER_CONFIGDUMP: true を設定している。
  • config.yaml ファイルで、ユーザーにスーパーユーザーロールを割り当てている。
  • スーパーユーザー用の OAuth 2 アクセストークンを生成している。

手順

  • v1/superuser/config API エンドポイントを使用して設定を取得します。以下に例を示します。 

    $ curl -X GET -H "Authorization: Bearer <bearer_token>" "http://<quay-server.example.com>/api/v1/superuser/config" | jq -r .config
    Copy to Clipboard Toggle word wrap

    出力例

    ...
  "TEAM_RESYNC_STALE_TIME": "30m",
  "UI_DELAY_AFTER_WRITE_SECONDS": 3,
  "UI_MODELCARD_ANNOTATION": {},
  "UI_MODELCARD_ARTIFACT_TYPE": "application/x-mlmodel",
  "UI_MODELCARD_LAYER_ANNOTATION": {
    "org.opencontainers.image.title": "README.md"
  }
...
    Copy to Clipboard Toggle word wrap

  • 特定の情報を返すには、.config、.env、.warning、.schema のいずれかを渡します。以下に例を示します。 

    $ curl -X GET -H "Authorization: Bearer <bearer_token>" "http://<quay-server.example.com>/api/v1/superuser/config" | jq -r .warning
    Copy to Clipboard Toggle word wrap

    出力例

    ...
  "BILLING_TYPE": "FakeStripe",
  "BUILDLOGS_OPTIONS": [],
  "BUILD_MANAGER": null,
  "CDN_SPECIFIC_NAMESPACES": [],
  "CHANNEL_COLORS": [
  ]
...
    Copy to Clipboard Toggle word wrap

第7章 Red Hat Quay 3.15 の新しい設定フィールド
リンクのコピー

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

7.1. Skopeo タイムアウト間隔
リンクのコピー

SKOPEO_TIMEOUT_INTERVAL が追加されました。この設定フィールドを使用すると、Red Hat Quay 管理者は、ミラーリングジョブがタイムアウトするまでの実行時間 (秒単位) を調整できます。このフィールドは必須であり、デフォルトは 300 秒、つまり 5 分です。300 秒未満に設定することはできません。

Expand

フィールド

型

説明

SKOPEO_TIMEOUT_INTERVAL

Integer

タイムアウトするまでにミラーリングジョブが実行される秒数。

でフィルト: 300

Skopeo タイムアウトの YAML サンプル

SKOPEO_TIMEOUT_INTERVAL: 300
Copy to Clipboard Toggle word wrap

7.2. スーパーユーザー configDump
リンクのコピー

FEATURE_SUPERUSER_CONFIGDUMP 設定フィールドが追加されました。このフィールドを使用すると、Red Hat Quay スーパーユーザーは configDump API フィールドを活用して、設定されているすべての Flask 設定フィールドを返すことができます。これは、PCI-DSS 4.0 などのさまざまなセキュリティーポリシーへの準拠の証明を示すために使用できます。このフィールドを使用するには、SUPER_USERS 設定フィールドを使用して config.yaml ファイルでスーパーユーザーを定義する必要があります。

Expand
表7.1 configDump 設定フィールド

フィールド

型

説明

FEATURE_SUPERUSER_CONFIGDUMP

Boolean

検証のために、実行中のフレームワーク、環境、スキーマの完全な設定ダンプを有効にします。

デフォルト: False

スーパーユーザー configDump の YAML サンプル

# ...
FEATURE_SUPERUSER_CONFIGDUMP: true
# ...
Copy to Clipboard Toggle word wrap

第8章 必須の設定フィールド
リンクのコピー

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

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

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

8.1. 一般的な必須設定フィールド
リンクのコピー

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

Expand
表8.1 一般的な必須フィールド
フィールド型説明

AUTHENTICATION_TYPE
(必須)

文字列

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

値:
Database、LDAP、JWT、Keystone、OIDC のいずれか。

デフォルト: Database

PREFERRED_URL_SCHEME
(必須)

文字列

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

値:
http, https のいずれか。

デフォルト: http

SERVER_HOSTNAME
(必須)

文字列

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

例:
quay-server.example.com

DATABASE_SECRET_KEY
(必須)

文字列

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

SECRET_KEY
(必須)

文字列

ユーザーセッションを正しく解釈するために必要なセッション 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 Toggle word wrap

8.2. データベース設定フィールド
リンクのコピー

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

8.2.1. データベース URI
リンクのコピー

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

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

Expand
表8.2 データベース URI
フィールド型説明

DB_URI
(必須)

文字列

認証情報を含む、データベースにアクセスするための 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 Toggle word wrap

8.2.2. データベース接続引数
リンクのコピー

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

Expand
表8.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 Toggle word wrap

8.2.2.1. SSL/TLS 接続引数
リンクのコピー

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

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

Expand
表8.4 sslmode オプション
Mode説明

sslmode

セキュアな SSL/TLS または TCP/IP 接続をサーバーとネゴシエートするかどうか、またはネゴシエートする場合はどのような優先順位でネゴシエートするかを決定します。

   *: disable

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

   *: allow

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

   *: prefer
    (Default)

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

   *: require

設定では 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 Toggle word wrap

8.3. ストレージオブジェクトの設定フィールド
リンクのコピー

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

  • Amazon Web Services (AWS) S3
  • AWS STS S3 (Security Token Service)
  • AWS CloudFront (CloudFront S3 ストレージ)
  • Google Cloud Storage
  • Microsoft Azure Blob Storage
  • Swift Storage
  • Nutanix オブジェクトストレージ
  • IBM Cloud オブジェクトストレージ
  • NetApp ONTAP S3 オブジェクトストレージ
  • 日立コンテンツプラットフォーム (HCP) オブジェクトストレージ
注記

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

8.3.1. ストレージ設定フィールド
リンクのコピー

次の表は、Red Hat Quay のストレージ設定フィールドについて説明しています。バックエンドストレージを設定する場合、これらのフィールドは必須です。

Expand
表8.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

最大レイヤーサイズ
(オプション)

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 Toggle word wrap

8.3.2. ローカルストレージ
リンクのコピー

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

重要

概念実証の 目的でレジストリーを展開する場合は、ローカルストレージのみを使用してください。生産目的には適していません。ローカルストレージを使用する場合は、レジストリーを起動するときに、レジストリーをコンテナー内の データストレージ パスのローカルディレクトリーにマップする必要があります。詳細は、概念実証 - Red Hat Quay のデプロイを 参照してください。

ローカルストレージの例

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

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

8.3.4. Ceph Object Gateway (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_key、secret_key、bucket_name などの同じ認証フィールドを必要とします。Ceph Object Gateway と S3 API の詳細は、Ceph Object Gateway を 参照してください。

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

一般的な S3 アクセスの例を使用した RadosGW

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 Toggle word wrap

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

8.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 ストレージバックエンドに関する追加情報を示します。

8.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 Toggle word wrap

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

1
一意の Amazon Resource Name (ARN)。
2
生成された AWS S3 ユーザーアクセスキー。
3
生成された AWS S3 ユーザー秘密鍵。
4
Amazon Web Services のリージョン。デフォルトは us-east-1 です。
8.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 policy と Cross-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 Toggle word wrap

バケットポリシーの例

{
    "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 Toggle word wrap

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

8.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 Toggle word wrap

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

8.3.7. Microsoft Azure Blob Storage
リンクのコピー

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

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

Microsoft Azure Blob ストレージの例

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 Toggle word wrap

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 エラーが発生します。

8.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 Toggle word wrap

8.3.9. Nutanix オブジェクトストレージ
リンクのコピー

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

次の YAML は、Nutanix Object Storage を使用したサンプル設定を示しています。

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

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 Toggle word wrap

8.3.10. IBM Cloud オブジェクトストレージ
リンクのコピー

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

次の YAML は、IBM Cloud Object Storage を使用したサンプル設定を示しています。

IBM Cloud オブジェクトストレージ

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 Toggle word wrap

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

8.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 Toggle word wrap

8.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 Toggle word wrap

8.4. Redis 設定フィールド
リンクのコピー

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

8.4.1. ビルドログ
リンクのコピー

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

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

Expand
表8.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 Toggle word wrap

1 2
デプロイメントで Azure Cache for Redis を使用し、ssl が True に設定されている場合、ポートはデフォルトで 6380 に設定されます。

8.4.2. ユーザーイベント
リンクのコピー

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

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

Expand
表8.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 Toggle word wrap

第9章 自動化設定オプション
リンクのコピー

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

注記

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 の変更を 参照してください。

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

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

関連情報

9.1. 自動化用の事前設定オプション
リンクのコピー

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

Expand
表9.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 を操作できなくなります。

SUPER_USERS

String

レジストリーへの完全な権限と無制限のアクセス権を持つ管理ユーザーまたはスーパーユーザーのリストを定義します。Red Hat Quay 管理者は、再デプロイを必要とせずに即時の管理アクセスを確保するために、デプロイメント前に config.yaml で SUPER_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 Toggle word wrap

第10章 コンポーネントと機能の設定フィールド
リンクのコピー

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

10.1. コア設定の概要
リンクのコピー

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

10.1.1. レジストリーのブランディングとアイデンティティーフィールド
リンクのコピー

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

注記

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

Expand
表10.1 レジストリーのブランディングとアイデンティティー設定フィールド
フィールド型説明

REGISTRY_TITLE

文字列

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

REGISTRY_TITLE_SHORT

文字列

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

CONTACT_INFO

文字列の配列

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

[0]

文字列

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

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

[1]

文字列

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

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

[2]

文字列

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

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

[3]

文字列

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

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

Expand
表10.2 ブランディング設定フィールド
フィールド型説明

BRANDING

Object

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

.logo
(必須)

文字列

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

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

.footer_img

文字列

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

例:
/static/img/RedHat.svg

.footer_url

文字列

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

例:
https://redhat.com

Expand
表10.3 フッターリンクの設定フィールド
フィールド型説明

FOOTER_LINKS

Object

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

.TERMS_OF_SERVICE_URL

文字列

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

例:
https://index.hr

.PRIVACY_POLICY_URL

文字列

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

例:
https://example.hr

.SECURITY_URL

文字列

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

例:
https://example.hr

.ABOUT_URL

文字列

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

例:
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 Toggle word wrap

10.1.2. SSL/TLS 設定フィールド
リンクのコピー

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

関連情報

Expand
表10.4 SSL 設定フィールド
フィールド型説明

PREFERRED_URL_SCHEME

String

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

10.1.3. IPv6 設定フィールド
リンクのコピー

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

Expand
表10.5 IPv6 設定フィールド
フィールド型説明

FEATURE_LISTEN_IP_VERSION

String

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

IPv6 の YAML サンプル

# ...
FEATURE_LISTEN_IP_VERSION: dual-stack
# ...
Copy to Clipboard Toggle word wrap

関連情報

10.1.4. ロギングとデバッグ変数
リンクのコピー

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

Expand
表10.6 ロギングとデバッグの設定変数
変数型説明

DEBUGLOG

Boolean

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

USERS_DEBUG

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

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

重要

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

ALLOW_PULLS_WITHOUT_STRICT_LOGGING

Boolean

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 Toggle word wrap

関連情報

10.1.5. レジストリー状態とシステム動作の設定フィールド
リンクのコピー

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

Expand
表10.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 Toggle word wrap

関連情報

10.2. ユーザーエクスペリエンスとインターフェイス
リンクのコピー

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

10.2.1. Web UI とユーザーエクスペリエンスの設定フィールド
リンクのコピー

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

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

AVATAR_KIND

String

表示する avatar のタイプ。インライン (local) または 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 Toggle word wrap

10.2.1.1. v2 ユーザーインターフェイス設定
リンクのコピー

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

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

10.2.2. セッションタイムアウト設定フィールド
リンクのコピー

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

重要

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

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

PERMANENT_SESSION_LIFETIME

Integer

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

デフォルト: 2678400

セッションタイムアウトの YAML サンプル

# ...
PERMANENT_SESSION_LIFETIME: 3000
# ...
Copy to Clipboard Toggle word wrap

10.3. ユーザーとアクセス管理
リンクのコピー

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

10.3.1. ユーザー設定フィールド
リンクのコピー

ユーザー設定フィールドは、Red Hat Quay デプロイメントにおけるユーザーアカウントの動作を定義します。これらのフィールドにより、ユーザーの作成、アクセスレベル、メタデータの追跡、回復オプション、namespace の管理を制御できます。組織のガバナンスおよびセキュリティーポリシーに合わせて、招待のみの作成やスーパーユーザー権限などの制限を適用することもできます。

Expand
表10.10 ユーザー設定フィールド
フィールド型説明

FEATURE_SUPER_USERS

Boolean

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

デフォルト: True

FEATURE_USER_CREATION

Boolean

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

デフォルト: True

FEATURE_USER_LAST_ACCESSED

Boolean

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

デフォルト: True

FEATURE_USER_LOG_ACCESS

Boolean

true に設定すると、ユーザーは自分の名前空間の監査ログにアクセスできるようになります。

デフォルト: False

FEATURE_USER_METADATA

Boolean

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

デフォルト: False

FEATURE_USERNAME_CONFIRMATION

Boolean

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

FEATURE_USER_RENAME

Boolean

true に設定すると、ユーザーは自分の名前空間の名前を変更できます

デフォルト: 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_SUPERUSER_CONFIGDUMP

Boolean

検証のために、実行中のフレームワーク、環境、スキーマの完全な設定ダンプを有効にします。

デフォルト: False

FEATURE_RESTRICTED_USERS

Boolean

RESTRICTED_USERS_WHITELIST で True に設定した場合:

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

デフォルト: False

RESTRICTED_USERS_WHITELIST

文字列

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

GLOBAL_READONLY_SUPER_USERS

文字列

設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。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_SUPERUSER_CONFIGDUMP: true
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 Toggle word wrap

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

10.3.2. ロボットアカウント設定フィールド
リンクのコピー

次の設定フィールドを使用すると、ロボットアカウントの作成と操作をグローバルに禁止できます。

関連情報

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

ROBOTS_DISALLOW

Boolean

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

ロボットアカウントを許可しない YAML サンプル

# ...
ROBOTS_DISALLOW: true
# ...
Copy to Clipboard Toggle word wrap

10.3.3. LDAP 設定フィールド
リンクのコピー

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

このセクションでは、次の LDAP シナリオの YAML サンプルを示します。

  • 基本的な LDAP 設定
  • LDAP 制限付きユーザー設定
  • LDAP スーパーユーザー設定

関連情報

Expand
表10.12 LDAP の設定
フィールド型説明

AUTHENTICATION_TYPE
(必須)

文字列

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

FEATURE_TEAM_SYNCING

Boolean

認証エンジン (OIDC、LDAP、または Keystone) のバックアップグループからチームメンバーシップを同期できるようにするかどうか。

デフォルト: True

FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP

Boolean

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

デフォルト: False

LDAP_ADMIN_DN

文字列

LDAP 認証の管理 DN。

LDAP_ADMIN_PASSWD

文字列

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

LDAP_ALLOW_INSECURE_FALLBACK

Boolean

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

LDAP_BASE_DN

文字列の配列

LDAP 認証のベース DN。

LDAP_EMAIL_ATTR

文字列

LDAP 認証のメール属性。

LDAP_UID_ATTR

文字列

LDAP 認証の uid 属性。

LDAP_URI

文字列

LDAP URI。

LDAP_USER_FILTER

文字列

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

LDAP_USER_RDN

文字列の配列

LDAP 認証のユーザー RDN。

LDAP_SECONDARY_USER_RDNS

文字列の配列

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

TEAM_RESYNC_STALE_TIME

文字列

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

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

LDAP_SUPERUSER_FILTER

文字列

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

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

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

LDAP_GLOBAL_READONLY_SUPERUSER_FILTER

文字列

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

LDAP_RESTRICTED_USER_FILTER

文字列

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

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

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 設定の YAML サンプル

# ...
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 Toggle word wrap

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 Toggle word wrap

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

LDAP スーパーユーザー設定リファレンスの YAML サンプル

# ...
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 Toggle word wrap

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

10.3.4. OAuth 設定フィールド
リンクのコピー

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

Expand
表10.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 Toggle word wrap

関連情報

Expand
表10.14 GitHub OAuth 設定フィールド
フィールド型説明

FEATURE_GITHUB_LOGIN

Boolean

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

**デフォルト: False

GITHUB_LOGIN_CONFIG

Object

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

   .ALLOWED_ORGANIZATIONS

文字列の配列

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

   .API_ENDPOINT

文字列

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

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

   .CLIENT_ID
(必須)

文字列

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

例: <client_id>

   .CLIENT_SECRET
(必須)

文字列

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

例: <client_secret>

   .GITHUB_ENDPOINT
(必須)

文字列

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 Toggle word wrap

Expand
表10.15 Google OAuth 設定フィールド
フィールド型説明

FEATURE_GOOGLE_LOGIN

Boolean

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

**デフォルト: False

GOOGLE_LOGIN_CONFIG

Object

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

   .CLIENT_ID
(必須)

文字列

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

例: <client_id>

   .CLIENT_SECRET
(必須)

文字列

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

例: <client_secret>

Google OAuth の YAML サンプル

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

10.3.5. OIDC 設定フィールド
リンクのコピー

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

関連情報

Expand
表10.16 OIDC フィールド
フィールド型説明

<文字列>_LOGIN_CONFIG
(必須)

文字列

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

   .CLIENT_ID
(必須)

文字列

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

例: 0e8dbe15c4c7630b6780

   .CLIENT_SECRET
(必須)

文字列

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

例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

   .LOGIN_BINDING_FIELD

文字列

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

   .LOGIN_SCOPES

Object

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

   .OIDC_ENDPOINT_CUSTOM_PARAMS

文字列

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

   .OIDC_ISSUER

文字列

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

   .OIDC_SERVER
(必須)

文字列

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

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

   .PREFERRED_USERNAME_CLAIM_NAME

文字列

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

   .SERVICE_ICON

文字列

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

   .SERVICE_NAME
(必須)

文字列

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

例: Microsoft Entra ID

   .VERIFIED_EMAIL_CLAIM_NAME

文字列

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

   .PREFERRED_GROUP_CLAIM_NAME

文字列

ユーザーのグループメンバーシップに関する情報を保持する 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 Toggle word wrap

10.3.6. Recaptcha 設定フィールド
リンクのコピー

Red Hat Quay インスタンスで Recaptcha サポートを有効にすると、自動システムによるユーザーログインおよびアカウント回復フォームの不正使用を防ぐことができます。

Expand
表10.17 Recaptcha 設定フィールド
フィールド型説明

FEATURE_RECAPTCHA

Boolean

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

デフォルト: False

RECAPTCHA_SECRET_KEY

文字列

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

RECAPTCHA_SITE_KEY

文字列

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

Recaptcha の YAML サンプル

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

10.3.7. JWT 設定フィールド
リンクのコピー

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

Expand
表10.18 JWT 設定フィールド
フィールド型説明

JWT_AUTH_ISSUER

文字列

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

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

JWT_GETUSER_ENDPOINT

文字列

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

JWT_QUERY_ENDPOINT

文字列

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

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

JWT_VERIFY_ENDPOINT

文字列

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 Toggle word wrap

10.3.8. アプリケーショントークン設定フィールド
リンクのコピー

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

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

FEATURE_APP_SPECIFIC_TOKENS

Boolean

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

デフォルト: True

APP_SPECIFIC_TOKEN_EXPIRATION

文字列

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

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

EXPIRED_APP_SPECIFIC_TOKEN_GC

文字列

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

デフォルト: 1d

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

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

10.4. セキュリティーおよびパーミッション
リンクのコピー

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

10.4.1. namespace とリポジトリー管理の設定フィールド
リンクのコピー

以下の設定フィールドは、Red Hat Quay が namespace とリポジトリーを管理する方法を制御します。これには、自動イメージプッシュ時の動作、デフォルトの可視性、レート制限の例外などが含まれます。

Expand
表10.20 namespace とリポジトリー管理の設定フィールド
フィールド型説明

DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT

数値

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

デフォルト: None

CREATE_PRIVATE_REPO_ON_PUSH

Boolean

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

デフォルト: True

CREATE_NAMESPACE_ON_PUSH

Boolean

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

デフォルト: False

PUBLIC_NAMESPACES

文字列の配列

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

NON_RATE_LIMITED_NAMESPACES

文字列の配列

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

DISABLE_PUSHES

Boolean

他のすべての機能を維持しながら、レジストリーへの新しいコンテンツのプッシュを無効にします。データベースが read-only として設定されていないため、read-only モードとは異なります。DISABLE_PUSHES が True に設定されている場合、Red Hat Quay ガベージコレクターは無効になります。その結果、PERMANENTLY_DELETE_TAGS が有効になっていると、Red Hat Quay UI を使用してタグを永久に削除しても、タグはすぐに削除されません。代わりに、DISABLE_PUSHES が False に設定され、ガベージコレクターが再度有効になるまで、イメージはバックエンドストレージに残ります。Red Hat Quay 管理者は、DISABLE_PUSHES と PERMANENTLY_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 Toggle word wrap

10.4.2. ネストされたリポジトリー設定フィールド
リンクのコピー

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

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

FEATURE_EXTENDED_REPOSITORY_NAMES

Boolean

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

デフォルト: True

ネストされたリポジトリーの YAML サンプル

# ...
FEATURE_EXTENDED_REPOSITORY_NAMES: true
# ...
Copy to Clipboard Toggle word wrap

10.5. 追加のセキュリティー設定フィールド
リンクのコピー

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

Expand
表10.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 Toggle word wrap

10.6. レート制限とパフォーマンス設定フィールド
リンクのコピー

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

Expand
表10.23 レート制限とパフォーマンス設定フィールド
フィールド型説明

FEATURE_RATE_LIMITS

Boolean

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

デフォルト: False

PROMETHEUS_NAMESPACE

文字列

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

デフォルト: quay

レート制限とパフォーマンスの YAML サンプル

# ...
FEATURE_RATE_LIMITS: false
PROMETHEUS_NAMESPACE: quay
# ...
Copy to Clipboard Toggle word wrap

10.8. ストレージとデータ管理
リンクのコピー

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

10.8.1. イメージストレージ機能
リンクのコピー

Red Hat Quay は、コンテナーイメージデータを管理する際のスケーラビリティー、回復力、柔軟性を強化するイメージストレージ機能をサポートしています。これらの機能により、Red Hat Quay はリポジトリーをミラーリングしたり、NGINX を介してストレージアクセスをプロキシーしたり、複数のストレージエンジン間でデータをレプリケートしたりできるようになります。

Expand
表10.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 Toggle word wrap

10.8.2. アクションログストレージ設定フィールド
リンクのコピー

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

関連情報

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

FEATURE_LOG_EXPORT

Boolean

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

デフォルト: True

LOGS_MODEL

String

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

値: database、transition_reads_both_writes_es、elasticsearch、splunk のいずれか。
デフォルト: 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 Toggle word wrap

10.8.2.1. アクションログのローテーションおよびアーカイブ設定
リンクのコピー

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

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

FEATURE_ACTION_LOG_ROTATION

Boolean

ログのローテーションとアーカイブを有効にすると、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 Toggle word wrap

10.8.2.2. アクションログの監査設定
リンクのコピー

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

Expand
表10.28 監査ログ設定フィールド
フィールド型説明

ACTION_LOG_AUDIT_LOGINS

Boolean

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

デフォルト: True

監査ログの設定の YAML サンプル

# ...
ACTION_LOG_AUDIT_LOGINS: true
# ...
Copy to Clipboard Toggle word wrap

10.8.3. Elasticsearch 設定フィールド
リンクのコピー

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

Expand
表10.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 シークレットキー。
例: 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

ログプロデューサータイプ。
許可される値: kafka、elasticsearch、kinesis_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 Toggle word wrap

10.8.3.1. Splunk 設定フィールド
リンクのコピー

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

Expand
表10.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 Toggle word wrap

10.8.3.1.1. Splunk HEC 設定フィールド
リンクのコピー

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

Expand
表10.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 の sourcetype。

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 Toggle word wrap

10.9. ビルドと自動化
リンクのコピー

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

これらのフィールドは次の目的で使用できます。

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

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

関連情報

10.9.1. Dockerfile ビルドトリガーフィールド
リンクのコピー

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

Expand
表10.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 Toggle word wrap

Expand
表10.33 GitHub ビルドトリガー
フィールド型説明

FEATURE_GITHUB_BUILD

Boolean

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

デフォルト: False

GITHUB_TRIGGER_CONFIG

Object

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

   .GITHUB_ENDPOINT
(必須)

文字列

GitHub Enterprise のエンドポイント。

例: https://github.com/

   .API_ENDPOINT

文字列

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

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

   .CLIENT_ID
(必須)

文字列

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

   .CLIENT_SECRET
(必須)

文字列

この 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 Toggle word wrap

Expand
表10.34 BitBucket ビルドトリガー
フィールド型説明

FEATURE_BITBUCKET_BUILD

Boolean

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

デフォルト: False

BITBUCKET_TRIGGER_CONFIG

Object

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

   .CONSUMER_KEY
(必須)

文字列

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

   .CONSUMER_SECRET
(必須)

文字列

この 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 Toggle word wrap

Expand
表10.35 GitLab ビルドトリガー
フィールド型説明

FEATURE_GITLAB_BUILD

Boolean

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

デフォルト: False

GITLAB_TRIGGER_CONFIG

Object

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

   .GITLAB_ENDPOINT
(必須)

文字列

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

   .CLIENT_ID
(必須)

文字列

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

   .CLIENT_SECRET
(必須)

文字列

この 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 Toggle word wrap

10.9.2. ビルドマネージャー設定フィールド
リンクのコピー

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

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

Expand
表10.36 ビルドマネージャー設定フィールド
フィールド型説明

ALLOWED_WORKER_COUNT

文字列

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

ORCHESTRATOR_PREFIX

文字列

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

REDIS_HOST

Object

Redis サービスのホスト名。

REDIS_PASSWORD

文字列

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

REDIS_SSL

Boolean

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

REDIS_SKIP_KEYSPACE_EVENT_SETUP

Boolean

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

EXECUTOR

文字列

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

BUILDER_NAMESPACE

文字列

Red Hat Quay のビルドが行われる Kubernetes namespace。

K8S_API_SERVER

Object

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

K8S_API_TLS_CA

Object

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

KUBERNETES_DISTRIBUTION

文字列

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

CONTAINER_*

Object

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

NODE_SELECTOR_*

Object

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

CONTAINER_RUNTIME

Object

ビルダーが docker と podman のどちらを実行するかを指定します。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 です。

BUILDER_VM_CONTAINER_IMAGE

Object

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

SETUP_TIME

文字列

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

MINIMUM_RETRY_THRESHOLD

文字列

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

10.9.3. ビルドログ設定フィールド
リンクのコピー

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

Expand
表10.37 ビルドログ設定フィールド
フィールド型説明

FEATURE_READER_BUILD_LOGS

Boolean

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

デフォルト:False

LOG_ARCHIVE_LOCATION

文字列

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

例: s3_us_east

LOG_ARCHIVE_PATH

文字列

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

例: archives/buildlogs

ビルドログの YAML サンプル

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

10.10. タグとイメージの管理
リンクのコピー

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

これらのフィールドは次の目的で使用できます。

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

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

10.10.1. タグの有効期限の設定フィールド
リンクのコピー

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

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

FEATURE_GARBAGE_COLLECTION

Boolean

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

デフォルト: True

TAG_EXPIRATION_OPTIONS
(必須)

文字列の配列

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

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

DEFAULT_TAG_EXPIRATION
(必須)

文字列

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

パターン:
^[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

ユーザーがイメージの有効期限に関する通知をセットアップできるようにします。通知は v2 UI でのみ返されます。

デフォルト: 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 Toggle word wrap

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

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

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

# ...
Copy to Clipboard Toggle word wrap

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

10.10.2. 設定フィールドのミラーリング
リンクのコピー

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

関連情報

Expand
表10.39 ミラーリング設定
フィールド型説明

FEATURE_REPO_MIRROR

Boolean

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

デフォルト: False

REPO_MIRROR_INTERVAL

数値

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

REPO_MIRROR_SERVER_HOSTNAME

文字列

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

デフォルト: None

例:
openshift-quay-service

REPO_MIRROR_TLS_VERIFY

Boolean

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

デフォルト: True

REPO_MIRROR_ROLLBACK

Boolean

True に設定すると、ミラーリングの試行が失敗した後にリポジトリーがロールバックされます。

デフォルト:False

SKOPEO_TIMEOUT_INTERVAL

Integer

タイムアウトするまでにミラーリングジョブが実行される秒数。

でフィルト: 300

ミラーリング設定の 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
SKOPEO_TIMEOUT_INTERVAL: 300
# ...
Copy to Clipboard Toggle word wrap

10.10.3. ModelCache 設定フィールド
リンクのコピー

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

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

DATA_MODEL_CACHE_CONFIG.engine

String

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

.redis_config.primary.host

String

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

.redis_config.primary.port

数値

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

.redis_config.primary.password

String

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

.redis_config.primary.ssl

Boolean

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

.redis_config.startup_nodes

マップの配列

rediscluster エンジン用。host と port を含む初期 Redis クラスターノードのリスト。

redis_config.password

String

Redis クラスターでの認証に使用されるパスワード。ssl が True の 場合は必須です。

.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 レプリカのパスワード。ssl が True の 場合は必須です。

.replica.ssl

Boolean

Redis レプリカ接続に SSL/TLS を使用するかどうか。

オプションのレプリカ付き単一 Redis の YAML サンプル

# ...
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 Toggle word wrap

クラスター化された 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 Toggle word wrap

10.11. スキャナーとメタデータ
リンクのコピー

このセクションでは、Red Hat Quay 内のセキュリティースキャン、メタデータの表示、およびアーティファクトの関係に関連する設定フィールドについて説明します。

これらの設定により、Red Hat Quay で次のことが可能になり、可視性とセキュリティーが強化されます。

  • 脆弱性スキャナーと統合して、コンテナーイメージの既知の CVE を評価します。
  • レジストリーに保存されているモデルカードを通じて AI/ML モデルメタデータをレンダリングします。
  • OCI アーティファクト仕様に準拠して、Referrers API を使用してコンテナーアーティファクト間の関係を公開します。

これらの機能を組み合わせることで、ソフトウェアサプライチェーンの透明性が向上し、セキュリティーポリシーが強化され、新しいメタデータ駆動型ワークフローがサポートされます。

10.11.1. Clair セキュリティースキャナーの設定フィールド
リンクのコピー

Red Hat Quay は、Clair セキュリティースキャナーを活用して、コンテナーイメージの脆弱性を検出できます。これらの設定フィールドは、スキャナーを有効にする方法、新しいコンテンツをインデックスする頻度、使用するエンドポイント、通知の処理方法を制御します。

Expand
表10.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 になります。使用可能なオプションには、Critical、High、Medium、Low、Negligible、Unknown があります。

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 です。受け入れられる値は、B、K、M、T、および 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 Toggle word wrap

1
推奨される最大値は 10G です。
10.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 データベースで実行されるデータベース操作のパターンをより詳細に制御する必要がある場合にパラメーターを変更することもできます。

10.11.2. モデルカードレンダリング設定フィールド
リンクのコピー

Red Hat Quay は、機械学習ワークフローで一般的に使用されるメタデータドキュメントの形式であるモデルカードのレンダリングをサポートし、OCI 準拠イメージ内のモデル関連コンテンツの可視性と管理性を向上させます。

関連情報

Expand
表10.42 モデルカードレンダリング設定フィールド
フィールド型説明

FEATURE_UI_MODELCARD

Boolean

UI で Model Card イメージタブを有効にします。デフォルトは True に設定されます。

UI_MODELCARD_ARTIFACT_TYPE

文字列

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

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 Toggle word wrap

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

10.11.3. Open Container Initiative リファラー API 設定フィールド
リンクのコピー

Open Container Initiative (OCI) リファラー API は、リファラーの取得と管理を支援し、コンテナーイメージ管理の改善に役立ちます。

関連情報

Expand
表10.43 リファラー API 設定フィールド
フィールド型説明

FEATURE_REFERRERS_API

Boolean

OCI 1.1 のリファラー API を有効にします。

OCI リファラー有効化の YAML サンプル

# ...
FEATURE_REFERRERS_API: True
# ...
Copy to Clipboard Toggle word wrap

10.12. クォータ管理とプロキシーキャッシュ機能
リンクのコピー

このセクションでは、ストレージ制限の適用とプロキシーキャッシュによるイメージの可用性の向上に関連する設定フィールドについて説明します。

これらの機能はレジストリー管理者に役立ちます。

  • 設定可能なクォータを使用して、組織とユーザーが消費するストレージの量を制御します。
  • プロキシーキャッシュを介してリモートコンテンツをローカルにキャッシュすることで、アップストリームイメージへのアクセスを改善します。
  • 分散環境全体のリソースの消費と可用性を監視および管理します。

これらの機能を組み合わせることで、コンテナーイメージワークフローの管理におけるパフォーマンス、ガバナンス、回復力が向上します。

関連情報

10.12.1. クォータ管理設定フィールド
リンクのコピー

次の設定フィールドは、Red Hat Quay のクォータ管理機能を有効にし、カスタマイズします。クォータ管理により、管理者は使用量制限の設定、Blob サイズの計算、タグ削除動作の制御などが可能になり、組織レベルでストレージ使用ポリシーを適用できるようになります。

Expand
表10.44 クォータ管理設定
フィールド型説明

FEATURE_QUOTA_MANAGEMENT

Boolean

クォータ管理機能の設定、キャッシュ、検証を有効にします。

デフォルト: False

DEFAULT_SYSTEM_REJECT_QUOTA_BYTES

文字列

すべての組織に対してシステムのデフォルトクォータ拒否バイト許容量を有効にします。

デフォルトでは、制限は設定されていません。

QUOTA_BACKFILL

Boolean

クォータバックフィルワーカーが既存の Blob のサイズを計算できるようにします。

デフォルト: True

QUOTA_TOTAL_DELAY_SECONDS

文字列

クォータバックフィルを開始するまでの遅延時間。ローリングデプロイメントでは、合計が不正確になる可能性があります。このフィールドは、ローリングデプロイメントが完了するまでにかかる時間よりも長い時間を設定する 必要があります。

デフォルト: 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 Toggle word wrap

10.12.2. プロキシーキャッシュ設定フィールド
リンクのコピー

Red Hat Quay のプロキシーキャッシュ設定により、Red Hat Quay はアップストリームのコンテナーレジストリーのプルスルーキャッシュとして機能するようになります。FEATURE_PROXY_CACHE を有効にすると、Red Hat Quay は外部レジストリーからプルされたイメージをキャッシュできるため、帯域幅の消費が削減され、後続の要求でのイメージ取得速度が向上します。

Expand
表10.45 プロキシーキャッシュ設定フィールド
フィールド型説明

FEATURE_PROXY_CACHE

Boolean

Red Hat Quay がアップストリームレジストリーのプルスルーキャッシュとして機能できるようにします。

デフォルト:False

プロキシーキャッシュの YAML サンプル

# ...
FEATURE_PROXY_CACHE: true
# ...
Copy to Clipboard Toggle word wrap

10.13. QuayIntegration 設定フィールド
リンクのコピー

QuayIntegration カスタムリソースを使用すると、OpenShift Container Platform クラスターと Red Hat Quay レジストリーインスタンス間の統合が可能になります。

関連情報

Expand
表10.46 QuayIntegration 設定フィールド
名前説明スキーマ

allowlistNamespaces
(オプション)

含める namespace のリスト。

Array

clusterID
(必須)

このクラスターに関連付けられている ID。

文字列

credentialsSecret.key
(必須)

Quay レジストリーと通信するための認証情報を含む秘密。

Object

denylistNamespaces
(オプション)

除外する namespace のリスト。

Array

insecureRegistry
(オプション)

Quay レジストリーへの TLS 検証をスキップするかどうか

Boolean

quayHostname
(必須)

Quay レジストリーのホスト名。

文字列

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 Toggle word wrap

10.14. メール設定フィールド
リンクのコピー

アカウントの確認、パスワードのリセット、セキュリティー警告など、Red Hat Quay インスタンスからのメール通知を有効にします。これらの設定により、Red Hat Quay は SMTP サーバーに接続し、レジストリーに代わって送信メッセージを送信できるようになります。

Expand
表10.47 メール設定フィールド
フィールド型説明

FEATURE_MAILING

Boolean

メールが有効かどうか

デフォルト: False

MAIL_DEFAULT_SENDER

文字列

指定されている場合、Red Hat Quay がメールを送信する際の from として使用されるメールアドレス。何も指定されていない場合は、support@quay.io にデフォルト設定されます。

例: support@example.com

MAIL_PASSWORD

文字列

メールの送信時に使用する SMTP パスワード。

MAIL_PORT

数値

使用する SMTP ポート。指定されていない場合は、デフォルトの 587 になります。

MAIL_SERVER

文字列

メールの送信に使用する SMTP サーバー。FEATURE_MAILING が true に設定されている場合にのみ必要です。

例: smtp.example.com

MAIL_USERNAME

文字列

メールの送信時に使用する 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 Toggle word wrap

第11章 環境変数の設定
リンクのコピー

Red Hat Quay は、ランタイム動作とパフォーマンスチューニングを制御する環境変数の限定されたセットをサポートしています。これらの値は、プロセスごとの動作、接続数、またはリージョナル設定を動的に調整する必要がある特定のシナリオで柔軟性を提供します。

環境変数は慎重に使用してください。これらのオプションは通常、既存の設定メカニズムをオーバーライドまたは拡張します。

このセクションでは、次のコンポーネントに関連する環境変数について説明します。

  • ジオレプリケーションの設定
  • データベース接続プール
  • HTTP 接続の同時実行
  • ワーカープロセスのスケーリング

11.1. Geo レプリケーション
リンクのコピー

Red Hat Quay は、地理的に分散したサイト間で複数のインスタンスが動作するマルチリージョンのデプロイメントをサポートします。これらのシナリオでは、各サイトは同じ設定とメタデータを共有しますが、ストレージバックエンドはリージョンによって異なる場合があります。

これに対応するために、Red Hat Quay では、環境変数を使用してデプロイメントごとに優先ストレージエンジンを指定できます。これにより、メタデータがすべてのリージョン間で同期されたまま、個別の設定ファイルを必要とせずに各リージョンが独自の最適化されたストレージバックエンドを使用できるようになります。

QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数を使用して、DISTRIBUTED_STORAGE_CONFIG で定義されているように、優先ストレージエンジンを ID で明示的に設定します。

Expand
表11.1 Geo レプリケーションの設定
変数タイプ説明

QUAY_DISTRIBUTED_STORAGE_PREFERENCE

文字列

使用する優先されるストレージ (DISTRIBUTED_STORAGE_CONFIG の ID 別)

11.2. データベース接続プール
リンクのコピー

Red Hat Quay は、すべてが同じコンテナー内で実行する多くの異なるプロセスで構成されています。これらのプロセスの多くは、データベースと連動しています。

データベース接続プールはデフォルトで有効になっており、データベースと対話する各プロセスには接続プールが含まれます。これらのプロセスごとのコネクションプールは、最大 20 個の接続を維持するように設定されています。高負荷時には、Red Hat Quay コンテナー内のすべてのプロセスの接続プールを満たすことが可能です。特定のデプロイメントおよび負荷では、Red Hat Quay が設定されたデータベースの最大接続数を超えないようにするための分析が必要になる場合があります。

時間が経つと、接続プールはアイドル状態の接続を解放します。すべての接続をすぐに解除するには、Red Hat Quay の再起動が必要です。

Expand
表11.2 データベース接続プールの設定
変数タイプ説明

DB_CONNECTION_POOLING

文字列

データベース接続プールを有効にするか無効にするかを指定します。デフォルトは true です。使用可能な値は "true" または "false" です。

データベース接続プーリングが有効な場合は、接続プールの最大サイズを変更することができます。これは、以下の config.yaml オプションを使用して実行できます。

データベース接続プールの YAML サンプル

# ...
DB_CONNECTION_ARGS:
  max_connections: 10
# ...
Copy to Clipboard Toggle word wrap

11.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 Toggle word wrap

11.2.2. Red Hat Quay on OpenShift Container Platform におけるデータベースプーリングの無効化
リンクのコピー

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 Toggle word wrap

11.3. HTTP 接続回数
リンクのコピー

環境変数を使用して、Red Hat Quay によって処理される同時 HTTP 接続の数を制御できます。これらの制限はグローバルに適用することも、個々のコンポーネント (レジストリー、Web UI、セキュリティースキャン) に限定することもできます。デフォルトでは、各ワーカープロセスは最大 50 の並列接続を許可します。

この設定は ワーカープロセス の数とは異なります。

これらの接続関連の環境変数は、デプロイメントタイプに応じて異なる方法で設定できます。

  • スタンドアロンデプロイメント では、config.yaml ファイルで接続数を設定します。
  • Red Hat Quay on OpenShift Container Platform デプロイメント で、QuayRegistry CR の env ブロックに値を定義します。
Expand
表11.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 Toggle word wrap

Red Hat Quay on OpenShift Container Platform の 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 Toggle word wrap

11.4. ワーカープロセス数
リンクのコピー

環境変数を使用して、Red Hat Quay で受信リクエストを処理するワーカープロセスの数を制御できます。これらの値は、レジストリー、Web UI、セキュリティースキャンなど、システムのさまざまなコンポーネントのタスクを処理するために開始される並列プロセスの数を定義します。

明示的に設定されていない場合、Red Hat Quay は利用可能な CPU コアの数に基づいて、ワーカープロセスの数を自動的に計算します。この動的スケーリングにより、大規模なマシンではパフォーマンスを最適化できますが、小規模な環境では不要なリソースの使用につながる可能性もあります。

Red Hat Quay on OpenShift Container Platform デプロイメントでは、Operator によって以下のデフォルト値が設定されます。

  • WORKER_COUNT_REGISTRY: 8
  • WORKER_COUNT_WEB: 4
  • WORKER_COUNT_SECSCAN: 2
Expand
表11.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 Toggle word wrap

Red Hat Quay on OpenShift Container Platform のワーカー数設定

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 Toggle word wrap

第12章 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