Red Hat Quay の設定

Red Hat Quay 3.9

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

Red Hat OpenShift Documentation Team

概要

Red Hat Quay の設定

第1章 Red Hat Quay 設定の開始

Red Hat Quay は、独立したスタンドアロン設定によって、または OpenShift Container Platform Red Hat Quay Operator を使用してデプロイできます。

Red Hat Quay 設定を作成、取得、更新、および検証する方法は、使用しているデプロイメントのタイプによって異なります。ただし、コア設定オプションはどちらのデプロイメントタイプでも同じです。コア設定は、次のオプションのいずれかで設定できます。

  • config.yaml ファイルを編集して直接実行する。詳細は、設定ファイルの編集を参照してください。
  • プログラムでコンフィグレーション API を使用する。詳細は、設定 API の使用を参照してください。
  • 視覚的に設定ツール UI を使用する。詳細は、「設定ツールの使用」を参照してください。

Red Hat Quay のスタンドアロンデプロイメントの場合は、レジストリーを開始する前に、最低限必要な設定パラメーターを指定する必要があります。Red Hat Quay レジストリーを開始するための最小要件は、「現在の設定の取得」セクションに記載されています。

Red Hat Quay Operator を使用して OpenShift Container Platform に Red Hat Quay をインストールする場合、Red Hat Quay Operator はレジストリーをデプロイするためのデフォルト情報を提供するため、設定パラメーターを指定する必要はありません。

目的の設定で Red Hat Quay をデプロイしたら、デプロイから完全な設定を取得して保存する必要があります。完全な設定には、システムの再始動またはアップグレード時に必要になる可能性がある追加の生成値が含まれています。

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

Red Hat Quay エンタープライズでは、特定の機能および設定パラメーターは積極的に使用または実装されていません。そのため、特定の機能を有効または無効にするフラグなどの機能フラグや、明示的に文書化されていない、または Red Hat サポートによって文書化が要求されていない設定パラメーターは、慎重に変更する必要があります。未使用の機能やパラメーターは完全にテスト、サポートされていない、または Red Hat Quay との互換性がない可能性があり、それを変更すると、予期しない問題やデプロイメントの中断が発生する可能性があります。

2.1. Red Hat Quay 3.9 の設定の更新

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

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

Red Hat Quay 3.9 では、デフォルトで監査ログインが追跡されます。

表2.1 監査ログ設定フィールド

フィールド説明

ACTION_LOG_AUDIT_LOGINS

Boolean

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

デフォルト: True

2.1.2. Splunk アクションログの追加

Red Hat Quay 3.9 では、Splunk を LOGS_MODEL パラメーターで設定できます。

表2.2 Splunk 設定フィールド

フィールド説明

LOGS_MODEL

String

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

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

2.1.2.1. LOGS_MODEL_CONFIG の追加

Splunk を設定する場合は、次の LOGS_MODEL_CONFIG オプションを使用できます。

  • LOGS_MODEL_CONFIG [オブジェクト]: アクションログ用のログモデル設定

    • producer [文字列]: splunk
    • splunk_config オブジェクト: Splunk アクションログのログモデル設定または Splunk クラスター設定

      • host [文字列]: Splunk クラスターのエンドポイント。
      • port [整数]: Splunk 管理クラスターのエンドポイントポート。
      • bearer_token [文字列]: Splunk のベアラートークン。
      • verify_ssl [ブール値]: HTTPS 接続の TLS/SSL 検証を有効 (True) または無効 (False) にする。
      • Index_prefix [文字列]: Splunk のインデックス接頭辞。
      • ssl_ca_path [文字列]: SSL 検証用の認証局 (CA) を含む単一の .pem ファイルへの相対コンテナーパス。

2.1.2.2. Splunk の設定例

次の YAML エントリーは、Splunk の設定例を示しています。

Splunk config.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>
---

2.1.3. クォータ管理設定フィールド

Red Hat Quay クォータ管理機能を強化するために、次の設定フィールドが追加されました。

表2.3 Red Hat Quay 3.9 クォータ管理設定フィールド

フィールド説明

QUOTA_BACKFILL

Boolean

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

デフォルト: True

QUOTA_TOTAL_DELAY_SECONDS

String

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

デフォルト: 1800

PERMANENTLY_DELETE_TAGS

Boolean

タイムマシンウィンドウからのタグの削除に関連する機能を有効にします。

デフォルト: False

RESET_CHILD_MANIFEST_EXPIRATION

Boolean

子マニフェストを対象とする一時タグの有効期限をリセットします。この機能を True に設定すると、子マニフェストはすぐにガベージコレクションされます。

デフォルト: False

2.1.3.1. 可能なクォータ管理設定

次の表は、Red Hat Quay 3.9 で可能なクォータ管理設定を説明しています。

表2.4 クォータ管理設定オプション

FEATURE_QUOTA_MANAGEMENTQUOTA_BACKFILL結果

true

true

これらの機能を true に設定すると、クォータ管理が有効になり、Red Hat Quay 3.9 で機能します。Red Hat Quay 3.9 のクォータ管理の設定の詳細は、Red Hat Quay 3.9 のクォータ管理を参照してください。

true

false

FEATURE_QUOTA_MANAGEMENTtrue に設定し、QUOTA_BACKFILLfalse に設定すると、クォータ管理機能が有効になります。ただし、クォータ計算を続行するには、Red Hat Quay の以前の (N-1) y ストリームバージョン (3.8 など) からの既存のイメージをバックフィルする必要があります。イメージサイズをバックフィルするには、QUOTA_BACKFILLtrue に設定します。

false

false

これらの機能を false に設定すると、クォータ管理機能は無効になります。

false

true

FEATURE_QUOTA_MANAGEMENTfalse に設定し、QUOTA_BACKFILLtrue に設定すると、クォータ管理機能は無効になります。

2.1.3.2. 推奨されるクォータ管理設定

次の YAML は、クォータ管理を有効にするときに推奨される設定です。

推奨されるクォータ管理設定

FEATURE_QUOTA_MANAGEMENT: true
FEATURE_GARBAGE_COLLECTION: true
PERMANENTLY_DELETE_TAGS: true
QUOTA_TOTAL_DELAY_SECONDS: 1800
RESET_CHILD_MANIFEST_EXPIRATION: true

2.1.4. PostgreSQL PVC バックアップ環境変数

バージョン 3.8 → 3.9 にアップグレードするときに、Red Hat Quay が古い Persistent Volume Claim (PVC) を自動的に削除するかどうかを設定するために、次の環境変数が追加されました。

表2.5 Red Hat Quay 3.9 PostgreSQL バックアップ環境変数

フィールド説明

POSTGRES_UPGRADE_RETAIN_BACKUP

Boolean

True に設定すると、PostgreSQL 10 の永続ボリューム要求がバックアップされます。

デフォルト: False

2.1.4.1. PostgreSQL PVC バックアップの設定例

以下の Subscription オブジェクトは、PostgreSQL 10 PVC をバックアップする設定例を提供します。

PostgreSQL 10 PVC の Subscription オブジェクト

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: quay-operator
  namespace: quay-enterprise
spec:
  channel: stable-3.8
  name: quay-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: POSTGRES_UPGRADE_RETAIN_BACKUP
      value: "true"

2.2. 設定ファイルの編集

Red Hat Quay のスタンドアロンインスタンスをデプロイするには、最小限の設定情報を提供する必要があります。最小設定の要件は、「Red Hat Quay の最小設定」に記載されています。

必須フィールドに入力したら、設定を検証できます。問題がある場合は強調表示されます。

注記

設定 API を使用して設定を検証することもできますが、検証するには Quay コンテナーを設定モードで起動する必要があります。詳細は、「設定ツールの使用」を参照してください。

変更を有効にするには、レジストリーを再起動する必要があります。

2.3. スタンドアロンデプロイメントにおける設定ファイルの場所

Red Hat Quay のスタンドアロンデプロイメントの場合、Red Hat Quay レジストリーを開始するときに config.yaml ファイルを指定する必要があります。このファイルは設定ボリュームにあります。たとえば、次のコマンドで Red Hat Quay をデプロイする場合、設定ファイルは $QUAY/config/config.yaml にあります。

$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
   --name=quay \
   -v $QUAY/config:/conf/stack:Z \
   -v $QUAY/storage:/datastorage:Z \
   registry.redhat.io/quay/quay-rhel8:v3.9.6

2.4. 最小設定

Red Hat Quay のスタンドアロンデプロイメントには、以下の設定オプションが必要です。

  • サーバーのホスト名
  • HTTP または HTTPS
  • 認証タイプ (データベースや LDAP (Lightweight Directory Access Protocol) など)
  • データ暗号化用の秘密鍵
  • イメージのストレージ
  • メタデータ用のデータベース
  • ビルドログおよびユーザーイベント用の Redis
  • タグの有効期限オプション

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

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

AUTHENTICATION_TYPE: Database
BUILDLOGS_REDIS:
    host: quay-server.example.com
    password: strongpassword
    port: 6379
    ssl: false
DATABASE_SECRET_KEY: 0ce4f796-c295-415b-bf9d-b315114704b8
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
DEFAULT_TAG_EXPIRATION: 2w
DISTRIBUTED_STORAGE_CONFIG:
    default:
        - LocalStorage
        - storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default
PREFERRED_URL_SCHEME: http
SECRET_KEY: e8f9fe68-1f84-48a8-a05f-02d72e6eccba
SERVER_HOSTNAME: quay-server.example.com
SETUP_COMPLETE: true
TAG_EXPIRATION_OPTIONS:
    - 0s
    - 1d
    - 1w
    - 2w
    - 4w
USER_EVENTS_REDIS:
    host: quay-server.example.com
    port: 6379
    ssl: false
注記

SETUP_COMPLETE フィールドは、設定が検証されたことを示します。レジストリーを起動する前に、設定エディターツールを使用して設定を検証する必要があります。

2.4.2. ローカルストレージ

イメージへのローカルストレージの使用は、概念実証の目的のためにレジストリーをデプロイする場合に限り推奨されます。

ローカルストレージを設定する場合は、レジストリーの起動時にコマンドラインでストレージを指定します。次のコマンドは、ローカルディレクトリー $QUAY/storage をコンテナー内の datastorage ストレージパスにマップします。

$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
   --name=quay \
   -v $QUAY/config:/conf/stack:Z \
   -v $QUAY/storage:/datastorage:Z \
   registry.redhat.io/quay/quay-rhel8:v3.9.6

2.4.3. クラウドストレージ

ストレージの設定は、イメージストレージ セクションを参照してください。一部のユーザーにとっては、Google Cloud Platform とローカルストレージ設定の違いを比較すると役立つ場合があります。たとえば、次の YAML は Google Cloud Platform のストレージ設定を表しています。

$QUAY/config/config.yaml

DISTRIBUTED_STORAGE_CONFIG:
    default:
        - GoogleCloudStorage
        - access_key: GOOGQIMFB3ABCDEFGHIJKLMN
          bucket_name: quay_bucket
          secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
          storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default

クラウドストレージを使用してレジストリーを起動する場合は、コマンドラインでの設定が必要ありません。以下に例を示します。

$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
   --name=quay \
   -v $QUAY/config:/conf/stack:Z \
   registry.redhat.io/quay/quay-rhel8:v3.9.6

