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 では、デフォルトで監査ログインが追跡されます。
フィールド | 型 | 説明 |
---|---|---|
ACTION_LOG_AUDIT_LOGINS | Boolean |
|
2.1.2. Splunk アクションログの追加
Red Hat Quay 3.9 では、Splunk を LOGS_MODEL パラメーターで設定できます。
フィールド | 型 | 説明 |
---|---|---|
LOGS_MODEL | String |
ログデータを処理するための推奨される方法を指定します。 |
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
ファイルへの相対コンテナーパス。
-
producer [文字列]:
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 クォータ管理機能を強化するために、次の設定フィールドが追加されました。
フィールド | 型 | 説明 |
---|---|---|
QUOTA_BACKFILL | Boolean |
クォータバックフィルワーカーが既存の BLOB のサイズを計算できるようにします。 |
QUOTA_TOTAL_DELAY_SECONDS | String |
クォータバックフィルを開始するまでの遅延時間。ローリングデプロイメントでは、合計が不正確になる可能性があります。このフィールドは、ローリングデプロイメントが完了するまでにかかる時間よりも長い時間を設定する 必要があります。 |
PERMANENTLY_DELETE_TAGS | Boolean |
タイムマシンウィンドウからのタグの削除に関連する機能を有効にします。 |
RESET_CHILD_MANIFEST_EXPIRATION | Boolean |
子マニフェストを対象とする一時タグの有効期限をリセットします。この機能を |
2.1.3.1. 可能なクォータ管理設定
次の表は、Red Hat Quay 3.9 で可能なクォータ管理設定を説明しています。
FEATURE_QUOTA_MANAGEMENT | QUOTA_BACKFILL | 結果 |
---|---|---|
|
|
これらの機能を |
|
|
|
|
|
これらの機能を |
|
|
|
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) を自動的に削除するかどうかを設定するために、次の環境変数が追加されました。
フィールド | 型 | 説明 |
---|---|---|
POSTGRES_UPGRADE_RETAIN_BACKUP | Boolean |
デフォルト: |
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.7
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.7
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.7
第3章 設定フィールド
このセクションでは、Red Hat Quay のデプロイ時に必須および任意の設定フィールドの両方を説明します。
3.1. 必須の設定フィールド
Red Hat Quay の設定で必須のフィールドは、以下のセクションで説明されています。
- 一般的な必須フィールド
- link::https://access.redhat.com/documentation/ja-jp/red_hat_quay/3.9/html-single/configure_red_hat_quay/index#config-fields-storage[Storage for images]
- メタデータ用のデータベース
- ビルドログおよびユーザーイベント用の Redis
- タグの有効期限オプション
3.2. 自動化オプション
以下のセクションでは、Red Hat Quay デプロイメントで利用可能な自動化オプションを説明します。
3.3. 任意の設定フィールド
Red Hat Quay の任意のフィールドは、以下のセクションで説明します。
3.4. 一般的な必須フィールド
以下の表は、Red Hat Quay デプロイメントの必須設定フィールドを説明しています。
フィールド | 型 | 説明 |
---|---|---|
AUTHENTICATION_TYPE | String |
認証情報の認証に使用する認証エンジン。 |
PREFERRED_URL_SCHEME | String |
Red Hat Quay へのアクセスに使用する URL スキーム。 |
SERVER_HOSTNAME | String |
スキームなしで Red Hat Quay にアクセスできる URL。 |
DATABASE_SECRET_KEY | String | データベース内で機密フィールドを暗号化するのに使用されるキー。この値は、一度設定したら変更しないでください。変更すると、リポジトリーのミラーユーザー名やパスワード設定など、すべての信頼できるフィールドが無効になります。 |
SECRET_KEY | String | データベース内および実行時に機密フィールドを暗号化するために使用されるキー。この値は一度設定したら決して変更しないでください。そうしないと、暗号化されたパスワード資格情報などのすべての依存フィールドが無効になります。 |
SETUP_COMPLETE | Boolean |
これは、以前のバージョンのソフトウェアからそのまま残っているアーティファクトで、現時点では値を |
3.5. データベースの設定
このセクションでは、Red Hat Quay デプロイメントで利用可能なデータベース設定フィールドを説明します。
3.5.1. データベース URI
Red Hat Quay では、必要な DB_URI
フィールドを使用してデータベースへの接続を設定します。
以下の表は DB_URI
設定フィールドを説明します。
フィールド | 型 | 説明 |
---|---|---|
DB_URI | String | 認証情報を含む、データベースにアクセスするための URI。
postgresql://quayuser:quaypass@quay-server.example.com:5432/quay |
3.5.2. データベース接続引数
オプションの接続引数は、DB_CONNECTION_ARGS
パラメーターで設定されます。DB_CONNECTION_ARGS
で定義されたキーと値のペアの一部は汎用的なものも、データベース固有のものもあります。
以下の表は、データベース接続引数を説明します。
フィールド | 型 | 説明 |
---|---|---|
DB_CONNECTION_ARGS | Object | タイムアウトや SSL/TLS などのデータベースの任意の接続引数。 |
.autorollback | Boolean |
スレッドローカル接続を使用するかどうか。 |
.threadlocals | Boolean |
自動ロールバック接続を使用するかどうか。 |
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 つあります。
モード | 説明 |
---|---|
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 のイメージストレージ機能を説明しています。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_REPO_MIRROR | Boolean |
true に設定されている場合は、リポジトリーのミラーリングを有効にします。 |
FEATURE_PROXY_STORAGE | Boolean |
NGINX を使用してストレージ内のすべての直接ダウンロード URL をプロキシーするかどうか。 |
FEATURE_STORAGE_REPLICATION | Boolean |
ストレージエンジン間で自動的にレプリケートするかどうか。 |
3.6.2. イメージストレージ設定フィールド
以下の表は、Red Hat Quay のイメージストレージ設定フィールドを説明しています。
フィールド | 型 | 説明 |
---|---|---|
DISTRIBUTED_STORAGE_CONFIG | Object |
Red Hat Quay で使用するストレージエンジンの設定。各キーは、ストレージエンジンの一意の ID を表します。この値は、ストレージエンジンパラメーターを記述するオブジェクトのタプル (キー、値) で設定されます。 |
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS | Array of string |
イメージをデフォルトで他のすべてのストレージエンジンに対して完全にレプリケートする必要のあるストレージエンジンの一覧 ( |
DISTRIBUTED_STORAGE_PREFERENCE | Array of string |
使用する優先ストレージエンジン ( |
MAXIMUM_LAYER_SIZE | String |
イメージレイヤーの最大許容サイズ。 |
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 デプロイメントには、以下のビルドログ設定フィールドを利用できます。
フィールド | 型 | 説明 |
---|---|---|
BUILDLOGS_REDIS | Object | ビルドログキャッシュ用の Redis 接続の詳細。 |
.host | String |
Redis にアクセスできるホスト名。 |
.port | Number |
Redis にアクセスできるポート。 |
.password | String |
Redis インスタンスに接続するためのパスワード。 |
.ssl | Boolean | Redis と Quay 間の TLS 通信を有効にするかどうか。デフォルトは false です。 |
3.7.2. ユーザーイベント
Redis デプロイメントには、以下のユーザーイベントフィールドを使用できます。
フィールド | 型 | 説明 |
---|---|---|
USER_EVENTS_REDIS | Object | ユーザーイベント処理の Redis 接続の詳細。 |
.host | String |
Redis にアクセスできるホスト名。 |
.port | Number |
Redis にアクセスできるポート。 |
.password | String |
Redis インスタンスに接続するためのパスワード。 |
.ssl | Boolean | Redis と Quay 間の TLS 通信を有効にするかどうか。デフォルトは false です。 |
.ssl_keyfile | String |
使用するクライアント証明書を格納する鍵データベースファイルの名前。 |
.ssl_certfile | String |
SSL 証明書のファイルパスを指定するために使用されます。 |
.ssl_cert_reqs | String |
SSL/TLS ハンドシェーク中に実行される証明書検証のレベルを指定するために使用されます。 |
.ssl_ca_certs | String |
信頼された認証局 (CA) 証明書のリストを含むファイルへのパスを指定するために使用されます。 |
.ssl_ca_data | String |
信頼できる CA 証明書を含む文字列を PEM 形式で指定するために使用されます。 |
.ssl_check_hostname | Boolean |
サーバーへの SSL/TLS 接続をセットアップするときに使用されます。サーバーの SSL/TLS 証明書のホスト名が、接続先のサーバーのホスト名と一致することをクライアントが確認する必要があるかどうかを指定します。 |
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 を使用し、ssl
が true
に設定されていると、ポートはデフォルトで 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 で利用できます。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_GARBAGE_COLLECTION | Boolean |
リポジトリーのガベージコレクションを有効にするかどうか。 |
TAG_EXPIRATION_OPTIONS | Array of string |
有効にすると、名前空間内のタグの有効期限についてユーザーが選択できるオプション。 |
DEFAULT_TAG_EXPIRATION | String |
タイムマシンのデフォルトの設定可能なタグの有効期限。 |
FEATURE_CHANGE_TAG_EXPIRATION | Boolean |
ユーザーおよび組織が namespace のタグの有効期限を変更できるかどうか。 |
3.9.1. タグの有効期限の設定例
以下の YAML は、タグの有効期限の設定例を示しています。
DEFAULT_TAG_EXPIRATION: 2w TAG_EXPIRATION_OPTIONS: - 0s - 1d - 1w - 2w - 4w
3.10. クォータ管理設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_QUOTA_MANAGEMENT | Boolean | クォータ管理機能の設定、キャッシュ、検証を有効にします。 **Default:** `False` |
DEFAULT_SYSTEM_REJECT_QUOTA_BYTES | String | すべての組織に対してシステムのデフォルトクォータ拒否バイト許容量を有効にします。 デフォルトでは、制限は設定されていません。 |
QUOTA_BACKFILL | Boolean | クォータバックフィルワーカーが既存の BLOB のサイズを計算できるようにします。
デフォルト: |
QUOTA_TOTAL_DELAY_SECONDS | String | クォータバックフィルを開始するまでの遅延時間。ローリングデプロイメントでは、合計が不正確になる可能性があります。このフィールドは、ローリングデプロイメントが完了するまでにかかる時間よりも長い時間を設定する 必要があります。
デフォルト: |
PERMANENTLY_DELETE_TAGS | Boolean | タイムマシンウィンドウからのタグの削除に関連する機能を有効にします。
デフォルト: |
RESET_CHILD_MANIFEST_EXPIRATION | Boolean |
子マニフェストを対象とする一時タグの有効期限をリセットします。この機能を
デフォルト: |
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. プロキシーキャッシュ設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_PROXY_CACHE | Boolean | Red Hat Quay がアップストリームレジストリーのプルスルーキャッシュとして機能できるようにします。
デフォルト: |
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_CREATION
を false
に設定することで、新しいユーザーを作成できる権限をスーパーユーザーグループに制限できます。以下に例を示します。
... 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 がインストールされている。
手順
設定ファイルを使用してシークレットを作成します。
$ oc create secret generic -n quay-enterprise --from-file config.yaml=./config.yaml init-config-bundle-secret
quayregistry.yaml
ファイルを作成します。以下のように、管理対象外のコンポーネントを特定し、作成されたシークレットを参照します。apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: init-config-bundle-secret
Red Hat Quay レジストリーをデプロイします。
$ oc create -n quay-enterprise -f quayregistry.yaml
次のステップ
3.12.8.1. API を使用した最初のユーザーの作成
以下の手順に従って、Red Hat Quay 組織で最初のユーザーを作成します。
前提条件
-
設定オプション
FEATURE_USER_INITIALIZE
はtrue
に設定する。 - データベースにユーザーが存在していない。
この手順では、"access_token": true
を指定して OAuth トークンを要求します。
root ユーザーとして、次のコマンドを入力して
python39
をインストールします。$ sudo yum install python39
Python 3.9 の
pip
パッケージマネージャーをアップグレードします。$ python3.9 -m pip install --upgrade pip
pip
パッケージマネージャーを使用してbcrypt
パッケージをインストールします。$ pip install bcrypt
次のコマンドを入力して、Python 3.9 の
bcrypt
パッケージを使用して、安全なハッシュ化されたパスワードを生成します。$ python3.9 -c 'import bcrypt; print(bcrypt.hashpw(b"subquay12345", bcrypt.gensalt(12)).decode("utf-8"))'
Red Hat Quay 設定ファイルを開き、以下の設定フィールドを更新します。
FEATURE_USER_INITIALIZE: true SUPER_USERS: - quayadmin
次のコマンドを入力して、Red Hat Quay サービスを停止します。
$ sudo podman stop quay
次のコマンドを入力して、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}
次の
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."}
以下のコマンドを入力して、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 を呼び出している。
手順
組織を作成するには、
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"
以下のコマンドを入力して、作成した組織の詳細を取得できます。
$ 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. 基本設定フィールド
フィールド | 型 | 説明 |
---|---|---|
REGISTRY_TITLE | String |
指定されている場合、レジストリーの長いタイトル。Red Hat Quay デプロイメントのフロントエンド (組織のサインインページなど) に表示されます。35 文字を超えないようにしてください。 |
REGISTRY_TITLE_SHORT | String |
指定されている場合は、省略形式のレジストリーのタイトル。タイトルは、組織のさまざまなページに表示されます。たとえば、組織の Tutorial ページのチュートリアルのタイトルとして表示されます。 |
CONTACT_INFO | Array of string | 指定されている場合は、連絡先ページに表示される連絡先情報。連絡先が 1 つしか指定されていない場合は、連絡先のフッターが直接リンクされます。 |
[0] | String |
電子メールを送信するためのリンクを追加します。 |
[1] | String |
IRC チャットルームにアクセスするためのリンクを追加します。 |
[2] | String |
電話番号を呼び出すためのリンクを追加します。+ |
[3] | String |
定義された URL へのリンクを追加します。 |
3.14. SSL 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
PREFERRED_URL_SCHEME | String |
+ TLS を終了するロードバランサー、リバースプロキシー (Nginx など) を使用する場合、またはカスタム SSL 証明書で Quay を直接使用する場合、ユーザーは |
SERVER_HOSTNAME | String |
スキームなしで Red Hat Quay にアクセスできる URL。 |
SSL_CIPHERS | Array of string |
指定されている場合は、有効化および無効化する SSL 暗号の nginx 定義の一覧。 |
SSL_PROTOCOLS | Array of string |
指定されている場合、nginx は、リストで定義される SSL プロトコルのリストを有効にするように設定されます。リストから SSL プロトコルを削除すると、Red Hat Quay の起動時にそのプロトコルが無効になります。 |
SESSION_COOKIE_SECURE | Boolean |
セッションクッキーに |
3.14.1. SSL の設定
証明書ファイルとプライマリーキーファイルを設定ディレクトリーにコピーして、それぞれ
ssl.cert
とssl.key
という名前が付けられていることを確認します。$ cp ~/ssl.cert $QUAY/config $ cp ~/ssl.key $QUAY/config $ cd $QUAY/config
config.yaml
ファイルを編集し、Quay で TLS を処理できるように指定します。config.yaml
... SERVER_HOSTNAME: quay-server.example.com ... PREFERRED_URL_SCHEME: https ...
-
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 に追加
コンテナーに追加される証明書を表示します。
$ cat storage.crt -----BEGIN CERTIFICATE----- MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV [...] -----END CERTIFICATE-----
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
Quay
コンテナーのCONTAINER ID
をpodman ps
で取得します。$ sudo podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS 5a3e82c4a75f <registry>/<repo>/quay:v3.9.7 "/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
その ID でコンテナーを再起動します。
$ sudo podman restart 5a3e82c4a75f
コンテナーの名前空間にコピーされた証明書を調べます。
$ sudo podman exec -it 5a3e82c4a75f cat /etc/ssl/certs/storage.pem -----BEGIN CERTIFICATE----- MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV
3.16. LDAP 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
AUTHENTICATION_TYPE | String |
|
FEATURE_TEAM_SYNCING | Boolean |
認証エンジン (LDAP または Keystone) のバッキンググループからのチームメンバーシップの同期を許可するかどうか。 |
FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP | Boolean |
有効にすると、スーパーユーザー以外も LDAP を使用してチームでの同期をセットアップできます。 |
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 |
チームでチーム同期が有効になっている場合は、そのメンバーシップを確認し、必要に応じて再同期する頻度。 |
LDAP_SUPERUSER_FILTER | String |
このフィールドを使用すると、管理者は Red Hat Quay 設定ファイルを更新してデプロイメントを再起動することなく、スーパーユーザーを追加または削除できます。
このフィールドでは、 |
LDAP_RESTRICTED_USER_FILTER | String |
このフィールドでは、 |
LDAP_TIMEOUT | Integer |
LDAP (Lightweight Directory Access Protocol) サーバーへの接続を確立するのに許可される最大時間を秒単位で指定します。
デフォルト: |
LDAP_NETWORK_TIMEOUT | Integer |
Red Hat Quay がネットワーク操作中に LDAP (Lightweight Directory Access Protocol)サーバーからの応答を待つ最大時間を秒単位で定義します。
デフォルト: |
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. 設定フィールドのミラーリング
フィールド | 型 | 説明 |
---|---|---|
FEATURE_REPO_MIRROR | Boolean |
リポジトリーミラーリングを有効または無効にします。 |
REPO_MIRROR_INTERVAL | Number |
次にリポジトリーミラー候補をチェックするまでの秒数。 |
REPO_MIRROR_SERVER_HOSTNAME | String |
|
REPO_MIRROR_TLS_VERIFY | Boolean |
HTTPS を必要とし、ミラー時に Quay レジストリーの証明書を検証します。 |
REPO_MIRROR_ROLLBACK | Boolean |
デフォルト: |
3.18. セキュリティースキャナー設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_SECURITY_SCANNER | Boolean |
セキュリティースキャナー。 |
FEATURE_SECURITY_NOTIFICATIONS | Boolean |
セキュリティースキャナーが有効になっている場合、セキュリティー通知を有効にするか、オフにします |
SECURITY_SCANNER_V4_REINDEX_THRESHOLD | String |
このパラメーターは、最終のインデックス作成から状態が変更されたか、以前に失敗したマニフェストのインデックスをもう一度作成するまで待機する最小時間を判断するのに使用します。データは manifestsecuritystatus テーブルの |
SECURITY_SCANNER_V4_ENDPOINT | String |
V4 セキュリティースキャナーのエンドポイント。 |
SECURITY_SCANNER_V4_PSK | String | Clair 用に生成された共有キー (PSK)。 |
SECURITY_SCANNER_ENDPOINT | String |
V2 セキュリティースキャナーのエンドポイント。 |
SECURITY_SCANNER_INDEXING_INTERVAL | Integer |
このパラメーターは、セキュリティースキャナーのインデックス作成の間隔 (秒単位) を決定するために使用されます。インデックスのトリガーが発生すると、Red Hat Quay は、Clair でインデックス化する必要のあるマニフェストに対してそのデータベースをクエリーします。これには、インデックス付けされていないマニフェストや、以前にインデックス付けに失敗したマニフェストが含まれます。 + デフォルト: 30 |
FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX | Boolean | 新しいプッシュの脆弱性に関する通知の送信を許可するかどうか。
+ デフォルト*: |
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 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_GENERAL_OCI_SUPPORT | Boolean |
OCI アーティファクトのサポートを有効にします。 |
次の Open Container Initiative (OCI) アーティファクトタイプは、デフォルトで Red Hat Quay に組み込まれており、FEATURE_GENERAL_OCI_SUPPORT 設定フィールドを通じて有効になります。
フィールド | メディアタイプ | サポートされているコンテンツタイプ |
---|---|---|
Helm |
|
|
Cosign |
|
|
SPDX |
|
|
Syft |
|
|
CycloneDX |
|
|
In-toto |
|
|
Unknown |
|
|
3.19.1. Helm の設定
次の YAML は、Helm を有効にする場合の設定例です。
Helm YAML 設定
FEATURE_GENERAL_OCI_SUPPORT: true
3.20. Open Container Initiative 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
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. 不明なメディアタイプ
フィールド | 型 | 説明 |
---|---|---|
IGNORE_UNKNOWN_MEDIATYPES | Boolean | 有効にすると、コンテナーレジストリープラットフォームは、サポートされているアーティファクトタイプに関する特定の制限を無視し、認識されないメディアタイプまたは未知のメディアタイプを受け入れることができます。
デフォルト: |
3.21.1. 不明なメディアタイプの設定
次の YAML は、不明なメディアタイプまたは認識されないメディアタイプを有効にする場合の設定例です。
不明なメディアタイプの YAML 設定
IGNORE_UNKNOWN_MEDIATYPES: true
3.22. アクションログ設定フィールド
3.22.1. アクションログストレージ設定
フィールド | 型 | 説明 |
---|---|---|
FEATURE_LOG_EXPORT | Boolean |
アクションログのエクスポートを許可するかどうか。 |
LOGS_MODEL | String |
ログデータを処理するための推奨される方法を指定します。 |
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. アクションログのローテーションおよびアーカイブ設定
フィールド | 型 | 説明 |
---|---|---|
FEATURE_ACTION_LOG_ROTATION | Boolean |
ログローテーションおよび archival を有効にすると、30 日以上経過したすべてのログをストレージに移動します。 |
ACTION_LOG_ARCHIVE_LOCATION | String |
アクションログのアーカイブが有効な場合は、アーカイブされたデータを配置するストレージエンジン。 |
ACTION_LOG_ARCHIVE_PATH | String |
アクションログのアーカイブが有効な場合は、アーカイブされたデータを配置するストレージのパス。 |
ACTION_LOG_ROTATION_THRESHOLD | String |
ログをローテーションする間隔。 |
3.22.3. アクションログの監査設定
フィールド | 型 | 説明 |
---|---|---|
ACTION_LOG_AUDIT_LOGINS | Boolean |
|
3.23. ビルドログ設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_READER_BUILD_LOGS | Boolean |
true に設定すると、 |
LOG_ARCHIVE_LOCATION | String |
アーカイブされたビルドログを配置する、 |
LOG_ARCHIVE_PATH | String |
アーカイブされたビルドログを |
3.24. Dockerfile ビルドトリガーフィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_BUILD_SUPPORT | Boolean |
Dockerfile ビルドをサポートするかどうか |
SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD | Number |
|
SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD | Number |
|
3.24.1. GitHub ビルドトリガー
フィールド | 型 | 説明 |
---|---|---|
FEATURE_GITHUB_BUILD | Boolean |
GitHub ビルドトリガーをサポートするかどうか。 |
|
|
|
GITHUB_TRIGGER_CONFIG | Object | ビルドトリガーに GitHub Enterprise を使用するための設定。 |
.GITHUB_ENDPOINT | String |
GitHub Enterprise のエンドポイント。 |
.API_ENDPOINT | String |
使用する GitHub Enterprise API のエンドポイント。 |
.CLIENT_ID | String |
この Red Hat Quay インスタンスの登録済みクライアント ID。これを |
.CLIENT_SECRET | String | この Red Hat Quay インスタンスの登録されたクライアントシークレット。 |
3.24.2. Bitbucket ビルドトリガー
フィールド | 型 | 説明 |
---|---|---|
FEATURE_BITBUCKET_BUILD | Boolean |
Bitbucket ビルドトリガーをサポートするかどうか。 |
|
|
|
BITBUCKET_TRIGGER_CONFIG | Object | ビルドトリガーに BitBucket を使用するための設定。 |
.CONSUMER_KEY | String | この Red Hat Quay インスタンスの登録済みコンシューマーキー (クライアント ID)。 |
.CONSUMER_SECRET | String | この Red Hat Quay インスタンスの登録済みコンシューマーシークレット (クライアントシークレット)。 |
3.24.3. GitLab ビルドトリガー
フィールド | 型 | 説明 |
---|---|---|
FEATURE_GITLAB_BUILD | Boolean |
GitLab ビルドトリガーをサポートするかどうか。 |
|
|
|
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. ビルドマネージャー設定フィールド
フィールド | 型 | 説明 |
---|---|---|
ALLOWED_WORKER_COUNT | String |
Red Hat Quay Pod ごとにインスタンス化される Build Worker の数を定義します。通常は |
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 はランタイム時のキーイベントに必要なキースペースイベントを設定しません。これを行うには、 |
EXECUTOR | String |
このタイプのエグゼキュータの定義を開始します。有効な値は |
BUILDER_NAMESPACE | String | Red Hat Quay のビルドが行われる Kubernetes 名前空間。 |
K8S_API_SERVER | Object | ビルドが行われる OpenShift Container Platform クラスターの API サーバーのホスト名。 |
K8S_API_TLS_CA | Object |
API 呼び出しの実行時に |
KUBERNETES_DISTRIBUTION | String |
使用している Kubernetes の種類を示します。有効な値は |
CONTAINER_* | Object |
各 |
NODE_SELECTOR_* | Object |
|
CONTAINER_RUNTIME | Object |
ビルダーが |
SERVICE_ACCOUNT_NAME/SERVICE_ACCOUNT_TOKEN | Object |
|
QUAY_USERNAME/QUAY_PASSWORD | Object |
|
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 ビルドの実行に必要な内部仮想マシンを保持するコンテナーイメージの完全な参照 ( |
SETUP_TIME | String |
ビルドがまだビルドマネージャーに登録されていない場合に、タイムアウトする秒数を指定します。デフォルトは |
MINIMUM_RETRY_THRESHOLD | String |
この設定は、複数のエグゼキューターで使用されます。別のエグゼキューターを選択するまでに、ビルドの開始を何回再試行するかを示します。 |
SSH_AUTHORIZED_KEYS | Object |
|
3.26. OAuth 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
DIRECT_OAUTH_CLIENTID_WHITELIST | Array of string | ユーザーの承認なしに直接 OAuth 承認を実行できる Red Hat Quay 管理 アプリケーションのクライアント ID のリスト。 |
3.26.1. GitHub OAuth 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_GITHUB_LOGIN | Boolean |
GitHub ログインがサポートされるかどうか。 |
GITHUB_LOGIN_CONFIG | Object | 外部ログインプロバイダーとして GitHub (Enterprise) を使用するための設定。 |
.ALLOWED_ORGANIZATIONS | Array of string | ORG_RESTRICT オプションを使用するためにホワイトリスト化された GitHub (Enterprise) 組織の名前。 |
.API_ENDPOINT | String |
使用する GitHub (Enterprise) API のエンドポイント。github.com に対してオーバーライドする必要があります。 |
.CLIENT_ID | String |
この Red Hat Quay インスタンスの登録されたクライアント ID。GITHUB_TRIGGER_CONFIG とは共有できません。 |
.CLIENT_SECRET | String |
Red Hat Quay インスタンスの登録クライアントシークレット。 |
.GITHUB_ENDPOINT | String |
GitHub (Enterprise) のエンドポイント。 |
.ORG_RESTRICT | Boolean | true の場合は、組織のホワイトリスト内のユーザーのみが、このプロバイダーを使用してログインできます。 |
3.26.2. Google OAuth 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_GOOGLE_LOGIN | Boolean |
Google ログインがサポートされるかどうか。 |
GOOGLE_LOGIN_CONFIG | Object | 外部認証に Google を使用するための設定。 |
.CLIENT_ID | String |
この Red Hat Quay インスタンスの登録されたクライアント ID。 |
.CLIENT_SECRET | String |
Red Hat Quay インスタンスの登録クライアントシークレット。 |
3.27. OIDC 設定フィールド
フィールド | 型 | 説明 |
<文字列>_LOGIN_CONFIG | String |
OIDC 設定を保持する親キー。通常は、OIDC プロバイダーの名前 ( |
.CLIENT_ID | String |
この Red Hat Quay インスタンスの登録されたクライアント ID。 |
.CLIENT_SECRET | String |
Red Hat Quay インスタンスの登録クライアントシークレット。 |
.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 エンドポイントでのカスタムクエリーパラメーターのサポートを追加しました。エンドポイント |
.OIDC_ISSUER | String |
ユーザーが検証する発行者を定義できます。たとえば、JWT トークンは、トークンを発行したユーザーを定義する |
.OIDC_SERVER | String |
認証に使用される OIDC サーバーのアドレス。 |
.PREFERRED_USERNAME_CLAIM_NAME | String | 優先ユーザー名をトークンのパラメーターに設定します。 |
.SERVICE_ICON | String | ログイン画面のアイコンを変更します。 |
.SERVICE_NAME | String |
認証されているサービスの名前。 |
.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 に追加されます。有効にすると、リポジトリー名で /
を使用できます。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_EXTENDED_REPOSITORY_NAMES | Boolean |
ネストされたリポジトリーのサポートを有効にします。 |
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. メール設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_MAILING | Boolean |
メールが有効かどうか |
MAIL_DEFAULT_SENDER | String |
指定されている場合、Red Hat Quay がメールを送信する際の |
MAIL_PASSWORD | String | メールの送信時に使用する SMTP パスワード。 |
MAIL_PORT | Number | 使用する SMTP ポート。指定されていない場合は、デフォルトの 587 になります。 |
MAIL_SERVER | String |
メールの送信に使用する SMTP サーバー。FEATURE_MAILING が true に設定されている場合にのみ必要です。 |
MAIL_USERNAME | String | メールの送信時に使用する SMTP ユーザー名。 |
MAIL_USE_TLS | Boolean |
指定されている場合は、電子メールの送信に TLS を使用するかどうか。 |
3.31. ユーザー設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_SUPER_USERS | Boolean |
スーパーユーザーがサポートされるかどうか。 |
FEATURE_USER_CREATION | Boolean |
ユーザーを作成できるようにするかどうか (スーパーユーザー以外が)。 |
FEATURE_USER_LAST_ACCESSED | Boolean |
ユーザーが最後にアクセスした時間を記録するかどうか。 |
FEATURE_USER_LOG_ACCESS | Boolean |
true に設定すると、ユーザーは namespace の監査ログにアクセスできます |
FEATURE_USER_METADATA | Boolean |
ユーザーメタデータを収集してサポートするかどうか。 |
FEATURE_USERNAME_CONFIRMATION | Boolean |
true に設定すると、OpenID Connect (OIDC) または LDAP などのデータベース以外の認証プロバイダーでログインする場合に、初期ユーザー名を確認および変更できます。 |
FEATURE_USER_RENAME | Boolean |
true に設定すると、ユーザーは独自の namespace の名前を変更できます。 |
FEATURE_INVITE_ONLY_USER_CREATION | Boolean |
作成するユーザーは別のユーザーから招待を受ける必要があります。 |
FRESH_LOGIN_TIMEOUT | String |
新規ログイン時にユーザーがパスワードの再入力を要求されるまでの時間。 |
USERFILES_LOCATION | String |
ユーザーがアップロードしたファイルを配置するストレージエンジンの ID。 |
USERFILES_PATH | String |
ユーザーがアップロードしたファイルを配置するストレージの下のパス。 |
USER_RECOVERY_TOKEN_LIFETIME | String |
ユーザーアカウントを復元するためのトークンが有効な期間。 |
FEATURE_SUPERUSERS_FULL_ACCESS | Boolean | スーパーユーザーが所有していない名前空間、または明示的なアクセス許可を持っていない名前空間内の他のリポジトリーからコンテンツを読み取り、書き込み、削除する機能をスーパーユーザーに付与します。
デフォルト: |
FEATURE_SUPERUSERS_ORG_CREATION_ONLY | Boolean | スーパーユーザーのみに組織の作成を許可するかどうか。
デフォルト: |
FEATURE_RESTRICTED_USERS | Boolean |
デフォルト: |
RESTRICTED_USERS_WHITELIST | String |
|
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_USERS
はconfig.yaml
ファイルでtrue
に設定されています。
--- AUTHENTICATION_TYPE: Database --- --- FEATURE_RESTRICTED_USERS: true RESTRICTED_USERS_WHITELIST: - user1 ---
このフィールドが設定されていると、ホワイトリストに登録されたユーザーは、FEATURE_RESTRICTED_USERS
が true
に設定されていても、組織を作成したり、リポジトリーからコンテンツを読み書きしたりできます。user2
、user3
、user4
などの他のユーザーは、組織の作成、コンテンツの読み取りまたは書き込みが制限されています。
3.32. reCAPTCHA 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_RECAPTCHA | Boolean |
ユーザーログインおよびリカバリーに Recaptcha が必要かどうか |
RECAPTCHA_SECRET_KEY | String | recaptcha が有効になっている場合は、Recaptcha サービスのシークレットキー |
RECAPTCHA_SITE_KEY | String | recaptcha が有効になっている場合は、Recaptcha サービスのサイトキー |
3.33. ACI 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_ACI_CONVERSION | Boolean |
ACI への変換を有効にするかどうか |
GPG2_PRIVATE_KEY_FILENAME | String | ACI の復号化に使用される秘密鍵のファイル名 |
GPG2_PRIVATE_KEY_NAME | String | ACI に署名するために使用されるプライベートキーの名前 |
GPG2_PUBLIC_KEY_FILENAME | String | ACI の暗号化に使用する公開鍵のファイル名 |
3.34. JWT 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
JWT_AUTH_ISSUER | String |
JWT ユーザーのエンドポイント |
JWT_GETUSER_ENDPOINT | String |
JWT ユーザーのエンドポイント |
JWT_QUERY_ENDPOINT | String |
JWT クエリーのエンドポイント |
JWT_VERIFY_ENDPOINT | String |
JWT 検証のエンドポイント |
3.35. アプリケーショントークン設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_APP_SPECIFIC_TOKENS | Boolean |
有効な場合、ユーザーは Docker CLI で使用するトークンを作成できます。 |
APP_SPECIFIC_TOKEN_EXPIRATION | String |
外部アプリトークンの有効期限。 |
EXPIRED_APP_SPECIFIC_TOKEN_GC | String |
期限切れとなった外部アプリケーションがガべージコレクションが行われるまでに留まる期間。 |
3.36. その他の設定フィールド
フィールド | 型 | 説明 |
---|---|---|
ALLOW_PULLS_WITHOUT_STRICT_LOGGING | String |
true に指定すると、プルの監査ログのエントリーに書き込みできない場合でも、プルは成功します。これは、データベースが読み取り専用の状態にフォールバックし、その間プルを続行する必要がある場合に便利です。 |
AVATAR_KIND | String |
表示する avatar のタイプ。インライン (local) または Gravatar (gravatar)。 |
BROWSER_API_CALLS_XHR_ONLY | Boolean |
有効になっていると、ブラウザーから XHR による呼び出しとしてマークが付けられた API のみが許可されます。 |
DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT | Number |
namespace でキューに入れることができるデフォルトの最大ビルド数です。 |
ENABLE_HEALTH_DEBUG_SECRET | String | 指定していると、スーパーユーザーとして認証されていない場合に詳細なデバッグ情報を表示するために正常性エンドポイントに指定できるシークレット。 |
EXTERNAL_TLS_TERMINATION | Boolean |
TLS がサポートされていても、Quay の前の層で終了する場合は |
FRESH_LOGIN_TIMEOUT | String |
新規ログイン時にユーザーがパスワードの再入力を要求されるまでの時間。 |
HEALTH_CHECKER | String |
設定済みのヘルスチェック。 |
PROMETHEUS_NAMESPACE | String |
公開されているすべての Prometheus メトリクスに適用される接頭辞。 |
PUBLIC_NAMESPACES | Array of string | namespace がパブリック namespace リストに定義されている場合に、それはユーザーが namespace のメンバーであるかどうかに関係なく、すべての ユーザーのリポジトリーリストページに表示されます。一般的には、企業のお客様がよく知られた名前空間のセットを設定する際に使用されます。 |
REGISTRY_STATE | String |
レジストリーの状態 |
SEARCH_MAX_RESULT_PAGE_COUNT | Number |
ユーザーが検索で表示できる最大ページ数。 |
SEARCH_RESULTS_PER_PAGE | Number |
検索ページでページごとに返される結果数。 |
V2_PAGINATION_SIZE | Number |
V2 レジストリー API において、1 ページあたりに返される結果の数。 |
WEBHOOK_HOSTNAME_BLACKLIST | Array of string | 検証時に、ローカルホスト以外に Webhook から禁止するホスト名のセット。 |
CREATE_PRIVATE_REPO_ON_PUSH | Boolean |
プッシュで作成された新規リポジトリーがプライベート表示に設定されているかどうか。 |
CREATE_NAMESPACE_ON_PUSH | Boolean |
既存の組織への新規プッシュで namespace を作成するかどうか。 |
NON_RATE_LIMITED_NAMESPACES | Array of string |
|
Boolean | 設定すると、ユーザーはベータ UI 環境を試すことができます。
デフォルト: | |
FEATURE_REQUIRE_TEAM_INVITE | Boolean |
ユーザーをチームに追加するときに招待を必要とするかどうか。 |
FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH | Boolean |
(暗号化されたトークンではなく) 暗号化されていないパスワードを Basic 認証に使用できるかどうか |
FEATURE_RATE_LIMITS | Boolean |
API およびレジストリーエンドポイントでレート制限を有効にするかどうか。FEATURE_RATE_LIMITS を |
FEATURE_FIPS | Boolean |
true に設定すると、Red Hat Quay は FIPS 準拠のハッシュ関数を使用して実行されます。 |
FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL | Boolean |
集計されたログ数の取得を許可するかどうか。 |
FEATURE_ANONYMOUS_ACCESS | Boolean |
匿名ユーザーにパブリックリポジトリーの参照とプルを許可するかどうか。 |
FEATURE_DIRECT_LOGIN | Boolean |
ユーザーが UI に直接ログインできるかどうか |
FEATURE_LIBRARY_SUPPORT | Boolean |
Docker からプルおよびプッシュするときに名前空間のないリポジトリーを許可するかどうか。 |
FEATURE_PARTIAL_USER_AUTOCOMPLETE | Boolean |
true に設定すると、オートコンプリートは部分的なユーザー名に適用されます。 |
FEATURE_PERMANENT_SESSIONS | Boolean |
セッションが永続的かどうか。 |
FEATURE_PUBLIC_CATALOG | Boolean |
true に設定すると、 |
3.37. レガシー設定フィールド
次のフィールドは非推奨または廃止されました。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_BLACKLISTED_EMAILS | Boolean | true に設定すると、メールドメインがブラックリストに指定されている場合に新しいユーザーアカウントが作成されません。 |
BLACKLISTED_EMAIL_DOMAINS | Array of string |
FEATURE_BLACKLISTED_EMAILS が true に設定されている場合に使用されるメールアドレスドメインの一覧。 |
BLACKLIST_V2_SPEC | String |
Red Hat Quay が V2 は サポート対象外 であることを示す応答を返す Docker CLI バージョン。 |
DOCUMENTATION_ROOT | String | ドキュメントリンクのルート URL。 |
SECURITY_SCANNER_V4_NAMESPACE_WHITELIST | String | セキュリティースキャナーを有効にする namespace。 |
FEATURE_RESTRICTED_V1_PUSH | Boolean |
true に設定すると、V1_PUSH_WHITELIST にリストされている名前空間のみが V1 プッシュをサポートします。 |
V1_PUSH_WHITELIST | Array of string | FEATURE_RESTRICTED_V1_PUSH が true に設定されている場合に V1 push をサポートする namespace 名の配列。 |
FEATURE_HELM_OCI_SUPPORT | Boolean |
Helm アーティファクトのサポートを有効にします。 |
3.38. ユーザーインターフェイス v2 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_UI_V2 | Boolean | 設定すると、ユーザーはベータ UI 環境を試すことができます。
デフォルト: |
3.38.1. v2 ユーザーインターフェイス設定
FEATURE_UI_V2
を有効にすると、現在のバージョンのユーザーインターフェイスと新しいバージョンのユーザーインターフェイスを切り替えることができます。
- この UI は現在ベータ版であり、変更される可能性があります。現在の状態では、ユーザーは組織、リポジトリー、およびイメージタグのみを作成、表示、および削除できます。
- 古い UI で Red Hat Quay を実行している場合にセッションがタイムアウトになると、ユーザーはポップアップウィンドウでパスワードを再度入力する必要がありました。新しい UI では、ユーザーはメインページに戻り、ユーザー名とパスワードの認証情報を入力する必要があります。これは既知の問題であり、新しい UI の今後のバージョンで修正される予定です。
- 従来の UI と新しい UI の間で、イメージマニフェストのサイズが報告される方法に違いがあります。従来の UI では、イメージマニフェストはメビバイト単位で報告されていました。新しい UI では、Red Hat Quay はメガバイト (MB) の標準定義を使用して、イメージマニフェストのサイズを報告します。
手順
デプロイメントの
config.yaml
ファイルで、FEATURE_UI_V2
パラメーターを追加し、true
に設定します。次に例を示します。--- FEATURE_TEAM_SYNCING: false FEATURE_UI_V2: true FEATURE_USER_CREATION: true ---
- Red Hat Quay デプロイメントにログインします。
Red Hat Quay デプロイメントのナビゲーションペインに、現在の UI と 新しい UI を切り替えるオプションが表示されます。切り替えボタンをクリックして新しい UI に設定し、次に Use Beta Environment をクリックします。次に例を示します。
3.39. IPv6 設定フィールド
フィールド | 型 | 説明 |
---|---|---|
FEATURE_LISTEN_IP_VERSION | String | IPv4、IPv6、またはデュアルスタックプロトコルファミリーを有効にします。この設定フィールドは正しく設定する必要があります。そうしないと、Red Hat Quay は起動に失敗します。
デフォルト:
追加設定: |
3.40. ブランディング設定フィールド
フィールド | 型 | 説明 |
---|---|---|
BRANDING | Object | Red Hat Quay UI のロゴおよび URL のカスタムブランディング |
.logo | String |
メインのロゴイメージ URL。
ヘッダーロゴのデフォルトは 205x30 PX です。Web UI の Red Hat Quay サインイン画面のフォームロゴは、デフォルトで 356.5x39.7 PX です。 |
.footer_img | String |
UI フッターのロゴ。デフォルトは 144x34 ピクセルです。 |
.footer_url | String |
フッターイメージへのリンク。 |
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 設定フィールドに依存しています。
フィールド | 型 | 説明 |
---|---|---|
PERMANENT_SESSION_LIFETIME | Integer |
永続セッションの有効期限を設定するために使用される
デフォルト: |
3.41.1. 設定セッションタイムアウトの設定例
次の YAML は、セッションの有効期間を有効にする場合の推奨設定です。
セッションの有効期間を変更することは推奨できません。管理者は、セッションタイムアウトを設定するときに、割り当てられた時間を認識する必要があります。時間が早すぎると、ワークフローが中断する可能性があります。
セッションタイムアウトの YAML 設定
PERMANENT_SESSION_LIFETIME: 3000
第4章 環境変数
Red Hat Quay は、動的に設定する多数の環境変数をサポートします。
4.1. Geo レプリケーション
ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、QUAY_DISTRIBUTED_STORAGE_PREFERENCE
環境変数を使用して明示的に設定できます。
変数 | 型 | 説明 |
---|---|---|
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_POOLING
を true
または false
に設定することで切り替えることができます。
変数 | 型 | 説明 |
---|---|---|
DB_CONNECTION_POOLING | Boolean | データベース接続プールの有効化または無効化 |
データベース接続プーリングが有効な場合は、接続プールの最大サイズを変更することができます。これは、以下の config.yaml
オプションを使用して実行できます。
config.yaml
... DB_CONNECTION_ARGS: max_connections: 10 ...
4.3. HTTP 接続回数
環境変数を使用して、HTTP の同時接続数を指定することができます。これらは、全体として、または特定のコンポーネントに対して指定できます。それぞれのデフォルトは、プロセスあたり 50 の
並列接続です。
変数 | 型 | 説明 |
---|---|---|
WORKER_CONNECTION_COUNT | Number |
同時 HTTP 接続 |
WORKER_CONNECTION_COUNT_REGISTRY | Number |
レジストリーの同時 HTTP 接続 |
WORKER_CONNECTION_COUNT_WEB | Number |
Web UI の同時 HTTP 接続 |
WORKER_CONNECTION_COUNT_SECSCAN | Number |
Clair の同時 HTTP 接続 |
4.4. ワーカーカウント変数
変数 | 型 | 説明 |
---|---|---|
WORKER_COUNT | Number | プロセス数の汎用上書き |
WORKER_COUNT_REGISTRY | Number |
|
WORKER_COUNT_WEB | Number |
コンテナー内の UI/Web リクエストを処理するプロセス数を指定します。 |
WORKER_COUNT_SECSCAN | Number |
コンテナー内のセキュリティースキャン (Clair など) の統合を処理するプロセス数を指定します。 |
4.5. デバッグ変数
次のデバッグ変数は Red Hat Quay で利用できます。
変数 | 型 | 説明 |
---|---|---|
DEBUGLOG | Boolean | デバッグログを有効または無効にするかどうか。 |
USERS_DEBUG |
integer |
パスワードを含むクリアテキストで LDAP 操作をデバッグするために使用されます。 重要
|
第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 が公開される場所を設定します。
デフォルト: |
introspection_addr | String | Clair のメトリクスと正常性エンドポイントが公開される場所を設定します。 |
log_level | String | ログレベルを設定します。文字列 debug-color、debug、info、warn、error、fatal、panic のいずれかが必要です。 |
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 |
レートは、インデックスレポート作成リクエストの数を制限します。これを
同時実行数を超えた場合、API はステータスコード |
.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 に接続して脆弱性レポートを作成します。このインデクサーの場所は必須です。
デフォルトは |
.migrations | Boolean | matcher ノードがデータベースへの移行を処理するかどうか。 |
.period | String | 新しいセキュリティーアドバイザリーの更新頻度を決定します。
デフォルトは |
.disable_updaters | Boolean | バックグラウンド更新を実行するかどうか。
デフォルト: |
.update_retention | Integer | ガベージコレクションサイクル間で保持する更新操作の数を設定します。これは、データベースサイズの制約に基づいて安全な MAX 値に設定する必要があります。
デフォルトは
|
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
設定フィールドとは異なります。
フィールド | 型 | 説明 |
---|---|---|
matchers | 文字列の配列。 |
ツリー内 |
.names | String |
有効な matchers について matcher ファクトリーに通知する文字列値のリスト。値を |
.config | String | 特定の matcher に設定を提供します。 matchers ファクトリーコンストラクターに提供されるサブオブジェクトを含む matcher の名前をキーとするマップ。以下に例を示します。 |
matchers 設定の例
次の例は、alpine
、aws
、debian
、oracle
matchers のみを必要とする仮の Clair デプロイメントを示しています。
matchers 設定の例
# ... matchers: names: - "alpine-matcher" - "aws" - "debian" - "oracle" # ...
5.1.7. Clair アップデーター設定フィールド
次の表では、Clair の updaters
コンポーネントの設定フィールドについて説明します。
フィールド | 型 | 説明 |
---|---|---|
updaters | Object | matcher の更新マネージャーの設定を提供します。 |
.sets | String | どのアップデーターを実行するかを更新マネージャーに通知する値のリスト。
値を 空白のままにすると、アップデーターは実行されません。 |
.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 ノーティファイアー環境で使用できます。
.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 |
|
.amqp.rollup | Integer |
|
.amqp.exchange | Object | 接続先の AMQP エクスチェンジ。 |
.amqp.exchange.name | String | 接続先のエクスチェンジの名前。 |
.amqp.exchange.type | String | エクスチェンジのタイプ。通常は、direct、fanout、topic、headers のいずれかです。 |
.amqp.exchange.durability | Boolean | 設定されたキューが永続的かどうか。 |
.amqp.exchange.auto_delete | Boolean |
設定されたキューが |
.amqp.routing_key | String | 各通知が送信されるルーティングキーの名前。 |
.amqp.callback | String |
|
.amqp.uris | String | 接続先の 1 つ以上の AMQP ブローカーのリスト (優先順位順)。 |
.amqp.tls | Object | AMQP ブローカーへの TLS/SSL 接続を設定します。 |
.amqp.tls.root_ca | String | ルート CA を読み取ることができるファイルシステムパス。 |
.amqp.tls.cert | String | TLS/SSL 証明書を読み取ることができるファイルシステムパス。
[注意] ==== Go |
.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 ノーティファイアー環境で使用できます。
.stomp | Object | STOMP 配信のノーティファイアーを設定します。 |
---|---|---|
.stomp.direct | Boolean |
|
.stomp.rollup | Integer |
|
.stomp.callback | String |
|
.stomp.destination | String | 通知を配信する STOMP の宛先。 |
.stomp.uris | String | 接続先の 1 つ以上の STOMP ブローカーのリスト (優先順位順)。 |
.stomp.tls | Object | STOMP ブローカーへの TLS/SSL 接続を設定しました。 |
.stomp.tls.root_ca | String | ルート CA を読み取ることができるファイルシステムパス。
[注意] ==== Go |
.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 ベースの認証を定義します。複数の |
.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 |
トレースを送信できる |
.jaeger.collector | Object | Jaeger コレクターへの配信を設定するための値を定義します。 |
.jaeger.collector.endpoint | String |
トレースを送信できる |
.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" # ...