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 をデプロイしたら、デプロイから完全な設定を取得して保存する必要があります。完全な設定には、システムの再始動またはアップグレード時に必要になる可能性がある追加の生成値が含まれています。
1.1. Quay 3.8 の設定更新
以下の設定フィールドが Red Hat Quay 3.8 で導入されました。
フィールド | タイプ | 説明 |
---|---|---|
Boolean | 設定すると、ユーザーはベータ UI 環境を試すことができます。
デフォルト: | |
String | IPv4、IPv6、またはデュアルスタックプロトコルファミリーを有効にします。この設定フィールドは正しく設定する必要があります。そうしないと、Red Hat Quay は起動に失敗します。
デフォルト:
追加設定: | |
String |
このフィールドを使用すると、管理者は Red Hat Quay 設定ファイルを更新してデプロイメントを再起動することなく、スーパーユーザーを追加または削除できます。 | |
String |
| |
ブール値 | スーパーユーザーが所有していない名前空間、または明示的なアクセス許可を持っていない名前空間内の他のリポジトリーからコンテンツを読み取り、書き込み、削除する機能をスーパーユーザーに付与します。
デフォルト: | |
String | 設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。 | |
ブール値 |
デフォルト: | |
String |
|
1.2. Quay 3.7 の設定更新
1.2.1. Red Hat Quay 3.7.7 の新規設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
REPO_MIRROR_ROLLBACK | Boolean |
デフォルト: |
1.2.2. 新規設定フィールド
以下の設定フィールドが Red Hat Quay 3.7 で導入されました。
パラメーター | 説明 |
---|---|
FEATURE_QUOTA_MANAGEMENT | クォータ管理がサポートされるようになりました。この機能により、ユーザーは、設定されたストレージクォータ制限を確立することにより、ストレージ消費を報告し、レジストリーの増加を抑えることができます。クォータ管理の詳細については、Red Hat Quay クォータの管理と実施 を参照してください。 |
DEFAULT_SYSTEM_REJECT_QUOTA_BYTES | すべての組織およびユーザーに適用するクォータサイズクォータ管理の詳細については、Red Hat Quay クォータの管理と実施 を参照してください。 |
FEATURE_PROXY_CACHE | Red Hat Quay を使用してリモート組織をプロキシーすることがサポートされるようになりました。この機能により、Red Hat Quay は、アップストリームレジストリーからのプルレート制限を回避するためのプロキシーキャッシュとして機能します。クォータ管理の詳細については、アップストリームレジストリーのプロキシーキャッシュとしての Red Hat Quay を参照してください。 |
1.3. Red Hat Quay 3.6 の設定の更新
1.3.1. 新規設定フィールド
以下の設定フィールドが Red Hat Quay 3.6 で導入されました。
パラメーター | 説明 |
---|---|
FEATURE_EXTENDED_REPOSITORY_NAMES |
ネストされたリポジトリーと拡張リポジトリー名のサポートが追加されました。この変更により、特定の OpenShift Container Platform ユースケースに必要なリポジトリー名で |
FEATURE_USER_INITIALIZE |
true に設定すると、API |
ALLOWED_OCI_ARTIFACT_TYPES |
Helm、cosign、および ztsd 圧縮スキームアーティファクトはデフォルトで Red Hat Quay 3.6 に組み込まれています。デフォルトでサポートされていないその他の Open Container Initiative (OCI) メディアタイプについては、Quay の |
CREATE_PRIVATE_REPO_ON_PUSH |
レジストリーユーザーは、セキュリティーのニーズに応じて、 |
CREATE_NAMESPACE_ON_PUSH | 存在しない組織にプッシュした場合に、組織を自動的に作成するように設定できるようになりました。 |
1.3.2. 非推奨の設定フィールド
以下の設定フィールドは、Red Hat Quay 3.6 で廃止されました。
パラメーター | 説明 |
---|---|
FEATURE_HELM_OCI_SUPPORT |
このオプションは廃止され、Red Hat Quay の将来のバージョンでは削除される予定です。Red Hat Quay 3.6 では、Helm アーティファクトがデフォルトでサポートされ、 |
1.4. 設定ファイルの編集
Red Hat Quay のスタンドアロンインスタンスをデプロイするには、最小限の設定情報を提供する必要があります。最小設定の要件は、「Red Hat Quay の最小設定」に記載されています。
必須フィールドに入力したら、設定を検証できます。問題がある場合は、強調表示されます。
コンフィグレーション API を使用して設定を検証することもできますが、これには Quay コンテナーを設定モードで起動する必要があります。詳細については、「設定ツールの使用」を参照してください。
変更を有効にするには、レジストリーを再起動する必要があります。
1.5. スタンドアロンデプロイメントにおける設定ファイルの場所
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.8.15
1.6. 最小設定
Red Hat Quay のスタンドアロンデプロイメントには、以下の設定オプションが必要です。
- サーバーのホスト名
- HTTP または HTTPS
- 認証タイプ (データベースや LDAP (Lightweight Directory Access Protocol) など)
- データ暗号化用の秘密鍵
- イメージのストレージ
- メタデータ用のデータベース
- ビルドログおよびユーザーイベント用の Redis
- タグの有効期限オプション
1.6.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
フィールドは、設定が検証されたことを示します。レジストリーを起動する前に、設定エディターツールを使用して設定を検証する必要があります。
1.6.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.8.15
1.6.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.8.15
第2章 設定フィールド
このセクションでは、Red Hat Quay のデプロイ時に必須および任意の設定フィールドの両方について説明します。
2.1. 必須の設定フィールド
Red Hat Quay の設定で必須のフィールドは、以下のセクションで説明されています。
2.2. 自動化オプション
以下のセクションでは、Red Hat Quay デプロイメントで利用可能な自動化オプションについて説明します。
2.3. 任意の設定フィールド
Red Hat Quay の任意のフィールドについては、以下のセクションで説明します。
2.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 |
これは、以前のバージョンのソフトウェアからそのまま残っているアーティファクトで、現時点では値を |
2.5. データベースの設定
このセクションでは、Red Hat Quay デプロイメントで利用可能なデータベース設定フィールドを説明します。
2.5.1. データベース URI
Red Hat Quay では、必要な DB_URI
フィールドを使用してデータベースへの接続を設定します。
以下の表は DB_URI
設定フィールドを説明します。
フィールド | タイプ | 説明 |
---|---|---|
DB_URI | String | 認証情報を含む、データベースにアクセスするための URI。
postgresql://quayuser:quaypass@quay-server.example.com:5432/quay |
2.5.2. データベース接続引数
オプションの接続引数は、DB_CONNECTION_ARGS
パラメーターで設定されます。DB_CONNECTION_ARGS
で定義されたキーと値のペアの一部は汎用的なものも、データベース固有のものもあります。
以下の表は、データベース接続引数を説明します。
フィールド | タイプ | 説明 |
---|---|---|
DB_CONNECTION_ARGS | Object | タイムアウトや SSL などのデータベースの任意の接続引数。 |
.autorollback | Boolean |
スレッドローカル接続を使用するかどうか。 |
.threadlocals | Boolean |
自動ロールバック接続を使用するかどうか。 |
2.5.2.1. PostgreSQL SSL 接続引数
SSL では、設定はデプロイするデータベースによって異なります。以下の例は、PostgreSQL SSL 設定を示します。
DB_CONNECTION_ARGS: sslmode: verify-ca sslrootcert: /path/to/cacert
sslmode
オプションは、セキュアな SSL/IP 接続がサーバーにネゴシエートされるかどうか、その優先度を決定します。モードは 6 つあります。
Mode | 説明 |
---|---|
disable | 設定は SSL 以外の接続のみを試みます。 |
allow | 設定は、SSL 以外の接続を最初に試行します。障害が発生したときに、SSL 接続を試行します。 |
prefer | 設定は最初に SSL 接続を試みます。障害が発生したときに、SSL 以外の接続を試みます。 |
require | 設定は SSL 接続のみを試みます。ルート CA ファイルが存在する場合は、verify-ca が指定されているのと同じ方法で証明書を検証します。 |
verify-ca | 設定は SSL 接続のみを試行し、サーバー証明書が信頼できる認証局 (CA) によって発行されたことを確認します。 |
verify-full | SSL 接続のみを試行し、信頼された CA によりサーバー証明書が発行され、要求されたサーバーのホスト名が証明書と一致することを確認します。 |
PostgreSQL の有効な引数の詳細は、Database Connection Control Functions を参照してください。
2.5.2.2. MySQL SSL 接続引数
以下の例は、MySQL SSL 設定の例を示します。
DB_CONNECTION_ARGS: ssl: ca: /path/to/cacert
MySQL の有効な接続引数に関する情報は、Connecting to the Server Using URI-Like Strings or Key-Value Pairs を参照してください。
2.6. イメージストレージ
このセクションでは、Red Hat Quay で利用可能なイメージストレージ機能と設定フィールドについて説明します。
2.6.1. イメージストレージ機能
以下の表は、Red Hat Quay のイメージストレージ機能について説明しています。
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_REPO_MIRROR | Boolean |
true に設定されている場合、リポジトリーのミラーリングを有効にします。 |
FEATURE_PROXY_STORAGE | Boolean |
NGINX を使用してストレージ内のすべての直接ダウンロード URL をプロキシーするかどうか。 |
FEATURE_STORAGE_REPLICATION | Boolean |
ストレージエンジン間で自動的にレプリケートするかどうか |
2.6.2. イメージストレージ設定フィールド
以下の表は、Red Hat Quay のイメージストレージ設定フィールドについて説明しています。
フィールド | タイプ | 説明 |
---|---|---|
DISTRIBUTED_STORAGE_CONFIG | Object |
Red Hat Quay で使用するストレージエンジンの設定。各キーは、ストレージエンジンの一意の ID を表します。この値は、ストレージエンジンパラメーターを記述するオブジェクトのタプル (キー、値) で設定されます。 |
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS | 文字列の配列 |
イメージをデフォルトで他のすべてのストレージエンジンに対して完全にレプリケートする必要のあるストレージエンジンの一覧 ( |
DISTRIBUTED_STORAGE_PREFERENCE | 文字列の配列 |
使用する優先ストレージエンジン( |
MAXIMUM_LAYER_SIZE | String |
イメージレイヤーの最大許容サイズ。 |
2.6.3. ローカルストレージ
以下の YAML は、ローカルストレージを使用した設定のサンプルを示しています。
DISTRIBUTED_STORAGE_CONFIG: default: - LocalStorage - storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
2.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
2.6.5. Ceph / RadosGW Storage / Hitachi HCP:
以下の YAML は、Ceph/RadosGW および Hitachi HCP ストレージを使用した設定例を示しています。
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 DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
2.6.6. AWS S3 ストレージ
以下の YAML は、AWS S3 ストレージを使用した設定のサンプルを示しています。
DISTRIBUTED_STORAGE_CONFIG: s3Storage: - S3Storage - 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
2.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
2.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
エラーが発生します。
2.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
2.7. Redis 設定フィールド
本セクションでは、Redis デプロイメントで利用可能な設定フィールドについて説明します。
2.7.1. ビルドログ
Redis デプロイメントには、以下のビルドログ設定フィールドを利用できます。
フィールド | タイプ | 説明 |
---|---|---|
BUILDLOGS_REDIS | Object | ビルドログキャッシュ用の Redis 接続の詳細 |
.host | String |
Redis にアクセスできるホスト名。 |
.port | 数値 |
Redis にアクセスできるポート。 |
.password | String |
Redis インスタンスに接続するためのパスワード。 |
.ssl | Boolean | Redis と Quay 間の TLS 通信を有効にするかどうか。デフォルトは false です。 |
2.7.2. ユーザーイベント
Redis デプロイメントには、以下のユーザーイベントフィールドを使用できます。
フィールド | タイプ | 説明 |
---|---|---|
USER_EVENTS_REDIS | Object | ユーザーイベント処理の Redis 接続の詳細 |
.host | String |
Redis にアクセスできるホスト名。 |
.port | 数値 |
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 証明書のホスト名が、接続先のサーバーのホスト名と一致することをクライアントが確認する必要があるかどうかを指定します。 |
2.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
になります。
2.8. ModelCache 設定オプション
以下のオプションは、ModelCache を設定するために Red Hat Quay で利用できます。
2.8.1. memcache 設定オプション
memcache は、デフォルトの ModelCache 設定オプションです。memcache を使用すると、追加の設定は必要ありません。
2.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 >
2.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 >
2.9. タグの有効期限の設定フィールド
以下のタグの有効期限設定フィールドは Red Hat Quay で利用できます。
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_GARBAGE_COLLECTION | Boolean |
リポジトリーのガベージコレクションを有効にするかどうか。 |
TAG_EXPIRATION_OPTIONS | 文字列の配列 |
有効にすると、名前空間内のタグの有効期限についてユーザーが選択できるオプション。 |
DEFAULT_TAG_EXPIRATION | String |
タイムマシンのデフォルトの設定可能なタグの有効期限。 |
FEATURE_CHANGE_TAG_EXPIRATION | Boolean |
ユーザーおよび組織が namespace のタグの有効期限を変更できるかどうか。 |
2.9.1. タグの有効期限の設定例
以下の YAML は、タグの有効期限の設定例を示しています。
DEFAULT_TAG_EXPIRATION: 2w TAG_EXPIRATION_OPTIONS: - 0s - 1d - 1w - 2w - 4w
2.10. 自動化のための Red Hat Quay の事前設定
Red Hat Quay には、自動化をサポートする複数の設定オプションがあります。これらのオプションはデプロイメントの前に設定でき、ユーザーインターフェイスとの対話の必要性を最小限に抑えることができます。
2.10.1. API による最初のユーザー作成の許可
/api/v1/user/initialize API
を使用して最初のユーザーを作成するには、FEATURE_USER_INITIALIZE
パラメーターを true
に設定します。既存の組織の OAuth アプリケーションによって生成された OAuth トークンを必要とする他のすべてのレジストリー API 呼び出しとは異なり、API エンドポイントには認証は必要ありません。
Red Hat Quay のデプロイ後に、API を使用して他のユーザーがすでに作成されていない限り、quayadmin
などのユーザーを作成できます。詳細は、API を使用して最初のユーザーを作成する を参照してください。
2.10.2. API 一般アクセスの有効化
Red Hat Quay レジストリー API の一般的なアクセスを許可するには、設定オプション BROWSER_API_CALLS_XHR_ONLY
を false
に設定します。
2.10.3. スーパーユーザーの追加
Red Hat Quay のデプロイ後に、ユーザーを作成できます。最初のユーザーには、完全な権限を持つ管理者権限を付与することを推奨します。すべてのパーミッションは、SUPER_USER
設定オブジェクトを使用して事前に設定できます。以下に例を示します。
... SERVER_HOSTNAME: quay-server.example.com SETUP_COMPLETE: true SUPER_USERS: - quayadmin ...
2.10.4. ユーザー作成の制限
スーパーユーザーを設定したら、新しいユーザーをスーパーユーザーグループに作成する機能を制限できます。ユーザー作成を制限するには、FEATURE_USER_CREATION
を false
に設定します。以下に例を示します。
... FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false ...
2.10.5. 新機能の有効化
新しい 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: - ...
2.10.6. 新機能の有効化
新規の 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 ...
2.10.7. 自動化の推奨設定
自動化には、以下の config.yaml
パラメーターが推奨されます。
... FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false ...
2.10.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
次のステップ
- API を使用した最初のユーザーの作成
2.10.9. API を使用した Red Hat Quay のデプロイ
このセクションでは、API を使用して Red Hat Quay をデプロイする方法を説明します。
前提条件
-
設定オプション
FEATURE_USER_INITIALIZE
はtrue
に設定する。 - データベースにユーザーが存在していない。
Red Hat Quay デプロイメントを事前に設定する方法は、自動化のための Red Hat Quay の設定 セクションを参照してください。
2.10.9.1. API を使用した最初のユーザーの作成
以下の手順に従って、Red Hat Quay 組織で最初のユーザーを作成します。
この手順では、"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!
2.10.9.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
ユーザーの詳細が返されます。
2.10.9.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 }
2.11. 基本設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
REGISTRY_TITLE | String |
指定されている場合、レジストリーの長いタイトル。Red Hat Quay デプロイメントのフロントエンド (組織のサインインページなど) に表示されます。35 文字を超えてはなりません。 |
REGISTRY_TITLE_SHORT | String |
指定されている場合は、省略形式のレジストリーのタイトル。タイトルは、組織のさまざまなページに表示されます。たとえば、組織の Tutorial ページのチュートリアルのタイトルとして表示されます。 |
CONTACT_INFO | 文字列の配列 | 指定されている場合は、連絡先ページに表示される連絡先情報。連絡先が 1 つしか指定されていない場合は、連絡先のフッターが直接リンクされます。 |
[0] | String |
電子メールを送信するためのリンクを追加します。 |
[1] | String |
IRC チャットルームにアクセスするためのリンクを追加します。 |
[2] | String |
電話番号を呼び出すためのリンクを追加します。+ |
[3] | String |
定義された URL へのリンクを追加します。 |
2.12. SSL 設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
PREFERRED_URL_SCHEME | String |
+ TLS を終了するロードバランサー、リバースプロキシー (Nginx など) を使用する場合、またはカスタム SSL 証明書で Quay を直接使用する場合、ユーザーは |
SERVER_HOSTNAME | String |
スキームなしで Red Hat Quay にアクセスできる URL |
SSL_CIPHERS | 文字列の配列 |
指定されている場合、有効化および無効化する SSL 暗号の nginx 定義の一覧 |
SSL_PROTOCOLS | 文字列の配列 |
指定されている場合、nginx は、一覧で定義される SSL プロトコルの一覧を有効にするように設定されます。リストから SSL プロトコルを削除すると、Red Hat Quay の起動時にそのプロトコルが無効になります。 |
SESSION_COOKIE_SECURE | Boolean |
セッションクッキーに |
2.12.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
コンテナーを停止し、レジストリーを再起動します。
2.13. Red Hat Quay コンテナーへの TLS 証明書の追加
カスタム TLS 証明書を Red Hat Quay に追加するには、Red Hat Quay の config ディレクトリーの下に extra_ca_certs/
という名前の新しいディレクトリーを作成します。必要なサイト固有の TLS 証明書をこの新しいディレクトリーにコピーします。
2.13.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.8.15 "/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
2.14. LDAP 設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
AUTHENTICATION_TYPE | String |
|
FEATURE_TEAM_SYNCING | ブール値 |
認証エンジン (LDAP または Keystone) のバッキンググループからチームメンバーシップを同期するかどうか。 |
FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP | ブール値 |
有効にすると、スーパーユーザー以外のユーザーは LDAP を使用してチームの同期を設定できます |
LDAP_ADMIN_DN | String | LDAP 認証の管理 DN。 |
LDAP_ADMIN_PASSWD | String | LDAP 認証の管理パスワード。 |
LDAP_ALLOW_INSECURE_FALLBACK | Boolean | LDAP 認証で SSL の非セキュアなフォールバックを許可するかどうか。 |
LDAP_BASE_DN | 文字列の配列 | LDAP 認証のベース DN。 |
LDAP_EMAIL_ATTR | String | LDAP 認証のメール属性。 |
LDAP_UID_ATTR | String | LDAP 認証の uid 属性。 |
LDAP_URI | String | LDAP URI。 |
LDAP_USER_FILTER | String | LDAP 認証のユーザーフィルター。 |
LDAP_USER_RDN | 文字列の配列 | LDAP 認証のユーザー RDN。 |
TEAM_RESYNC_STALE_TIME | String |
チームの同期が有効になっている場合、必要に応じてメンバーシップを確認して再同期する頻度 |
LDAP_SUPERUSER_FILTER | String |
このフィールドを使用すると、管理者は Red Hat Quay 設定ファイルを更新してデプロイメントを再起動することなく、スーパーユーザーを追加または削除できます。
このフィールドでは、 |
LDAP_RESTRICTED_USER_FILTER | String |
このフィールドでは、 |
2.14.1. LDAP 設定フィールドのリファレンス
次の参照を使用して、目的の設定フィールドで config.yaml
ファイルを更新します。
2.14.1.1. 基本 LDAP ユーザー設定
--- AUTHENTICATION_TYPE: LDAP --- LDAP_ADMIN_DN: uid=testuser,ou=Users,o=orgid,dc=jumpexamplecloud,dc=com LDAP_ADMIN_PASSWD: samplepassword LDAP_ALLOW_INSECURE_FALLBACK: false LDAP_BASE_DN: - o=orgid - dc=example - dc=com LDAP_EMAIL_ATTR: mail LDAP_UID_ATTR: uid LDAP_URI: ldap://ldap.example.com:389 LDAP_USER_RDN: - ou=Users
2.14.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 ---
2.14.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
2.15. 設定フィールドのミラーリング
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_REPO_MIRROR | Boolean |
リポジトリーミラーリングを有効化または無効化します |
REPO_MIRROR_INTERVAL | 数値 |
次にリポジトリーミラー候補をチェックするまでの秒数。 |
REPO_MIRROR_SERVER_HOSTNAME | String |
|
REPO_MIRROR_TLS_VERIFY | Boolean |
HTTPS を必要とし、ミラー時に Quay レジストリーの証明書を検証します。 |
REPO_MIRROR_ROLLBACK | Boolean |
デフォルト: |
2.16. セキュリティースキャナー設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
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 | 数値 | このパラメーターは、セキュリティースキャナーのインデックス作成の間隔 (秒単位) を決定するために使用されます。インデックスがトリガーされると、Red Hat Quay は、Clair でインデックス化する必要のあるマニフェストに対してそのデータベースをクエリーします。これには、インデックス化されていないマニフェストや、以前にインデックスに失敗したマニフェストが含まれます。 デフォルト: 30 |
以下は、インデックス変更の特別なケースです。
Clair v4 がマニフェストをインデックス化する場合は、結果として、決定論的なものである必要があります。たとえば、同じマニフェストが同じインデックスレポートを生成する必要があります。これは、異なるスキャナーを使用するとレポートで返される特定のマニフェストに関連して異なる情報を生成するため、スキャナーが変更されるまで True となります。そのため、Clair v4 はインデックスエンジン (/indexer/api/v1/index_state
) の状態表現を公開し、スキャナー設定が変更されたかどうかを判別します。
Red Hat Quay は、Quay のデータベースの解析時にこれをインデックスレポートに保存し、このインデックス状態を活用します。以前にスキャンされてからこの状態が変更された場合、Quay は定期的なインデックスプロセス時にマニフェストの再作成を試行します。
デフォルトでは、このパラメーターは 30 秒に設定されています。インデックス作成のプロセスをより頻繁に実行する場合は、時間を短縮します。たとえば、新規タグをプッシュしてから、30 秒待たずに、UI でセキュリティースキャンの結果を表示する場合などです。また、ユーザーは要求パターンを Clair に制御し、Quay データベースで実行されるデータベース操作のパターンをより詳細に制御する必要がある場合にパラメーターを変更することもできます。
2.17. OCI および Helm 設定フィールド
Helm のサポートが FEATURE_GENERAL_OCI_SUPPORT
プロパティーでサポートされるようになりました。機能を明示的に有効にする必要がある場合 (機能が無効にされている場合や、デフォルトで有効にされていないバージョンからアップグレードした場合など) は、OCI アーティファクトの使用を有効にするために 2 つのプロパティーを Quay 設定に追加する必要があります。
FEATURE_GENERAL_OCI_SUPPORT: true FEATURE_HELM_OCI_SUPPORT: true
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_GENERAL_OCI_SUPPORT | ブール値 |
OCI アーティファクトのサポートを有効にします |
FEATURE_HELM_OCI_SUPPORT | ブール値 |
Helm アーティファクトのサポートを有効にします |
Red Hat Quay 3.6 の時点で、FEATURE_HELM_OCI_SUPPORT
は非推奨になり、Red Hat Quay の今後のバージョンで削除される予定です。Red Hat Quay 3.6 では、Helm アーティファクトがデフォルトでサポートされ、FEATURE_GENERAL_OCI_SUPPORT
プロパティーに含まれています。ユーザーは、サポートを有効にするために config.yaml ファイルを更新する必要がなくなりました。
2.18. アクションログ設定フィールド
2.18.1. アクションログストレージ設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_LOG_EXPORT | ブール値 |
アクションログのエクスポートを許可するかどうか |
LOGS_MODEL | String |
セキュリティースキャナーを有効または無効にします。 |
LOGS_MODEL_CONFIG | オブジェクト | アクションログのログモデル設定 |
LOGS_MODEL_CONFIG [オブジェクト]: アクションログ用のログモデル設定
elasticsearch_config [オブジェクト]: Elasticsearch クラスターの設定
access_key [文字列] :Elasticsearch のユーザー (AWS ES の場合は IAM キー)
-
例:
some_string
-
例:
ホスト [文字列]: 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
-
例:
2.18.2. アクションログのローテーションおよびアーカイブ設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_ACTION_LOG_ROTATION | ブール値 |
ログローテーションおよび archival を有効にすると、30 日以上経過したすべてのログをストレージに移動します。 |
ACTION_LOG_ARCHIVE_LOCATION | String |
アクションログのアーカイブが有効な場合、アーカイブされたデータを配置するストレージエンジン |
ACTION_LOG_ARCHIVE_PATH | String |
アクションログのアーカイブが有効な場合、アーカイブされたデータを配置するストレージのパス |
ACTION_LOG_ROTATION_THRESHOLD | String |
ログをローテーションする間隔。 |
2.19. ビルドログ設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_READER_BUILD_LOGS | Boolean |
true に設定されている場合、書き込みアクセスや管理アクセスがある場合だけでなく、リポジトリーへの読み取りアクセスを持つユーザーがビルドログを読み取ることができます。 |
LOG_ARCHIVE_LOCATION | String |
アーカイブされたビルドログを配置する、 DISTRIBUTED_STORAGE_CONFIG で定義されたストレージの場所 |
LOG_ARCHIVE_PATH | String |
アーカイブされたビルドログを JSON 形式で配置する、設定されたストレージエンジンの下のパス |
2.20. Dockerfile ビルドトリガーフィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_BUILD_SUPPORT | Boolean |
Dockerfile ビルドをサポートするかどうか。 |
SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD | 数値 |
None ではない場合に、ビルドトリガーが自動的に無効にされる前に、連続で失敗できる回数。 |
SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD | 数値 |
None ではない場合に、ビルドトリガーが自動的に無効にされる前に、連続で発生可能な内部エラーの回数。 |
2.20.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。GITHUB_LOGIN_CONFIG と共有にすることはできません。 |
.CLIENT_SECRET | String | この Red Hat Quay インスタンスの登録されたクライアントシークレット。 |
2.20.2. Bitbucket ビルドトリガー
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_BITBUCKET_BUILD | Boolean |
Bitbucket ビルドトリガーをサポートしているかどうか |
|
|
|
BITBUCKET_TRIGGER_CONFIG | Object | ビルドトリガーに BitBucket を使用するための設定 |
.CONSUMER_KEY | String | この Quay インスタンスの登録されたコンシューマーキー (クライアント ID) |
.CONSUMER_SECRET | String | この Quay インスタンスの、登録されたコンシューマーシークレット (クライアントシークレット) |
2.20.3. GitLab ビルドトリガー
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_GITLAB_BUILD | Boolean |
GitLab ビルドトリガーをサポートしているかどうか |
|
|
|
GITLAB_TRIGGER_CONFIG | Object | ビルドトリガーに Gitlab を使用するための設定 |
.GITLAB_ENDPOINT | String | Gitlab (Enterprise) が実行されているエンドポイント |
.CLIENT_ID | String | この Quay インスタンスの、登録されたクライアント ID |
.CLIENT_SECRET | String | この Quay インスタンスの、登録されたクライアントシークレット |
2.21. OAuth 設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
DIRECT_OAUTH_CLIENTID_WHITELIST | 文字列の配列 | ユーザーの承認なしに直接 OAuth 承認を実行できる Red Hat Quay 管理 アプリケーションのクライアント ID の一覧。 |
2.21.1. GitHub OAuth 設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_GITHUB_LOGIN | Boolean |
GitHub ログインがサポートされるかどうか |
GITHUB_LOGIN_CONFIG | Object | 外部ログインプロバイダーとして GitHub (Enterprise) を使用するための設定 |
.ALLOWED_ORGANIZATIONS | 文字列の配列 | 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 の場合、このプロバイダーを使用してログインできるのは組織のホワイトリスト内のユーザーのみです。 |
2.21.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 インスタンスの登録クライアントシークレット。 |
2.22. 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 | ユーザーの電子メールアドレスを確認するために使用されるクレームの名前。 |
2.22.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",
2.23. ネストされたリポジトリー設定フィールド
Red Hat Quay 3.6 では、ネストされたリポジトリーパス名のサポートが FEATURE_EXTENDED_REPOSITORY_NAMES
プロパティーに追加されました。このオプションの設定は、デフォルトで config.yaml に追加されます。有効にすると、リポジトリー名で /
を使用できます。
FEATURE_EXTENDED_REPOSITORY_NAMES: true
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_EXTENDED_REPOSITORY_NAMES | Boolean |
ネストされたリポジトリーのサポートを有効にする |
2.24. その他の OCI メディアタイプの Quay への追加
Helm、cosign、および ztsd 圧縮スキームアーティファクトはデフォルトで Red Hat Quay 3.6 に組み込まれています。デフォルトでサポートされていない他の OCI メディアタイプでは、以下の形式を使用して Quay の config.yaml の ALLOWED_OCI_ARTIFACT_TYPES
設定に追加できます。
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) サポートを追加できます。
... 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 メディアタイプを追加する場合、ユーザーは必要に応じて cosign と Helm のサポートも手動で追加する必要があります。ztsd 圧縮スキームはデフォルトでサポートされているため、ユーザーはサポートを有効にするためにその OCI メディアタイプを config.yaml に追加する必要はありません。
2.25. メール設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_MAILING | Boolean |
メールが有効かどうか |
MAIL_DEFAULT_SENDER | String |
指定されている場合、Red Hat Quay がメールを送信する際の |
MAIL_PASSWORD | String | メールの送信時に使用する SMTP パスワード。 |
MAIL_PORT | 数値 | 使用する SMTP ポート。指定されていない場合は、デフォルトの 587 になります。 |
MAIL_SERVER | String |
メールの送信に使用する SMTP サーバー。FEATURE_MAILING が true に設定されている場合にのみ必要です。 |
MAIL_USERNAME | String | メールの送信時に使用する SMTP ユーザー名 |
MAIL_USE_TLS | Boolean |
指定されている場合、電子メールの送信に TLS を使用するかどうか |
2.26. ユーザー設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
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_RESTRICTED_USERS | Boolean |
デフォルト: |
RESTRICTED_USERS_WHITELIST | String |
|
GLOBAL_READONLY_SUPER_USERS | String | 設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。 |
2.26.1. ユーザー設定フィールドのリファレンス
次の参照を使用して、目的の設定フィールドで config.yaml
ファイルを更新します。
2.26.1.1. FEATURE_SUPERUSERS_FULL_ACCESS 設定リファレンス
--- SUPER_USERS: - quayadmin FEATURE_SUPERUSERS_FULL_ACCESS: True ---
2.26.1.2. GLOBAL_READONLY_SUPER_USERS 設定リファレンス
--- GLOBAL_READONLY_SUPER_USERS: - user1 ---
2.26.1.3. FEATURE_RESTRICTED_USERS 設定リファレンス
--- AUTHENTICATION_TYPE: Database --- --- FEATURE_RESTRICTED_USERS: true ---
2.26.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
などの他のユーザーは、組織の作成、コンテンツの読み取りまたは書き込みが制限されています。
2.27. reCAPTCHA 設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_RECAPTCHA | Boolean |
ユーザーログインおよびリカバリーに Recaptcha が必要かどうか |
RECAPTCHA_SECRET_KEY | String | recaptcha が有効にされている場合は、Recaptcha サービスのシークレットキー |
RECAPTCHA_SITE_KEY | String | recaptcha が有効にされている場合は、Recaptcha サービスのサイトキー |
2.28. ACI 設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_ACI_CONVERSION | Boolean |
ACI への変換を有効にするかどうか。 |
GPG2_PRIVATE_KEY_FILENAME | String | ACI の復号化に使用される秘密鍵のファイル名 |
GPG2_PRIVATE_KEY_NAME | String | ACI に署名するために使用されるプライベートキーの名前 |
GPG2_PUBLIC_KEY_FILENAME | String | ACI の暗号化に使用する公開鍵のファイル名 |
2.29. JWT 設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
JWT_AUTH_ISSUER | String |
JWT ユーザーのエンドポイント |
JWT_GETUSER_ENDPOINT | String |
JWT ユーザーのエンドポイント |
JWT_QUERY_ENDPOINT | String |
JWT クエリーのエンドポイント |
JWT_VERIFY_ENDPOINT | String |
JWT 検証のエンドポイント |
2.30. アプリケーショントークン設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_APP_SPECIFIC_TOKENS | Boolean |
有効な場合には、ユーザーは Docker CLI で使用するトークンを作成できます。 |
APP_SPECIFIC_TOKEN_EXPIRATION | String |
外部アプリトークンの有効期限。 |
EXPIRED_APP_SPECIFIC_TOKEN_GC | String |
期限切れとなった外部アプリケーションがガべージコレクションが行われるまでに留まる期間。 |
2.31. その他の設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
ALLOW_PULLS_WITHOUT_STRICT_LOGGING | String |
true に指定すると、プルの監査ログのエントリーに書き込みできない場合でも、プルは成功します。これは、データベースが読み取り専用の状態にフォールバックし、その間プルを続行する必要がある場合に便利です。 |
AVATAR_KIND | String |
表示する avatar のタイプ。インライン (ローカル) または Gravatar (gravatar)。 |
BROWSER_API_CALLS_XHR_ONLY | Boolean |
有効にされている場合には、ブラウザーから XHR による呼び出しとしてマークが付けられた API のみが許可されます。 |
DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT | 数値 |
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 | 文字列の配列 | namespace がパブリック namespace 一覧に定義されている場合に、それはユーザーが namespace のメンバーであるかどうかに関係なく、すべての ユーザーのリポジトリー一覧ページに表示されます。一般的には、企業のお客様がよく知られた名前空間のセットを設定する際に使用されます。 |
REGISTRY_STATE | String |
レジストリーの状態 |
SEARCH_MAX_RESULT_PAGE_COUNT | 数値 |
ユーザーが検索で表示できる最大ページ数。 |
SEARCH_RESULTS_PER_PAGE | 数値 |
検索ページでページごとに返される結果数 |
V2_PAGINATION_SIZE | 数値 |
V2 レジストリー API において、1 ページあたりに返される結果の数 |
WEBHOOK_HOSTNAME_BLACKLIST | 文字列の配列 | 検証時に、ローカルホスト以外に Webhook から禁止するホスト名のセット |
CREATE_PRIVATE_REPO_ON_PUSH | Boolean |
プッシュで作成された新規リポジトリーがプライベート表示に設定されているかどうか |
CREATE_NAMESPACE_ON_PUSH | Boolean |
既存の組織への新規プッシュで namespace を作成するかどうか |
NON_RATE_LIMITED_NAMESPACES | 文字列の配列 |
|
Boolean | 設定すると、ユーザーはベータ UI 環境を試すことができます。
デフォルト: |
2.31.1. その他の設定フィールドのリファレンス
次の参照を使用して、目的の設定フィールドで config.yaml
ファイルを更新します。
2.31.1.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 をクリックします。次に例を示します。
2.31.1.1.1. Red Hat Quay 3.8 ベータ UI での新しい組織の作成
前提条件
- 3.8 ベータ UI を使用するように Red Hat Quay デプロイメントを切り替えている。
以下の手順に従って、Red Hat Quay 3.8 ベータ UI を使用して組織を作成します。
手順
- ナビゲーションペインで Organization をクリックします。
- Create Organization をクリックします。
-
Organization Name (
testorg
など) を入力します。 - Create をクリックします。
これで、サンプルの組織が Organizations ページの下に表示されます。
2.31.1.1.2. Red Hat Quay 3.8 ベータ UI を使用した組織の削除
以下の手順に従って、Red Hat Quay 3.8 ベータ UI を使用して組織を削除します。
手順
-
Organizations ページで、削除する組織の名前 (
testorg
など) を選択します。 - More Actions ドロップダウンメニューをクリックします。
Delete をクリックします。
注記Delete ページには、Search 入力ボックスがあります。このボックスを使用すると、ユーザーは特定の組織を検索して、削除が適切にスケジュールされていることを確認できます。たとえば、ユーザーが 10 の組織を削除していて、特定の組織が削除されたことを確認したい場合、Search 入力ボックスを使用して、その組織が削除対象としてマークされていることを確認できます。
- ボックスに confirm と入力して、組織を完全に削除することを確定します。
- Delete をクリックします。
削除後、Organizations ページに戻ります。
複数の組織を選択してから、More Actions → Delete をクリックすると、一度に複数の組織を削除できます。
2.31.1.1.3. Red Hat Quay 3.8 ベータ UI を使用した新しいリポジトリーの作成
以下の手順に従って、Red Hat Quay 3.8 ベータ UI を使用してリポジトリーを作成します。
手順
- ナビゲーションペインで Repositories をクリックします。
- Create Repository をクリックします。
-
名前空間 (例: quayadmin) を選択し、リポジトリー名 (例:
testrepo
) を入力します。 - Create をクリックします。
これで、サンプルリポジトリーが Repositories ページの下に表示されるはずです。
2.31.1.1.4. Red Hat Quay 3.8 ベータ UI を使用したリポジトリーの削除
前提条件
- リポジトリーを作成している。
手順
-
Red Hat Quay 3.8 ベータ UI の Repositories ページで、削除するイメージの名前 (
quay/admin/busybox
など) をクリックします。 - More Actions ドロップダウンメニューをクリックします。
Delete をクリックします。
注記必要に応じて、Make Public または Make Private をクリックできます。
- ボックスに confirm と入力してから、Delete をクリックします。
- 削除後、Repositories ページに戻ります。
2.31.1.1.5. Red Hat Quay 3.8 ベータ UI へのイメージのプッシュ
以下の手順に従って、イメージを Red Hat Quay 3.8 ベータ UI にプッシュします。
手順
外部レジストリーからサンプルイメージをプルします。
$ podman pull busybox
イメージにタグを付けます。
$ podman tag docker.io/library/busybox quay-server.example.com/quayadmin/busybox:test
イメージを Red Hat Quay レジストリーにプッシュします。
$ podman push quay-server.example.com/quayadmin/busybox:test
- Red Hat Quay UI の Repositories ページに移動し、イメージが適切にプッシュされていることを確認します。
- イメージタグを選択し、Security Report ページに移動すると、セキュリティーの詳細を確認できます。
2.31.1.1.6. Red Hat Quay 3.8 ベータ UI を使用したイメージの削除
以下の手順に従って、Red Hat Quay 3.8 ベータ UI を使用してイメージを削除します。
前提条件
- イメージを Red Hat Quay レジストリーにプッシュしている。
手順
-
Red Hat Quay 3.8 ベータ UI の Repositories ページで、削除するイメージの名前 (
quay/admin/busybox
など) をクリックします。 - More Actions ドロップダウンメニューをクリックします。
Delete をクリックします。
注記必要に応じて、Make Public または Make Private をクリックできます。
- ボックスに confirm と入力してから、Delete をクリックします。
- 削除後、Repositories ページに戻ります。
2.31.1.1.7. Red Hat Quay レガシー UI の有効化
Red Hat Quay デプロイメントのナビゲーションペインに、Current UI と New UI を切り替えるオプションが表示されます。切り替えボタンをクリックして、Current UI に設定します。
2.32. レガシー設定フィールド
一部のフィールドは非推奨または廃止されています。
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_BLACKLISTED_EMAILS | Boolean | true に設定すると、メールドメインがブラックリストに指定されている場合には、新しいユーザーアカウントが作成されません。 |
BLACKLISTED_EMAIL_DOMAINS | 文字列の配列 |
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 | ブール値 |
true に設定すると、V1_PUSH_WHITELIST にリストされている名前空間のみが V1 プッシュをサポートします |
V1_PUSH_WHITELIST | 文字列の配列 | FEATURE_RESTRICTED_V1_PUSH が true に設定されている場合に V1 push をサポートする namespace 名の配列。 |
2.33. ユーザーインターフェイス v2 設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_UI_V2 | Boolean | 設定すると、ユーザーはベータ UI 環境を試すことができます。
デフォルト: |
2.34. IPv6 設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_LISTEN_IP_VERSION | String | IPv4、IPv6、またはデュアルスタックプロトコルファミリーを有効にします。この設定フィールドは正しく設定する必要があります。そうしないと、Red Hat Quay は起動に失敗します。
デフォルト:
追加設定: |
2.35. ブランディング設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
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 |
フッターイメージへのリンク。 |
2.35.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/
2.36. セッションタイムアウト設定フィールド
次の設定フィールドは、同じ名前の Flask API 設定フィールドに依存しています。
フィールド | タイプ | 説明 |
---|---|---|
PERMANENT_SESSION_LIFETIME | Integer |
永続セッションの有効期限を設定するために使用される
デフォルト: |
2.36.1. 設定セッションタイムアウトの設定例
次の YAML は、セッションの有効期間を有効にする場合の推奨設定です。
セッションの有効期間を変更することは推奨できません。管理者は、セッションタイムアウトを設定するときに、割り当てられた時間を認識する必要があります。時間が早すぎると、ワークフローが中断される可能性があります。
セッションタイムアウトの YAML 設定
PERMANENT_SESSION_LIFETIME: 3000
第3章 環境変数
Red Hat Quay は、動的に設定する多数の環境変数をサポートします。
3.1. Geo レプリケーション
ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、QUAY_DISTRIBUTED_STORAGE_PREFERENCE
環境変数を使用して明示的に設定できます。
変数 | タイプ | 説明 |
---|---|---|
QUAY_DISTRIBUTED_STORAGE_PREFERENCE | String | 使用する優先されるストレージ (DISTRIBUTED_STORAGE_CONFIG の ID 別) |
3.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 ...
3.3. HTTP 接続回数
環境変数を使用して、HTTP の同時接続数を指定することができます。これらは、全体として、または特定のコンポーネントに対して指定することができます。それぞれのデフォルトは、プロセスあたり 50 の
並列接続です。
変数 | タイプ | 説明 |
---|---|---|
WORKER_CONNECTION_COUNT | 数値 |
同時 HTTP 接続 |
WORKER_CONNECTION_COUNT_REGISTRY | 数値 |
レジストリーの同時 HTTP 接続 |
WORKER_CONNECTION_COUNT_WEB | 数値 |
Web UI の同時 HTTP 接続 |
WORKER_CONNECTION_COUNT_SECSCAN | 数値 |
Clair の同時 HTTP 接続 |
3.4. ワーカーカウント変数
変数 | タイプ | 説明 |
---|---|---|
WORKER_COUNT | 数値 | プロセス数の汎用上書き |
WORKER_COUNT_REGISTRY | 数値 |
|
WORKER_COUNT_WEB | 数値 |
コンテナー内の UI/Web リクエストを処理するプロセス数を指定します |
WORKER_COUNT_SECSCAN | 数値 |
コンテナー内のセキュリティースキャン (Clair など) の統合を処理するプロセス数を指定します。 |
3.5. デバッグ変数
次のデバッグ変数は Red Hat Quay で利用できます。
変数 | タイプ | 説明 |
---|---|---|
DEBUGLOG | Boolean | デバッグログを有効または無効にするかどうか。 |
USERS_DEBUG |
整数 |
パスワードを含むクリアテキストで LDAP 操作をデバッグするために使用されます。 重要
|
第4章 設定ツールを使用した OpenShift における Quay の再設定
4.1. 設定エディターへのアクセス
QuayRegistry 画面の Details セクションには、設定エディターのエンドポイントと、設定エディターへのログインに使用する認証情報などのシークレットのリンクがあります。
4.1.1. 設定エディターの認証情報の取得
設定エディターシークレットのリンクをクリックします。
Secret details 画面の Data セクションで、
Reveal values
をクリックし、設定エディターへのログインに使用する認証情報を表示します。
4.1.2. 設定エディターへのログイン
設定エディターエンドポイントを参照し、設定ツールにアクセスする時に使用するユーザー名 (通常は quayconfig
)、および対応するパスワードを入力します。
4.1.3. 設定の変更
次の例では、削除されたタグのデフォルトの有効期限を変更して、設定ファイルを更新します。
手順
- 設定エディターで、Time Machine セクションを見つけます。
許可された有効期限 ボックスに有効期限を追加します (例:
4w
)。- Validate Configuration Changes を選択して、変更が有効であることを確認します。
Reconfigure Quay を押して変更を適用します。
変更を適用した後、設定ツールは、加えられた変更が Red Hat Quay デプロイメントに送信されたことを通知します。
+
設定ツール UI を使用して Red Hat Quay を再設定すると、更新された設定が適用されるまでの間、レジストリーが短時間使用できなくなる可能性があります。
4.2. UI での再設定の監視
4.2.1. QuayRegistry リソース
Operator の再設定後に、QuayRegistry の特定インスタンスの YAML タブで再デプロイの進捗を追跡できます (この場合は example-registry
)。
ステータスが変わるたびに、データをリロードして更新されたバージョンを表示するように求められます。最終的に、Operator は変更を調整し、正常でないコンポーネントが報告されることはありません。
4.2.2. イベント
QuayRegistry の Events タブには、再デプロイに関連するイベントが表示されます。
再設定の影響を受ける namespace のすべてのリソースのストリーミングイベントは、Home → Events の OpenShift コンソールで利用できます。
4.3. 再設定後に更新された情報へのアクセス
4.3.1. UI で更新された設定ツールの認証情報へのアクセス
Red Hat Quay 3.7 では、UI を介して Quay を再設定しても、新しいログインパスワードが生成されなくなりました。パスワードは 1 回だけ生成され、QuayRegistry
オブジェクトを調整した後も同じままです。
4.3.2. UI で更新された config.yaml へのアクセス
設定バンドルを使用して、更新された config.yaml
ファイルにアクセスします。
- QuayRegistry の詳細画面で、Config Bundle Secret をクリックします。
-
Secret の詳細画面の Data セクションで、Reveal values をクリックし、
config.yaml
ファイルを表示します。 変更が適用されていることを確認します。この場合、
4w
はTAG_EXPIRATION_OPTIONS
の一覧に存在するはずです。... SERVER_HOSTNAME: example-quay-openshift-operators.apps.docs.quayteam.org SETUP_COMPLETE: true SUPER_USERS: - quayadmin TAG_EXPIRATION_OPTIONS: - 2w - 4w ...
第5章 Quay Operator コンポーネント
Quay は強力なコンテナーレジストリープラットフォームであるため、多くの依存関係が存在します。これらには、データベース、オブジェクトストレージ、Redis などが含まれます。Quay Operator は、Kubernetes 上で Quay とその依存関係に指向したデプロイメントを管理します。これらの依存関係は コンポーネント として処理され、QuayRegistry
API で設定されます。
QuayRegistry
カスタムリソースでは、spec.components
フィールドでコンポーネントを設定します。各コンポーネントには、kind
(コンポーネントの名前) と managed
(コンポーネントのライフサイクルを Operator が処理するかどうかを示すブール値) の 2 つのフィールドがあります。(このフィールドを省略する) デフォルトでは、すべてのコンポーネントが管理され、調整時に表示できるように自動的に入力されます。
spec: components: - kind: quay managed: true - kind: postgres managed: true - kind: clair managed: true - kind: redis managed: true - kind: horizontalpodautoscaler managed: true - kind: objectstorage managed: true - kind: route managed: true - kind: mirror managed: true - kind: monitoring managed: true - kind: tls managed: true - kind: clairpostgres managed: true
5.1. 管理コンポーネントの使用
QuayRegistry
カスタムリソースで特に指定しない限り、Red Hat Quay Operator は以下の管理コンポーネントにデフォルトを使用します。
- quay: Red Hat Quay デプロイメントのオーバーライドを保持します。たとえば、環境変数とレプリカの数です。このコンポーネントは Red Hat Quay 3.7 の新機能であり、アンマネージドに設定することはできません。
- postgres: レジストリーメタデータを保存するには、Software Collections から Postgres 10 のバージョンを使用します。
- clair: イメージの脆弱性スキャンを提供します。
- redis: ライブビルダーログと Red Hat Quay チュートリアルを保存します。ガベージコレクションに必要なロックメカニズムも含まれます。
-
horizontalpodautoscaler: メモリー/CPU 消費量に応じて
Quay
Pod の数を調整します。 -
ObjectStorage: イメージレイヤー Blob を格納するには、Noobaa/RHOCS によって提供される
ObjectBucketClaim
Kubernetes API を使用します。 - route: OpenShift Container Platform の外部から Red Hat Quay レジストリーへの外部エントリーポイントを提供します
- mirror: オプションのリポジトリーミラーリングをサポートするようにリポジトリーミラーワーカーを設定します。
- monitoring: Grafana ダッシュボード、個別のメトリクスへのアクセス、Quay Pod が頻繁に再起動されていることを通知するアラートなどが含まれます。
- tls: Red Hat Quay または OpenShift Container Platform が SSL/TLS を処理するかどうかを設定します
- clairpostgres: 管理された Clair データベースを設定します
Red Hat Quay Operator は、Red Hat Quay がマネージドコンポーネントを使用するために必要な設定およびインストール作業を処理します。Red Hat Quay Operator によって実行される独自のデプロイメントが環境に適していない場合は、以下のセクションで説明するように、Red Hat Quay Operator に unmanaged
リソース (オーバーライド) を提供できます。
5.2. 依存関係向けの管理対象外コンポーネントの使用
Quay で使用する Postgres、Redis、またはオブジェクトストレージなどの既存のコンポーネントがある場合は、まず Quay 設定バンドル (config.yaml
) 内でそれらを設定し、QuayRegistry
でバンドルを参照します (Kubernetes Secret
)。これは、非管理対象のコンポーネントを示します。
Quay 設定エディターを使用して、既存の設定バンドルを作成または変更したり、Kubernetes Secret
の更新プロセスを単純化したりできます。Quay の設定が設定エディターで変更され、Operator に送信されると、Quay デプロイメントは新規の設定を反映するように更新されます。
5.2.1. 既存の Postgres データベースの使用
要件
外部で管理された PostgreSQL データベースを使用している場合は、デプロイメントを成功させるために手動で pg_trgm 拡張機能を有効にする必要があります。
必要なデータベースフィールドを使用して設定ファイル
config.yaml
を作成します。config.yaml:
DB_URI: postgresql://test-quay-database:postgres@test-quay-database:5432/test-quay-database
設定ファイルを使用してシークレットを作成します。
$ kubectl create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
postgres
コンポーネントを管理対象外としてマークし、作成された Secret を参照する QuayRegistry YAML ファイルquayregistry.yaml
を作成します。quayregistry.yaml
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: postgres managed: false
- 以下のセクションで説明されているようにレジストリーをデプロイします。
5.2.2. NooBaa アンマネージドストレージ
- Storage → Object Bucket Claims のコンソールで NooBaa Object Bucket Claim を作成します。
- アクセスキー、バケット名、エンドポイント (ホスト名)、およびシークレットキーを含む Object Bucket Claim データの詳細を取得します。
Object Bucket Claim (オブジェクトバケット要求) の情報を使用して
config.yaml
設定ファイルを作成します。DISTRIBUTED_STORAGE_CONFIG: default: - RHOCSStorage - access_key: WmrXtSGk8B3nABCDEFGH bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef hostname: s3.openshift-storage.svc.cluster.local is_secure: true port: "443" secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
5.2.3. 水平 Pod オートスケーラー
水平 Pod オートスケーラー (HPA) が Clair
、Quay
、および Mirror
Pod に追加され、負荷の急増時に自動的にスケーリングされるようになりました。
HPA はデフォルトで managed
ように設定されているため、Clair Pod
、Quay Pod
、および Mirror
Pod の数は 2 に設定されています。これにより Operator による Red Hat Quay の更新または再設定時、またはイベントの再スケジュール中のダウンタイムの回避が容易になります。
5.2.3.1. Horizontal Pod Autoscaler の無効化
自動スケーリングを無効にするか、独自の HorizontalPodAutoscaler
を作成するには、QuayRegistry
インスタンスでコンポーネントを unamanged
として指定します。以下に例を示します。
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: components: - kind: horizontalpodautoscaler managed: false
5.3. Kubernetes へのデプロイ時に証明書を追加
Kubernetes にデプロイすると、Red Hat Quay は config アセットを保存するボリュームとしてシークレットにマウントします。残念ながら、これは現在、スーパーユーザーパネルの証明書のアップロード機能に干渉します。
このエラーを回避するには、Red Hat Quay が展開された 後に base64 エンコードされた証明書をシークレットに追加します。以下に、実行する方法を説明します。
まず、証明書の内容を Base64 エンコードします。
$ cat ca.crt -----BEGIN CERTIFICATE----- MIIDljCCAn6gAwIBAgIBATANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5MQUIu TElCQ09SRS5TTzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2 MDExMjA2NTkxMFoXDTM2MDExMjA2NTkxMFowOTEXMBUGA1UECgwOTEFCLkxJQkNP UkUuU08xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZI [...] -----END CERTIFICATE----- $ cat ca.crt | base64 -w 0 [...] c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
kubectl
ツールを使用して、quay-enterprise-config-secret を編集します。$ kubectl --namespace quay-enterprise edit secret/quay-enterprise-config-secret
証明書のエントリーを追加し、エントリーの下に base64 エンコードされた文字列を完全に貼り付けます。
custom-cert.crt: c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
-
最後に、すべての Red Hat Quay Pod をリサイクルします。
kubectl delete
を使用して、すべての Red Hat Quay Pod を削除します。Red Hat Quay Deployment は、新しい証明書データを使用して交換用 Pod を自動的にスケジュールします。
5.4. Operator を使用した OCI および Helm の設定
Quay の設定のカスタマイズは、設定バンドルを含むシークレットで提供できます。以下のコマンドを実行して、quay-config-bundle
という新規シークレットを適切な namespace に作成します。これには、OCI サポートを有効にするために必要なプロパティーが含まれます。
quay-config-bundle.yaml
apiVersion: v1 stringData: config.yaml: | FEATURE_GENERAL_OCI_SUPPORT: true FEATURE_HELM_OCI_SUPPORT: true kind: Secret metadata: name: quay-config-bundle namespace: quay-enterprise type: Opaque
Red Hat Quay 3.8 の時点で、FEATURE_HELM_OCI_SUPPORT
は非推奨になり、Red Hat Quay の将来のバージョンで削除される予定です。Red Hat Quay 3.6 では、Helm アーティファクトがデフォルトでサポートされ、FEATURE_GENERAL_OCI_SUPPORT
プロパティーに含まれています。ユーザーは、サポートを有効にするために config.yaml ファイルを更新する必要がなくなりました。
シークレットを適切な namespace に作成します (この例では quay-enterprise
です)。
$ oc create -n quay-enterprise -f quay-config-bundle.yaml
spec.configBundleSecret
フィールドのシークレットを指定します。
quay-registry.yaml
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: quay-config-bundle
指定された設定でレジストリーを作成します。
$ oc create -n quay-enterprise -f quay-registry.yaml
5.5. ボリュームサイズのオーバーライド
マネージドコンポーネントにプロビジョニングされるストレージリソースの希望のサイズを指定できます。Clair および Quay PostgreSQL データベースのデフォルトサイズは 50Gi
です。パフォーマンス上の理由がある場合や、ストレージバックエンドにサイズ変更機能がない場合など、十分な容量を事前に選択できるようになりました。
以下の例では、Clair および Quay PostgreSQL データベースのボリュームサイズは 70Gi
に設定されています。
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: quay-example namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: objectstorage managed: false - kind: route managed: true - kind: tls managed: false - kind: clair managed: true overrides: volumeSize: 70Gi - kind: postgres managed: true overrides: volumeSize: 70Gi - kind: clairpostgres managed: true
clairpostgres
コンポーネントのボリュームサイズはオーバーライドできません。これは既知の問題であり、Red Hat Quay の将来のバージョンで修正される予定です。(PROJQUAY-4301)
第6章 Red Hat Quay の Clair
Clair v4 (Clair) は、静的コード分析を活用してイメージコンテンツを解析し、コンテンツに影響を与える脆弱性を報告するオープンソースアプリケーションです。Clair は Red Hat Quay にパッケージ化されており、スタンドアロンと Operator デプロイメントの両方で使用できます。エンタープライズ環境に合わせてコンポーネントを個別にスケーリングできる、非常にスケーラブルな設定で実行できます。
6.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 つはマッチング機能を実行します。
Go 標準ライブラリーが尊重する環境変数は、必要に応じて指定できます。次に例を示します。
-
HTTP_PROXY
-
HTTPS_PROXY
-
SSL_CERT_DIR
Clair を combo
モードで実行している場合は、設定でインデクサー、マッチャー、通知設定ブロックを指定する必要があります。
6.1.1. Clair 設定リファレンス
次の YAML は、Clair 設定の例を示しています。
http_listen_addr: "" introspection_addr: "" log_level: "" tls: {} indexer: connstring: "" scanlock_retry: 0 layer_scan_concurrency: 0 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 ファイルには、完全を期すためにすべてのキーがリストされています。この設定ファイルをそのまま使用すると、一部のオプションがデフォルトで正常に設定されない場合があります。
6.1.2. 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 証明書。フルチェーン証明書である必要があります。 |
6.1.3. Clair インデクサー設定フィールド
Clair では、次のインデクサー設定フィールドを使用できます。
フィールド | タイプ | 説明 |
---|---|---|
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 を持つマップ。 |
6.1.4. Clair マッチャー設定フィールド
Clair では、次のマッチャー設定フィールドを使用できます。
matchers
設定フィールドとは異なります。
フィールド | タイプ | 説明 |
---|---|---|
matcher | Object | Clair マッチャーノード設定を提供します。 |
.cache_age | String | レスポンスをキャッシュするように、ユーザーに通知する期間を制御します。 |
.connstring | String | Postgres 接続文字列。URL または libpq 接続文字列として形式を受け入れます。 |
.max_conn_pool | Integer | データベース接続プールのサイズを制限します。 Clair では、カスタムの接続プールサイズを使用できます。この数は、同時に許可されるアクティブなデータベース接続の数を直接設定します。 このパラメーターは、将来のバージョンでは無視されます。ユーザーは、接続文字列を使用して、これを設定する必要があります。 |
.indexer_addr | String |
マッチャーはインデクサーに接続して
デフォルトは |
.migrations | Boolean | マッチャーノードがデータベースへの移行を処理するかどうか。 |
.period | String | 新しいセキュリティーアドバイザリーの更新頻度を決定します。
デフォルトは |
.disable_updaters | Boolean | バックグラウンド更新を実行するかどうか。 |
.update_retention | Integer | ガベージコレクションサイクル間で保持する更新操作の数を設定します。これは、データベースサイズの制約に基づいて安全な MAX 値に設定する必要があります。
デフォルトは
|
6.1.5. Clair マッチャー設定フィールド
Clair では、次のマッチャー設定フィールドを使用できます。
matcher
設定フィールドとは異なります。
フィールド | タイプ | 説明 |
---|---|---|
matchers | 文字列の配列。 |
in-tree |
.names | String |
有効なマッチャーについてマッチャーファクトリーに通知する文字列値のリスト。値が |
.config | String | 特定のマッチャーに設定を提供します。 マッチャーファクトリーコンストラクターに提供されるサブオブジェクトを含むマッチャーの名前をキーとするマップ。以下に例を示します。 config: python: ignore_vulns: - CVE-XYZ - CVE-ABC |
6.1.6. Clair アップデーター設定フィールド
Clair では、次のアップデーター設定フィールドを使用できます。
フィールド | タイプ | 説明 |
---|---|---|
updaters | Object | マッチャーの更新マネージャーの設定を提供します。 |
.sets | String | どのアップデーターを実行するかを更新マネージャーに通知する値のリスト。
値が 空白のままにすると、更新プログラムは実行されません。 |
.config | String | 特定のアップデーターセットに設定を提供します。 アップデーターセットのコンストラクターに提供されるサブオブジェクトを含むアップデーターセットの名前をキーとするマップ。以下に例を示します。 config: ubuntu: security_tracker_url: http://security.url ignore_distributions: - cosmic |
6.1.7. Clair ノーティファイアー設定フィールド
Clair では、次のノーティファイアー設定フィールドを使用できます。
フィールド | タイプ | 説明 |
---|---|---|
notifier | Object | Clair ノーティファイアーノード設定を提供します。 |
.connstring | String | Postgres 接続文字列。形式を URL または libpq 接続文字列として受け入れます。 |
.migrations | Boolean | ノーティファイアーノードがデータベースへの移行を処理するかどうか。 |
.indexer_addr | String | ノーティファイアーはインデクサーに連絡して、脆弱性の影響を受けるマニフェストを作成または取得します。このインデクサーの場所は必須です。 |
.matcher_addr | String | ノーティファイアーはマッチャーに連絡して、更新操作をリストし、差分を取得します。このマッチャーの場所は必須です。 |
.poll_interval | String | ノーティファイアーがマッチャーに更新操作をクエリーする頻度。 |
.delivery_interval | String | ノーティファイアーが、作成された通知または以前に失敗した通知の配信を試行する頻度。 |
.disable_summary | Boolean | 通知をマニフェストごとに 1 つに要約するかどうかを制御します。 |
.webhook | Object | Webhook 配信のノーティファイアーを設定します。 |
.webhook.target | String | Webhook が配信される URL。 |
.webhook.callback | String | 通知を取得できるコールバック URL。この URL に通知 ID が追加されます。 これは通常、Clair ノーティファイアーがホスティングされている場所です。 |
.webhook.headers | String | ヘッダー名を値のリストに関連付けるマップ。 |
.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 秘密鍵を読み取ることができるファイルシステムパス。 |
.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 パスコード。 |
6.1.8. Clair 承認設定フィールド
Clair では、次の承認設定フィールドを使用できます。
フィールド | タイプ | 説明 |
---|---|---|
auth | Object |
Clair の外部およびサービス内 JWT ベースの認証を定義します。複数の |
.psk | String | 事前共有キー認証を定義します。 |
.psk.key | String | JWT の署名と検証を行うすべての当事者間で配布される、base64 でエンコードされた共有キー。 |
.psk.iss | String | 確認する JWT 発行者のリスト。空のリストは、JWT クレームで任意の発行者を受け入れます。 |
6.1.9. 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 バックエンドに送信される前にメモリーにバッファーできるスパンの最大数。 |
6.1.10. Clair メトリック設定フィールド
Clair では、次のメトリック設定フィールドを使用できます。
フィールド | タイプ | 説明 |
---|---|---|
metrics | Object | OpenTelemetry に基づいて分散トレース設定を定義します。 |
.name | String | 使用中のメトリックの名前。 |
.prometheus | String | Prometheus メトリックエクスポーターの設定。 |
.prometheus.endpoint | String | メトリックが提供されるパスを定義します。 |
第7章 コンテナーセキュリティー Operator での Pod イメージのスキャン
Container Security Operator (CSO) は、OpenShift Container Platform およびその他の Kubernetes プラットフォームで利用可能な Clair セキュリティースキャナーのアドオンです。CSO を使用すると、ユーザーはアクティブな Pod に関連付けられているコンテナーイメージをスキャンして、既知の脆弱性を見つけることができます。
CSO は、Red Hat Quay と Clair なしでは機能しません。
Container Security Operator (CSO) は、次の機能を実行します。
- 指定された namespace またはすべての namespace の Pod に関連付けられたコンテナーを監視します。
- コンテナーのソースであるコンテナーレジストリーにクエリーを実行して、脆弱性情報を取得します (イメージのレジストリーが、Clair スキャンを使用する Red Hat Quay レジストリーなどのイメージスキャンをサポートしている場合)。
-
Kubernetes API の
ImageManifestVuln
オブジェクトを使用して脆弱性を公開します。
CSO を Kubernetes にインストールする手順を見るには、Container Security OperatorHub.io のページから Install ボタンを選択します。
7.1. OpenShift Container Platform での Container Security Operator のダウンロードおよび実行
Container Security Operator (CSO) をダウンロードするには、次の手順を使用します。
次の手順では、CSO を marketplace-operators
namespace にインストールします。これにより、OpenShift Container Platform クラスターのすべての namespace で CSO を使用できるようになります。
手順
- OpenShift Container Platform コンソールページで、Operators → OperatorHub を選択し、Container Security Operator を検索します。
- Container Security Operator を選択し、Install を選択して Create Operator Subscription ページに移動します。
- 設定 (デフォルトでは、すべての名前空間と自動承認戦略) を確認し、Subcription を選択します。しばらくすると、Installed Operators 画面に Container Security が表示されます。
オプション: カスタム証明書を CSO に追加できます。以下の例では、現在のディレクトリーに
quay.crt
という名前の証明書を作成します。次に、次のコマンドを実行して証明書を CSO に追加します。$ oc create secret generic container-security-operator-extra-certs --from-file=quay.crt -n openshift-operators
注記新しい証明書を有効にするには、Operator Pod を再起動する必要があります。
Home → Dashboard に移動します。Image Security へのリンクが status セクションに表示され、これまでに見つかった脆弱性の数の一覧が表示されます。次の図に示すように、リンクを選択するとセキュリティーの内訳が表示されます。
重要Container Security Operator は現在、Red Hat セキュリティーアドバイザリーの壊れたリンクを提供しています。たとえば、リンク
https://access.redhat.com/errata/RHSA-2023:1842%20https://access.redhat.com/security/cve/CVE-2023-23916
が提供される場合があります。URL 内の%20
はスペース文字を表しますが、現時点では 2 つの URL が 1 つの不完全な URL に結合されます (例:https://access.redhat.com/errata/RHSA-2023:1842
とhttps://access.redhat.com/security/cve/CVE-2023-23916
。一時的な回避策として、各 URL をブラウザーにコピーして、適切なページに移動できます。これは既知の問題であり、Red Hat Quay の今後のバージョンで修正される予定です。この時点で、検出された脆弱性をフォローするために以下の 2 つのいずれかの操作を実行できます。
脆弱性へのリンクを選択します。コンテナーのレジストリー、Red Hat Quay、またはコンテナーを取得したその他のレジストリーに移動し、脆弱性に関する情報が表示されます。以下の図は、Quay.io レジストリーから検出された脆弱性の例を示しています。
namespaces リンクを選択し、ImageManifestVuln 画面に移動します。ここでは、選択されたイメージの名前、およびイメージが実行されているすべての namespace を確認できます。以下の図は、特定の脆弱なイメージが 2 つの namespace で実行されていることを示しています。
この手順を実行すると、どのイメージに脆弱性があるか、それらの脆弱性を修正するために何をしなければならないか、およびイメージが実行されたすべての名前空間がわかります。これを知っていると、次のアクションを実行できます。
- イメージを実行しているユーザーに、脆弱性を修正する必要があることを警告します。
デプロイメント、またはイメージが含まれる Pod を開始したオブジェクトを削除して、イメージの実行を停止します。
注記Pod を削除した場合、ダッシュボードで脆弱性がリセットされるまでに数分かかる場合があります。
7.2. CLI からイメージの脆弱性を問い合わせ
コマンドラインからセキュリティーに関する情報を照会することができます。検出された脆弱性を照会するには、次のように入力します。
$ oc get vuln --all-namespaces NAMESPACE NAME AGE default sha256.ca90... 6m56s skynet sha256.ca90... 9m37s
特定の脆弱性の詳細を表示するには、脆弱性の 1 つを特定し、その namespace および describe
オプションを指定します。以下の例は、イメージに脆弱性のある RPM パッケージが含まれるアクティブなコンテナーを示しています。
$ oc describe vuln --namespace mynamespace sha256.ac50e3752... Name: sha256.ac50e3752... Namespace: quay-enterprise ... Spec: Features: Name: nss-util Namespace Name: centos:7 Version: 3.44.0-3.el7 Versionformat: rpm Vulnerabilities: Description: Network Security Services (NSS) is a set of libraries...