第3章 設定フィールド

このセクションでは、Red Hat Quay のデプロイ時に必須および任意の設定フィールドの両方を説明します。

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

Red Hat Quay の設定で必須のフィールドは、以下のセクションで説明されています。

3.2. 自動化オプション

以下のセクションでは、Red Hat Quay デプロイメントで利用可能な自動化オプションを説明します。

3.3. 任意の設定フィールド

Red Hat Quay の任意のフィールドは、以下のセクションで説明します。

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

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

表3.1 一般的な必須フィールド

フィールド説明

AUTHENTICATION_TYPE
(必須)

String

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

値:
DatabaseLDAPJWTKeystoneOIDC のいずれか。

デフォルト: Database

PREFERRED_URL_SCHEME
(必須)

String

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

値:
http, https のいずれか。

デフォルト: http

SERVER_HOSTNAME
(必須)

String

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

例:
quay-server.example.com

DATABASE_SECRET_KEY
(必須)

String

データベース内で機密フィールドを暗号化するのに使用されるキー。この値は、一度設定したら変更しないでください。変更すると、リポジトリーのミラーユーザー名やパスワード設定など、すべての信頼できるフィールドが無効になります。

SECRET_KEY
(必須)

String

データベース内および実行時に機密フィールドを暗号化するために使用されるキー。この値は一度設定したら決して変更しないでください。そうしないと、暗号化されたパスワード資格情報などのすべての依存フィールドが無効になります。

SETUP_COMPLETE
(必須)

Boolean

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

3.5. データベースの設定

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

3.5.1. データベース URI

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

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

表3.2 データベース URI

フィールド説明

DB_URI
(必須)

String

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

DB_URI フィールドの例:

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

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

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

以下の表は、データベース接続引数を説明します。

表3.3 データベース接続引数

フィールド説明

DB_CONNECTION_ARGS

Object

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

.autorollback

Boolean

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

.threadlocals

Boolean

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

3.5.2.1. PostgreSQL SSL/TLS 接続引数

SSL/TLS では、設定はデプロイするデータベースによって異なります。次の例は、PostgreSQL SSL/TLS 設定を示しています。

DB_CONNECTION_ARGS:
  sslmode: verify-ca
  sslrootcert: /path/to/cacert

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

表3.4 SSL/TLS オプション

モード説明

disable

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

allow

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

prefer
(デフォルト)

設定では、まず 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 を参照してください。

3.5.2.2. MySQL SSL/TLS 接続引数

次の例は、MySQL SSL/TLS 設定のサンプルを示しています。

DB_CONNECTION_ARGS:
  ssl:
    ca: /path/to/cacert

MySQL の有効な接続引数に関する情報は、Connecting to the Server Using URI-Like Strings or Key-Value Pairs を参照してください。

3.6. イメージストレージ

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

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

以下の表は、Red Hat Quay のイメージストレージ機能を説明しています。

表3.5 ストレージ設定機能

フィールド説明

FEATURE_REPO_MIRROR

Boolean

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

デフォルト: false

FEATURE_PROXY_STORAGE

Boolean

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

デフォルト: false

FEATURE_STORAGE_REPLICATION

Boolean

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

のデフォルト: false

3.6.2. イメージストレージ設定フィールド

以下の表は、Red Hat Quay のイメージストレージ設定フィールドを説明しています。

表3.6 ストレージ設定フィールド

フィールド説明

DISTRIBUTED_STORAGE_CONFIG
(必須)

Object

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

デフォルト: []

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS
(必須)

Array of string

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

DISTRIBUTED_STORAGE_PREFERENCE
(必須)

Array of string

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

デフォルト: false

MAXIMUM_LAYER_SIZE

String

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

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

: 100G

デフォルト: 20G

3.6.3. ローカルストレージ

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

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

3.6.4. OCS/NooBaa

以下の YAML は、Open Container Storage/NooBaa インスタンスを使用した設定例を示しています。

DISTRIBUTED_STORAGE_CONFIG:
  rhocsStorage:
    - RHOCSStorage
    - access_key: access_key_here
      secret_key: secret_key_here
      bucket_name: quay-datastore-9b2108a3-29f5-43f2-a9d5-2872174f9a56
      hostname: s3.openshift-storage.svc.cluster.local
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry

3.6.5. Ceph/RadosGW ストレージ

次の例は、Ceph/RadosGW を使用する場合に考えられる 2 つの YAML 設定を示しています。

例 A: radosGWStorage ドライバーで RadosGW を使用する

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

例 B: 一般的な s3 アクセスで RadosGW を使用する

DISTRIBUTED_STORAGE_CONFIG:
  s3Storage: 1
    - RadosGWStorage
    - access_key: <access_key_here>
      bucket_name: <bucket_name_here>
      hostname: <hostname_here>
      is_secure: true
      secret_key: <secret_key_here>
      storage_path: /datastorage/registry

1
一般的な s3 アクセスに使用します。一般的な s3 アクセスは、厳密には Amazon Web Services (AWS) 3 に限定されず、RadosGW または他のストレージサービスでも使用できることに注意してください。AWS S3 ドライバーを使用した一般的な s3 アクセスの例については、「AWS S3 ストレージ」を参照してください。

3.6.6. AWS S3 ストレージ

以下の YAML は、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
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - s3Storage
1
S3Storage ストレージドライバーは、AWS S3 バケットにのみ使用してください。これは、RadosGW ドライバーや他のストレージサービスを使用できる一般的な S3 アクセスとは異なることに注意してください。例については、「例 B: 一般的な S3 アクセスで RadosGW を使用する」を参照してください。

3.6.7. Google Cloud Storage

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

DISTRIBUTED_STORAGE_CONFIG:
    googleCloudStorage:
        - GoogleCloudStorage
        - access_key: GOOGQIMFB3ABCDEFGHIJKLMN
          bucket_name: quay-bucket
          secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
          storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - googleCloudStorage

3.6.8. Azure Storage

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

DISTRIBUTED_STORAGE_CONFIG:
  azureStorage:
    - AzureStorage
    - azure_account_name: azure_account_name_here
      azure_container: azure_container_here
      storage_path: /datastorage/registry
      azure_account_key: azure_account_key_here
      sas_token: some/path/
      endpoint_url: https://[account-name].blob.core.usgovcloudapi.net 1
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - azureStorage
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 エラーが発生します。

3.6.9. Swift ストレージ:

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

DISTRIBUTED_STORAGE_CONFIG:
  swiftStorage:
    - SwiftStorage
    - swift_user: swift_user_here
      swift_password: swift_password_here
      swift_container: swift_container_here
      auth_url: https://example.org/swift/v1/quay
      auth_version: 1
      ca_cert_path: /conf/stack/swift.cert"
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - swiftStorage

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

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

DISTRIBUTED_STORAGE_CONFIG:
  nutanixStorage: #storage config name
    - RadosGWStorage #actual driver
    - access_key: access_key_here #parameters
      secret_key: secret_key_here
      bucket_name: bucket_name_here
      hostname: hostname_here
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE: #must contain name of the storage config
    - nutanixStorage

3.7. Redis 設定フィールド

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

3.7.1. ビルドログ

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

表3.7 ビルドログの設定

フィールド説明

BUILDLOGS_REDIS
(必須)

Object

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

.host
(必須)

String

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

.port
(必須)

Number

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

.password

String

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

.ssl
(オプション)

Boolean

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

3.7.2. ユーザーイベント

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

表3.8 ユーザーイベント設定

フィールド説明

USER_EVENTS_REDIS
(必須)

Object

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

.host
(必須)

String

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

.port
(必須)

Number

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

3.7.3. redis の設定例

次の YAML は、オプションの SSL/TLS フィールドを持つ Redis を使用したサンプル設定を示しています。

BUILDLOGS_REDIS:
  host: quay-server.example.com
  password: strongpassword
  port: 6379
  ssl: true


USER_EVENTS_REDIS:
  host: quay-server.example.com
  password: strongpassword
  port: 6379
  ssl: true
  ssl_*: <path_location_or_certificate>
注記

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

3.8. ModelCache 設定オプション

以下のオプションは、ModelCache を設定するために Red Hat Quay で利用できます。

3.8.1. memcache 設定オプション

memcache は、デフォルトの ModelCache 設定オプションです。memcache を使用すると、追加の設定は必要ありません。

3.8.2. 単一の Redis 設定オプション

以下の設定は、オプションの読み取り専用レプリカを持つ単一の Redis インスタンス用です。

    DATA_MODEL_CACHE_CONFIG:
      engine: redis
      redis_config:
        primary:
            host: <host>
            port: <port>
            password: <password if ssl is true>
           ssl: <true | false >
        replica:
            host: <host>
            port: <port>
            password: <password if ssl is true>
           ssl: <true | false >

3.8.3. クラスター化された Redis 設定オプション

クラスター化された Redis インスタンスには、次の設定を使用します。

    DATA_MODEL_CACHE_CONFIG:
      engine: rediscluster
      redis_config:
        startup_nodes:
          - host: <cluster-host>
            port: <port>
        password: <password if ssl: true>
        read_from_replicas: <true|false>
        skip_full_coverage_check: <true | false>
        ssl: <true | false >

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

以下のタグの有効期限設定フィールドは Red Hat Quay で利用できます。

表3.9 タグの有効期限の設定フィールド

フィールド説明

FEATURE_GARBAGE_COLLECTION

Boolean

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

デフォルト: True

TAG_EXPIRATION_OPTIONS
(必須)

Array of string

有効にすると、名前空間内のタグの有効期限についてユーザーが選択できるオプション。

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

DEFAULT_TAG_EXPIRATION
(必須)

String

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

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

FEATURE_CHANGE_TAG_EXPIRATION

Boolean

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

デフォルト: True

3.9.1. タグの有効期限の設定例

以下の YAML は、タグの有効期限の設定例を示しています。

DEFAULT_TAG_EXPIRATION: 2w
TAG_EXPIRATION_OPTIONS:
    - 0s
    - 1d
    - 1w
    - 2w
    - 4w

3.10. クォータ管理設定フィールド

表3.10 クォータ管理設定

フィールド説明

FEATURE_QUOTA_MANAGEMENT

Boolean

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

**Default:** `False`

DEFAULT_SYSTEM_REJECT_QUOTA_BYTES

String

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

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

QUOTA_BACKFILL

Boolean

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

デフォルト: True

QUOTA_TOTAL_DELAY_SECONDS

String

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

デフォルト: 1800

PERMANENTLY_DELETE_TAGS

Boolean

タイムマシンウィンドウからのタグの削除に関連する機能を有効にします。

デフォルト:False

RESET_CHILD_MANIFEST_EXPIRATION

Boolean

子マニフェストを対象とする一時タグの有効期限をリセットします。この機能を True に設定すると、子マニフェストはすぐにガベージコレクションされます。

デフォルト:False

3.10.1. クォータ管理設定の例

次の YAML は、クォータ管理を有効にするときに推奨される設定です。

クォータ管理 YAML 設定

FEATURE_QUOTA_MANAGEMENT: true
FEATURE_GARBAGE_COLLECTION: true
PERMANENTLY_DELETE_TAGS: true
QUOTA_TOTAL_DELAY_SECONDS: 1800
RESET_CHILD_MANIFEST_EXPIRATION: true

3.11. プロキシーキャッシュ設定フィールド

表3.11 プロキシー設定

フィールド説明

FEATURE_PROXY_CACHE

Boolean

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

デフォルト: false

3.12. 自動化のための Red Hat Quay の事前設定

Red Hat Quay は、自動化を可能にするいくつかの設定オプションをサポートします。ユーザーはデプロイメント前にこれらのオプションを設定して、ユーザーインターフェイスとの対話の必要性を減らすことができます。

3.12.1. API による最初のユーザー作成の許可

最初のユーザーを作成するには、ユーザーは FEATURE_USER_INITIALIZE パラメーターを true に設定し、/api/v1/user/initialize API を呼び出す必要があります。既存の組織の OAuth アプリケーションによって生成された OAuth トークンを必要とする他のすべてのレジストリー API 呼び出しとは異なり、API エンドポイントは認証を必要としません。

他のユーザーが作成されていない場合、ユーザーは Red Hat Quay のデプロイ後に API を使用して quayadmin などのユーザーを作成できます。詳細は、API を使用して最初のユーザーを作成する を参照してください。

3.12.2. API 一般アクセスの有効化

Red Hat Quay レジストリー API への一般的なアクセスを許可するには、ユーザーは BROWSER_API_CALLS_XHR_ONLY 設定オプションを false に設定する必要があります。

3.12.3. スーパーユーザーの追加

Red Hat Quay をデプロイした後、ユーザーはユーザーを作成し、最初のユーザーに完全な権限を持つ管理者権限を与えることができます。ユーザーは、SUPER_USER 設定オブジェクトを使用して、事前に完全な権限を設定できます。以下に例を示します。

...
SERVER_HOSTNAME: quay-server.example.com
SETUP_COMPLETE: true
SUPER_USERS:
  - quayadmin
...

3.12.4. ユーザー作成の制限

スーパーユーザーを設定した後、FEATURE_USER_CREATIONfalse に設定することで、新しいユーザーを作成できる権限をスーパーユーザーグループに制限できます。以下に例を示します。

...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
...

3.12.5. Red Hat Quay 3.8 での新機能の有効化

新しい Red Hat Quay 3.8 の機能を使用するには、次の機能の一部またはすべてを有効にします。

...
FEATURE_UI_V2: true
FEATURE_LISTEN_IP_VERSION:
FEATURE_SUPERUSERS_FULL_ACCESS: true
GLOBAL_READONLY_SUPER_USERS:
      -
FEATURE_RESTRICTED_USERS: true
RESTRICTED_USERS_WHITELIST:
      -
...

3.12.6. Red Hat Quay 3.7 での新機能の有効化

新しい Red Hat Quay 3.7 の機能を使用するには、次の機能の一部またはすべてを有効にします。

...
FEATURE_QUOTA_MANAGEMENT: true
FEATURE_BUILD_SUPPORT: true
FEATURE_PROXY_CACHE: true
FEATURE_STORAGE_REPLICATION: true
DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: 102400000
...

3.12.7. 自動化の推奨設定

自動化には、以下の config.yaml パラメーターが推奨されます。

...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
...

3.12.8. 初期設定を使用した Red Hat Quay Operator のデプロイ

以下の手順に従って、初期設定を使用して OpenShift Container Platform に Red Hat Quay をデプロイします。

前提条件

  • oc CLI がインストールされている。

手順

  1. 設定ファイルを使用してシークレットを作成します。

    $ oc create secret generic -n quay-enterprise --from-file config.yaml=./config.yaml init-config-bundle-secret
  2. quayregistry.yaml ファイルを作成します。以下のように、管理対象外のコンポーネントを特定し、作成されたシークレットを参照します。

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: example-registry
      namespace: quay-enterprise
    spec:
      configBundleSecret: init-config-bundle-secret
  3. Red Hat Quay レジストリーをデプロイします。

    $ oc create -n quay-enterprise -f quayregistry.yaml

3.12.8.1. API を使用した最初のユーザーの作成

以下の手順に従って、Red Hat Quay 組織で最初のユーザーを作成します。

前提条件

  • 設定オプション FEATURE_USER_INITIALIZEtrue に設定する。
  • データベースにユーザーが存在していない。
手順

この手順では、"access_token": true を指定して OAuth トークンを要求します。

  1. root ユーザーとして、次のコマンドを入力して python39 をインストールします。

    $ sudo yum install python39
  2. Python 3.9 の pip パッケージマネージャーをアップグレードします。

    $ python3.9 -m pip install --upgrade pip
  3. pip パッケージマネージャーを使用して bcrypt パッケージをインストールします。

    $ pip install bcrypt
  4. 次のコマンドを入力して、Python 3.9 の bcrypt パッケージを使用して、安全なハッシュ化されたパスワードを生成します。

    $ python3.9 -c 'import bcrypt; print(bcrypt.hashpw(b"subquay12345", bcrypt.gensalt(12)).decode("utf-8"))'
  5. Red Hat Quay 設定ファイルを開き、以下の設定フィールドを更新します。

    FEATURE_USER_INITIALIZE: true
    SUPER_USERS:
         -  quayadmin
  6. 次のコマンドを入力して、Red Hat Quay サービスを停止します。

    $ sudo podman stop quay
  7. 次のコマンドを入力して、Red Hat Quay サービスを開始します。

    $ sudo podman run -d -p 80:8080 -p 443:8443 --name=quay -v $QUAY/config:/conf/stack:Z  -v $QUAY/storage:/datastorage:Z {productrepo}/{quayimage}:{productminv}
  8. 次の CURL コマンドを実行して、ユーザー名、パスワード、電子メール、およびアクセストークンを使用して新しいユーザーを生成します。

    $ curl -X POST -k  http://quay-server.example.com/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"quaypass12345", "email": "quayadmin@example.com", "access_token": true}'

    成功すると、このコマンドはユーザー名、メール、および暗号化されたパスワードが含まれるオブジェクトを返します。以下に例を示します。

    {"access_token":"6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED", "email":"quayadmin@example.com","encrypted_password":"1nZMLH57RIE5UGdL/yYpDOHLqiNCgimb6W9kfF8MjZ1xrfDpRyRs9NUnUuNuAitW","username":"quayadmin"} # gitleaks:allow

    データベースにユーザーが存在している場合は、エラーが返されます。

    {"message":"Cannot initialize user in a non-empty database"}

    パスワードが 8 文字以上でない場合や、空白が含まれている場合には、エラーが返されます。

    {"message":"Failed to initialize user: Invalid password, password must be at least 8 characters and contain no whitespace."}
  9. 以下のコマンドを入力して、Red Hat Quay デプロイメントにログインします。

    $ sudo podman login -u quayadmin -p quaypass12345 http://quay-server.example.com --tls-verify=false

    出力例

    Login Succeeded!

3.12.8.2. OAuth トークンの使用

API の呼び出し後に、返される OAuth コードを指定して残りの Red Hat Quay API を呼び出すことができます。

前提条件

  • /api/v1/user/initialize API を呼び出し、ユーザー名、パスワード、およびメールアドレスに渡している。

手順

  • 以下のコマンドを入力して、現在のユーザーの一覧を取得します。

    $ curl -X GET -k -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/superuser/users/

    出力例:

    {
        "users": [
            {
                "kind": "user",
                "name": "quayadmin",
                "username": "quayadmin",
                "email": "quayadmin@example.com",
                "verified": true,
                "avatar": {
                    "name": "quayadmin",
                    "hash": "3e82e9cbf62d25dec0ed1b4c66ca7c5d47ab9f1f271958298dea856fb26adc4c",
                    "color": "#e7ba52",
                    "kind": "user"
                },
                "super_user": true,
                "enabled": true
            }
        ]
    }

    このインスタンスでは、これまで作成した唯一のユーザーであるため、quayadmin ユーザーの詳細が返されます。

3.12.8.3. API を使用した組織の作成

以下の手順では、API を使用して Red Hat Quay 組織を作成する方法を説明します。

前提条件

  • /api/v1/user/initialize API を呼び出し、ユーザー名、パスワード、およびメールアドレスに渡している。
  • 返された OAuth コードを指定して、残りの Red Hat Quay API を呼び出している。

手順

  1. 組織を作成するには、api/v1/organization/ エンドポイントへの POST 呼び出しを使用します。

    $ curl -X POST -k --header 'Content-Type: application/json' -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/organization/ --data '{"name": "testorg", "email": "testorg@example.com"}'

    出力例:

    "Created"
  2. 以下のコマンドを入力して、作成した組織の詳細を取得できます。

    $ curl -X GET -k --header 'Content-Type: application/json' -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://min-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/organization/testorg

    出力例:

    {
        "name": "testorg",
        "email": "testorg@example.com",
        "avatar": {
            "name": "testorg",
            "hash": "5f113632ad532fc78215c9258a4fb60606d1fa386c91b141116a1317bf9c53c8",
            "color": "#a55194",
            "kind": "user"
        },
        "is_admin": true,
        "is_member": true,
        "teams": {
            "owners": {
                "name": "owners",
                "description": "",
                "role": "admin",
                "avatar": {
                    "name": "owners",
                    "hash": "6f0e3a8c0eb46e8834b43b03374ece43a030621d92a7437beb48f871e90f8d90",
                    "color": "#c7c7c7",
                    "kind": "team"
                },
                "can_view": true,
                "repo_count": 0,
                "member_count": 1,
                "is_synced": false
            }
        },
        "ordered_teams": [
            "owners"
        ],
        "invoice_email": false,
        "invoice_email_address": null,
        "tag_expiration_s": 1209600,
        "is_free_account": true
    }

3.13. 基本設定フィールド

表3.12 基本設定

フィールド説明

REGISTRY_TITLE

String

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

REGISTRY_TITLE_SHORT

String

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

CONTACT_INFO

Array of string

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

[0]

String

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

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

[1]

String

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

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

[2]

String

電話番号を呼び出すためのリンクを追加します。+
パターン:
^tel:(.)+$
例:
tel:+1-888-930-3475

[3]

String

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

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

3.14. SSL 設定フィールド

表3.13 SSL 設定

フィールド説明

PREFERRED_URL_SCHEME

String

http または https のいずれか。クライアントから Quay への通信パスに TLS 暗号化がない場合に限り、ユーザーは PREFERRED_URL_SCHEMEhttp に設定することに注意してください。

+ TLS を終了するロードバランサー、リバースプロキシー (Nginx など) を使用する場合、またはカスタム SSL 証明書で Quay を直接使用する場合、ユーザーは PREFERRED_URL_SCHEMEhttps に設定する必要があります。ほとんどの場合、PREFERRED_URL_SCHEMEhttps である必要があります。
デフォルト: http

SERVER_HOSTNAME
(必須)

String

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

例:
quay-server.example.com

SSL_CIPHERS

Array of string

指定されている場合は、有効化および無効化する SSL 暗号の nginx 定義の一覧。

例:
[CAMELLIA, !3DES]

SSL_PROTOCOLS

Array of string

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

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

SESSION_COOKIE_SECURE

Boolean

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

デフォルト:
False

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

3.14.1. SSL の設定

  1. 証明書ファイルとプライマリーキーファイルを設定ディレクトリーにコピーして、それぞれ ssl.certssl.key という名前が付けられていることを確認します。

    $ cp ~/ssl.cert $QUAY/config
    $ cp ~/ssl.key $QUAY/config
    $ cd $QUAY/config
  2. config.yaml ファイルを編集し、Quay で TLS を処理できるように指定します。

    config.yaml

    ...
    SERVER_HOSTNAME: quay-server.example.com
    ...
    PREFERRED_URL_SCHEME: https
    ...

  3. Quay コンテナーを停止し、レジストリーを再起動します。

3.15. Red Hat Quay コンテナーへの TLS 証明書の追加

カスタム TLS 証明書を Red Hat Quay に追加するには、Red Hat Quay の config ディレクトリーの下に extra_ca_certs/ という名前の新しいディレクトリーを作成します。必要なサイト固有の TLS 証明書をこの新しいディレクトリーにコピーします。

3.15.1. TLS 証明書を Red Hat Quay に追加

  1. コンテナーに追加される証明書を表示します。

    $ cat storage.crt
    -----BEGIN CERTIFICATE-----
    MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV
    [...]
    -----END CERTIFICATE-----
  2. certs ディレクトリーを作成し、そこに証明書をコピーします。

    $ mkdir -p quay/config/extra_ca_certs
    $ cp storage.crt quay/config/extra_ca_certs/
    $ tree quay/config/
    ├── config.yaml
    ├── extra_ca_certs
    │   ├── storage.crt
  3. Quay コンテナーの CONTAINER IDpodman ps で取得します。

    $ sudo podman ps
    CONTAINER ID        IMAGE                                COMMAND                  CREATED             STATUS              PORTS
    5a3e82c4a75f        <registry>/<repo>/quay:v3.9.6 "/sbin/my_init"          24 hours ago        Up 18 hours         0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 443/tcp   grave_keller
  4. その ID でコンテナーを再起動します。

    $ sudo podman restart 5a3e82c4a75f
  5. コンテナーの名前空間にコピーされた証明書を調べます。

    $ sudo podman exec -it 5a3e82c4a75f cat /etc/ssl/certs/storage.pem
    -----BEGIN CERTIFICATE-----
    MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV

3.16. LDAP 設定フィールド

表3.14 LDAP の設定

フィールド説明

AUTHENTICATION_TYPE
(必須)

String

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

FEATURE_TEAM_SYNCING

Boolean

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

デフォルト: true

FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP

Boolean

有効にすると、スーパーユーザー以外も LDAP を使用してチームでの同期をセットアップできます。

デフォルト: false

LDAP_ADMIN_DN

String

LDAP 認証の管理 DN。

LDAP_ADMIN_PASSWD

String

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

LDAP_ALLOW_INSECURE_FALLBACK

Boolean

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

LDAP_BASE_DN

Array of string

LDAP 認証のベース DN。

LDAP_EMAIL_ATTR

String

LDAP 認証のメール属性。

LDAP_UID_ATTR

String

LDAP 認証の uid 属性。

LDAP_URI

String

LDAP URI。

LDAP_USER_FILTER

String

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

LDAP_USER_RDN

Array of string

LDAP 認証のユーザー RDN。

TEAM_RESYNC_STALE_TIME

String

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

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

LDAP_SUPERUSER_FILTER

String

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

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

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

LDAP_RESTRICTED_USER_FILTER

String

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

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

LDAP_TIMEOUT

Integer

LDAP (Lightweight Directory Access Protocol) サーバーへの接続を確立するのに許可される最大時間を秒単位で指定します。

デフォルト: 10

LDAP_NETWORK_TIMEOUT

Integer

Red Hat Quay がネットワーク操作中に LDAP (Lightweight Directory Access Protocol)サーバーからの応答を待つ最大時間を秒単位で定義します。

デフォルト: 10

3.16.1. LDAP 設定リファレンス

次の参照を使用して、目的の設定フィールドで config.yaml ファイルを更新します。

3.16.1.1. 基本的な LDAP 設定

---
AUTHENTICATION_TYPE: LDAP
---
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com
LDAP_ADMIN_PASSWD: ABC123
LDAP_ALLOW_INSECURE_FALLBACK: false
LDAP_BASE_DN:
    - o=<organization_id>
    - dc=<example_domain_component>
    - dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldaps://<ldap_url_domain_name>
LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,dc=<domain_name>,dc=com)
LDAP_USER_RDN:
    - ou=<example_organization_unit>
    - o=<organization_id>
    - dc=<example_domain_component>
    - dc=com

3.16.1.2. LDAP 制限付きユーザー設定

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

3.16.1.3. LDAP スーパーユーザー設定リファレンス

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

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

表3.15 ミラーリング設定

フィールド説明

FEATURE_REPO_MIRROR

Boolean

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

デフォルト: false

REPO_MIRROR_INTERVAL

Number

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

REPO_MIRROR_SERVER_HOSTNAME

String

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

デフォルト: None

:
openshift-quay-service

REPO_MIRROR_TLS_VERIFY

Boolean

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

デフォルト: false

REPO_MIRROR_ROLLBACK

Boolean

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

デフォルト: false

3.18. セキュリティースキャナー設定フィールド

表3.16 セキュリティースキャナーの設定

フィールド説明

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

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

3.18.2. セキュリティースキャナーの設定の例

次の YAML は、セキュリティースキャナー機能を有効にする場合の推奨設定です。

セキュリティースキャナーの 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_ENDPOINT: http://quay-server.example.com:8081
SECURITY_SCANNER_V4_PSK: MTU5YzA4Y2ZkNzJoMQ==
SERVER_HOSTNAME: quay-server.example.com
...

3.19. Helm 設定フィールド

表3.17 Helm 設定フィールド

フィールド説明

FEATURE_GENERAL_OCI_SUPPORT

Boolean

OCI アーティファクトのサポートを有効にします。

デフォルト: True

次の Open Container Initiative (OCI) アーティファクトタイプは、デフォルトで Red Hat Quay に組み込まれており、FEATURE_GENERAL_OCI_SUPPORT 設定フィールドを通じて有効になります。

フィールドメディアタイプサポートされているコンテンツタイプ

Helm

application/vnd.cncf.helm.config.v1+json

application/tar+gzipapplication/vnd.cncf.helm.chart.content.v1.tar+gzip

Cosign

application/vnd.oci.image.config.v1+json

application/vnd.dev.cosign.simplesigning.v1+jsonapplication/vnd.dsse.envelope.v1+json

SPDX

application/vnd.oci.image.config.v1+json

text/spdxtext/spdx+xmltext/spdx+json

Syft

application/vnd.oci.image.config.v1+json

application/vnd.syft+json

CycloneDX

application/vnd.oci.image.config.v1+json

application/vnd.cyclonedxapplication/vnd.cyclonedx+xmlapplication/vnd.cyclonedx+json

In-toto

application/vnd.oci.image.config.v1+json

application/vnd.in-toto+json

Unknown

application/vnd.cncf.openpolicyagent.policy.layer.v1+rego

application/vnd.cncf.openpolicyagent.policy.layer.v1+regoapplication/vnd.cncf.openpolicyagent.data.layer.v1+json

3.19.1. Helm の設定

次の YAML は、Helm を有効にする場合の設定例です。

Helm YAML 設定

FEATURE_GENERAL_OCI_SUPPORT: true

3.20. Open Container Initiative 設定フィールド

表3.18 追加の OCI アーティファクト設定フィールド

フィールド説明

ALLOWED_OCI_ARTIFACT_TYPES

Object

許可される OCI アーティファクト MIME タイプと関連するレイヤータイプのセット。

3.20.1. 追加のアーティファクトタイプの設定

デフォルトでサポートされていない他の OCI アーティファクトタイプは、ALLOWED_OCI_ARTIFACT_TYPES 設定フィールドを使用して Red Hat Quay デプロイメントに追加できます。

追加の OCI アーティファクトタイプを追加するには、次のリファレンスを使用します。

OCI アーティファクトタイプの設定

FEATURE_GENERAL_OCI_SUPPORT: true
ALLOWED_OCI_ARTIFACT_TYPES:
  <oci config type 1>:
  - <oci layer type 1>
  - <oci layer type 2>

  <oci config type 2>:
  - <oci layer type 3>
  - <oci layer type 4>

たとえば、以下を config.yaml に追加して Singularity (SIF) サポートを追加できます。

OCI アーティファクトタイプの設定例

ALLOWED_OCI_ARTIFACT_TYPES:
  application/vnd.oci.image.config.v1+json:
  - application/vnd.dev.cosign.simplesigning.v1+json
  application/vnd.cncf.helm.config.v1+json:
  - application/tar+gzip
  application/vnd.sylabs.sif.config.v1+json:
  - application/vnd.sylabs.sif.layer.v1+tar

注記

デフォルトで設定されていない OCI アーティファクトタイプを追加する場合、Red Hat Quay 管理者は、必要に応じて cosign と Helm のサポートを手動で追加する必要もあります。

3.21. 不明なメディアタイプ

表3.19 不明なメディアタイプ設定フィールド

フィールド説明

IGNORE_UNKNOWN_MEDIATYPES

Boolean

有効にすると、コンテナーレジストリープラットフォームは、サポートされているアーティファクトタイプに関する特定の制限を無視し、認識されないメディアタイプまたは未知のメディアタイプを受け入れることができます。

デフォルト: false

3.21.1. 不明なメディアタイプの設定

次の YAML は、不明なメディアタイプまたは認識されないメディアタイプを有効にする場合の設定例です。

不明なメディアタイプの YAML 設定

IGNORE_UNKNOWN_MEDIATYPES: true

3.22. アクションログ設定フィールド

3.22.1. アクションログストレージ設定

表3.20 アクションログストレージ設定

フィールド説明

FEATURE_LOG_EXPORT

Boolean

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

デフォルト: True

LOGS_MODEL

String

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

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

LOGS_MODEL_CONFIG

Object

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

  • LOGS_MODEL_CONFIG [オブジェクト]: アクションログ用のログモデル設定。

    • elasticsearch_config [オブジェクト]: Elasticsearch クラスターの設定。

      • access_key [文字列] :Elasticsearch のユーザー (AWS ES の場合は IAM キー)。

        • : some_string
      • host [文字列]: Elasticsearch クラスターのエンドポイント。

        • : host.elasticsearch.example
      • index_prefix [文字列]。Elasticsearch のインデックスの接頭辞。

        • : logentry_
      • index_settings [オブジェクト]: Elasticsearch のインデックス設定。
      • use_ssl [ブール値]。Elasticsearch に ssl を使用します。デフォルトは True に設定されます。

        • : True
      • secret_key [文字列] :Elasticsearch のパスワード (AWS ES の場合は IAM シークレット)。

        • : some_secret_string
      • aws_region [文字列]: Amazon Web サービスの地域。

        • : us-east-1
      • port [数値]: Elasticsearch クラスターのエンドポイントポート。

        • : 1234
    • kinesis_stream_config [オブジェクト]: AWS Kinesis ストリームの設定。

      • aws_secret_key [文字列]: AWS の秘密鍵。

        • : some_secret_key
      • stream_name [文字列]: アクションログの送信先となる Kinesis ストリーム。

        • : logentry-kinesis-stream
      • aws_access_key [文字列]: AWS アクセスキー。

        • : some_access_key
      • retries [数値]: 一回のリクエストに対する最大試行回数。

        • : 5
      • read_timeout [数値]: 接続の読み込み時にタイムアウトするまでの秒数。

        • : 5
      • max_pool_connections [数値]: コネクションプールに保持するコネクションの最大数。

        • : 10
      • aws_region [文字列]: AWS のリージョン。

        • : us-east-1
      • connect_timeout [数値]: 接続を試みる際のタイムアウトまでの秒数。

        • : 5
    • producer [文字列]: Elasticsearch にロギングする場合は、producer を記録する。

      • enum: kafka、elasticsearch、kinesis_stream
      • : kafka
    • kafka_config [オブジェクト]: Kafka クラスターの設定。

      • topic [文字列]: ログエントリーを公開する Kafka トピック。

        • : logentry
      • bootstrap_servers [配列]: クライアントをブートストラップさせる Kafka ブローカーのリスト。
      • max_block_seconds [数値]: send() の実行中に、バッファーがいっぱいになったり、メタデータが利用できないなどの理由でブロックする最大秒数。

        • : 10
    • producer [文字列]: splunk
    • splunk_config [オブジェクト]: Splunk アクションログのログモデル設定または Splunk クラスター設定。

      • host [文字列]: Splunk クラスターのエンドポイント。
      • port [整数]: Splunk 管理クラスターのエンドポイントポート。
      • bearer_token [文字列]: Splunk のベアラートークン。
      • verify_ssl [ブール値]: HTTPS 接続の TLS/SSL 検証を有効 (True) または無効 (False) にする。
      • Index_prefix [文字列]: Splunk のインデックス接頭辞。
      • ssl_ca_path [文字列]: SSL 検証用の認証局 (CA) を含む単一の .pem ファイルへの相対コンテナーパス。

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

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

フィールド説明

FEATURE_ACTION_LOG_ROTATION

Boolean

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

デフォルト: false

ACTION_LOG_ARCHIVE_LOCATION

String

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

例: s3_us_east

ACTION_LOG_ARCHIVE_PATH

String

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

例: archives/actionlogs

ACTION_LOG_ROTATION_THRESHOLD

String

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

例: 30d

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

表3.22 監査ログ設定フィールド

フィールド説明

ACTION_LOG_AUDIT_LOGINS

Boolean

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

デフォルト: True

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

表3.23 ビルドログ設定フィールド

フィールド説明

FEATURE_READER_BUILD_LOGS

Boolean

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

デフォルト:False

LOG_ARCHIVE_LOCATION

String

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

例: s3_us_east

LOG_ARCHIVE_PATH

String

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

例: archives/buildlogs

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

表3.24 Dockerfile ビルドのサポート

フィールド説明

FEATURE_BUILD_SUPPORT

Boolean

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

デフォルト: False

SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD

Number

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

デフォルト: 100

SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD

Number

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

デフォルト: 5

3.24.1. GitHub ビルドトリガー

表3.25 GitHub ビルドトリガー

フィールド説明

FEATURE_GITHUB_BUILD

Boolean

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

デフォルト: False

 

 

 

GITHUB_TRIGGER_CONFIG

Object

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

   .GITHUB_ENDPOINT
(必須)

String

GitHub Enterprise のエンドポイント。

例: https://github.com/

   .API_ENDPOINT

String

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

: https://api.github.com/

   .CLIENT_ID
(必須)

String

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

   .CLIENT_SECRET
(必須)

String

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

3.24.2. Bitbucket ビルドトリガー

表3.26 Bitbucket ビルドトリガー

フィールド説明

FEATURE_BITBUCKET_BUILD

Boolean

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

デフォルト: False

 

 

 

BITBUCKET_TRIGGER_CONFIG

Object

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

   .CONSUMER_KEY
(必須)

String

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

   .CONSUMER_SECRET
(必須)

String

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

3.24.3. GitLab ビルドトリガー

表3.27 GitLab ビルドトリガー

フィールド説明

FEATURE_GITLAB_BUILD

Boolean

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

デフォルト: False

 

 

 

GITLAB_TRIGGER_CONFIG

Object

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

   .GITLAB_ENDPOINT
(必須)

String

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

   .CLIENT_ID
(必須)

String

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

   .CLIENT_SECRET
(必須)

String

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

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

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

フィールド説明

ALLOWED_WORKER_COUNT

String

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

ORCHESTRATOR_PREFIX

String

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

REDIS_HOST

Object

Redis サービスのホスト名。

REDIS_PASSWORD

String

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

REDIS_SSL

Boolean

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

REDIS_SKIP_KEYSPACE_EVENT_SETUP

Boolean

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

EXECUTOR

String

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

BUILDER_NAMESPACE

String

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

K8S_API_SERVER

Object

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

K8S_API_TLS_CA

Object

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

KUBERNETES_DISTRIBUTION

String

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

CONTAINER_*

Object

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

NODE_SELECTOR_*

Object

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

CONTAINER_RUNTIME

Object

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

SERVICE_ACCOUNT_NAME/SERVICE_ACCOUNT_TOKEN

Object

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

QUAY_USERNAME/QUAY_PASSWORD

Object

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

WORKER_IMAGE

Object

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

WORKER_TAG

Object

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

BUILDER_VM_CONTAINER_IMAGE

Object

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

SETUP_TIME

String

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

MINIMUM_RETRY_THRESHOLD

String

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

SSH_AUTHORIZED_KEYS

Object

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

3.26. OAuth 設定フィールド

表3.29 OAuth フィールド

フィールド説明

DIRECT_OAUTH_CLIENTID_WHITELIST

Array of string

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

3.26.1. GitHub OAuth 設定フィールド

表3.30 GitHub OAuth フィールド

フィールド説明

FEATURE_GITHUB_LOGIN

Boolean

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

**デフォルト: False

GITHUB_LOGIN_CONFIG

Object

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

   .ALLOWED_ORGANIZATIONS

Array of string

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

   .API_ENDPOINT

String

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

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

   .CLIENT_ID
(必須)

String

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

例: 0e8dbe15c4c7630b6780

   .CLIENT_SECRET
(必須)

String

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

例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

   .GITHUB_ENDPOINT
(必須)

String

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

: https://github.com/

   .ORG_RESTRICT

Boolean

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

3.26.2. Google OAuth 設定フィールド

表3.31 Google OAuth フィールド

フィールド説明

FEATURE_GOOGLE_LOGIN

Boolean

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

**デフォルト: False

GOOGLE_LOGIN_CONFIG

Object

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

   .CLIENT_ID
(必須)

String

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

例: 0e8dbe15c4c7630b6780

   .CLIENT_SECRET
(必須)

String

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

例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

3.27. OIDC 設定フィールド

表3.32 OIDC フィールド

フィールド

説明

<文字列>_LOGIN_CONFIG
(必須)

String

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

.CLIENT_ID
(必須)

String

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

例: 0e8dbe15c4c7630b6780

.CLIENT_SECRET
(必須)

String

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

例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

.DEBUGLOG

Boolean

デバッグを有効にするかどうか。

.LOGIN_BINDING_FIELD

String

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

.LOGIN_SCOPES

Object

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

.OIDC_ENDPOINT_CUSTOM_PARAMS

String

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

.OIDC_ISSUER

String

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

.OIDC_SERVER
(必須)

String

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

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

.PREFERRED_USERNAME_CLAIM_NAME

String

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

.SERVICE_ICON

String

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

.SERVICE_NAME
(必須)

String

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

例: Azure AD

.VERIFIED_EMAIL_CLAIM_NAME

String

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

3.27.1. OIDC 設定

以下の例は、OIDC 設定のサンプルを示しています。

OIDC 設定の例

AZURE_LOGIN_CONFIG:
    CLIENT_ID: <client_id>
    CLIENT_SECRET: <client_secret>
    OIDC_SERVER: <oidc_server_address_>
    DEBUGGING: true
    SERVICE_NAME: Azure AD
    VERIFIED_EMAIL_CLAIM_NAME: <verified_email>
    OIDC_ENDPOINT_CUSTOM_PARAMS":
                "authorization_endpoint":
                    "some": "param",

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

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

表3.33 OCI およびネストされたリポジトリー設定フィールド

フィールド説明

FEATURE_EXTENDED_REPOSITORY_NAMES

Boolean

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

デフォルト: True

OCI とネストされたリポジトリーの設定例

FEATURE_EXTENDED_REPOSITORY_NAMES: true

3.29. QuayIntegration 設定フィールド

QuayIntegration カスタムリソースでは、次の設定フィールドを使用できます。

名前説明スキーマ

allowlistNamespaces
(オプション)

含める namespace のリスト。

アレイ

clusterID
(必須)

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

String

credentialsSecret.key
(必須)

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

Object

denylistNamespaces
(オプション)

除外する namespace のリスト。

アレイ

insecureRegistry
(オプション)

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

Boolean

quayHostname
(必須)

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

String

scheduledImageStreamImport
(オプション)

イメージストリームのインポートを有効にするかどうか。

Boolean

3.30. メール設定フィールド

表3.34 メール設定フィールド

フィールド説明

FEATURE_MAILING

Boolean

メールが有効かどうか

デフォルト: False

MAIL_DEFAULT_SENDER

String

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

例: support@example.com

MAIL_PASSWORD

String

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

MAIL_PORT

Number

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

MAIL_SERVER

String

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

例: smtp.example.com

MAIL_USERNAME

String

メールの送信時に使用する SMTP ユーザー名。

MAIL_USE_TLS

Boolean

指定されている場合は、電子メールの送信に TLS を使用するかどうか。

デフォルト: True

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

表3.35 ユーザー設定フィールド

フィールド説明

FEATURE_SUPER_USERS

Boolean

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

デフォルト: true

FEATURE_USER_CREATION

Boolean

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

デフォルト: true

FEATURE_USER_LAST_ACCESSED

Boolean

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

デフォルト: true

FEATURE_USER_LOG_ACCESS

Boolean

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

デフォルト: false

FEATURE_USER_METADATA

Boolean

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

デフォルト: false

FEATURE_USERNAME_CONFIRMATION

Boolean

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

FEATURE_USER_RENAME

Boolean

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

デフォルト: false

FEATURE_INVITE_ONLY_USER_CREATION

Boolean

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

デフォルト: false

FRESH_LOGIN_TIMEOUT

String

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

: 5m

USERFILES_LOCATION

String

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

: s3_us_east

USERFILES_PATH

String

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

: userfiles

USER_RECOVERY_TOKEN_LIFETIME

String

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

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

FEATURE_SUPERUSERS_FULL_ACCESS

Boolean

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

デフォルト: False

FEATURE_SUPERUSERS_ORG_CREATION_ONLY

Boolean

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

デフォルト: False

FEATURE_RESTRICTED_USERS

Boolean

RESTRICTED_USERS_WHITELIST を設定すると、制限されたユーザーは自分の名前空間で組織やコンテンツを作成できなくなります。通常のアクセス許可は、組織のメンバーシップに適用されます。たとえば、制限付きのユーザーは、所属するチームをもとに、組織内の通常のパーミッションは割り当てられたままです。

デフォルト: False

RESTRICTED_USERS_WHITELIST

String

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

GLOBAL_READONLY_SUPER_USERS

String

設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。

3.31.1. ユーザー設定フィールドのリファレンス

次の参照を使用して、目的の設定フィールドで config.yaml ファイルを更新します。

3.31.1.1. FEATURE_SUPERUSERS_FULL_ACCESS 設定リファレンス

---
SUPER_USERS:
- quayadmin
FEATURE_SUPERUSERS_FULL_ACCESS: True
---

3.31.1.2. GLOBAL_READONLY_SUPER_USERS 設定リファレンス

---
GLOBAL_READONLY_SUPER_USERS:
      - user1
---

3.31.1.3. FEATURE_RESTRICTED_USERS 設定リファレンス

---
AUTHENTICATION_TYPE: Database
---
---
FEATURE_RESTRICTED_USERS: true
---

3.31.1.4. RESTRICTED_USERS_WHITELIST 設定リファレンス

前提条件

  • FEATURE_RESTRICTED_USERSconfig.yaml ファイルで true に設定されています。
---
AUTHENTICATION_TYPE: Database
---
---
FEATURE_RESTRICTED_USERS: true
RESTRICTED_USERS_WHITELIST:
      - user1
---
注記

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

3.32. reCAPTCHA 設定フィールド

表3.36 reCAPTCHA 設定フィールド

フィールド説明

FEATURE_RECAPTCHA

Boolean

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

デフォルト: False

RECAPTCHA_SECRET_KEY

String

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

RECAPTCHA_SITE_KEY

String

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

3.33. ACI 設定フィールド

表3.37 ACI 設定フィールド

フィールド説明

FEATURE_ACI_CONVERSION

Boolean

ACI への変換を有効にするかどうか

デフォルト: False

GPG2_PRIVATE_KEY_FILENAME

String

ACI の復号化に使用される秘密鍵のファイル名

GPG2_PRIVATE_KEY_NAME

String

ACI に署名するために使用されるプライベートキーの名前

GPG2_PUBLIC_KEY_FILENAME

String

ACI の暗号化に使用する公開鍵のファイル名

3.34. JWT 設定フィールド

表3.38 JWT 設定フィールド

フィールド説明

JWT_AUTH_ISSUER

String

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

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

JWT_GETUSER_ENDPOINT

String

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

JWT_QUERY_ENDPOINT

String

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

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

JWT_VERIFY_ENDPOINT

String

JWT 検証のエンドポイント

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

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

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

フィールド説明

FEATURE_APP_SPECIFIC_TOKENS

Boolean

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

デフォルト: True

APP_SPECIFIC_TOKEN_EXPIRATION

String

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

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

EXPIRED_APP_SPECIFIC_TOKEN_GC

String

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

デフォルト: 1d

3.36. その他の設定フィールド

表3.40 その他の設定フィールド

フィールド説明

ALLOW_PULLS_WITHOUT_STRICT_LOGGING

String

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

デフォルト: False

AVATAR_KIND

String

表示する avatar のタイプ。インライン (local) または Gravatar (gravatar)。

値: local、gravatar

BROWSER_API_CALLS_XHR_ONLY

Boolean

有効になっていると、ブラウザーから XHR による呼び出しとしてマークが付けられた API のみが許可されます。

デフォルト: True

DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT

Number

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

デフォルト: None

ENABLE_HEALTH_DEBUG_SECRET

String

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

EXTERNAL_TLS_TERMINATION

Boolean

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

FRESH_LOGIN_TIMEOUT

String

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

例: 5m

HEALTH_CHECKER

String

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

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

PROMETHEUS_NAMESPACE

String

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

デフォルト: quay

PUBLIC_NAMESPACES

Array of string

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

REGISTRY_STATE

String

レジストリーの状態

値: normal または read-only

SEARCH_MAX_RESULT_PAGE_COUNT

Number

ユーザーが検索で表示できる最大ページ数。

デフォルト: 10

SEARCH_RESULTS_PER_PAGE

Number

検索ページでページごとに返される結果数。

デフォルト: 10

V2_PAGINATION_SIZE

Number

V2 レジストリー API において、1 ページあたりに返される結果の数。

デフォルト: 50

WEBHOOK_HOSTNAME_BLACKLIST

Array of string

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

CREATE_PRIVATE_REPO_ON_PUSH

Boolean

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

デフォルト: True

CREATE_NAMESPACE_ON_PUSH

Boolean

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

デフォルト: False

NON_RATE_LIMITED_NAMESPACES

Array of string

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

FEATURE_UI_V2

Boolean

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

デフォルト: True

FEATURE_REQUIRE_TEAM_INVITE

Boolean

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

デフォルト: True

FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH

Boolean

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

デフォルト: False

FEATURE_RATE_LIMITS

Boolean

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

デフォルト: False

FEATURE_FIPS

Boolean

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

デフォルト: False

FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL

Boolean

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

デフォルト: True

FEATURE_ANONYMOUS_ACCESS

Boolean

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

デフォルト: True

FEATURE_DIRECT_LOGIN

Boolean

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

デフォルト: True

FEATURE_LIBRARY_SUPPORT

Boolean

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

デフォルト: True

FEATURE_PARTIAL_USER_AUTOCOMPLETE

Boolean

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

FEATURE_PERMANENT_SESSIONS

Boolean

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

デフォルト: True

FEATURE_PUBLIC_CATALOG

Boolean

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

デフォルト: False

3.37. レガシー設定フィールド

次のフィールドは非推奨または廃止されました。

表3.41 レガシー設定フィールド

フィールド説明

FEATURE_BLACKLISTED_EMAILS

Boolean

true に設定すると、メールドメインがブラックリストに指定されている場合に新しいユーザーアカウントが作成されません。

BLACKLISTED_EMAIL_DOMAINS

Array of string

FEATURE_BLACKLISTED_EMAILS が true に設定されている場合に使用されるメールアドレスドメインの一覧。

例: "example.com", "example.org"

BLACKLIST_V2_SPEC

String

Red Hat Quay が V2 は サポート対象外 であることを示す応答を返す Docker CLI バージョン。

: <1.8.0
デフォルト: <1.6.0

DOCUMENTATION_ROOT

String

ドキュメントリンクのルート URL。

SECURITY_SCANNER_V4_NAMESPACE_WHITELIST

String

セキュリティースキャナーを有効にする namespace。

FEATURE_RESTRICTED_V1_PUSH

Boolean

true に設定すると、V1_PUSH_WHITELIST にリストされている名前空間のみが V1 プッシュをサポートします。

デフォルト: True

V1_PUSH_WHITELIST

Array of string

FEATURE_RESTRICTED_V1_PUSH が true に設定されている場合に V1 push をサポートする namespace 名の配列。

FEATURE_HELM_OCI_SUPPORT

Boolean

Helm アーティファクトのサポートを有効にします。

デフォルト: False

3.38. ユーザーインターフェイス v2 設定フィールド

表3.42 ユーザーインターフェイス v2 設定フィールド

フィールド説明

FEATURE_UI_V2

Boolean

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

デフォルト: False

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

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

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

手順

  1. デプロイメントの config.yaml ファイルで、FEATURE_UI_V2 パラメーターを追加し、true に設定します。次に例を示します。

    ---
    FEATURE_TEAM_SYNCING: false
    FEATURE_UI_V2: true
    FEATURE_USER_CREATION: true
    ---
  2. Red Hat Quay デプロイメントにログインします。
  3. Red Hat Quay デプロイメントのナビゲーションペインに、現在の UI新しい UI を切り替えるオプションが表示されます。切り替えボタンをクリックして新しい UI に設定し、次に Use Beta Environment をクリックします。次に例を示します。

    Red Hat Quay v2 UI toggle

3.39. IPv6 設定フィールド

表3.43 IPv6 設定フィールド

フィールド説明

FEATURE_LISTEN_IP_VERSION

String

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

デフォルト: IPv4

追加設定: IPv6デュアルスタック

3.40. ブランディング設定フィールド

表3.44 ブランディング設定フィールド

フィールド説明

BRANDING

Object

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

.logo
(必須)

String

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

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

.footer_img

String

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

例:
/static/img/RedHat.svg

.footer_url

String

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

例:
https://redhat.com

3.40.1. Red Hat Quay ブランディングの設定例

ブランディング config.yaml の例

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/

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

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

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

フィールド説明

PERMANENT_SESSION_LIFETIME

Integer

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

デフォルト: 2678400

3.41.1. 設定セッションタイムアウトの設定例

次の YAML は、セッションの有効期間を有効にする場合の推奨設定です。

重要

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

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

PERMANENT_SESSION_LIFETIME: 3000

第4章 環境変数

Red Hat Quay は、動的に設定する多数の環境変数をサポートします。

4.1. Geo レプリケーション

ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数を使用して明示的に設定できます。

表4.1 Geo レプリケーションの設定

変数説明

QUAY_DISTRIBUTED_STORAGE_PREFERENCE

String

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

4.2. データベース接続プール

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

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

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

データベース接続プーリングは、環境変数 DB_CONNECTION_POOLINGtrue または false に設定することで切り替えることができます。

表4.2 データベース接続プールの設定

変数説明

DB_CONNECTION_POOLING

Boolean

データベース接続プールの有効化または無効化

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

config.yaml

...
DB_CONNECTION_ARGS:
  max_connections: 10
...

4.3. HTTP 接続回数

環境変数を使用して、HTTP の同時接続数を指定することができます。これらは、全体として、または特定のコンポーネントに対して指定できます。それぞれのデフォルトは、プロセスあたり 50 の 並列接続です。

表4.3 HTTP 接続数の設定

変数説明

WORKER_CONNECTION_COUNT

Number

同時 HTTP 接続

デフォルト: 50

WORKER_CONNECTION_COUNT_REGISTRY

Number

レジストリーの同時 HTTP 接続

デフォルト: WORKER_CONNECTION_COUNT

WORKER_CONNECTION_COUNT_WEB

Number

Web UI の同時 HTTP 接続

デフォルト: WORKER_CONNECTION_COUNT

WORKER_CONNECTION_COUNT_SECSCAN

Number

Clair の同時 HTTP 接続

デフォルト: WORKER_CONNECTION_COUNT

4.4. ワーカーカウント変数

表4.4 ワーカーカウント変数

変数説明

WORKER_COUNT

Number

プロセス数の汎用上書き

WORKER_COUNT_REGISTRY

Number

Quay コンテナー内のレジストリー要求を処理するプロセス数を指定します。

値: 8 から 64 までの整数

WORKER_COUNT_WEB

Number

コンテナー内の UI/Web リクエストを処理するプロセス数を指定します。

値: 2 から 32 までの整数

WORKER_COUNT_SECSCAN

Number

コンテナー内のセキュリティースキャン (Clair など) の統合を処理するプロセス数を指定します。

値: 整数。Operator がリソースの要求と制限に 2 vCPU を指定するため、この値は 2 から 4 に設定するのが安全です。ただし、ユーザーは、保証があれば、それ以上 (たとえば 16) 実行できます。

4.5. デバッグ変数

次のデバッグ変数は Red Hat Quay で利用できます。

表4.5 デバッグ設定変数

変数説明

DEBUGLOG

Boolean

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

USERS_DEBUG

integer0 または 1 のいずれか。

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

重要

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

第5章 Red Hat Quay の Clair

Clair v4 (Clair) は、静的コード分析を活用してイメージコンテンツを解析し、コンテンツに影響を与える脆弱性を報告するオープンソースアプリケーションです。Clair は Red Hat Quay にパッケージ化されており、スタンドアロンと Operator デプロイメントの両方で使用できます。エンタープライズ環境に合わせてコンポーネントを個別にスケーリングできる、非常にスケーラブルな設定で実行できます。

5.1. Clair 設定の概要

Clair は、構造化された YAML ファイルによって設定されます。各 Clair ノードは、CLI フラグまたは環境変数を使用して、実行するモードと設定ファイルへのパスを指定する必要があります。以下に例を示します。

$ clair -conf ./path/to/config.yaml -mode indexer

または、以下を実行します。

$ clair -conf ./path/to/config.yaml -mode matcher

前述のコマンドはそれぞれ、同じ設定ファイルを使用して 2 つの Clair ノードを開始します。1 つはインデックス作成機能を実行し、もう 1 つはマッチング機能を実行します。

Clair を combo モードで実行している場合は、設定でインデクサー、matcher、およびノーティファイアー設定ブロックを指定する必要があります。

5.1.1. プロキシー環境での Clair の使用に関する情報

Go 標準ライブラリーが尊重する環境変数は、必要に応じて指定できます。次に例を示します。

  • HTTP_PROXY

    $ export http://<user_name>:<password>@<proxy_host>:<proxy_port>
  • HTTPS_PROXY

    $ export https://<user_name>:<password>@<proxy_host>:<proxy_port>
  • SSL_CERT_DIR

    $ export SSL_CERT_DIR=/<path>/<to>/<ssl>/<certificates>

Clair のアップデーター URL を使用して環境内でプロキシーサーバーを使用している場合は、Clair がスムーズにその URL にアクセスできるように、どの URL をプロキシー許可リストに追加する必要があるかを特定する必要があります。たとえば、osv アップデーターは、エコシステムデータダンプを取得するために https://osv-vulnerabilities.storage.googleapis.com にアクセスする必要があります。このような場合、URL をプロキシー許可リストに追加する必要があります。アップデーター URL の完全なリストについては、「Clair のアップデーター URL」を参照してください。

また、標準の Clair URL がプロキシー許可リストに追加されていることを確認する必要があります。

  • https://search.maven.org/solrsearch/select
  • https://catalog.redhat.com/api/containers/
  • https://access.redhat.com/security/data/metrics/repository-to-cpe.json
  • https://access.redhat.com/security/data/metrics/container-name-repos-map.json

プロキシーサーバーを設定するときは、Clair とこれらの URL 間のシームレスな通信を可能にするために必要な認証要件や特定のプロキシー設定を考慮してください。これらの考慮事項をすべて文書化して対処することで、アップデーターのトラフィックをプロキシー経由でルーティングしながら、Clair を効果的に機能させることができます。

5.1.2. Clair 設定リファレンス

次の YAML は、Clair 設定の例を示しています。

http_listen_addr: ""
introspection_addr: ""
log_level: ""
tls: {}
indexer:
    connstring: ""
    scanlock_retry: 0
    layer_scan_concurrency: 5
    migrations: false
    scanner: {}
    airgap: false
matcher:
    connstring: ""
    indexer_addr: ""
    migrations: false
    period: ""
    disable_updaters: false
    update_retention: 2
matchers:
    names: nil
    config: nil
updaters:
    sets: nil
    config: nil
notifier:
    connstring: ""
    migrations: false
    indexer_addr: ""
    matcher_addr: ""
    poll_interval: ""
    delivery_interval: ""
    disable_summary: false
    webhook: null
    amqp: null
    stomp: null
auth:
  psk: nil
trace:
    name: ""
    probability: null
    jaeger:
        agent:
            endpoint: ""
        collector:
            endpoint: ""
            username: null
            password: null
        service_name: ""
        tags: nil
        buffer_max: 0
metrics:
    name: ""
    prometheus:
        endpoint: null
    dogstatsd:
        url: ""
注記

上記の YAML ファイルには、万全を期すためにすべてのキーがリストされています。この設定ファイルをそのまま使用すると、一部のオプションがデフォルトで正常に設定されない場合があります。

5.1.3. Clair の一般的なフィールド

次の表では、Clair デプロイメントで使用できる一般的な設定フィールドについて説明します。

フィールドTyphttp_listen_ae説明

http_listen_addr

String

HTTP API が公開される場所を設定します。

デフォルト: :6060

introspection_addr

String

Clair のメトリクスと正常性エンドポイントが公開される場所を設定します。

log_level

String

ログレベルを設定します。文字列 debug-colordebuginfowarnerrorfatalpanic のいずれかが必要です。

tls

String

TLS/SSL および HTTP/2 の HTTP API を提供するための設定を含むマップ。

.cert

String

使用する TLS 証明書。フルチェーン証明書である必要があります。

一般的な Clair フィールドの設定例

次の例は、Clair 設定を示しています。

一般的な Clair フィールドの設定例

# ...
http_listen_addr: 0.0.0.0:6060
introspection_addr: 0.0.0.0:8089
log_level: info
# ...

5.1.4. Clair インデクサー設定フィールド

次の表では、Clair の indexer コンポーネントの設定フィールドについて説明します。

フィールド説明

indexer

Object

Clair インデクサーノード設定を提供します。

.airgap

Boolean

インデクサーとフェッチャーのインターネットへの HTTP アクセスを無効にします。プライベート IPv4 および IPv6 アドレスが許可されます。データベース接続は影響を受けません。

.connstring

String

Postgres 接続文字列。URL または libpq 接続文字列として形式を受け入れます。

.index_report_request_concurrency

Integer

レートは、インデックスレポート作成リクエストの数を制限します。これを 0 に設定すると、この値の自動サイズ調整が試みられます。負の値を設定すると、無制限になります。自動サイジングは、使用可能なコア数の倍数です。

同時実行数を超えた場合、API はステータスコード 429 を返します。

.scanlock_retry

Integer

秒を表す正の整数。並行インデクサーは、マニフェストスキャンをロックして、上書きを回避します。この値は、待機中のインデクサーがロックをポーリングする頻度をチューニングします。

.layer_scan_concurrency

Integer

レイヤーの同時スキャン数を制限する正の整数。インデクサーは、マニフェストのレイヤーを同時にマッチングします。この値は、インデクサーが並行してスキャンするレイヤーの数をチューニングします。

.migrations

Boolean

インデクサーノードがデータベースへの移行を処理するかどうか。

.scanner

String

インデクサー設定。

Scanner を使用すると、設定オプションをレイヤースキャナーに渡すことができます。スキャナーは、そのように設計されていると、構築時にこの設定を渡します。

.scanner.dist

String

特定のスキャナーの名前と値として任意の YAML を持つマップ。

.scanner.package

String

特定のスキャナーの名前と値として任意の YAML を持つマップ。

.scanner.repo

String

特定のスキャナーの名前と値として任意の YAML を持つマップ。

インデクサー設定の例

次の例は、Clair の仮のインデクサー設定を示しています。

インデクサー設定の例

# ...
indexer:
  connstring: host=quay-server.example.com port=5433 dbname=clair user=clairuser password=clairpass sslmode=disable
  scanlock_retry: 10
  layer_scan_concurrency: 5
  migrations: true
# ...

5.1.5. Clair matcher 設定フィールド

次の表では、Clair の matcher コンポーネントの設定フィールドについて説明します。

注記

matchers 設定フィールドとは異なります。

フィールド説明

matcher

Object

Clair matcher ノード設定を提供します。

.cache_age

String

レスポンスをキャッシュするように、ユーザーに通知する期間を制御します。

.connstring

String

Postgres 接続文字列。URL または libpq 接続文字列として形式を受け入れます。

.max_conn_pool

Integer

データベース接続プールのサイズを制限します。

Clair では、カスタムの接続プールサイズを使用できます。この数は、同時に許可されるアクティブなデータベース接続の数を直接設定します。

このパラメーターは、将来のバージョンでは無視されます。ユーザーは、接続文字列を使用して、これを設定する必要があります。

.indexer_addr

String

matcher は indexer に接続して脆弱性レポートを作成します。このインデクサーの場所は必須です。

デフォルトは 30m です。

.migrations

Boolean

matcher ノードがデータベースへの移行を処理するかどうか。

.period

String

新しいセキュリティーアドバイザリーの更新頻度を決定します。

デフォルトは 30m です。

.disable_updaters

Boolean

バックグラウンド更新を実行するかどうか。

デフォルト: False

.update_retention

Integer

ガベージコレクションサイクル間で保持する更新操作の数を設定します。これは、データベースサイズの制約に基づいて安全な MAX 値に設定する必要があります。

デフォルトは 10m です。

0 未満の値を指定すると、ガベージコレクションが無効になります。2 は、更新を通知と比較できるようにするための最小値です。

matcher 設定の例

matcher 設定の例

# ...
matcher:
  connstring: >-
    host=<DB_HOST> port=5432 dbname=<matcher> user=<DB_USER> password=D<B_PASS>
    sslmode=verify-ca sslcert=/etc/clair/ssl/cert.pem sslkey=/etc/clair/ssl/key.pem
    sslrootcert=/etc/clair/ssl/ca.pem
  indexer_addr: http://clair-v4/
  disable_updaters: false
  migrations: true
  period: 6h
  update_retention: 2
# ...

5.1.6. Clair matchers 設定フィールド

次の表では、Clair の matchers コンポーネントの設定フィールドについて説明します。

注記

matcher 設定フィールドとは異なります。

表5.1 matchers 設定フィールド

フィールド説明

matchers

文字列の配列。

ツリー内 matchers の設定を提供します。

.names

String

有効な matchers について matcher ファクトリーに通知する文字列値のリスト。値を null に設定すると、matchers のデフォルトのリストが実行されます。次の文字列が受け入れられます。alpine-matcheraws-matcherdebian-matchergobinjava-mavenoraclephotonpythonrhelrhel-container-matcherRubysuseubuntu-matcher

.config

String

特定の matcher に設定を提供します。

matchers ファクトリーコンストラクターに提供されるサブオブジェクトを含む matcher の名前をキーとするマップ。以下に例を示します。

matchers 設定の例

次の例は、alpineawsdebianoracle matchers のみを必要とする仮の Clair デプロイメントを示しています。

matchers 設定の例

# ...
matchers:
  names:
  - "alpine-matcher"
  - "aws"
  - "debian"
  - "oracle"
# ...

5.1.7. Clair アップデーター設定フィールド

次の表では、Clair の updaters コンポーネントの設定フィールドについて説明します。

表5.2 アップデーター設定フィールド

フィールド説明

updaters

Object

matcher の更新マネージャーの設定を提供します。

.sets

String

どのアップデーターを実行するかを更新マネージャーに通知する値のリスト。

値を null に設定すると、アップデーターのデフォルトのセットが、alpineawsclair.cvssdebianoraclephotonosvrhelrhcc suseubuntu を実行します。

空白のままにすると、アップデーターは実行されません。

.config

String

特定のアップデーターセットに設定を提供します。

アップデーターセットのコンストラクターに提供されるサブオブジェクトを含むアップデーターセットの名前をキーとするマップ。各アップデーターのサブオブジェクトのリストについては、「詳細なアップデーター設定」を参照してください。

アップデーター設定の例

次の設定では、rhel セットのみが設定されます。rhel アップデーターに固有の ignore_unpatched 変数も定義されています。

アップデーター設定の例

# ...
updaters:
  sets:
    - rhel
  config:
    rhel:
      ignore_unpatched: false
# ...

5.1.8. Clair ノーティファイアー設定フィールド

Clair の一般的なノーティファイアー設定フィールドを以下に示します。

フィールド説明

notifier

Object

Clair ノーティファイアーノード設定を提供します。

.connstring

String

Postgres 接続文字列。形式を URL または libpq 接続文字列として受け入れます。

.migrations

Boolean

ノーティファイアーノードがデータベースへの移行を処理するかどうか。

.indexer_addr

String

ノーティファイアーはインデクサーに接続して、脆弱性の影響を受けるマニフェストを作成または取得します。このインデクサーの場所は必須です。

.matcher_addr

String

ノーティファイアーは matcher に接続して、更新操作をリストし、差分を取得します。この matcher の場所は必須です。

.poll_interval

String

ノーティファイアーが matcher に更新操作をクエリーする頻度。

.delivery_interval

String

ノーティファイアーが、作成された通知または以前に失敗した通知の配信を試行する頻度。

.disable_summary

Boolean

通知をマニフェストごとに 1 つに要約するかどうかを制御します。

ノーティファイアー設定の例

次の notifier スニペットは、最小設定用です。

ノーティファイアー設定の例

# ...
notifier:
  connstring: >-
    host=DB_HOST port=5432 dbname=notifier user=DB_USER password=DB_PASS
    sslmode=verify-ca sslcert=/etc/clair/ssl/cert.pem sslkey=/etc/clair/ssl/key.pem
    sslrootcert=/etc/clair/ssl/ca.pem
  indexer_addr: http://clair-v4/
  matcher_addr: http://clair-v4/
  delivery_interval: 5s
  migrations: true
  poll_interval: 15s
  webhook:
    target: "http://webhook/"
    callback: "http://clair-notifier/notifier/api/v1/notifications"
    headers: ""
  amqp: null
  stomp: null
# ...

5.1.8.1. Clair Webhook 設定フィールド

次の Webhook フィールドを Clair ノーティファイアー環境で使用できます。

表5.3 Clair Webhook フィールド

.webhook

Object

Webhook 配信のノーティファイアーを設定します。

.webhook.target

String

Webhook が配信される URL。

.webhook.callback

String

通知を取得できるコールバック URL。この URL に通知 ID が追加されます。

これは通常、Clair ノーティファイアーがホスティングされている場所です。

.webhook.headers

String

ヘッダー名を値のリストに関連付けるマップ。

Webhook 設定の例

Webhook 設定の例

# ...
notifier:
# ...
  webhook:
    target: "http://webhook/"
    callback: "http://clair-notifier/notifier/api/v1/notifications"
# ...

5.1.8.2. Clair amqp 設定フィールド

次の Advanced Message Queuing Protocol (AMQP) フィールドを Clair ノーティファイアー環境で使用できます。

.amqp

Object

AMQP 配信のノーティファイアーを設定します。

[注記] ==== Clair は独自に AMQP コンポーネントを宣言しません。エクスチェンジまたはキューを使用しようとするすべての試みは、パッシブのみであり、失敗します。ブローカー管理者は、事前にエクスチェンジとキューをセットアップする必要があります。====

.amqp.direct

Boolean

true の場合、ノーティファイアーは設定された AMQP ブローカーに個別の通知 (コールバックではない) を配信します。

.amqp.rollup

Integer

amqp.directtrue に設定されている場合、この値は直接配信で送信する通知の数をノーティファイアーに通知します。たとえば、directtrue に設定され、amqp.rollup5 に設定されている場合、ノーティファイアーは単一の JSON ペイロードで 5 つ以下の通知をブローカーに配信します。値を 0 に設定すると、実質的に 1 に設定されます。

.amqp.exchange

Object

接続先の AMQP エクスチェンジ。

.amqp.exchange.name

String

接続先のエクスチェンジの名前。

.amqp.exchange.type

String

エクスチェンジのタイプ。通常は、directfanouttopicheaders のいずれかです。

.amqp.exchange.durability

Boolean

設定されたキューが永続的かどうか。

.amqp.exchange.auto_delete

Boolean

設定されたキューが auto_delete_policy を使用するかどうか。

.amqp.routing_key

String

各通知が送信されるルーティングキーの名前。

.amqp.callback

String

amqp.directfalse に設定されている場合、この URL はブローカーに送信される通知コールバックで提供されます。この URL は、Clair の通知 API エンドポイントを指している必要があります。

.amqp.uris

String

接続先の 1 つ以上の AMQP ブローカーのリスト (優先順位順)。

.amqp.tls

Object

AMQP ブローカーへの TLS/SSL 接続を設定します。

.amqp.tls.root_ca

String

ルート CA を読み取ることができるファイルシステムパス。

.amqp.tls.cert

String

TLS/SSL 証明書を読み取ることができるファイルシステムパス。

[注意] ==== Go crypto/x509 パッケージに記載されているように、Clair は SSL_CERT_DIR も許可します。====

.amqp.tls.key

String

TLS/SSL 秘密鍵を読み取ることができるファイルシステムパス。

AMQP 設定の例

次の例は、Clair の仮の AMQP 設定を示しています。

AMQP 設定の例

# ...
notifier:
# ...
  amqp:
    exchange:
        name: ""
        type: "direct"
        durable: true
        auto_delete: false
    uris: ["amqp://user:pass@host:10000/vhost"]
    direct: false
    routing_key: "notifications"
    callback: "http://clair-notifier/notifier/api/v1/notifications"
    tls:
     root_ca: "optional/path/to/rootca"
     cert: "madatory/path/to/cert"
     key: "madatory/path/to/key"
# ...

5.1.8.3. Clair STOMP 設定フィールド

次の Simple Text Oriented Message Protocol (STOMP) フィールドを Clair ノーティファイアー環境で使用できます。

.stompObjectSTOMP 配信のノーティファイアーを設定します。

.stomp.direct

Boolean

true の場合、ノーティファイアーは個別の通知 (コールバックではない) を設定済みの STOMP ブローカーに配信します。

.stomp.rollup

Integer

stomp.directtrue に設定されている場合、この値は、1 回の直接配信で送信される通知の数を制限します。たとえば、directtrue に設定され、rollup5 に設定されている場合、ノーティファイアーは単一の JSON ペイロードで 5 つ以下の通知をブローカーに配信します。値を 0 に設定すると、実質的に 1 に設定されます。

.stomp.callback

String

stomp.callbackfalse に設定されている場合は、通知コールバックで指定された URL がブローカーに送信されます。この URL は、Clair の通知 API エンドポイントを指している必要があります。

.stomp.destination

String

通知を配信する STOMP の宛先。

.stomp.uris

String

接続先の 1 つ以上の STOMP ブローカーのリスト (優先順位順)。

.stomp.tls

Object

STOMP ブローカーへの TLS/SSL 接続を設定しました。

.stomp.tls.root_ca

String

ルート CA を読み取ることができるファイルシステムパス。

[注意] ==== Go crypto/x509 パッケージに記載されているように、Clair は SSL_CERT_DIR も受け入れます。====

.stomp.tls.cert

String

TLS/SSL 証明書を読み取ることができるファイルシステムパス。

.stomp.tls.key

String

TLS/SSL 秘密鍵を読み取ることができるファイルシステムパス。

.stomp.user

String

STOMP ブローカーのログインの詳細を設定します。

.stomp.user.login

String

接続に使用する STOMP ログイン。

.stomp.user.passcode

String

接続に使用する STOMP パスコード。

STOMP 設定の例

次の例は、Clair の仮の STOMP 設定を示しています。

STOMP 設定の例

# ...
notifier:
# ...
  stomp:
    desitnation: "notifications"
    direct: false
    callback: "http://clair-notifier/notifier/api/v1/notifications"
    login:
      login: "username"
      passcode: "passcode"
    tls:
     root_ca: "optional/path/to/rootca"
     cert: "madatory/path/to/cert"
     key: "madatory/path/to/key"
# ...

5.1.9. Clair 認可設定フィールド

Clair では、次の認可設定フィールドを使用できます。

フィールド説明

auth

Object

Clair の外部およびサービス内 JWT ベースの認証を定義します。複数の auth 機能が定義されている場合、Clair は 1 つを選択します。現在、複数の機能はサポートされていません。

.psk

String

事前共有キー認証を定義します。

.psk.key

String

JWT の署名と検証を行うすべての当事者間で配布される、base64 でエンコードされた共有キー。

.psk.iss

String

確認する JWT 発行者のリスト。空のリストは、JWT クレームで任意の発行者を受け入れます。

認可設定の例

次の authorization スニペットは、最小設定用です。

認可設定の例

# ...
auth:
  psk:
    key: MTU5YzA4Y2ZkNzJoMQ== 1
    iss: ["quay"]
# ...

5.1.10. Clair トレース設定フィールド

Clair では、次のトレース設定フィールドを使用できます。

フィールド説明

trace

Object

OpenTelemetry に基づいて分散トレース設定を定義します。

.name

String

トレースが属するアプリケーションの名前。

.probability

Integer

トレースが発生する確率。

.jaeger

Object

Jaeger トレースの値を定義します。

.jaeger.agent

Object

Jaeger エージェントへの配信を設定するための値を定義します。

.jaeger.agent.endpoint

String

トレースを送信できる <host>:<post> 構文のアドレス。

.jaeger.collector

Object

Jaeger コレクターへの配信を設定するための値を定義します。

.jaeger.collector.endpoint

String

トレースを送信できる <host>:<post> 構文のアドレス。

.jaeger.collector.username

String

Jaeger ユーザー名。

.jaeger.collector.password

String

Jaeger パスワード。

.jaeger.service_name

String

Jaeger に登録されているサービス名。

.jaeger.tags

String

追加のメタデータを提供するキーと値のペア。

.jaeger.buffer_max

Integer

保管および分析のために Jaeger バックエンドに送信される前にメモリーにバッファーできるスパンの最大数。

トレース設定の例

次の例は、Clair の仮のトレース設定を示しています。

トレース設定の例

# ...
trace:
  name: "jaeger"
  probability: 1
  jaeger:
    agent:
      endpoint: "localhost:6831"
    service_name: "clair"
# ...

5.1.11. Clair メトリクス設定フィールド

Clair では、次のメトリクス設定フィールドを使用できます。

フィールド説明

metrics

Object

OpenTelemetry に基づいて分散トレース設定を定義します。

.name

String

使用中のメトリクスの名前。

.prometheus

String

Prometheus メトリクスエクスポーターの設定。

.prometheus.endpoint

String

メトリクスが提供されるパスを定義します。

メトリクス設定の例

次の例は、Clair の仮のメトリクス設定を示しています。

メトリクス設定の例

# ...
metrics:
  name: "prometheus"
  prometheus:
    endpoint: "/metricsz"
# ...

法律上の通知

Copyright © 2024 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.