Red Hat Quay の設定
第1章 Red Hat Quay 設定の開始
Red Hat Quay は、セルフマネージドインストールとして、または OpenShift Container Platform Operator の Red Hat Quay でデプロイできるセキュアなアーティファクトレジストリーです。デプロイメントタイプによって設定や管理には異なるアプローチがありますが、それぞれは同じ設定パラメーターセットに依存してレジストリーの動作を制御します。一般的な設定パラメーターを使用すると、管理者はレジストリーがユーザー、ストレージバックエンド、認証プロバイダー、セキュリティーポリシー、およびその他の統合サービスと対話する方法を定義できます。
デプロイメントタイプに応じて Red Hat Quay を設定するには、次の 2 つの方法があります。
-
事前に Red Hat Quay の場合:Red Hat Quay の前に、レジストリー管理者は、必要なすべてのパラメーターを含む
config.yaml
ファイルを提供します。このデプロイメントタイプでは、有効な設定がないとレジストリーを起動することができません。 -
Red Hat Quay Operator: デフォルトでは、Red Hat Quay Operator は、最低限必要な値を生成し、必要なコンポーネントをデプロイして Red Hat Quay デプロイメントを自動的に設定します。初回のデプロイメント後に、
QuayRegistry
カスタムリソースを変更するか、OpenShift Container Platform Web コンソール を使用してレジストリーの動作をカスタマイズできます。
本ガイドでは、以下の設定の概念の概要を説明します。
- prem および Operator ベースの Red Hat Quay デプロイメントタイプの両方に対して現在の設定を取得、検査、および変更する方法。
- 起動に最低限必要な設定フィールド。
- 利用可能なすべての Red Hat Quay 設定フィールドと、これらのフィールドの YAML サンプルの概要。
第2章 Red Hat Quay 設定の免責事項
一部の機能と設定パラメーターは、Red Hat Quay のスタンドアロンデプロイメントでも Operator ベースのデプロイメントでも、積極的には使用または実装されていません。そのため、特定の機能を有効または無効にするフラグや、Red Hat サポートのドキュメントが明示的に文書化またはサポートされていない設定パラメーターなど、一部の機能フラグは注意して変更する必要があります。
未使用または文書化されていない機能は、Red Hat Quay と完全にテスト、サポートされていない、または互換性がない可能性があります。これらの設定を変更すると、予期しない動作が発生したり、デプロイメントが中断される可能性があります。
第3章 Red Hat Quay 設定ファイルについて
Red Hat Quay on OpenShift Container Platform Operator によってデプロイされたオンプレミスに関わらず、レジストリーの動作は config.yaml
ファイルによって定義されます。レジストリーを起動するには、config.yaml
ファイルに必要なすべての設定フィールドを含める必要があります。Red Hat Quay 管理者は、認証パラメーター、ストレージパラメーター、プロキシーキャッシュパラメーターなどのレジストリーをカスタマイズするオプションのパラメーターを定義することもできます。
config.yaml
ファイルは有効な YAML (YAML Ain't Markup Language)構文を使用して記述する必要があります。また、ファイル自体にフォーマットエラーが含まれる場合、または必須フィールドがない場合は Red Hat Quay を起動できません。デプロイメントタイプに関係なく、Operator によって設定されている OpenShift Container Platform 上のオンプレミスまたは Red Hat Quay であるかに関係なく、YAML の原則は、必要な設定フィールドが若干異なる場合でも同じままになります。
次のセクションでは、Red Hat Quay config.yaml
ファイルの作成および編集に関連する基本的な YAML 構文の概要を説明します。YAML の詳細な概要は、What is YAML を参照してください。
3.1. キーと値のペア。
config.yaml
ファイル内の設定フィールドは、以下の形式でキーと値のペアとして記述されます。
# ... EXAMPLE_FIELD_NAME: <value> # ...
# ...
EXAMPLE_FIELD_NAME: <value>
# ...
config.yaml
ファイル内の各行には、フィールド名、次にコロン、スペース、キーと一致する適切な値が含まれます。以下の例は、AUTHENTICATION_TYPE
設定フィールドを config.yaml
ファイルでフォーマットする必要がある方法を示しています。
AUTHENTICATION_TYPE: Database # ...
AUTHENTICATION_TYPE: Database
# ...
- 1
- クレデンシャル認証に使用する認証エンジン。
上記の例では、AUTHENTICATION_TYPE
が Database
に設定されていますが、デプロイメントタイプごとに異なる値が必要になります。以下の例は、LDAP
または Lightweight Directory Access Protocol が認証に使用される場合に config.yaml
ファイルがどのようになるかを示しています。
AUTHENTICATION_TYPE: LDAP # ...
AUTHENTICATION_TYPE: LDAP
# ...
3.2. インデントとネスト
多くの Red Hat Quay 設定フィールドでは、ネストされた構造を示すためにインデントが必要です。インデントは、空白またはリテラル 空白 文字を使用して行う必要があります。タブ文字は、設計的には使用できません。インデントは、ファイル全体で一貫している必要があります。以下の YAML スニペットは、BUILDLOGS_REDIS
フィールドが必要な ホスト
、パスワード、
および ポート
フィールドにインデントを使用する方法を示しています。
# ... BUILDLOGS_REDIS: host: quay-server.example.com password: example-password port: 6379 # ...
# ...
BUILDLOGS_REDIS:
host: quay-server.example.com
password: example-password
port: 6379
# ...
3.3. リスト
場合によっては、Red Hat Quay 設定フィールドはリストに依存して特定の値を定義します。リストは、ハイフン(-
)とそれに続くスペースを使用してフォーマットされます。次の例は、SUPER_USERS
設定フィールドがリストを使用してスーパーユーザーを定義する方法を示しています。
# ... SUPER_USERS: - quayadmin # ...
# ...
SUPER_USERS:
- quayadmin
# ...
3.4. 引用符で囲まれた値
一部の Red Hat Quay 設定フィールドでは、変数を適切に定義するために引用符(""
)を使用する必要があります。通常、これは必須ではありません。次の例は、FOOTER_LINKS
設定フィールドで引用符を使用して TERMS_OF_SERVICE_URL
、PRIVACY_POLICY_URL
、SECURITY_URL
、および ABOUT_URL
を定義する方法を示しています。
FOOTER_LINKS: "TERMS_OF_SERVICE_URL": "https://www.index.hr" "PRIVACY_POLICY_URL": "https://www.jutarnji.hr" "SECURITY_URL": "https://www.bug.hr" "ABOUT_URL": "https://www.zagreb.hr"
FOOTER_LINKS:
"TERMS_OF_SERVICE_URL": "https://www.index.hr"
"PRIVACY_POLICY_URL": "https://www.jutarnji.hr"
"SECURITY_URL": "https://www.bug.hr"
"ABOUT_URL": "https://www.zagreb.hr"
3.5. コメント
ハッシュ記号または #
は、コメントを追加したり、設定フィールドを一時的に無効にするために行頭に配置できます。これらは設定パーサーで無視され、レジストリーの動作には影響しません。以下に例を示します。
# ... # FEATURE_UI_V2: true # ...
# ...
# FEATURE_UI_V2: true
# ...
この例では、FEATURE_UI_V2
設定がパーサーによって無視され、v2 UI を使用するオプションが無効になります。必要な設定フィールドに #
記号を使用すると、レジストリーが起動しなくなります。
第4章 事前に設定されている Red Hat Quay 設定の概要
Red Hat Quay のオンプレミスデプロイメントの場合、管理者が管理する config.yaml
ファイルは起動時にコンテナーにマウントされ、初期化中に Red Hat Quay によって読み取られます。config.yaml
ファイルは動的にリロードされません。つまり、ファイルに変更を加えるには、レジストリーコンテナーを再起動する必要があります。
本章では、以下の概念の概要を説明します。
- 最低限必要な設定フィールド。
- デプロイメント後に設定を編集および管理する方法。
このセクションは、特にオンプレミスの Red Hat Quay デプロイメントタイプに適用されます。OpenShift Container Platform での Red Hat Quay の設定は、Red Hat Quay on OpenShift Container Platform 設定の概要 を参照してください。
4.1. 必須の設定フィールド
Red Hat Quay のオンプレミスデプロイメントには、以下の設定フィールドが必要です。
フィールド | 型 | 説明 |
AUTHENTICATION_TYPE | String |
認証情報の認証に使用する認証エンジン。 |
BUILDLOGS_REDIS | Object | ビルドログキャッシュ用の Redis 接続の詳細。 |
.host | String | Redis にアクセスできるホスト名。 |
.password | String | Redis インスタンスに接続するためのパスワード。 |
DATABASE_SECRET_KEY | String |
データベース内で機密フィールドを暗号化するのに使用されるキー。この値は、一度設定したら変更しないでください。変更すると、リポジトリーのミラーユーザー名やパスワード設定など、すべての信頼できるフィールドが無効になります。 |
DB_URI | String | 認証情報を含む、データベースにアクセスするための URI。 |
DISTRIBUTED_STORAGE_CONFIG | Object |
Red Hat Quay で使用するストレージエンジンの設定。各キーは、ストレージエンジンの一意の ID を表します。この値は、ストレージエンジンパラメーターを記述するオブジェクトのタプル (キー、値) で構成されます。 |
SECRET_KEY | String | ユーザーセッションを正しく解釈するために必要なセッション Cookie と CSRF トークンを暗号化するために使用されるキー。設定時に値を変更しないでください。すべての Red Hat Quay インスタンスで永続的である必要があります。すべてのインスタンスで永続的でない場合、ログインの失敗やセッションの永続性に関連するその他のエラーが発生する可能性があります。 |
SERVER_HOSTNAME | String | スキームなしで Red Hat Quay にアクセスできる URL。 |
SETUP_COMPLETE | Boolean |
これは、以前のバージョンのソフトウェアからそのまま残っているアーティファクトです。現時点では値を |
USER_EVENTS_REDIS | Object | ユーザーイベント処理の Redis 接続の詳細。 |
.host | String | Redis にアクセスできるホスト名。 |
.port | 数値 | Redis にアクセスできるポート。 |
.password | String | Redis インスタンスに接続するためのパスワード。 |
4.1.1. 最小設定ファイルの例
このセクションでは、最小設定ファイルの例を 2 つ示します。1 つはローカルストレージを使用する例で、もう 1 つは Google Cloud Platform でクラウドベースのストレージを使用する別の例です。
4.1.1.1. ローカルストレージを使用した最小設定
次の例は、イメージにローカルストレージを使用する最小限の設定ファイルの例を示しています。
概念実証のためにレジストリーをデプロイする場合は、ローカルストレージのみを使用してください。これは実稼働環境での使用を目的としていません。ローカルストレージを使用する場合は、レジストリーの起動時に、レジストリーをコンテナー内の datastorage
パスにマップする必要があります。詳細は、概念実証 - Red Hat Quay のデプロイ を参照してください。
ローカルストレージの最小設定
AUTHENTICATION_TYPE: Database BUILDLOGS_REDIS: host: <quay-server.example.com> password: <password> port: <port> DATABASE_SECRET_KEY: <example_database_secret_key> DB_URI: postgresql://<username>:<password>@<registry_url>.com:<port>/quay DISTRIBUTED_STORAGE_CONFIG: default: - LocalStorage - storage_path: /datastorage/registry SECRET_KEY: <example_secret_key> SERVER_HOSTNAME: <server_host_name> SETUP_COMPLETE: true USER_EVENTS_REDIS: host: <redis_events_url> password: <password> port: <port>
AUTHENTICATION_TYPE: Database
BUILDLOGS_REDIS:
host: <quay-server.example.com>
password: <password>
port: <port>
DATABASE_SECRET_KEY: <example_database_secret_key>
DB_URI: postgresql://<username>:<password>@<registry_url>.com:<port>/quay
DISTRIBUTED_STORAGE_CONFIG:
default:
- LocalStorage
- storage_path: /datastorage/registry
SECRET_KEY: <example_secret_key>
SERVER_HOSTNAME: <server_host_name>
SETUP_COMPLETE: true
USER_EVENTS_REDIS:
host: <redis_events_url>
password: <password>
port: <port>
4.1.1.2. クラウドベースのストレージを使用した最小設定
ほとんどの実稼働環境では、Red Hat Quay 管理者は、サポートされるベンダーが提供するクラウドまたはエンタープライズレベルのストレージバックエンドを使用します。次の例は、イメージストレージに Google Cloud Platform を使用するように Red Hat Quay を設定する方法を示しています。サポート対象のストレージプロバイダーの完全なリストは、イメージストレージ を参照 し てください。
クラウドまたはエンタープライズレベルのストレージバックエンドを使用する場合、レジストリーをローカルディレクトリーにマッピングするなどの追加設定は必要ありません。
クラウドストレージの最小設定
AUTHENTICATION_TYPE: Database BUILDLOGS_REDIS: host: <quay-server.example.com> password: <password> port: <port> DATABASE_SECRET_KEY: <example_database_secret_key> DB_URI: postgresql://<username>:<password>@<registry_url>.com:<port>/quay DISTRIBUTED_STORAGE_CONFIG: default: - GoogleCloudStorage - access_key: <access_key> bucket_name: <bucket_name> secret_key: <secret_key> storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default SECRET_KEY: <example_secret_key> SERVER_HOSTNAME: <server_host_name> SETUP_COMPLETE: true USER_EVENTS_REDIS: host: <redis_events_url> password: <password> port: <port>
AUTHENTICATION_TYPE: Database
BUILDLOGS_REDIS:
host: <quay-server.example.com>
password: <password>
port: <port>
DATABASE_SECRET_KEY: <example_database_secret_key>
DB_URI: postgresql://<username>:<password>@<registry_url>.com:<port>/quay
DISTRIBUTED_STORAGE_CONFIG:
default:
- GoogleCloudStorage
- access_key: <access_key>
bucket_name: <bucket_name>
secret_key: <secret_key>
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- default
SECRET_KEY: <example_secret_key>
SERVER_HOSTNAME: <server_host_name>
SETUP_COMPLETE: true
USER_EVENTS_REDIS:
host: <redis_events_url>
password: <password>
port: <port>
4.2. デプロイメント後の設定ファイルの変更
初期 config.yaml
ファイルを使用して Red Hat Quay レジストリーをデプロイした後、Red Hat Quay 管理者は設定ファイルを更新して、必要に応じて機能を有効または無効にすることができます。このような柔軟性により、管理者はレジストリーを調整して、特定の環境のニーズに合わせてしたり、特定のセキュリティーポリシーを満たしたりできます。
config.yaml
ファイルは動的に再読み込みされないため、Red Hat Quay コンテナーを再起動してから再起動する必要があります。
以下の手順では、quay-registry
コンテナーから config.yaml
ファイルを取得する方法、その機能の設定フィールドをファイルに追加することで新機能を有効にする方法、Podman を使用して quay-registry
コンテナーを再起動する方法を紹介します。
前提条件
- Red Hat Quay をデプロイしている。
- レジストリーの管理者である。
手順
config.yaml
ファイルにアクセスできる場合:config.yaml
ファイルを保存するディレクトリーに移動します。以下に例を示します。cd /home/<username>/<quay-deployment-directory>/config
$ cd /home/<username>/<quay-deployment-directory>/config
Copy to Clipboard Copied! 新しい機能フラグを追加して
config.yaml
ファイルに変更を加えます。以下の例では、v2 UI を有効にします。# ... FEATURE_UI_V2: true # ...
# ... FEATURE_UI_V2: true # ...
Copy to Clipboard Copied! -
config.yaml
ファイルへの変更を保存します。 次のコマンドを入力して、
quay-registry
Pod を再起動します。podman restart <container_id>
$ podman restart <container_id>
Copy to Clipboard Copied!
config.yaml
ファイルへのアクセスがなく、同じ認証情報を維持しながら新規ファイルを作成する必要がある場合:次のコマンドを入力して、
quay-registry
Pod のコンテナー ID を取得します。podman ps
$ podman ps
Copy to Clipboard Copied! 出力例
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5f2297ef53ff registry.redhat.io/rhel8/postgresql-13:1-109 run-postgresql 20 hours ago Up 20 hours 0.0.0.0:5432->5432/tcp postgresql-quay 3b40fb83bead registry.redhat.io/rhel8/redis-5:1 run-redis 20 hours ago Up 20 hours 0.0.0.0:6379->6379/tcp redis 0b4b8fbfca6d registry-proxy.engineering.redhat.com/rh-osbs/quay-quay-rhel8:v3.14.0-14 registry 20 hours ago Up 20 hours 0.0.0.0:80->8080/tcp, 0.0.0.0:443->8443/tcp, 7443/tcp, 9091/tcp, 55443/tcp quay
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5f2297ef53ff registry.redhat.io/rhel8/postgresql-13:1-109 run-postgresql 20 hours ago Up 20 hours 0.0.0.0:5432->5432/tcp postgresql-quay 3b40fb83bead registry.redhat.io/rhel8/redis-5:1 run-redis 20 hours ago Up 20 hours 0.0.0.0:6379->6379/tcp redis 0b4b8fbfca6d registry-proxy.engineering.redhat.com/rh-osbs/quay-quay-rhel8:v3.14.0-14 registry 20 hours ago Up 20 hours 0.0.0.0:80->8080/tcp, 0.0.0.0:443->8443/tcp, 7443/tcp, 9091/tcp, 55443/tcp quay
Copy to Clipboard Copied! 次のコマンドを入力して、
config.yaml
ファイルをquay-registry
Pod からディレクトリーにコピーします。podman cp <container_id>:/quay-registry/conf/stack/config.yaml ./config.yaml
$ podman cp <container_id>:/quay-registry/conf/stack/config.yaml ./config.yaml
Copy to Clipboard Copied! 新しい機能フラグを追加して
config.yaml
ファイルに変更を加えます。以下の例では、AUTHENTICATION_TYPE
をLDAP
に設定します。# ... AUTHENTICATION_TYPE: LDAP # ...
# ... AUTHENTICATION_TYPE: LDAP # ...
Copy to Clipboard Copied! 次のコマンドを入力して、レジストリーを再デプロイし、
config.yaml
ファイルをquay-registry
設定ボリュームにマウントします。sudo podman run -d --rm -p 80:8080 -p 443:8443 \ --name=quay \ -v /home/<username>/<quay-deployment-directory>/config:/conf/stack:Z \ registry.redhat.io/quay/quay-rhel8:v3.14.0
$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \ --name=quay \ -v /home/<username>/<quay-deployment-directory>/config:/conf/stack:Z \ registry.redhat.io/quay/quay-rhel8:v3.14.0
Copy to Clipboard Copied!
4.3. 設定のトラブルシューティング
すべての必要な設定フィールドを追加したり、一部のパラメーターに適切な情報を提供したりしないと、quay-registry
コンテナーのデプロイに失敗する場合があります。以下の手順に従って、失敗したオンプレミスのデプロイメントタイプを表示し、トラブルシューティングします。
前提条件
- 最小限の設定ファイルを作成している。
手順
次のコマンドを入力して、
quay-registry
コンテナーのデプロイを試みます。このコマンドは、デバッグ情報を表示する-it
を使用することに注意してください。podman run -it --rm -p 80:8080 -p 443:8443 --name=quay -v /home/<username>/<quay-deployment-directory>/config:/conf/stack:Z -v /home/<username>/<quay-deployment-directory>/storage:/datastorage:Z 33f1c3dc86be
$ podman run -it --rm -p 80:8080 -p 443:8443 --name=quay -v /home/<username>/<quay-deployment-directory>/config:/conf/stack:Z -v /home/<username>/<quay-deployment-directory>/storage:/datastorage:Z 33f1c3dc86be
Copy to Clipboard Copied! 出力例
--- +------------------------+-------+--------+ | LDAP | - | X | +------------------------+-------+--------+ | LDAP_ADMIN_DN is required | X | +-----------------------------------------+ | LDAP_ADMIN_PSSWD is required | X | +-----------------------------------------+ | . . . Connection refused | X | +-----------------------------------------+ ---
--- +------------------------+-------+--------+ | LDAP | - | X | +------------------------+-------+--------+ | LDAP_ADMIN_DN is required | X | +-----------------------------------------+ | LDAP_ADMIN_PSSWD is required | X | +-----------------------------------------+ | . . . Connection refused | X | +-----------------------------------------+ ---
Copy to Clipboard Copied! この例では、
quay-registry
コンテナーは不適切な LDAP 認証情報が指定されたためにデプロイできませんでした。
第5章 OpenShift Container Platform 上の Red Hat Quay 設定の概要
Operator を使用して Red Hat Quay を OpenShift Container Platform にデプロイする場合、設定は QuayRegistry
カスタムリソース(CR)を使用して宣言的に管理されます。このモデルを使用すると、クラスター管理者は、有効なコンポーネント、ストレージバックエンド、SSL/TLS 設定、他のコア機能など、必要な Red Hat Quay デプロイメントの必要な状態を定義できます。
Operator を使用して OpenShift Container Platform に Red Hat Quay をデプロイした後に、管理者は config.yaml
ファイルを更新し、Kubernetes シークレットで参照することで、レジストリーをさらにカスタマイズできます。この設定バンドルは、configBundleSecret
フィールドを使用して QuayRegistry
CR にリンクされます。
Operator は、QuayRegistry
CR およびその関連設定で定義される状態を調整し、必要に応じてレジストリーコンポーネントを自動的にデプロイまたは更新します。
このガイドでは、QuayRegistry
CR の背後にある基本的な概念と、OpenShift Container Platform デプロイメントの Red Hat Quay での config.yaml
ファイルの変更について説明します。QuayRegistry
CR 内で管理対象外コンポーネントを使用するなどの高度なトピックは、Red Hat Quay Operator の OpenShift Container Platform へのデプロイ を参照してください。
5.1. QuayRegistry CR について
デフォルトでは、QuayRegistry
CR には以下のキーフィールドが含まれます。
-
configBundleSecret
: 追加の設定パラメーターを定義するconfig.yaml
ファイルを含む Kubernetes シークレットの名前。 -
Name
: Red Hat Quay レジストリーの名前。 -
namespace
: レジストリーが作成された namespace またはプロジェクト。 spec.components
: Operator が自動的に管理するコンポーネントの一覧。それぞれのspec.component
フィールドには 2 つのフィールドが含まれます。-
Name
: コンポーネントの名前。 -
Managed
: コンポーネントのライフサイクルが Red Hat Quay Operator によって処理されるかどうかに対応するブール値。managed: true
をQuayRegistry
CR のコンポーネントに設定すると、Operator がコンポーネントを管理します。
-
すべての QuayRegistry
コンポーネントは、特に指定されていない限り、調整時に自動的に管理され、自動入力されます。以下のセクションでは、主要な QuayRegistry
コンポーネントを説明し、デフォルト設定を示す YAML ファイルのサンプルを提供します。
5.2. 管理対象コンポーネント
デフォルトで、Operator は Red Hat Quay の管理コンポーネントに必要なすべての必要な設定およびインストールを処理します。
Red Hat Quay Operator が実行するデプロイが環境に適さない場合は、Red Hat Quay Operator に unmanaged
リソース (オーバーライド) を指定できます。これは、次のセクションで説明します。
フィールド | 型 | 説明 |
---|---|---|
| Boolean |
環境変数やレプリカの数など、OpenShift Container Platform で Red Hat Quay のデプロイメントのオーバーライドを保持します。このコンポーネントは、管理対象外( |
| Boolean | レジストリーメタデータの保存に使用されます。現在、PostgreSQL バージョン 13 が使用されています。 |
| Boolean | clair: イメージの脆弱性スキャンを提供します。 |
| Boolean | ストレージライブビルダーログ、およびガベージコレクションに必要なロックメカニズム。 |
| Boolean |
メモリーおよび CPU の消費に応じて |
ObjectStorage | Boolean |
イメージレイヤー Blob を格納します。 |
| Boolean | route: OpenShift Container Platform の外部から Red Hat Quay レジストリーへの外部エントリーポイントを提供します。 |
| Boolean | mirror: オプションのリポジトリーミラーリングをサポートするようにリポジトリーミラーワーカーを設定します。 |
| Boolean |
|
| Boolean | SSL/TLS を自動的に処理するかどうかを設定します。 |
| Boolean | マネージド Clair データベースを設定します。これは、Red Hat Quay のデプロイに使用される PostgreSQL データベースとは別のデータベースです。 |
次の例は、Red Hat Quay Operator が提供する QuayRegistry
カスタムリソースのデフォルト設定を示しています。これは OpenShift Container Platform Web コンソールで利用できます。
QuayRegistry
カスタムリソースの例
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: <example_registry> namespace: <namespace> spec: configBundleSecret: config-bundle-secret components: - kind: quay managed: true - kind: postgres managed: true - kind: clair managed: true - kind: redis managed: true - kind: horizontalpodautoscaler managed: true - kind: objectstorage managed: true - kind: route managed: true - kind: mirror managed: true - kind: monitoring managed: true - kind: tls managed: true - kind: clairpostgres managed: true
apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
name: <example_registry>
namespace: <namespace>
spec:
configBundleSecret: config-bundle-secret
components:
- kind: quay
managed: true
- kind: postgres
managed: true
- kind: clair
managed: true
- kind: redis
managed: true
- kind: horizontalpodautoscaler
managed: true
- kind: objectstorage
managed: true
- kind: route
managed: true
- kind: mirror
managed: true
- kind: monitoring
managed: true
- kind: tls
managed: true
- kind: clairpostgres
managed: true
5.3. デプロイメント後の QuayRegistry CR の変更
Red Hat Quay Operator をインストールして初期デプロイメントを作成した後、QuayRegistry
カスタムリソース(CR)を変更して Red Hat Quay 環境の要素をカスタマイズまたは再設定できます。
Red Hat Quay 管理者は、次の理由により QuayRegistry CR を変更する場合があります。
-
独自のインフラストラクチャーを使用 するには、コンポーネント管理: コンポーネントを
managed: true
からmanaged: false
に切り替えます。たとえば、kind: objectstorage
を unmanaged に設定して、Google Cloud Storage や Nutanix などの外部オブジェクトストレージプラットフォームを統合することができます。 -
カスタム設定を適用する:
configBundleSecret
を更新または置き換えて、認証プロバイダー、外部の SSL/TLS 設定、機能フラグなどの新しい設定を適用します。 -
機能を有効または無効 にする:
spec.components
リストを変更して、リポジトリーのミラーリング、Clair スキャン、水平 Pod 自動スケーリングなどの機能を切り替えます。 - デプロイメントをスケーリングするに は、Quay アプリケーションの環境変数またはレプリカ数を調整します。
- 外部サービスと統合する:外部 PostgreSQL、Redis、または Clair データベースの設定を提供し、エンドポイントまたは認証情報を更新します。
5.3.1. OpenShift Container Platform Web コンソールを使用した QuayRegistry CR の変更
QuayRegistry
は、OpenShift Container Platform Web コンソールを使用して変更できます。これにより、マネージドコンポーネントを管理対象外(managed: false
)に設定し、独自のインフラストラクチャーを使用できます。
前提条件
- admin 権限を持つユーザーとして OpenShift Container Platform にログインしている。
- Red Hat Quay Operator をインストールしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → Installed Operators をクリックします。
- Red Hat Quay をクリックします。
- Quay Registry をクリックします。
- Red Hat Quay レジストリーの名前をクリックします(例: example-registry )。
- YAML をクリックします。
-
目的のコンポーネントの
マネージド
フィールドをtrue
またはfalse
に調整します。 Save をクリックします。
注記コンポーネントを管理対象外(
managed: false
)に設定すると、追加の設定が必要になる場合があります。QuayRegistry
CR で管理対象外コンポーネントを設定する方法は、依存関係への管理対象外コンポーネントの使用 を 参照してください。
5.3.2. CLI を使用した QuayRegistry CR の変更
QuayRegistry
CR は CLI を使用して変更できます。これにより、マネージドコンポーネントを管理対象外(managed: false
)に設定し、独自のインフラストラクチャーを使用できます。
前提条件
- cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている。
手順
次のコマンドを入力して、
QuayRegistry
CR を編集します。oc edit quayregistry <registry_name> -n <namespace>
$ oc edit quayregistry <registry_name> -n <namespace>
Copy to Clipboard Copied! QuayRegistry
CR に必要な変更を加えます。注記コンポーネントを管理対象外(
managed: false
)に設定すると、追加の設定が必要になる場合があります。QuayRegistry
CR で管理対象外コンポーネントを設定する方法は、依存関係への管理対象外コンポーネントの使用 を 参照してください。- 変更を保存します。
5.3.3. configBundleSecret について
spec.configBundleSecret
フィールドは、QuayRegistry リソースと同じ namespace にある Secret の metadata.name
への参照です。この Secret には config.yaml
のキー/値のペアが含まれる必要があります。この値は Red Hat Quay 設定ファイルです。
configBundleSecret
は、config.yaml
ファイルを保存します。Red Hat Quay 管理者は、config.yaml
ファイルを使用して以下の設定を定義できます。
- 認証バックエンド(OIDC、LDAP など)
- 外部 TLS ターミネーションの設定
- リポジトリー作成ポリシー
- 機能フラグ
- 通知設定
Red Hat Quay は、次の理由でこのシークレットを更新する場合があります。
- 新しい認証方法を有効にする
- カスタム SSL/TLS 証明書 UI
- 機能の有効化
- セキュリティースキャン設定の変更
このフィールドを省略すると、Red Hat Quay Operator はデフォルト値と管理コンポーネント設定に基づいて設定シークレットを自動的に生成します。フィールドを指定すると、config.yaml
の内容は基本設定として使用され、マネージドコンポーネントの値にマージされ、quay
アプリケーション Pod にマウントされる最終的な設定を形成します。
QuayRegistry
CR の設定方法によって、OpenShift Container Platform の Red Hat Quay の configBundleSecrets にどのフィールドを含める必要があるかが決まります
。次の例は、すべてのコンポーネントが Operator によって管理されている場合のデフォルトの config.yaml
ファイルを示しています。この例は、コンポーネントが管理対象か管理対象外か(managed: false
)によって異なることに注意してください。
Operator によって管理されるすべてのコンポーネントを含む YAML の例
ALLOW_PULLS_WITHOUT_STRICT_LOGGING: false AUTHENTICATION_TYPE: Database DEFAULT_TAG_EXPIRATION: 2w ENTERPRISE_LOGO_URL: /static/img/RH_Logo_Quay_Black_UX-horizontal.svg FEATURE_BUILD_SUPPORT: false FEATURE_DIRECT_LOGIN: true FEATURE_MAILING: false REGISTRY_TITLE: Red Hat Quay REGISTRY_TITLE_SHORT: Red Hat Quay SETUP_COMPLETE: true TAG_EXPIRATION_OPTIONS: - 2w TEAM_RESYNC_STALE_TIME: 60m TESTING: false
ALLOW_PULLS_WITHOUT_STRICT_LOGGING: false
AUTHENTICATION_TYPE: Database
DEFAULT_TAG_EXPIRATION: 2w
ENTERPRISE_LOGO_URL: /static/img/RH_Logo_Quay_Black_UX-horizontal.svg
FEATURE_BUILD_SUPPORT: false
FEATURE_DIRECT_LOGIN: true
FEATURE_MAILING: false
REGISTRY_TITLE: Red Hat Quay
REGISTRY_TITLE_SHORT: Red Hat Quay
SETUP_COMPLETE: true
TAG_EXPIRATION_OPTIONS:
- 2w
TEAM_RESYNC_STALE_TIME: 60m
TESTING: false
場合によっては、オブジェクトストレージなど、特定のコンポーネントを独自に管理することもできます。このシナリオでは、QuayRegistry
CR を次のように変更します。
管理対象外のオブジェクトストレージコンポーネント
# ... - kind: objectstorage managed: false # ...
# ...
- kind: objectstorage
managed: false
# ...
独自のコンポーネントを管理する場合は、そのコンポーネントに必要な情報またはリソースを含めるようにデプロイメントを設定する必要があります。たとえば、objectstorage
コンポーネントが managed: false
に設定されている場合は、config.yaml
ファイル内にストレージプロバイダーに応じて関連情報が含まれます。次の例は、Google Cloud Storage を使用した分散ストレージ設定を示しています。
objectstorage が管理対象外の場合に必要な情報
# ... DISTRIBUTED_STORAGE_CONFIG: default: - GoogleCloudStorage - access_key: <access_key> bucket_name: <bucket_name> secret_key: <secret_key> storage_path: /datastorage/registry # ...
# ...
DISTRIBUTED_STORAGE_CONFIG:
default:
- GoogleCloudStorage
- access_key: <access_key>
bucket_name: <bucket_name>
secret_key: <secret_key>
storage_path: /datastorage/registry
# ...
同様に、Horizontalpodautoscaler
コンポーネントを管理する場合は、付随する HorizontalPodAutoscaler
カスタムリソース を作成する必要があります。
5.3.3.1. OpenShift Container Platform Web コンソールを使用した設定ファイルの変更
以下の手順を使用して、OpenShift Container Platform Web コンソールを使用して configBundleSecret
によって保存される config.yaml
ファイルを変更します。
前提条件
- cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operator → Installed Operator → Quay Registry をクリックします。
- Quay Registry をクリックします。
- Red Hat Quay レジストリーの名前をクリックします(例: example-registry )。
- QuayRegistry details ページで、Config Bundle Secret の名前をクリックします(例: example-registry-config-bundle )。
- Actions → Edit Secret をクリックします。
Value ボックスに、必要なキー/値のペアを追加します。たとえば、OpenShift Container Platform デプロイメントの Red Hat Quay にスーパーユーザーを追加するには、以下のリファレンスを追加します。
SUPER_USERS: - quayadmin
SUPER_USERS: - quayadmin
Copy to Clipboard Copied! - Save をクリックします。
検証
変更が受け入れられたことを確認します。
- OpenShift Container Platform Web コンソールで、Operator → Installed Operator → Quay Registry をクリックします。
- Quay Registry をクリックします。
- Red Hat Quay レジストリーの名前をクリックします(例: example-registry )。
Events をクリックします。成功すると、次のメッセージが表示されます。
All objects created/updated successfully
All objects created/updated successfully
Copy to Clipboard Copied!
シークレットに配置する前に、更新された config.yaml を base64 でエンコードする必要があります。Secret 名が spec.configBundleSecret で指定された値と一致することを確認します。Secret が更新されると、Operator は変更を検出し、Red Hat Quay Pod に更新を自動的にロールアウトします。
詳細な手順については、Red Hat Quay UI での設定シークレットの更新を参照してください。
5.3.3.2. CLI を使用した設定ファイルの変更
CLI を使用して既存の設定をダウンロードし、configBundleSecret
によって保存される config.yaml
ファイルを変更できます。変更後に、configBundleSecret
リソースを再アップロードして、Red Hat Quay レジストリーに変更を加えることができます。
configBundleSecret
リソースによって保存される config.yaml
ファイルの変更は、既存の設定ファイルのデコードと変更のアップロードが必要な複数ステップの手順です。ほとんどの場合、OpenShift Container Platform Web コンソールを使用して config.yaml
ファイルに変更を加える方が簡単です。
前提条件
- cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている。
手順
次のコマンドを入力して、
QuayRegistry
リソースを記述します。oc describe quayregistry -n <quay_namespace>
$ oc describe quayregistry -n <quay_namespace>
Copy to Clipboard Copied! ... ...
# ... Config Bundle Secret: example-registry-config-bundle-v123x # ...
Copy to Clipboard Copied! 次のコマンドを入力してシークレットデータを取得します。
oc get secret -n <quay_namespace> <example-registry-config-bundle-v123x> -o jsonpath='{.data}'
$ oc get secret -n <quay_namespace> <example-registry-config-bundle-v123x> -o jsonpath='{.data}'
Copy to Clipboard Copied! 出力例
{ "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo=" }
{ "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo=" }
Copy to Clipboard Copied! >> config.yaml
フラグを渡すことで、データを現在のディレクトリーの YAML ファイルにエクスポートできます。以下に例を示します。echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode >> config.yaml
$ echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode >> config.yaml
Copy to Clipboard Copied! -
config.yaml
ファイルに必要な変更を加え、ファイルをconfig.yaml
として保存します。 次のコマンドを入力して、新しい
configBundleSecret
YAML を作成します。touch <new_configBundleSecret_name>.yaml
$ touch <new_configBundleSecret_name>.yaml
Copy to Clipboard Copied! 次のコマンドを入力して、新しい
configBundleSecret
リソースを作成し、config.yaml
ファイルを渡します。oc -n <namespace> create secret generic <secret_name> \ --from-file=config.yaml=</path/to/config.yaml> \ --dry-run=client -o yaml > <new_configBundleSecret_name>.yaml
$ oc -n <namespace> create secret generic <secret_name> \ --from-file=config.yaml=</path/to/config.yaml> \
1 --dry-run=client -o yaml > <new_configBundleSecret_name>.yaml
Copy to Clipboard Copied! - 1
<config.yaml>
はbase64 でデコード
されたconfig.yaml
ファイルです。
次のコマンドを入力して、
configBundleSecret
リソースを作成します。oc create -n <namespace> -f <new_configBundleSecret_name>.yaml
$ oc create -n <namespace> -f <new_configBundleSecret_name>.yaml
Copy to Clipboard Copied! 出力例
secret/config-bundle created
secret/config-bundle created
Copy to Clipboard Copied! 次のコマンドを入力して、
QuayRegistry
YAML ファイルを更新して、新しいconfigBundleSecret
オブジェクトを参照します。oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":{"configBundleSecret":"<new_configBundleSecret_name>"}}'
$ oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":{"configBundleSecret":"<new_configBundleSecret_name>"}}'
Copy to Clipboard Copied! 出力例
quayregistry.quay.redhat.com/example-registry patched
quayregistry.quay.redhat.com/example-registry patched
Copy to Clipboard Copied!
検証
QuayRegistry
CR が新規のconfigBundleSecret
で更新されていることを確認します。oc describe quayregistry -n <quay_namespace>
$ oc describe quayregistry -n <quay_namespace>
Copy to Clipboard Copied! 出力例
... ...
# ... Config Bundle Secret: <new_configBundleSecret_name> # ...
Copy to Clipboard Copied! レジストリーにパッチを適用した後、Red Hat Quay Operator は変更を自動的に調整します。
第6章 Red Hat Quay 3.14 の新しい設定フィールド
以下のセクションでは、Red Hat Quay 3.14 で追加された新しい設定フィールドを詳しく説明します。
6.1. モデルカードレンダリング設定フィールド
v2 UI でのモデルカードのレンダリングをサポートするために、次の設定フィールドが追加されました。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_UI_MODELCARD | Boolean |
UI で Model card イメージタブを有効にします。デフォルトは |
UI_MODELCARD_ARTIFACT_TYPE | String | モデルカードアーティファクトタイプを定義します。 |
UI_MODELCARD_ANNOTATION | Object | このオプションフィールドは、OCI イメージに格納されているモデルカードのレイヤーアノテーションを定義します。 |
UI_MODELCARD_LAYER_ANNOTATION | Object | このオプションフィールドは、OCI イメージに格納されているモデルカードのレイヤーアノテーションを定義します。 |
モデルカード YAML の例
FEATURE_UI_MODELCARD: true UI_MODELCARD_ARTIFACT_TYPE: application/x-mlmodel UI_MODELCARD_ANNOTATION: org.opencontainers.image.description: "Model card metadata" UI_MODELCARD_LAYER_ANNOTATION: org.opencontainers.image.title: README.md
FEATURE_UI_MODELCARD: true
UI_MODELCARD_ARTIFACT_TYPE: application/x-mlmodel
UI_MODELCARD_ANNOTATION:
org.opencontainers.image.description: "Model card metadata"
UI_MODELCARD_LAYER_ANNOTATION:
org.opencontainers.image.title: README.md
- 1
- UI で Model Card イメージタブを有効にします。
- 2
- モデルカードアーティファクトタイプを定義します。この例では、アーティファクトタイプは
application/x-mlmodel
です。 - 3
- オプション: イメージに
artifactType
が定義されていない場合、このフィールドはマニフェストレベルでチェックされます。一致するアノテーションが見つかった場合、システムはUI_MODELCARD_LAYER_ANNOTATION
に一致するアノテーションを持つレイヤーを検索します。 - 4
- オプション: イメージに
artifactType
が定義されており、レイヤーが複数ある場合、このフィールドを使用して、モデルカードを含む特定のレイヤーを検索します。
第7章 必須の設定フィールド
Red Hat Quay では、Operator に正しく設定フィールドの最小セットが必要です。これらのフィールドは、レジストリーへのアクセス方法、イメージコンテンツの保存方法、メタデータの永続化方法、ログなどのバックグラウンドサービスの管理方法など、デプロイメントの重要な側面を定義します。
必要な設定フィールドは 5 つの主要なカテゴリーに分類されます。
- 一般的な必須フィールド。本セクションでは、認証タイプ、URL スキーム、サーバーのホスト名、データベースシークレットキー、およびシークレットキーなどのコアフィールドについて説明します。
- データベース設定フィールド。Red Hat Quay には、リポジトリー、ユーザー、チーム、およびタグに関するメタデータを保存するために、PostgreSQL リレーショナルデータベースが必要です。
- オブジェクトストレージ設定フィールド。オブジェクトストレージは、コンテナーイメージ Blob とマニフェストの保存先のバックエンドを定義します。ストレージバックエンドは、Ceph/RadosGW、AWS S3 ストレージ、Google Cloud Storage、Nutanix などの Red Hat Quay でサポートされている必要があります。
- Redis 設定フィールド。Redis は、プッシュログ、ユーザー通知、その他の操作などのデータのバックエンドとして使用されます。
7.1. 一般的な必須フィールド
以下の表は、Red Hat Quay デプロイメントの必須設定フィールドを説明しています。
フィールド | 型 | 説明 |
---|---|---|
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 | ユーザーセッションを正しく解釈するために必要なセッション Cookie と CSRF トークンを暗号化するために使用されるキー。設定時に値を変更しないでください。すべての Red Hat Quay インスタンスで永続的である必要があります。すべてのインスタンスで永続的でない場合、ログインの失敗やセッションの永続性に関連するその他のエラーが発生する可能性があります。 |
SETUP_COMPLETE | Boolean |
これは、以前のバージョンのソフトウェアからそのまま残っているアーティファクトです。現時点では値を |
一般的な必須フィールドの例
AUTHENTICATION_TYPE: Database PREFERRED_URL_SCHEME: https SERVER_HOSTNAME: <quay-server.example.com> SECRET_KEY: <secret_key_value> DATABASE_SECRET_KEY: <database_secret_key_value> SETUP_COMPLETE: true # ...
AUTHENTICATION_TYPE: Database
PREFERRED_URL_SCHEME: https
SERVER_HOSTNAME: <quay-server.example.com>
SECRET_KEY: <secret_key_value>
DATABASE_SECRET_KEY: <database_secret_key_value>
SETUP_COMPLETE: true
# ...
7.2. データベース設定フィールド
このセクションでは、Red Hat Quay デプロイメントで利用可能なデータベース設定フィールドを説明します。
7.2.1. データベース URI
Red Hat Quay では、必要な DB_URI
フィールドを使用してデータベースへの接続を設定します。
以下の表は DB_URI
設定フィールドを説明します。
フィールド | 型 | 説明 |
---|---|---|
DB_URI | String | 認証情報を含む、データベースにアクセスするための URI。
postgresql://quayuser:quaypass@quay-server.example.com:5432/quay |
データベース URI の例
# ... DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay # ...
# ...
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
# ...
7.2.2. データベース接続引数
オプションの接続引数は、DB_CONNECTION_ARGS
パラメーターで設定されます。DB_CONNECTION_ARGS
で定義されたキーと値のペアの一部は汎用的なものも、データベース固有のものもあります。
フィールド | 型 | 説明 |
---|---|---|
DB_CONNECTION_ARGS | Object | タイムアウトや SSL/TLS などのデータベースの任意の接続引数。 |
.autorollback | Boolean |
スレッドローカル接続を使用するかどうか。 |
.threadlocals | Boolean |
自動ロールバック接続を使用するかどうか。 |
データベース接続引数の例
# ... DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay DB_CONNECTION_ARGS: autorollback: true threadlocals: true # ...
# ...
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
DB_CONNECTION_ARGS:
autorollback: true
threadlocals: true
# ...
7.2.2.1. SSL/TLS 接続引数
SSL/TLS では、設定はデプロイするデータベースによって異なります。
sslmode
オプションは、セキュアな SSL/TLS TCP/IP 接続がサーバーにネゴシエートされるかどうか、その優先度を決定します。モードは 6 つあります。
モード | 説明 |
---|---|
sslmode | セキュアな SSL/TLS または TCP/IP 接続がサーバーにネゴシエートされるかどうか、またはその優先度を決定します。 |
*: 無効 | この設定では、非 SSL/TLS 接続のみが試行されます。 |
*: 許可 | 設定では、まず非 SSL/TLS 接続が試行されます。失敗すると、SSL/TLS 接続が試行されます。 |
*: 優先 | 設定では、まず SSL/TLS 接続が試行されます。失敗すると、非 SSL/TLS 接続が試行されます。 |
*: 必須 | 設定では SSL/TLS 接続のみが試行されます。ルート CA ファイルが存在する場合は、verify-ca が指定されているのと同じ方法で証明書が検証されます。 |
*: verify-ca | 設定では SSL/TLS 接続のみが試行され、サーバー証明書が信頼された認証局 (CA) によって発行されたかどうかが検証されます。 |
*: verify-full | SSL/TLS 接続のみを試行し、サーバー証明書が信頼できる CA によって発行されていること、および要求されたサーバーのホスト名が証明書内のホスト名と一致することが確認されます。 |
PostgreSQL の有効な引数の詳細は、Database Connection Control Functions を参照してください。
PostgreSQL SSL/TLS 設定
# ... DB_CONNECTION_ARGS: sslmode: <value> sslrootcert: path/to/.postgresql/root.crt # ...
# ...
DB_CONNECTION_ARGS:
sslmode: <value>
sslrootcert: path/to/.postgresql/root.crt
# ...
7.3. ストレージオブジェクト設定フィールド
ストレージフィールドは、コンテナーイメージ Blob とマニフェストの保存先のバックエンドを定義します。Red Hat Quay では、次のストレージプロバイダーがサポートされています。
- Amazon Web Services (AWS) S3
- AWS STS S3 (セキュリティートークンサービス)
- AWS CloudFront (CloudFront S3Storage)
- Google Cloud Storage
- Microsoft Azure Blob Storage
- Swift Storage
- Nutanix オブジェクトストレージ
- IBM Cloud Object Storage
- NetApp ONTAP S3 オブジェクトストレージ
- Hitachi Content Platform (HCP)オブジェクトストレージ
S3 互換 API により、サポートされているストレージプロバイダーの多くは RadosGWStorage
ドライバーを使用します。
7.3.1. ストレージ設定フィールド
以下の表は、Red Hat Quay のストレージ設定フィールドを説明しています。バックエンドストレージの設定時に、これらのフィールドが必要です。
フィールド | 型 | 説明 |
---|---|---|
DISTRIBUTED_STORAGE_CONFIG | Object |
Red Hat Quay で使用するストレージエンジンの設定。各キーは、ストレージエンジンの一意の ID を表します。この値は、ストレージエンジンパラメーターを記述するオブジェクトのタプル (キー、値) で構成されます。 |
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS | 文字列の配列 |
イメージをデフォルトで他のすべてのストレージエンジンに対して完全にレプリケートする必要のあるストレージエンジンの一覧 ( |
DISTRIBUTED_STORAGE_PREFERENCE | 文字列の配列 |
使用する優先ストレージエンジン ( |
MAXIMUM_LAYER_SIZE | String |
イメージレイヤーの最大許容サイズ。 |
ストレージ設定の例
DISTRIBUTED_STORAGE_CONFIG: DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default MAXIMUM_LAYER_SIZE: 100G
DISTRIBUTED_STORAGE_CONFIG:
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- default
MAXIMUM_LAYER_SIZE: 100G
7.3.2. ローカルストレージ
以下の YAML は、ローカルストレージを使用した設定例を示しています。
概念実証の ためにレジストリーをデプロイする場合は、ローカルストレージのみを使用してください。これは実稼働環境での使用を目的としていません。ローカルストレージを使用する場合は、レジストリーの起動時に、レジストリーをコンテナー内の datastorage
パスにマップする必要があります。詳細は、Proof of Concept - Deploying Red Hat Quayを参照してください。
ローカルストレージの例
DISTRIBUTED_STORAGE_CONFIG: default: - LocalStorage - storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
DISTRIBUTED_STORAGE_CONFIG:
default:
- LocalStorage
- storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- default
7.3.3. Red Hat OpenShift Data Foundation
以下の YAML は、Red Hat OpenShift Data Foundation を使用した設定のサンプルを示しています。
DISTRIBUTED_STORAGE_CONFIG: rhocsStorage: - RHOCSStorage - access_key: <access_key_here> secret_key: <secret_key_here> bucket_name: <bucket_name> hostname: <hostname> is_secure: 'true' port: '443' storage_path: /datastorage/registry maximum_chunk_size_mb: 100 server_side_assembly: true
DISTRIBUTED_STORAGE_CONFIG:
rhocsStorage:
- RHOCSStorage
- access_key: <access_key_here>
secret_key: <secret_key_here>
bucket_name: <bucket_name>
hostname: <hostname>
is_secure: 'true'
port: '443'
storage_path: /datastorage/registry
maximum_chunk_size_mb: 100
server_side_assembly: true
7.3.4. Ceph オブジェクトゲートウェイ(RadosGW)ストレージの例
Red Hat Quay は、Ceph Object Gateway (RadosGW)をオブジェクトストレージのバックエンドとして使用することをサポートします。radosgw は、プライベートアーキテクチャー用のストレージプラットフォームである Red Hat Ceph Storage のコンポーネントです。Red Hat Ceph Storage は、Ceph と対話するための S3 互換の REST API を提供します。
radosgw は、オンプレミスの S3 互換ストレージソリューションです。S3 API を実装し、access_key
、secret_key
、bucket_name
などの同じ認証フィールドを必要とします。Ceph Object Gateway および S3 API の詳細は、Ceph Object Gateway を参照してください。
以下の YAML は、RadosGW を使用した設定例を示しています。
一般的な s3 アクセスの例
DISTRIBUTED_STORAGE_CONFIG: radosGWStorage: - RadosGWStorage - access_key: <access_key_here> bucket_name: <bucket_name_here> hostname: <hostname_here> is_secure: true port: '443' secret_key: <secret_key_here> storage_path: /datastorage/registry maximum_chunk_size_mb: 100 server_side_assembly: true
DISTRIBUTED_STORAGE_CONFIG:
radosGWStorage:
- RadosGWStorage
- access_key: <access_key_here>
bucket_name: <bucket_name_here>
hostname: <hostname_here>
is_secure: true
port: '443'
secret_key: <secret_key_here>
storage_path: /datastorage/registry
maximum_chunk_size_mb: 100
server_side_assembly: true
- 1
- 一般的な s3 アクセスに使用します。一般的な s3 アクセスは、厳密には Amazon Web Services (AWS) s3 に限定されず、RadosGW または他のストレージサービスでも使用できることに注意してください。AWS S3 ドライバーを使用した一般的な s3 アクセスの例は、「AWS S3 ストレージ」を参照してください。
- 2
- オプション: 最終コピーの最大チャンクサイズ (MB 単位) を定義します。
server_side_assembly
がfalse
に設定されている場合、効果はありません。 - 3
- オプション: Red Hat Quay がクライアントアセンブリーではなく、サーバー側アセンブリーと最終的なチャンクコピーの使用を試みるかどうか指定します。デフォルトは
true
です。
7.3.5. サポートされている AWS ストレージバックエンド
Red Hat Quay は、複数の Amazon Web Services (AWS)ストレージバックエンドをサポートします。
- S3 ストレージ: AWS のネイティブオブジェクトストレージサービスを使用する AWS S3 バケットの標準サポート。
- STS S3 ストレージ: IAM ロールを引き受けるための AWS Security Token Service (STS)のサポートにより、よりセキュアな S3 操作が可能になります。
- CloudFront S3 ストレージ: AWS CloudFront と統合して、AWS S3 をオリジンとして使用しながらコンテンツの高可用性ディストリビューションを有効にします。
以下のセクションでは、YAML の例と各 AWS ストレージバックエンドに関する追加情報を提供します。
7.3.5.1. Amazon Web Services S3 ストレージ
Red Hat Quay は、AWS S3 をオブジェクトストレージのバックエンドとして使用することをサポートします。AWS S3 は、データの可用性、スケーラビリティー、セキュリティー、およびパフォーマンスのために設計されたオブジェクトストレージサービスです。以下の YAML は、AWS S3 を使用した設定例を示しています。
AWS S3 の例
# ... DISTRIBUTED_STORAGE_CONFIG: default: - S3Storage - host: s3.us-east-2.amazonaws.com s3_access_key: ABCDEFGHIJKLMN s3_secret_key: OL3ABCDEFGHIJKLMN s3_bucket: quay_bucket s3_region: <region> storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default # ...
# ...
DISTRIBUTED_STORAGE_CONFIG:
default:
- S3Storage
- host: s3.us-east-2.amazonaws.com
s3_access_key: ABCDEFGHIJKLMN
s3_secret_key: OL3ABCDEFGHIJKLMN
s3_bucket: quay_bucket
s3_region: <region>
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- default
# ...
7.3.5.2. Amazon Web Services STS S3 ストレージ
AWS Security Token Service (STS)は、AWS リソースにアクセスするための一時的な制限付き権限の認証情報を提供し、長期アクセスキーを保存する必要性を回避してセキュリティーを強化します。これは、IAM ロールで認証情報をローテーションしたり、管理できる OpenShift Container Platform などの環境で役立ちます。
以下の YAML は、OpenShift Container Platform 設定で AWS STS を Red Hat Quay で使用する設定例を示しています。
AWS STS S3 ストレージの例
# ... DISTRIBUTED_STORAGE_CONFIG: default: - STSS3Storage - sts_role_arn: <role_arn> s3_bucket: <s3_bucket_name> storage_path: <storage_path> sts_user_access_key: <s3_user_access_key> sts_user_secret_key: <s3_user_secret_key> s3_region: <region> DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default # ...
# ...
DISTRIBUTED_STORAGE_CONFIG:
default:
- STSS3Storage
- sts_role_arn: <role_arn>
s3_bucket: <s3_bucket_name>
storage_path: <storage_path>
sts_user_access_key: <s3_user_access_key>
sts_user_secret_key: <s3_user_secret_key>
s3_region: <region>
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- default
# ...
7.3.5.3. AWS CloudFront ストレージ
AWS CloudFront はコンテンツ配信ネットワーク(CDN)サービスで、ユーザーにコンテンツをキャッシュして配信し、パフォーマンスを向上させ、レイテンシーを短縮します。Red Hat Quay は、CloudFrontedS3Storage
ドライバーを介して CloudFront をサポートします。これにより、CloudFront ディストリビューションを介した S3 バケットへの安全で署名されたアクセスが可能になります。
Red Hat Quay デプロイメント用に AWS CloudFront を設定する場合は、次の例を使用します。
AWS Cloudfront ストレージを設定する場合、Red Hat Quay を適切に使用するには次の条件を満たす必要があります。
-
config.yaml
ファイルで定義されている Red Hat Quay のストレージパスと一致するように Origin パス を設定する必要があります。この要件を満たさない場合、イメージを取得するときに403
エラーが発生します。詳細は、Origin path を参照してください。 - Bucket policy と Cross-origin resource sharing (CORS) ポリシーを設定する必要があります。
-
Cloudfront S3 の YAML 例
DISTRIBUTED_STORAGE_CONFIG: default: - CloudFrontedS3Storage - cloudfront_distribution_domain: <CLOUDFRONT_DISTRIBUTION_DOMAIN> cloudfront_key_id: <CLOUDFRONT_KEY_ID> cloudfront_privatekey_filename: <CLOUDFRONT_PRIVATE_KEY_FILENAME> host: <S3_HOST> s3_access_key: <S3_ACCESS_KEY> s3_bucket: <S3_BUCKET_NAME> s3_secret_key: <S3_SECRET_KEY> storage_path: <STORAGE_PATH> s3_region: <S3_REGION> DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: - default DISTRIBUTED_STORAGE_PREFERENCE: - default
DISTRIBUTED_STORAGE_CONFIG:
default:
- CloudFrontedS3Storage
- cloudfront_distribution_domain: <CLOUDFRONT_DISTRIBUTION_DOMAIN>
cloudfront_key_id: <CLOUDFRONT_KEY_ID>
cloudfront_privatekey_filename: <CLOUDFRONT_PRIVATE_KEY_FILENAME>
host: <S3_HOST>
s3_access_key: <S3_ACCESS_KEY>
s3_bucket: <S3_BUCKET_NAME>
s3_secret_key: <S3_SECRET_KEY>
storage_path: <STORAGE_PATH>
s3_region: <S3_REGION>
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- default
DISTRIBUTED_STORAGE_PREFERENCE:
- default
バケットポリシーの例
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>/*" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>" } ] }
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::<S3_BUCKET_NAME>/*"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::<S3_BUCKET_NAME>"
}
]
}
7.3.6. Google Cloud Storage
Red Hat Quay は、Google Cloud Storage (GCS)をオブジェクトストレージバックエンドとして使用することをサポートします。Red Hat Quay で使用すると、コンテナーイメージとアーティファクトを保存するためのクラウドネイティブソリューションが提供されます。
以下の YAML は、Google Cloud Storage を使用した設定例を示しています。
Google Cloud Storage の例
DISTRIBUTED_STORAGE_CONFIG: googleCloudStorage: - GoogleCloudStorage - access_key: <access_key> bucket_name: <bucket_name> secret_key: <secret_key> storage_path: /datastorage/registry boto_timeout: 120 DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - googleCloudStorage
DISTRIBUTED_STORAGE_CONFIG:
googleCloudStorage:
- GoogleCloudStorage
- access_key: <access_key>
bucket_name: <bucket_name>
secret_key: <secret_key>
storage_path: /datastorage/registry
boto_timeout: 120
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- googleCloudStorage
- 1
- オプション: 接続から読み取ろうとしたときにタイムアウト例外が出力されるまでの時間 (秒単位)。デフォルトは
60
秒です。また、接続を試行するときにタイムアウト例外が出力されるまでの時間 (秒単位) も含まれます。デフォルトは60
秒です。
7.3.7. Microsoft Azure Blob Storage
Red Hat Quay は、Microsoft Azure Blob Storage をオブジェクトストレージのバックエンドとして使用することをサポートします。Azure Blob Storage を使用すると、コンテナーイメージ、メタデータ、およびその他のアーティファクトを安全でクラウドネイティブな方法で永続化できます。
以下の YAML は、Azure Storage を使用した設定のサンプルを示しています。
Microsoft Azure Blob Storage の例
DISTRIBUTED_STORAGE_CONFIG: azureStorage: - AzureStorage - azure_account_name: <azure_account_name> azure_container: <azure_container_name> storage_path: /datastorage/registry azure_account_key: <azure_account_key> sas_token: some/path/ endpoint_url: https://[account-name].blob.core.usgovcloudapi.net DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - azureStorage
DISTRIBUTED_STORAGE_CONFIG:
azureStorage:
- AzureStorage
- azure_account_name: <azure_account_name>
azure_container: <azure_container_name>
storage_path: /datastorage/registry
azure_account_key: <azure_account_key>
sas_token: some/path/
endpoint_url: https://[account-name].blob.core.usgovcloudapi.net
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
エラーが発生します。
7.3.8. Swift オブジェクトストレージ
Red Hat Quay は、Red Hat OpenStack Platform (RHOSP) Object Storage サービス(Swift) をオブジェクトストレージバックエンドとして使用することをサポートします。Swift は、独自の API と認証メカニズムで S3 のような機能を提供します。
以下の YAML は、Swift ストレージを使用した設定のサンプルを示しています。
Swift オブジェクトストレージの例
DISTRIBUTED_STORAGE_CONFIG: swiftStorage: - SwiftStorage - swift_user: <swift_username> swift_password: <swift_password> swift_container: <swift_container> auth_url: https://example.org/swift/v1/quay auth_version: 3 os_options: tenant_id: <osp_tenant_id> user_domain_name: <osp_domain_name> ca_cert_path: /conf/stack/swift.cert" storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - swiftStorage
DISTRIBUTED_STORAGE_CONFIG:
swiftStorage:
- SwiftStorage
- swift_user: <swift_username>
swift_password: <swift_password>
swift_container: <swift_container>
auth_url: https://example.org/swift/v1/quay
auth_version: 3
os_options:
tenant_id: <osp_tenant_id>
user_domain_name: <osp_domain_name>
ca_cert_path: /conf/stack/swift.cert"
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- swiftStorage
7.3.9. Nutanix オブジェクトストレージ
Red Hat Quay は、Nutanix Objects Storage をオブジェクトストレージバックエンドとしてサポートします。Nutanix Object Storage は、Nutanix を使用してプライベートクラウドインフラストラクチャーを実行している組織に適しています。
以下の YAML は、Nutanix オブジェクトストレージを使用した設定例を示しています。
Nutanix Objects ストレージの例
DISTRIBUTED_STORAGE_CONFIG: nutanixStorage: # storage config name - RadosGWStorage # actual driver - access_key: <access_key> secret_key: <secret_key> bucket_name: <bucket_name> hostname: <hostname> is_secure: 'true' port: '443' storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: # must contain name of the storage config - nutanixStorage
DISTRIBUTED_STORAGE_CONFIG:
nutanixStorage: # storage config name
- RadosGWStorage # actual driver
- access_key: <access_key>
secret_key: <secret_key>
bucket_name: <bucket_name>
hostname: <hostname>
is_secure: 'true'
port: '443'
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE: # must contain name of the storage config
- nutanixStorage
7.3.10. IBM Cloud Object Storage
Red Hat Quay は、IBM Cloud Object Storage をオブジェクトストレージバックエンドとしてサポートします。IBM Cloud Object Storage は、IBM Cloud 上のスケーラブルで安全なストレージを必要とするクラウドネイティブアプリケーションに適しています。
以下の YAML は、IBM Cloud Object Storage を使用した設定例を示しています。
IBM Cloud Object Storage
DISTRIBUTED_STORAGE_CONFIG: default: - IBMCloudStorage # actual driver - access_key: <access_key> # parameters secret_key: <secret_key> bucket_name: <bucket_name> hostname: <hostname> is_secure: 'true' port: '443' storage_path: /datastorage/registry maximum_chunk_size_mb: 100mb minimum_chunk_size_mb: 5mb DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: - default DISTRIBUTED_STORAGE_PREFERENCE: - default
DISTRIBUTED_STORAGE_CONFIG:
default:
- IBMCloudStorage # actual driver
- access_key: <access_key> # parameters
secret_key: <secret_key>
bucket_name: <bucket_name>
hostname: <hostname>
is_secure: 'true'
port: '443'
storage_path: /datastorage/registry
maximum_chunk_size_mb: 100mb
minimum_chunk_size_mb: 5mb
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- default
DISTRIBUTED_STORAGE_PREFERENCE:
- default
- 1
- オプション:
100mb
に設定することを推奨します。 - 2
- オプション: デフォルトは
5mb
です。このフィールドは、Red Hat サポート に相談せずに調整しないでください。意図しない結果が生じる可能性があるためです。
7.3.11. NetApp ONTAP S3 オブジェクトストレージ
Red Hat Quay は、NetApp ONTAP S3 をオブジェクトストレージバックエンドとして使用することをサポートしています。
次の YAML は、NetApp ONTAP S3 を使用したサンプル設定を示しています。
NetApp ONTAP S3 の例
DISTRIBUTED_STORAGE_CONFIG: local_us: - RadosGWStorage - access_key: <access_key> bucket_name: <bucket_name> hostname: <host_url_address> is_secure: true port: <port> secret_key: <secret_key> storage_path: /datastorage/registry signature_version: v4 DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: - local_us DISTRIBUTED_STORAGE_PREFERENCE: - local_us
DISTRIBUTED_STORAGE_CONFIG:
local_us:
- RadosGWStorage
- access_key: <access_key>
bucket_name: <bucket_name>
hostname: <host_url_address>
is_secure: true
port: <port>
secret_key: <secret_key>
storage_path: /datastorage/registry
signature_version: v4
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- local_us
DISTRIBUTED_STORAGE_PREFERENCE:
- local_us
7.3.12. Hitachi Content Platform オブジェクトストレージ
Red Hat Quay は、オブジェクトストレージバックエンドとしての Hitachi Content Platform (HCP) の使用をサポートします。
次の YAML は、オブジェクトストレージに HCP を使用するサンプル設定を示しています。
HCP ストレージ設定の例
DISTRIBUTED_STORAGE_CONFIG: hcp_us: - RadosGWStorage - access_key: <access_key> bucket_name: <bucket_name> hostname: <hitachi_hostname_example> is_secure: true secret_key: <secret_key> storage_path: /datastorage/registry signature_version: v4 DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: - hcp_us DISTRIBUTED_STORAGE_PREFERENCE: - hcp_us
DISTRIBUTED_STORAGE_CONFIG:
hcp_us:
- RadosGWStorage
- access_key: <access_key>
bucket_name: <bucket_name>
hostname: <hitachi_hostname_example>
is_secure: true
secret_key: <secret_key>
storage_path: /datastorage/registry
signature_version: v4
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
- hcp_us
DISTRIBUTED_STORAGE_PREFERENCE:
- hcp_us
7.4. Redis 設定フィールド
Redis は、ビルドトリガーや通知などのバックエンドタスクおよびサービスをサポートするために Red Hat Quay によって使用されます。Redis に関連する設定タイプ(ビルドログおよびユーザーイベント)があります。以下のセクションでは、各タイプで利用可能な設定フィールドについて詳しく説明します。
7.4.1. ビルドログ
ビルドログは、イメージのビルドプロセス中に生成され、デバッグと監査の洞察を提供します。Red Hat Quay は Redis を使用して、ユーザーインターフェイスまたは API 経由でアクセスする前に、これらのログを一時的に保存します。
Redis デプロイメントには、以下のビルドログ設定フィールドを使用できます。
フィールド | 型 | 説明 |
---|---|---|
BUILDLOGS_REDIS | Object | ビルドログキャッシュ用の Redis 接続の詳細。 |
.host | String |
Redis にアクセスできるホスト名。 |
.port | 数値 |
Redis にアクセスできるポート。 |
.password | String |
Redis インスタンスに接続するためのパスワード。 |
.ssl | Boolean | Redis と Quay 間の TLS 通信を有効にするかどうか。デフォルトは false です。 |
ビルドログ設定の例
# ... BUILDLOGS_REDIS: host: <quay-server.example.com> password: <example_password> port: 6379 ssl: true # ...
# ...
BUILDLOGS_REDIS:
host: <quay-server.example.com>
password: <example_password>
port: 6379
ssl: true
# ...
7.4.2. ユーザーイベント
ユーザーイベントは、リポジトリーのプッシュ、タグの作成、削除、パーミッションの変更などの Red Hat Quay 全体のアクティビティーを追跡します。これらのイベントは、アクティビティーストリームの一部として Redis に記録され、API または Web インターフェイスからアクセスできます。
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 証明書のホスト名が、接続先のサーバーのホスト名と一致することをクライアントが確認する必要があるかどうかを指定します。 |
Redis ユーザーイベントの例
# ... USER_EVENTS_REDIS: host: <quay-redis.example.com> port: 6379 password: <example_password> ssl: true ssl_keyfile: /etc/ssl/private/redis-client.key ssl_certfile: /etc/ssl/certs/redis-client.crt ssl_cert_reqs: <required_certificate> ssl_ca_certs: /etc/ssl/certs/ca-bundle.crt ssl_check_hostname: true # ...
# ...
USER_EVENTS_REDIS:
host: <quay-redis.example.com>
port: 6379
password: <example_password>
ssl: true
ssl_keyfile: /etc/ssl/private/redis-client.key
ssl_certfile: /etc/ssl/certs/redis-client.crt
ssl_cert_reqs: <required_certificate>
ssl_ca_certs: /etc/ssl/certs/ca-bundle.crt
ssl_check_hostname: true
# ...
第8章 自動化設定オプション
Red Hat Quay は、デプロイメントと設定を自動化するさまざまなメカニズムをサポートしています。これにより、Red Hat Quay を GitOps および CI/CD パイプラインに統合することができます。これらのオプションを定義し、API を利用することで、Red Hat Quay は UI を使用せずに初期化および管理できます。
Red Hat Quay Operator は configBundleSecret
カスタムリソース(CR)で config.yaml
ファイルを管理するため、OpenShift Container Platform で Red Hat Quay を事前に設定するには、管理者が必要な設定で有効な config.yaml
ファイルを手動で作成する必要があります。次に、このファイルを新規の Kubernetes Secret にバンドルし、QuayRegistry
CR によって参照されるデフォルトの configBundleSecret
CR を置き換えるために使用される必要があります。これにより、Web ベースの設定 UI をバイパスして、OpenShift Container Platform 上の Red Hat Quay を完全に自動化された方法でデプロイできます。詳細は、QuayRegistry CR after deployment を 参照してください。
オンプレミスの Red Hat Quay デプロイメントの場合、事前設定は有効な config.yaml
ファイルを作成し、レジストリーをデプロイすることで行われます。
自動化オプションは、切断されたクラスターやエアギャップクラスターなどの宣言型 Red Hat Quay デプロイメントを必要とする環境に最適です。
8.1. 自動化用の事前設定オプション
Red Hat Quay には、レジストリー管理者が早期セットアップタスクおよび API のアクセシビリティーを自動化できるようにする設定オプションが用意されています。これらのオプションは、新規のデプロイメントや、API 呼び出しの作成方法の制御に役立ちます。次のオプションは、自動化および管理の制御をサポートしています。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_USER_INITIALIZE | Boolean |
新しくデプロイされた Red Hat Quay レジストリーで最初のユーザーブートストラップを有効にします。デプロイ前に 注記
既存の組織の OAuth アプリケーションによって生成された OAuth 2 アクセストークン を必要とする他のすべてのレジストリー API 呼び出しとは異なり、 |
BROWSER_API_CALLS_XHR_ONLY | Boolean |
レジストリー API がブラウザーへの呼び出しのみを受け入れるかどうかを制御します。通常、ブラウザーベースで API にアクセスできるようにするには、管理者はこのフィールドを |
SUBNET_USER | String |
レジストリーへの完全な特権と無制限のアクセス権を持つ管理者ユーザーまたはスーパーユーザーの一覧を定義します。Red Hat Quay 管理者は、デプロイ前に |
FEATURE_USER_CREATION | Boolean |
このフィールドが |
次の YAML は、自動化の推奨設定を示しています。
自動化の推奨設定
# ... FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false # ...
# ...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
# ...
第9章 コンポーネントおよび機能設定フィールド
Component and Feature Configuration セクションでは、さまざまなサブシステム間で Red Hat Quay を微調整するために使用できる設定可能なフィールドを説明します。これらのフィールドを使用すると、管理者はレジストリーの動作をカスタマイズしたり、特定の機能を有効にしたり、外部サービスやインフラストラクチャーと統合したりできます。基本的なデプロイメントには必要ありませんが、これらのオプションはセキュリティー、自動化、スケーラビリティー、コンプライアンス、およびパフォーマンスに関連する高度なユースケースをサポートします。
9.1. コア設定の概要
これらのコアフィールドを使用して、ホスト名、プロトコル、認証設定など、レジストリーの基本動作を設定します。
9.1.1. レジストリーブランディングおよびアイデンティティーフィールド
次の設定フィールドを使用すると、Red Hat Quay デプロイメントに表示されるブランディング、アイデンティティー、および連絡先情報を変更できます。これらのフィールドを使用すると、UI 全体に表示されるタイトル、ヘッダー、フッター、および組織連絡先リンクを指定して、レジストリーがユーザーに表示される方法をカスタマイズできます。
以下のフィールドの一部は、Red Hat Quay v2 UI では利用できません。
フィールド | 型 | 説明 |
---|---|---|
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 へのリンクを追加します。 |
フィールド | 型 | 説明 |
---|---|---|
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 |
フッターイメージへのリンク。 |
フィールド | 型 | 説明 |
---|---|---|
FOOTER_LINKS | Object | オンプレミスインストールの Red Hat Quay の UI でフッターリンクのカスタマイズを有効にします。 |
.TERMS_OF_SERVICE_URL | String |
オンプレミスインストール用のカスタム利用規約。 |
.PRIVACY_POLICY_URL | String |
オンプレミスインストール用のカスタムプライバシーポリシー。 |
.SECURITY_URL | String |
オンプレミスインストール用のカスタムセキュリティーページ。 |
.ABOUT_URL | String |
オンプレミスインストール用のカスタムの概要ページ。 |
レジストリーのブランディングおよびアイデンティティーの例の YAML
# ... REGISTRY_TITLE: "Example Container Registry" REGISTRY_TITLE_SHORT: "Example Quay" CONTACT_INFO: - mailto:support@example.io - irc://chat.freenode.net:6665/examplequay - tel:+1-800-555-1234 - https://support.example.io BRANDING: logo: https://www.mend.io/wp-content/media/2020/03/5-tips_small.jpg footer_img: https://www.mend.io/wp-content/media/2020/03/5-tips_small.jpg footer_url: https://opensourceworld.org/ FOOTER_LINKS: "TERMS_OF_SERVICE_URL": "https://www.index.hr" "PRIVACY_POLICY_URL": "https://www.example.hr" "SECURITY_URL": "https://www.example.hr" "ABOUT_URL": "https://www.example.hr" # ...
# ...
REGISTRY_TITLE: "Example Container Registry"
REGISTRY_TITLE_SHORT: "Example Quay"
CONTACT_INFO:
- mailto:support@example.io
- irc://chat.freenode.net:6665/examplequay
- tel:+1-800-555-1234
- https://support.example.io
BRANDING:
logo: https://www.mend.io/wp-content/media/2020/03/5-tips_small.jpg
footer_img: https://www.mend.io/wp-content/media/2020/03/5-tips_small.jpg
footer_url: https://opensourceworld.org/
FOOTER_LINKS:
"TERMS_OF_SERVICE_URL": "https://www.index.hr"
"PRIVACY_POLICY_URL": "https://www.example.hr"
"SECURITY_URL": "https://www.example.hr"
"ABOUT_URL": "https://www.example.hr"
# ...
9.1.2. SSL/TLS 設定フィールド
このセクションでは、Red Hat Quay デプロイメントで SSL/TLS 暗号化を有効にして管理するために使用できる設定フィールドについて説明します。
フィールド | 型 | 説明 |
---|---|---|
PREFERRED_URL_SCHEME | String |
|
SERVER_HOSTNAME | String |
スキームなしで Red Hat Quay にアクセスできる URL。 |
SSL_CIPHERS | 文字列の配列 |
指定した場合、nginx で定義された SSL 暗号のリストが有効または無効になります。 |
SSL_PROTOCOLS | 文字列の配列 |
指定されている場合、nginx は、リストで定義される SSL プロトコルのリストを有効にするように設定されます。リストから SSL プロトコルを削除すると、Red Hat Quay の起動時にそのプロトコルが無効になります。 |
SESSION_COOKIE_SECURE | Boolean |
セッションクッキーに |
EXTERNAL_TLS_TERMINATION | Boolean |
TLS がサポートされていても、Quay の前の層で終了する場合は |
SSL 設定例の YAML
# ... PREFERRED_URL_SCHEME: https SERVER_HOSTNAME: quay-server.example.com SSL_CIPHERS: - ECDHE-RSA-AES128-GCM-SHA256 SSL_PROTOCOLS: - TLSv1.3 SESSION_COOKIE_SECURE: true EXTERNAL_TLS_TERMINATION: true # ...
# ...
PREFERRED_URL_SCHEME: https
SERVER_HOSTNAME: quay-server.example.com
SSL_CIPHERS:
- ECDHE-RSA-AES128-GCM-SHA256
SSL_PROTOCOLS:
- TLSv1.3
SESSION_COOKIE_SECURE: true
EXTERNAL_TLS_TERMINATION: true
# ...
9.1.3. IPv6 設定フィールド
FEATURE_LISTEN_IP_VERSION
設定フィールドを使用して、Red Hat Quay がリッスンする IP プロトコルファミリー(IPv4、IPv6、またはその両方(デュアルスタック))を指定できます。このフィールドは、レジストリーが IPv6 のみのネットワークまたはデュアルスタックネットワークで動作する必要がある環境では重要です。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_LISTEN_IP_VERSION | String |
IPv4、IPv6、またはデュアルスタックプロトコルファミリーを有効にします。この設定フィールドは正しく設定する必要があります。そうしないと、Red Hat Quay は起動に失敗します。デフォルト: |
IPv6 サンプル YAML
# ... FEATURE_LISTEN_IP_VERSION: dual-stack # ...
# ...
FEATURE_LISTEN_IP_VERSION: dual-stack
# ...
9.1.4. ロギング変数およびデバッグ変数
以下の変数は、Red Hat Quay のイベントをログに記録し、デバッグ情報を公開し、システムヘルスチェックと対話する方法を制御します。これらの設定は、レジストリーのトラブルシューティングおよびモニタリングに役立ちます。
変数 | 型 | 説明 |
---|---|---|
DEBUGLOG | Boolean | デバッグログを有効または無効にするかどうか。 |
USERS_DEBUG |
整数。 |
パスワードを含むクリアテキストで LDAP 操作をデバッグするために使用されます。 重要
|
ALLOW_PULLS_WITHOUT_STRICT_LOGGING | String |
true に指定すると、プルの監査ログのエントリーに書き込みできない場合でも、プルは成功します。これは、データベースが読み取り専用の状態にフォールバックし、その間プルを続行する必要がある場合に便利です。 |
ENABLE_HEALTH_DEBUG_SECRET | String | 指定していると、スーパーユーザーとして認証されていない場合に詳細なデバッグ情報を表示するために正常性エンドポイントに指定できるシークレット。 |
HEALTH_CHECKER | String |
設定済みのヘルスチェック。 |
FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL | Boolean |
集計されたログ数の取得を許可するかどうか。 |
ロギングとデバッグの例の YAML
#... DEBUGLOG: true USERS_DEBUG: 1 ALLOW_PULLS_WITHOUT_STRICT_LOGGING: "true" ENABLE_HEALTH_DEBUG_SECRET: "<secret_value>" HEALTH_CHECKER: "('RDSAwareHealthCheck', {'access_key': 'foo', 'secret_key': 'bar'})" FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL: true # ...
#...
DEBUGLOG: true
USERS_DEBUG: 1
ALLOW_PULLS_WITHOUT_STRICT_LOGGING: "true"
ENABLE_HEALTH_DEBUG_SECRET: "<secret_value>"
HEALTH_CHECKER: "('RDSAwareHealthCheck', {'access_key': 'foo', 'secret_key': 'bar'})"
FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL: true
# ...
9.1.5. レジストリーの状態およびシステム動作の設定フィールド
次の設定フィールドは、Red Hat Quay レジストリーの運用状態と、それが外部システムと対話する方法を制御します。これらの設定により、管理者はレジストリーをメンテナンス目的で制限された読み取り専用モードに配置し、特定のホスト名が Webhook がターゲットであることをブロックして追加のセキュリティーを適用できます。
フィールド | 型 | 説明 |
---|---|---|
REGISTRY_STATE | String |
レジストリーの状態 |
WEBHOOK_HOSTNAME_BLACKLIST | 文字列の配列 | 検証時に、ローカルホスト以外に Webhook から禁止するホスト名のセット。 |
レジストリーの状態とシステム動作の例(YAML)
# ... REGISTRY_STATE: normal WEBHOOK_HOSTNAME_BLACKLIST: - "169.254.169.254" - "internal.example.com" - "127.0.0.2" # ...
# ...
REGISTRY_STATE: normal
WEBHOOK_HOSTNAME_BLACKLIST:
- "169.254.169.254"
- "internal.example.com"
- "127.0.0.2"
# ...
9.2. User Experience and Interface
これらのフィールドでは、ユーザーが UI と対話する方法を設定します。これには、ブランド、ページネーション、ブラウザーの動作、recaptcha などのアクセシビリティオプションが含まれます。また、ユーザー向けのパフォーマンスと表示の設定も説明します。
9.2.1. Web UI およびユーザーエクスペリエンスの設定フィールド
これらの設定フィールドは、Red Hat Quay Web インターフェイスと全体的なユーザーエクスペリエンスの動作と外観を制御します。このセクションのオプションを使用すると、管理者はログイン動作、アバターディスプレイ、ユーザーの自動補完、セッション処理、およびカタログ可視性をカスタマイズできます。
フィールド | 型 | 説明 |
---|---|---|
AVATAR_KIND | String |
表示する avatar のタイプ。インライン(ローカル)または Gravatar (gravatar)。 |
FRESH_LOGIN_TIMEOUT | String |
新規ログイン時にユーザーがパスワードの再入力を要求されるまでの時間。 |
FEATURE_UI_V2 | Boolean | 設定すると、ユーザーは v2 ベータ UI 環境を試すことができます。
デフォルト: |
FEATURE_UI_V2_REPO_SETTINGS | Boolean |
+ デフォルト: |
FEATURE_DIRECT_LOGIN | Boolean |
ユーザーが UI に直接ログインできるかどうか |
FEATURE_PARTIAL_USER_AUTOCOMPLETE | Boolean |
true に設定すると、オートコンプリートは部分的なユーザー名に適用されます。 |
FEATURE_LIBRARY_SUPPORT | Boolean |
Docker からプルおよびプッシュするときに "名前空間のない" リポジトリーを許可するかどうか。 |
FEATURE_PERMANENT_SESSIONS | Boolean |
セッションが永続的かどうか。 |
FEATURE_PUBLIC_CATALOG | Boolean |
true に設定すると、 |
サンプル YAML
# ... AVATAR_KIND: local FRESH_LOGIN_TIMEOUT: 5m FEATURE_UI_V2: true FEATURE_UI_V2_REPO_SETTINGS: false FEATURE_DIRECT_LOGIN: true FEATURE_PARTIAL_USER_AUTOCOMPLETE: true FEATURE_LIBRARY_SUPPORT: true FEATURE_PERMANENT_SESSIONS: true FEATURE_PUBLIC_CATALOG: false # ...
# ...
AVATAR_KIND: local
FRESH_LOGIN_TIMEOUT: 5m
FEATURE_UI_V2: true
FEATURE_UI_V2_REPO_SETTINGS: false
FEATURE_DIRECT_LOGIN: true
FEATURE_PARTIAL_USER_AUTOCOMPLETE: true
FEATURE_LIBRARY_SUPPORT: true
FEATURE_PERMANENT_SESSIONS: true
FEATURE_PUBLIC_CATALOG: false
# ...
9.2.1.1. v2 ユーザーインターフェイス設定
FEATURE_UI_V2
を有効にすると、現在のバージョンのユーザーインターフェイスと新しいバージョンのユーザーインターフェイスを切り替えることができます。
- この UI は現在ベータ版であり、変更される可能性があります。現在の状態では、ユーザーは組織、リポジトリー、およびイメージタグのみを作成、表示、および削除できます。
- 古い UI で Red Hat Quay を実行している場合にセッションがタイムアウトになると、ユーザーはポップアップウィンドウでパスワードを再度入力する必要がありました。新しい UI では、ユーザーはメインページに戻り、ユーザー名とパスワードの認証情報を入力する必要があります。これは既知の問題であり、新しい UI の今後のバージョンで修正される予定です。
- 従来の UI と新しい UI の間で、イメージマニフェストのサイズが報告される方法に違いがあります。従来の UI では、イメージマニフェストはメビバイト単位で報告されていました。新しい UI では、Red Hat Quay はメガバイト (MB) の標準定義を使用して、イメージマニフェストのサイズを報告します。
9.2.2. セッションタイムアウト設定フィールド
次の設定フィールドは、同じ名前の Flask API 設定フィールドに依存しています。
セッションの有効期間を変更することは推奨できません。管理者は、セッションタイムアウトを設定するときに、割り当てられた時間を認識する必要があります。時間が早すぎると、ワークフローが中断する可能性があります。
フィールド | 型 | 説明 |
---|---|---|
PERMANENT_SESSION_LIFETIME | Integer |
永続セッションの有効期限を設定するために使用される
デフォルト: |
セッションタイムアウトの例 YAML
# ... PERMANENT_SESSION_LIFETIME: 3000 # ...
# ...
PERMANENT_SESSION_LIFETIME: 3000
# ...
9.3. ユーザーおよびアクセス管理
これらのフィールドを使用して、ユーザーの作成、認証、および管理方法を設定します。これには、スーパーユーザー、アカウントリカバリー、アプリケーション固有のトークン、ログイン動作、LDAP、OAuth、OIDC などの外部 ID プロバイダーの設定が含まれます。
9.3.1. ユーザー設定フィールド
ユーザー設定フィールドは、Red Hat Quay デプロイメントでのユーザーアカウントの動作を定義します。これらのフィールドを使用すると、ユーザーの作成、アクセスレベル、メタデータ追跡、リカバリーオプション、および名前空間管理の制御が可能になります。また、所属組織のガバナンスおよびセキュリティーポリシーに一致するように、招待のみの作成またはスーパーユーザー権限などの制限を適用することもできます。
フィールド | 型 | 説明 |
---|---|---|
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 |
設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。 |
ユーザー例の YAML
# ... FEATURE_SUPER_USERS: true FEATURE_USER_CREATION: true FEATURE_INVITE_ONLY_USER_CREATION: false FEATURE_USER_RENAME: true FEATURE_SUPERUSERS_FULL_ACCESS: true FEATURE_SUPERUSERS_ORG_CREATION_ONLY: false FEATURE_RESTRICTED_USERS: true RESTRICTED_USERS_WHITELIST: - user1 GLOBAL_READONLY_SUPER_USERS: - quayadmin FRESH_LOGIN_TIMEOUT: "5m" USER_RECOVERY_TOKEN_LIFETIME: "30m" USERFILES_LOCATION: "s3_us_east" USERFILES_PATH: "userfiles" # ...
# ...
FEATURE_SUPER_USERS: true
FEATURE_USER_CREATION: true
FEATURE_INVITE_ONLY_USER_CREATION: false
FEATURE_USER_RENAME: true
FEATURE_SUPERUSERS_FULL_ACCESS: true
FEATURE_SUPERUSERS_ORG_CREATION_ONLY: false
FEATURE_RESTRICTED_USERS: true
RESTRICTED_USERS_WHITELIST:
- user1
GLOBAL_READONLY_SUPER_USERS:
- quayadmin
FRESH_LOGIN_TIMEOUT: "5m"
USER_RECOVERY_TOKEN_LIFETIME: "30m"
USERFILES_LOCATION: "s3_us_east"
USERFILES_PATH: "userfiles"
# ...
- 1
RESTRICTED_USERS_WHITELIST
フィールドが設定されている場合、ホワイトリストに登録されたユーザーは、FEATURE_RESTRICTED_USERS
がtrue
に設定されていても、組織を作成したり、リポジトリーからコンテンツを読み書きしたりできます。user2
、user3
、およびuser4
などの他のユーザーは、組織の作成、コンテンツの読み取りまたは書き込みが制限されます。
9.3.2. ロボットアカウント設定フィールド
以下の設定フィールドを使用すると、ロボットアカウントの作成および対話をグローバルに拒否できます。
関連情報
フィールド | 型 | 説明 |
---|---|---|
ROBOTS_DISALLOW | Boolean |
|
Robot account disallow example YAML
# ... ROBOTS_DISALLOW: true # ...
# ...
ROBOTS_DISALLOW: true
# ...
9.3.3. LDAP 設定フィールド
以下の設定フィールドを使用すると、管理者は Red Hat Quay と LDAP ベースの認証システムを統合できます。AUTHENTICATION_TYPE
が LDAP
に設定されている場合、Red Hat Quay は LDAP ディレクトリーに対してユーザーを認証し、チームの同期、スーパーユーザーアクセス制御、制限付きユーザーロール、セキュアな接続パラメーターなどのオプション機能をサポートします。
このセクションでは、以下の LDAP シナリオの YAML の例を紹介します。
- 基本的な LDAP 設定
- LDAP 制限付きユーザー設定
- LDAP スーパーユーザー設定
フィールド | 型 | 説明 |
---|---|---|
AUTHENTICATION_TYPE | String |
|
FEATURE_TEAM_SYNCING | Boolean |
認証エンジン (OIDC、LDAP または Keystone) のバッキンググループからのチームメンバーシップの同期を許可するかどうか。 |
FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP | Boolean |
有効にすると、スーパーユーザー以外のユーザーもチームの同期を設定できます。 |
LDAP_ADMIN_DN | String | LDAP 認証の管理 DN。 |
LDAP_ADMIN_PASSWD | String | LDAP 認証の管理パスワード。 |
LDAP_ALLOW_INSECURE_FALLBACK | Boolean | LDAP 認証で SSL の非セキュアなフォールバックを許可するかどうか。 |
LDAP_BASE_DN | 文字列の配列 | LDAP 認証のベース DN。 |
LDAP_EMAIL_ATTR | String | LDAP 認証のメール属性。 |
LDAP_UID_ATTR | String | LDAP 認証の uid 属性。 |
LDAP_URI | String | LDAP URI。 |
LDAP_USER_FILTER | String | LDAP 認証のユーザーフィルター。 |
LDAP_USER_RDN | 文字列の配列 | LDAP 認証のユーザー RDN。 |
LDAP_SECONDARY_USER_RDNS | 文字列の配列 | ユーザーオブジェクトが存在する組織単位が複数ある場合は、Secondary User Relative DNs を指定します。 |
TEAM_RESYNC_STALE_TIME | String |
チームでチーム同期が有効になっている場合は、そのメンバーシップを確認し、必要に応じて再同期する頻度。 |
LDAP_SUPERUSER_FILTER | String |
このフィールドを使用すると、管理者は Red Hat Quay 設定ファイルを更新してデプロイメントを再起動することなく、スーパーユーザーを追加または削除できます。
このフィールドでは、 |
LDAP_GLOBAL_READONLY_SUPERUSER_FILTER | String |
設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。 |
LDAP_RESTRICTED_USER_FILTER | String |
このフィールドでは、 |
FEATURE_RESTRICTED_USERS | Boolean |
デフォルト: |
LDAP_TIMEOUT | Integer |
LDAP 操作の時間制限を秒単位で指定します。これにより、LDAP 検索、バインド、またはその他の操作にかかる時間が制限されます。 |
LDAP_NETWORK_TIMEOUT | Integer |
LDAP サーバーへの接続を確立するための時間制限を秒単位で指定します。これは、 |
基本的な 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: - dc=example - dc=com LDAP_EMAIL_ATTR: mail LDAP_UID_ATTR: uid LDAP_URI: ldap://<example_url>.com LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,dc=<domain_name>,dc=com) LDAP_USER_RDN: - ou=people LDAP_SECONDARY_USER_RDNS: - ou=<example_organization_unit_one> - ou=<example_organization_unit_two> - ou=<example_organization_unit_three> - ou=<example_organization_unit_four>
# ...
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:
- dc=example
- dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldap://<example_url>.com
LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,dc=<domain_name>,dc=com)
LDAP_USER_RDN:
- ou=people
LDAP_SECONDARY_USER_RDNS:
- ou=<example_organization_unit_one>
- ou=<example_organization_unit_two>
- ou=<example_organization_unit_three>
- ou=<example_organization_unit_four>
- 1
- 必須。
LDAP
に設定する必要があります。 - 2
- 必須。LDAP 認証の管理 DN。
- 3
- 必須。LDAP 認証の管理パスワード。
- 4
- 必須。LDAP 認証に SSL/TLS の安全でないフォールバックを許可するかどうか。
- 5
- 必須。LDAP 認証のベース DN。
- 6
- 必須。LDAP 認証のメール属性。
- 7
- 必須。LDAP 認証の UID 属性。
- 8
- 必須。LDAP URI。
- 9
- 必須。LDAP 認証のユーザーフィルター。
- 10
- 必須。LDAP 認証のユーザー RDN。
- 11
- オプション: ユーザーオブジェクトが存在する組織単位が複数ある場合の Secondary User Relative DN。
LDAP 制限付きユーザー設定の例 YAML
# ... AUTHENTICATION_TYPE: LDAP # ... FEATURE_RESTRICTED_USERS: true # ... 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 # ...
# ...
AUTHENTICATION_TYPE: LDAP
# ...
FEATURE_RESTRICTED_USERS: true
# ...
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
# ...
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 # ...
# ...
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
# ...
- 1
- 指定されたユーザーをスーパーユーザーとして設定します。
9.3.4. OAuth 設定フィールド
以下のフィールドは、OAuth を使用して外部 ID プロバイダーによる認証を処理する際の Red Hat Quay の動作を定義します。トークンの割り当てやホワイトリスト化されたクライアント ID、GitHub および Google のプロバイダー固有の設定などのグローバル OAuth オプションを設定できます。
フィールド | 型 | 説明 |
---|---|---|
DIRECT_OAUTH_CLIENTID_WHITELIST | 文字列の配列 | ユーザーの承認なしに直接 OAuth 承認を実行できる Quay 管理 アプリケーションのクライアント ID のリスト。 |
FEATURE_ASSIGN_OAUTH_TOKEN | Boolean | 組織管理者が他のユーザーに OAuth トークンを割り当てることを許可します。 |
グローバル OAuth の例の YAML
# ... DIRECT_OAUTH_CLIENTID_WHITELIST: - <quay_robot_client> - <quay_app_token_issuer> FEATURE_ASSIGN_OAUTH_TOKEN: true # ...
# ...
DIRECT_OAUTH_CLIENTID_WHITELIST:
- <quay_robot_client>
- <quay_app_token_issuer>
FEATURE_ASSIGN_OAUTH_TOKEN: true
# ...
関連情報
フィールド | 型 | 説明 |
---|---|---|
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。 |
.CLIENT_SECRET | String |
この Red Hat Quay インスタンスの登録されたクライアントシークレット。 |
.GITHUB_ENDPOINT | String |
GitHub (Enterprise) のエンドポイント。 |
.ORG_RESTRICT | Boolean | true の場合は、組織のホワイトリスト内のユーザーのみが、このプロバイダーを使用してログインできます。 |
GitHub OAth のサンプル YAML
# ... FEATURE_GITHUB_LOGIN: true GITHUB_LOGIN_CONFIG: ALLOWED_ORGANIZATIONS: - <myorg> - <dev-team> API_ENDPOINT: <https://api.github.com/> CLIENT_ID: <client_id> CLIENT_SECRET: <client_secret> GITHUB_ENDPOINT: <https://github.com/> ORG_RESTRICT: true # ...
# ...
FEATURE_GITHUB_LOGIN: true
GITHUB_LOGIN_CONFIG:
ALLOWED_ORGANIZATIONS:
- <myorg>
- <dev-team>
API_ENDPOINT: <https://api.github.com/>
CLIENT_ID: <client_id>
CLIENT_SECRET: <client_secret>
GITHUB_ENDPOINT: <https://github.com/>
ORG_RESTRICT: true
# ...
フィールド | 型 | 説明 |
---|---|---|
FEATURE_GOOGLE_LOGIN | Boolean |
Google ログインがサポートされるかどうか。 |
GOOGLE_LOGIN_CONFIG | Object | 外部認証に Google を使用するための設定。 |
.CLIENT_ID | String |
この Red Hat Quay インスタンスの登録されたクライアント ID。 |
.CLIENT_SECRET | String |
この Red Hat Quay インスタンスの登録されたクライアントシークレット。 |
Google OAuth の例 YAML
# ... FEATURE_GOOGLE_LOGIN: true GOOGLE_LOGIN_CONFIG: CLIENT_ID: <client_id> CLIENT_SECRET: <client_secret> # ...
# ...
FEATURE_GOOGLE_LOGIN: true
GOOGLE_LOGIN_CONFIG:
CLIENT_ID: <client_id>
CLIENT_SECRET: <client_secret>
# ...
9.3.5. OIDC 設定フィールド
Azure Entra ID (以前の Azure AD)、Okta、Keycloak など、OpenID Connect (OIDC)互換アイデンティティープロバイダーを介してユーザーを認証するように Red Hat Quay を設定できます。これらのフィールドは、OIDC ログインフロー時に使用される必要なクライアント認証情報、エンドポイント、およびトークンの動作を定義します。
フィールド | 型 | 説明 |
---|---|---|
<文字列>_LOGIN_CONFIG | String |
OIDC 設定を保持する親キー。通常は、OIDC プロバイダーの名前 ( |
.CLIENT_ID | String |
この Red Hat Quay インスタンスの登録されたクライアント ID。 |
.CLIENT_SECRET | String |
Red Hat Quay インスタンスの登録クライアントシークレット。 |
.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 | ユーザーの電子メールアドレスを確認するために使用されるクレームの名前。 |
.PREFERRED_GROUP_CLAIM_NAME | String | ユーザーのグループメンバーシップに関する情報を保持する OIDC トークンペイロード内のキー名。 |
.OIDC_DISABLE_USER_ENDPOINT | Boolean |
|
OIDC 例の YAML
AUTHENTICATION_TYPE: OIDC # ... <oidc_provider>_LOGIN_CONFIG: CLIENT_ID: <client_id> CLIENT_SECRET: <client_secret> LOGIN_BINDING_FIELD: <login_binding_field> LOGIN_SCOPES: - openid - email - profile OIDC_ENDPOINT_CUSTOM_PARAMS: authorization_endpoint: some: "param" token_endpoint: some: "param" user_endpoint: some: "param" OIDC_ISSUER: <oidc_issuer_url> OIDC_SERVER: <oidc_server_address> PREFERRED_USERNAME_CLAIM_NAME: <preferred_username_claim> SERVICE_ICON: <service_icon_url> SERVICE_NAME: <service_name> VERIFIED_EMAIL_CLAIM_NAME: <verified_email_claim> PREFERRED_GROUP_CLAIM_NAME: <preferred_group_claim> OIDC_DISABLE_USER_ENDPOINT: true # ...
AUTHENTICATION_TYPE: OIDC
# ...
<oidc_provider>_LOGIN_CONFIG:
CLIENT_ID: <client_id>
CLIENT_SECRET: <client_secret>
LOGIN_BINDING_FIELD: <login_binding_field>
LOGIN_SCOPES:
- openid
- email
- profile
OIDC_ENDPOINT_CUSTOM_PARAMS:
authorization_endpoint:
some: "param"
token_endpoint:
some: "param"
user_endpoint:
some: "param"
OIDC_ISSUER: <oidc_issuer_url>
OIDC_SERVER: <oidc_server_address>
PREFERRED_USERNAME_CLAIM_NAME: <preferred_username_claim>
SERVICE_ICON: <service_icon_url>
SERVICE_NAME: <service_name>
VERIFIED_EMAIL_CLAIM_NAME: <verified_email_claim>
PREFERRED_GROUP_CLAIM_NAME: <preferred_group_claim>
OIDC_DISABLE_USER_ENDPOINT: true
# ...
9.3.6. Recaptcha 設定フィールド
Red Hat Quay インスタンスで Recaptcha サポートを有効にすると、自動システムによるユーザーのログインおよびアカウントの回復フォームの保護に役立ちます。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_RECAPTCHA | Boolean |
ユーザーログインおよびリカバリーに Recaptcha が必要かどうか |
RECAPTCHA_SECRET_KEY | String | recaptcha が有効になっている場合は、Recaptcha サービスの秘密鍵 |
RECAPTCHA_SITE_KEY | String | recaptcha が有効になっている場合は、Recaptcha サービスのサイトキー |
reCAPTCHA の例の YAML
# ... FEATURE_RECAPTCHA: true RECAPTCHA_SITE_KEY: "<site_key>" RECAPTCHA_SECRET_KEY: "<secret_key>" # ...
# ...
FEATURE_RECAPTCHA: true
RECAPTCHA_SITE_KEY: "<site_key>"
RECAPTCHA_SECRET_KEY: "<secret_key>"
# ...
9.3.7. JWT 設定フィールド
Red Hat Quay は、JSON Web Token (JWT)を使用して外部認証をサポートするように設定できます。このインテグレーションにより、サードパーティーのアイデンティティープロバイダーまたはトークン発行者は、トークンの検証、ユーザールックアップ、およびパーミッションクエリーを処理する特定のエンドポイントを呼び出して、ユーザーを認証および承認できます。
フィールド | 型 | 説明 |
---|---|---|
JWT_AUTH_ISSUER | String |
JWT ユーザーのエンドポイント |
JWT_GETUSER_ENDPOINT | String |
JWT ユーザーのエンドポイント |
JWT_QUERY_ENDPOINT | String |
JWT クエリーのエンドポイント |
JWT_VERIFY_ENDPOINT | String |
JWT 検証のエンドポイント |
JWT 例の YAML
# ... JWT_AUTH_ISSUER: "http://192.168.99.101:6060" JWT_GETUSER_ENDPOINT: "http://192.168.99.101:6060/getuser" JWT_QUERY_ENDPOINT: "http://192.168.99.101:6060/query" JWT_VERIFY_ENDPOINT: "http://192.168.99.101:6060/verify" # ...
# ...
JWT_AUTH_ISSUER: "http://192.168.99.101:6060"
JWT_GETUSER_ENDPOINT: "http://192.168.99.101:6060/getuser"
JWT_QUERY_ENDPOINT: "http://192.168.99.101:6060/query"
JWT_VERIFY_ENDPOINT: "http://192.168.99.101:6060/verify"
# ...
9.3.8. アプリケーショントークン設定フィールド
アプリケーション固有のトークンにより、ユーザーはトークンベースの認証情報を使用して Red Hat Quay で認証できるようになります。これらのフィールドは、Docker などの CLI ツールに役に立ちます。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_APP_SPECIFIC_TOKENS | Boolean |
有効な場合、ユーザーは Docker CLI で使用するトークンを作成できます。 |
APP_SPECIFIC_TOKEN_EXPIRATION | String |
外部アプリトークンの有効期限。 |
EXPIRED_APP_SPECIFIC_TOKEN_GC | String |
期限切れとなった外部アプリケーションがガべージコレクションが行われるまでに留まる期間。 |
アプリケーショントークンの例 YAML
# ... FEATURE_APP_SPECIFIC_TOKENS: true APP_SPECIFIC_TOKEN_EXPIRATION: "30d" EXPIRED_APP_SPECIFIC_TOKEN_GC: "1d" # ...
# ...
FEATURE_APP_SPECIFIC_TOKENS: true
APP_SPECIFIC_TOKEN_EXPIRATION: "30d"
EXPIRED_APP_SPECIFIC_TOKEN_GC: "1d"
# ...
9.4. セキュリティーおよびパーミッション
このセクションでは、Red Hat Quay 内のコアセキュリティー動作およびアクセスポリシーを管理する設定フィールドについて説明します。
9.4.1. 名前空間およびリポジトリー管理設定フィールド
次の設定フィールドは、自動イメージのプッシュ中の動作、可視性のデフォルト、およびレート制限例外を含む、Red Hat Quay による namespace とリポジトリーの管理方法を管理します。
フィールド | 型 | 説明 |
---|---|---|
DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT | 数値 |
namespace でキューに入れることができるデフォルトの最大ビルド数です。 |
CREATE_PRIVATE_REPO_ON_PUSH | Boolean |
プッシュで作成された新規リポジトリーがプライベート表示に設定されているかどうか。 |
CREATE_NAMESPACE_ON_PUSH | Boolean |
既存の組織への新規プッシュで namespace を作成するかどうか。 |
PUBLIC_NAMESPACES | 文字列の配列 | 名前空間がパブリック名前空間リストで定義されている場合、ユーザーが名前空間のメンバーであるかどうかに関係なく、その名前空間は すべて のユーザーのリポジトリーリストページに表示されます。一般的には、企業のお客様が "よく知られた" 名前空間のセットを設定する際に使用されます。 |
NON_RATE_LIMITED_NAMESPACES | 文字列の配列 |
|
DISABLE_PUSHES | Boolean |
他のすべての機能を維持しながら、レジストリーへの新しいコンテンツのプッシュを無効にします。データベースが |
namespace とリポジトリー管理の例 YAML
# ... DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT: 10 CREATE_PRIVATE_REPO_ON_PUSH: true CREATE_NAMESPACE_ON_PUSH: false PUBLIC_NAMESPACES: - redhat - opensource - infra-tools NON_RATE_LIMITED_NAMESPACES: - ci-pipeline - trusted-partners DISABLE_PUSHES: false # ...
# ...
DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT: 10
CREATE_PRIVATE_REPO_ON_PUSH: true
CREATE_NAMESPACE_ON_PUSH: false
PUBLIC_NAMESPACES:
- redhat
- opensource
- infra-tools
NON_RATE_LIMITED_NAMESPACES:
- ci-pipeline
- trusted-partners
DISABLE_PUSHES: false
# ...
9.4.2. ネストされたリポジトリー設定フィールド
ネストされたリポジトリーパス名のサポートが FEATURE_EXTENDED_REPOSITORY_NAMES
プロパティーに追加されました。このオプションの設定は、デフォルトで config.yaml
に追加されます。有効にすると、リポジトリー名で /
を使用できます。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_EXTENDED_REPOSITORY_NAMES | Boolean |
ネストされたリポジトリーのサポートを有効にします。 |
ネストされたリポジトリーの例 YAML
# ... FEATURE_EXTENDED_REPOSITORY_NAMES: true # ...
# ...
FEATURE_EXTENDED_REPOSITORY_NAMES: true
# ...
9.5. 追加のセキュリティー設定フィールド
以下の設定フィールドは、Red Hat Quay デプロイメントの追加のセキュリティー制御を提供します。これらのオプションにより、管理者は、認証プラクティスの適用、コンテンツへの匿名アクセスの制御、チームの招待が必要、セキュリティー要件が強化された環境で FIPS 準拠の暗号化機能を有効にすることができます。
機能 | 型 | 説明 |
---|---|---|
FEATURE_REQUIRE_TEAM_INVITE | Boolean |
ユーザーをチームに追加するときに招待を必要とするかどうか。 |
FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH | Boolean |
(暗号化されたトークンではなく) 暗号化されていないパスワードを Basic 認証に使用できるかどうか |
FEATURE_ANONYMOUS_ACCESS | Boolean |
匿名ユーザーにパブリックリポジトリーの参照とプルを許可するかどうか。 |
FEATURE_FIPS | Boolean |
true に設定すると、Red Hat Quay は FIPS 準拠のハッシュ関数を使用して実行されます。 |
追加のセキュリティー例 YAML
# ... FEATURE_REQUIRE_TEAM_INVITE: true FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH: false FEATURE_ANONYMOUS_ACCESS: true FEATURE_FIPS: false # ...
# ...
FEATURE_REQUIRE_TEAM_INVITE: true
FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH: false
FEATURE_ANONYMOUS_ACCESS: true
FEATURE_FIPS: false
# ...
9.6. レート制限およびパフォーマンス設定フィールド
以下のフィールドは、Red Hat Quay デプロイメントのレート制限およびパフォーマンス関連の動作を制御します。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_RATE_LIMITS | Boolean |
API およびレジストリーエンドポイントでレート制限を有効にするかどうか。FEATURE_RATE_LIMITS を |
PROMETHEUS_NAMESPACE | String |
公開されているすべての Prometheus メトリクスに適用される接頭辞。 |
レート制限とパフォーマンスの例 YAML
# ... FEATURE_RATE_LIMITS: false PROMETHEUS_NAMESPACE: quay # ...
# ...
FEATURE_RATE_LIMITS: false
PROMETHEUS_NAMESPACE: quay
# ...
9.7. 設定フィールドの検索
次の設定フィールドは、Red Hat Quay ユーザーインターフェイスで検索結果がどのようにページ分割されるかを定義します。
フィールド | 型 | 説明 |
---|---|---|
SEARCH_MAX_RESULT_PAGE_COUNT | 数値 |
ユーザーが検索で表示できる最大ページ数。 |
SEARCH_RESULTS_PER_PAGE | 数値 |
検索ページでページごとに返される結果数。 |
検索例の YAML
# ... SEARCH_MAX_RESULT_PAGE_COUNT: 10 SEARCH_RESULTS_PER_PAGE: 10 # ...
# ...
SEARCH_MAX_RESULT_PAGE_COUNT: 10
SEARCH_RESULTS_PER_PAGE: 10
# ...
9.8. ストレージおよびデータ管理
このセクションでは、Red Hat Quay がデータを保存、管理、および監査する方法を管理する設定フィールドについて説明します。
9.8.1. イメージストレージ機能
Red Hat Quay は、コンテナーイメージデータの管理におけるスケーラビリティー、耐障害性、および柔軟性を強化するイメージストレージ機能をサポートしています。この機能により、Red Hat Quay はリポジトリーをミラーリングし、NGINX を介したプロキシーストレージアクセスを提供し、複数のストレージエンジン間でデータを複製できます。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_REPO_MIRROR | Boolean |
true に設定されている場合は、リポジトリーのミラーリングを有効にします。 |
FEATURE_PROXY_STORAGE | Boolean |
NGINX を使用してストレージ内のすべての直接ダウンロード URL をプロキシーするかどうか。 |
FEATURE_STORAGE_REPLICATION | Boolean |
ストレージエンジン間で自動的にレプリケートするかどうか。 |
イメージストレージの例 YAML
# ... FEATURE_REPO_MIRROR: true FEATURE_PROXY_STORAGE: false FEATURE_STORAGE_REPLICATION: true # ...
# ...
FEATURE_REPO_MIRROR: true
FEATURE_PROXY_STORAGE: false
FEATURE_STORAGE_REPLICATION: true
# ...
9.8.2. アクションログストレージ設定フィールド
Red Hat Quay は、リポジトリーイベント、認証アクション、イメージ操作など、ユーザーおよびシステムアクティビティーを追跡する詳細なアクションログを維持します。デフォルトでは、このログデータはデータベースに保存されますが、管理者は高度な分析、監査、またはコンプライアンスのために Elasticsearch や Splunk などの外部システムにログをエクスポートまたは転送するようにデプロイメントを設定できます。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_LOG_EXPORT | Boolean |
アクションログのエクスポートを許可するかどうか。 |
LOGS_MODEL | String |
ログデータを処理するための推奨される方法を指定します。 |
LOGS_MODEL_CONFIG | Object | アクションログのログモデル設定。 |
ALLOW_WITHOUT_STRICT_LOGGING | Boolean |
|
アクションログストレージ YAML の例
# ... FEATURE_LOG_EXPORT: true LOGS_MODEL: elasticsearch LOGS_MODEL_CONFIG: elasticsearch: endpoint: http://elasticsearch.example.com:9200 index_prefix: quay-logs username: elastic password: changeme ALLOW_WITHOUT_STRICT_LOGGING: true # ...
# ...
FEATURE_LOG_EXPORT: true
LOGS_MODEL: elasticsearch
LOGS_MODEL_CONFIG:
elasticsearch:
endpoint: http://elasticsearch.example.com:9200
index_prefix: quay-logs
username: elastic
password: changeme
ALLOW_WITHOUT_STRICT_LOGGING: true
# ...
9.8.2.1. アクションログのローテーションおよびアーカイブ設定
このセクションでは、Red Hat Quay でのアクションログのローテーションおよびアーカイブに関連する設定フィールドについて説明します。これを有効にすると、古いログを自動的にローテーションおよびアーカイブして、指定されたストレージの場所にアーカイブすることができ、ログの保持とストレージの使用率を効率的に管理できるようになります。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_ACTION_LOG_ROTATION | Boolean |
ログローテーションおよび archival を有効にすると、30 日以上経過したすべてのログをストレージに移動します。 |
ACTION_LOG_ARCHIVE_LOCATION | String |
アクションログのアーカイブが有効な場合は、アーカイブされたデータを配置するストレージエンジン。 |
ACTION_LOG_ARCHIVE_PATH | String |
アクションログのアーカイブが有効な場合は、アーカイブされたデータを配置するストレージのパス。 |
ACTION_LOG_ROTATION_THRESHOLD | String |
ログをローテーションする間隔。 |
アクションログのローテーションおよびアーカイブ例の YAML
# ... FEATURE_ACTION_LOG_ROTATION: true ACTION_LOG_ARCHIVE_LOCATION: s3_us_east ACTION_LOG_ARCHIVE_PATH: archives/actionlogs ACTION_LOG_ROTATION_THRESHOLD: 30d # ...
# ...
FEATURE_ACTION_LOG_ROTATION: true
ACTION_LOG_ARCHIVE_LOCATION: s3_us_east
ACTION_LOG_ARCHIVE_PATH: archives/actionlogs
ACTION_LOG_ROTATION_THRESHOLD: 30d
# ...
9.8.2.2. アクションログの監査設定
このセクションでは、Red Hat Quay 内の監査ログの設定フィールドを説明します。有効にすると、監査ログは、通常のユーザー、ロボットアカウント、トークンベースのアカウントの UI ログイン、ログアウト、Docker ログインなど、詳細なユーザーアクティビティーを追跡します。
フィールド | 型 | 説明 |
---|---|---|
ACTION_LOG_AUDIT_LOGINS | Boolean |
|
監査ログ設定の例の YAML
# ... ACTION_LOG_AUDIT_LOGINS: true # ...
# ...
ACTION_LOG_AUDIT_LOGINS: true
# ...
9.8.3. Elasticsearch 設定フィールド
以下の設定フィールドを使用して、Red Hat Quay を外部 Elasticsearch サービスと統合します。これにより、アクションログ、リポジトリーイベント、内部データベース外のその他の運用レコードなど、構造化データを保存およびクエリーできます。
フィールド | 型 | 説明 |
---|---|---|
LOGS_MODEL_CONFIG.elasticsearch_config.access_key | String |
Elasticsearch ユーザー(AWS ES の場合は IAM キー)。 |
.elasticsearch_config.host | String |
Elasticsearch クラスターのエンドポイント。 |
.elasticsearch_config.index_prefix | String |
Elasticsearch インデックスの接頭辞。 |
.elasticsearch_config.index_settings | Object | Elasticsearch のインデックス設定。 |
LOGS_MODEL_CONFIG.elasticsearch_config.use_ssl | Boolean |
Elasticsearch に SSL を使用するかどうか。 |
.elasticsearch_config.secret_key | String |
Elasticsearch パスワード(AWS ES の場合は IAM シークレット)。 |
.elasticsearch_config.aws_region | String |
AWS リージョン。 |
.elasticsearch_config.port | 数値 |
Elasticsearch クラスターのポート。 |
.kinesis_stream_config.aws_secret_key | String |
AWS secret key。 |
.kinesis_stream_config.stream_name | String |
アクションログの送信先となる AWS Kinesis ストリーム。 |
.kinesis_stream_config.aws_access_key | String |
AWS アクセスキー。 |
.kinesis_stream_config.retries | 数値 |
1 回のリクエストの最大再試行回数。 |
.kinesis_stream_config.read_timeout | 数値 |
読み取りタイムアウト(秒単位)。 |
.kinesis_stream_config.max_pool_connections | 数値 |
プールの最大接続数。 |
.kinesis_stream_config.aws_region | String |
AWS リージョン。 |
.kinesis_stream_config.connect_timeout | 数値 |
接続タイムアウト(秒単位)。 |
.producer | String |
プロデューサータイプをログに記録します。 |
.kafka_config.topic | String |
ログエントリーの公開に使用される Kafka トピック。 |
.kafka_config.bootstrap_servers | アレイ | クライアントのブートストラップに使用される Kafka ブローカーのリスト。 |
.kafka_config.max_block_seconds | 数値 |
|
Elasticsearch の例の YAML
# ... FEATURE_LOG_EXPORT: true LOGS_MODEL: elasticsearch LOGS_MODEL_CONFIG: producer: elasticsearch elasticsearch_config: access_key: elastic_user secret_key: elastic_password host: es.example.com port: 9200 use_ssl: true aws_region: us-east-1 index_prefix: logentry_ index_settings: number_of_shards: 3 number_of_replicas: 1 ALLOW_WITHOUT_STRICT_LOGGING: true # ...
# ...
FEATURE_LOG_EXPORT: true
LOGS_MODEL: elasticsearch
LOGS_MODEL_CONFIG:
producer: elasticsearch
elasticsearch_config:
access_key: elastic_user
secret_key: elastic_password
host: es.example.com
port: 9200
use_ssl: true
aws_region: us-east-1
index_prefix: logentry_
index_settings:
number_of_shards: 3
number_of_replicas: 1
ALLOW_WITHOUT_STRICT_LOGGING: true
# ...
9.8.3.1. Splunk 設定フィールド
次のフィールドを使用して、アクションログを Splunk エンドポイントにエクスポートするように Red Hat Quay を設定します。この設定により、監査ログとイベントログを外部 Splunk サーバーに送信して、集中分析、検索、および長期保存を行うことができます。
フィールド | 型 | 説明 |
---|---|---|
producer | String |
Splunk をログエクスポーターとして設定する場合は、 |
splunk_config | Object | Splunk アクションログまたは Splunk クラスター設定のログモデル設定。 |
.host | String | Splunk クラスターのエンドポイント。 |
.port | Integer | Splunk 管理クラスターエンドポイントのポート番号。 |
.BEARER_TOKEN | String | Splunk での認証に使用されるベアラートークン。 |
.verify_ssl | Boolean |
HTTPS 接続の TLS/SSL 検証を有効( |
.index_prefix | String | Splunk によって使用されるインデックス接頭辞。 |
.ssl_ca_path | String |
SSL 検証用の認証局(CA)を含む |
Splunk 設定例の YAML
# ... LOGS_MODEL: splunk LOGS_MODEL_CONFIG: producer: splunk splunk_config: host: http://<user_name>.remote.csb port: 8089 bearer_token: <bearer_token> url_scheme: <http/https> verify_ssl: False index_prefix: <splunk_log_index_name> ssl_ca_path: <location_to_ssl-ca-cert.pem> # ...
# ...
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>
# ...
9.8.3.1.1. Splunk HEC 設定フィールド
Red Hat Quay 用に Splunk HTTP Event Collector (HEC) を設定する場合は、次のフィールドを使用できます。
フィールド | 型 | 説明 |
---|---|---|
producer | String |
Splunk HTTP Event Collector (HEC)を設定する場合は、 |
splunk_hec_config | Object | Splunk HTTP Event Collector アクションログのログモデル設定。 |
.host | String | Splunk クラスターのエンドポイント。 |
.port | Integer | Splunk 管理クラスターのエンドポイントポート。 |
.hec_token | String | Splunk での認証に使用される HEC トークン。 |
.url_scheme | String |
Splunk サービスにアクセスするための URL スキーム。Splunk が SSL/TLS の背後にある場合は、 |
.verify_ssl | Boolean |
HTTPS 接続の SSL/TLS 検証を有効( |
.index | String | ログストレージに使用する Splunk インデックス。 |
.splunk_host | String | ログに記録されたイベントに割り当てるホスト名。 |
.splunk_sourcetype | String |
イベントに関連付ける Splunk |
Splunk HEC 例 YAML
# ... LOGS_MODEL: splunk LOGS_MODEL_CONFIG: producer: splunk_hec splunk_hec_config: host: prd-p-aaaaaq.splunkcloud.com port: 8088 hec_token: 12345678-1234-1234-1234-1234567890ab url_scheme: https verify_ssl: False index: quay splunk_host: quay-dev splunk_sourcetype: quay_logs # ...
# ...
LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
producer: splunk_hec
splunk_hec_config:
host: prd-p-aaaaaq.splunkcloud.com
port: 8088
hec_token: 12345678-1234-1234-1234-1234567890ab
url_scheme: https
verify_ssl: False
index: quay
splunk_host: quay-dev
splunk_sourcetype: quay_logs
# ...
9.9. ビルドと自動化
このセクションでは、Red Hat Quay 内で自動ビルドを管理するために利用できる設定オプションを説明します。これらの設定は、Dockerfile のビルドのトリガー、処理、保存方法、およびビルドログの管理およびアクセス方法を制御します。
これらのフィールドを使用すると、以下のことができます。
- ソースリポジトリーからの自動ビルドを有効または無効にします。
- ビルドマネージャーの動作およびリソース管理を設定します。
- 監査またはデバッグ目的で、ビルドログへのアクセスおよび保持を制御します。
これらのオプションにより、CI/CD パイプラインを合理化し、ビルドポリシーの適用、レジストリー全体でビルド履歴の可視性を維持するのに役立ちます。
関連情報
9.9.1. Dockerfile ビルドトリガーフィールド
このセクションでは、Dockerfiles およびソースコードリポジトリーから Red Hat Quay での自動ビルドを有効にし、管理するために使用される設定フィールドについて説明します。これらのフィールドでは、ビルドの動作を定義し、GitHub、GitLab、および Bitbucket トリガーのサポートを有効にし、各 SCM プロバイダーの OAuth 認証情報およびエンドポイントを指定できます。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_BUILD_SUPPORT | Boolean |
Dockerfile ビルドをサポートするかどうか |
SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD | 数値 |
|
SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD | 数値 |
|
Dockerfile ビルドのサポートサンプル YAML
# ... FEATURE_BUILD_SUPPORT: true SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD: 100 SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD: 5 # ...
# ...
FEATURE_BUILD_SUPPORT: true
SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD: 100
SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD: 5
# ...
フィールド | 型 | 説明 |
---|---|---|
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 インスタンスの登録されたクライアントシークレット。 |
GitHub ビルドトリガーの例 YAML
# ... FEATURE_GITHUB_BUILD: true GITHUB_TRIGGER_CONFIG: GITHUB_ENDPOINT: https://github.com/ API_ENDPOINT: https://api.github.com/ CLIENT_ID: your-client-id CLIENT_SECRET: your-client-secret # ...
# ...
FEATURE_GITHUB_BUILD: true
GITHUB_TRIGGER_CONFIG:
GITHUB_ENDPOINT: https://github.com/
API_ENDPOINT: https://api.github.com/
CLIENT_ID: your-client-id
CLIENT_SECRET: your-client-secret
# ...
フィールド | 型 | 説明 |
---|---|---|
FEATURE_BITBUCKET_BUILD | Boolean |
Bitbucket ビルドトリガーをサポートするかどうか。 |
BITBUCKET_TRIGGER_CONFIG | Object | ビルドトリガーに BitBucket を使用するための設定。 |
.CONSUMER_KEY | String | この Red Hat Quay インスタンスの登録済みコンシューマーキー (クライアント ID)。 |
.CONSUMER_SECRET | String | この Red Hat Quay インスタンスの登録済みコンシューマーシークレット (クライアントシークレット)。 |
Bitbucket ビルドトリガーの例 YAML
# ... FEATURE_BITBUCKET_BUILD: true BITBUCKET_TRIGGER_CONFIG: CONSUMER_KEY: <your_consumer_key> CONSUMER_SECRET: <your-consumer-secret> # ...
# ...
FEATURE_BITBUCKET_BUILD: true
BITBUCKET_TRIGGER_CONFIG:
CONSUMER_KEY: <your_consumer_key>
CONSUMER_SECRET: <your-consumer-secret>
# ...
フィールド | 型 | 説明 |
---|---|---|
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 インスタンスの登録されたクライアントシークレット。 |
GitLab ビルドトリガーの例 YAML
# ... FEATURE_GITLAB_BUILD: true GITLAB_TRIGGER_CONFIG: GITLAB_ENDPOINT: https://gitlab.example.com/ CLIENT_ID: <your_gitlab_client_id> CLIENT_SECRET: <your_gitlab_client_secret> # ...
# ...
FEATURE_GITLAB_BUILD: true
GITLAB_TRIGGER_CONFIG:
GITLAB_ENDPOINT: https://gitlab.example.com/
CLIENT_ID: <your_gitlab_client_id>
CLIENT_SECRET: <your_gitlab_client_secret>
# ...
9.9.2. ビルドマネージャー設定フィールド
以下の設定フィールドは、Red Hat Quay のビルドマネージャーコンポーネントがコンテナーイメージのビルドをオーケストレーションおよび管理する方法を制御します。これには、Redis の調整、Kubernetes、EC2、ビルダーイメージ設定などのエグゼキューターバックエンド、高度なスケジューリングおよび再試行ポリシーの設定が含まれます。
これらのフィールドは、インフラストラクチャー環境およびワークロードの要件に合わせて設定する必要があります。
フィールド | 型 | 説明 |
---|---|---|
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.14 です。 |
BUILDER_VM_CONTAINER_IMAGE | Object |
各 Red Hat Quay ビルドの実行に必要な内部仮想マシンを保持するコンテナーイメージの完全な参照 ( |
SETUP_TIME | String |
ビルドがまだビルドマネージャーに登録されていない場合に、タイムアウトする秒数を指定します。デフォルトは |
MINIMUM_RETRY_THRESHOLD | String |
この設定は、複数のエグゼキューターで使用されます。別のエグゼキューターを選択するまでに、ビルドの開始を何回再試行するかを示します。 |
SSH_AUTHORIZED_KEYS | Object |
|
ビルドマネージャー設定フィールド
# ... ALLOWED_WORKER_COUNT: "1" ORCHESTRATOR_PREFIX: "quaybuild:" REDIS_HOST: redis.example.com REDIS_PASSWORD: examplepassword REDIS_SSL: true REDIS_SKIP_KEYSPACE_EVENT_SETUP: false EXECUTOR: kubernetes BUILDER_NAMESPACE: quay-builder K8S_API_SERVER: https://api.openshift.example.com:6443 K8S_API_TLS_CA: /etc/ssl/certs/ca.crt KUBERNETES_DISTRIBUTION: openshift CONTAINER_RUNTIME: podman CONTAINER_MEMORY_LIMITS: 2Gi NODE_SELECTOR_ROLE: quay-build-node SERVICE_ACCOUNT_NAME: quay-builder-sa QUAY_USERNAME: quayuser QUAY_PASSWORD: quaypassword WORKER_IMAGE: quay.io/quay/quay-builder WORKER_TAG: latest BUILDER_VM_CONTAINER_IMAGE: quay.io/quay/vm-builder:latest SETUP_TIME: "500" MINIMUM_RETRY_THRESHOLD: "1" SSH_AUTHORIZED_KEYS: - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsomekey user@example.com - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAnotherkey user2@example.com # ...
# ...
ALLOWED_WORKER_COUNT: "1"
ORCHESTRATOR_PREFIX: "quaybuild:"
REDIS_HOST: redis.example.com
REDIS_PASSWORD: examplepassword
REDIS_SSL: true
REDIS_SKIP_KEYSPACE_EVENT_SETUP: false
EXECUTOR: kubernetes
BUILDER_NAMESPACE: quay-builder
K8S_API_SERVER: https://api.openshift.example.com:6443
K8S_API_TLS_CA: /etc/ssl/certs/ca.crt
KUBERNETES_DISTRIBUTION: openshift
CONTAINER_RUNTIME: podman
CONTAINER_MEMORY_LIMITS: 2Gi
NODE_SELECTOR_ROLE: quay-build-node
SERVICE_ACCOUNT_NAME: quay-builder-sa
QUAY_USERNAME: quayuser
QUAY_PASSWORD: quaypassword
WORKER_IMAGE: quay.io/quay/quay-builder
WORKER_TAG: latest
BUILDER_VM_CONTAINER_IMAGE: quay.io/quay/vm-builder:latest
SETUP_TIME: "500"
MINIMUM_RETRY_THRESHOLD: "1"
SSH_AUTHORIZED_KEYS:
- ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsomekey user@example.com
- ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAnotherkey user2@example.com
# ...
9.9.3. ビルドログ設定フィールド
このセクションでは、Red Hat Quay でビルドログを管理するための使用可能な設定フィールドを説明します。これらの設定は、ビルドログをアーカイブする場所、そのログにアクセスできるユーザー、および保存方法を決定します。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_READER_BUILD_LOGS | Boolean |
true に設定すると、 |
LOG_ARCHIVE_LOCATION | String |
アーカイブされたビルドログを配置する、 |
LOG_ARCHIVE_PATH | String |
アーカイブされたビルドログを |
ビルドログ YAML の例
# ... FEATURE_READER_BUILD_LOGS: true LOG_ARCHIVE_LOCATION: s3_us_east LOG_ARCHIVE_PATH: archives/buildlogs # ...
# ...
FEATURE_READER_BUILD_LOGS: true
LOG_ARCHIVE_LOCATION: s3_us_east
LOG_ARCHIVE_PATH: archives/buildlogs
# ...
9.10. タグおよびイメージ管理
このセクションでは、タグとイメージを Red Hat Quay 内で管理する方法を制御する設定フィールドについて説明します。これらの設定は、イメージのクリーンアップの自動化、リポジトリーミラーの管理、およびキャッシュによるパフォーマンスの向上に役立ちます。
これらのフィールドを使用すると、以下のことができます。
- タグ付けされていないイメージまたは古いイメージの有効期限ポリシーを定義します。
- 外部リポジトリーのミラーリングをレジストリーへの有効にし、スケジュールします。
- モデルキャッシュを活用して、タグとリポジトリー操作のパフォーマンスを最適化します。
これらのオプションは、最新のイメージレジストリー環境を維持するのに役立ちます。
9.10.1. タグの有効期限の設定フィールド
次の設定オプションを使用して、タグの有効期限とガベージコレクションを自動化できます。これらの機能は、定義されたポリシーに基づいて未使用タグまたは期限切れのタグのクリーンアップを有効にすることで、ストレージの使用を管理するのに役立ちます。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_GARBAGE_COLLECTION | Boolean |
リポジトリーのガベージコレクションを有効にするかどうか。 |
TAG_EXPIRATION_OPTIONS | 文字列の配列 |
有効にすると、ユーザーが namespace 内のタグの有効期限を選択できるオプション。 |
DEFAULT_TAG_EXPIRATION | String |
タイムマシンのデフォルトの設定可能なタグ有効期限。 |
FEATURE_CHANGE_TAG_EXPIRATION | Boolean |
ユーザーおよび組織が namespace のタグの有効期限を変更できるかどうか。 |
FEATURE_AUTO_PRUNE | Boolean |
|
NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES | Integer |
有効期限が切れるイメージに関する通知を再実行する頻度を定義する間隔 (分単位)。 |
DEFAULT_NAMESPACE_AUTOPRUNE_POLICY | Object | 組織全体のデフォルトの自動プルーニングポリシー。 |
.method: number_of_tags | Object | 保持するタグの数を指定するオプション。 |
.value: <integer> | Integer |
method: number_of_tags と一緒に使用した場合に、保持するタグの数を示します。
たとえば、2 つのタグを保持するには、 |
.creation_date | Object | タグを保持する期間を指定するオプション。 |
.value: <integer> | Integer |
creation_date と一緒に使用した場合に、タグを保持する期間を示します。
秒 ( |
AUTO_PRUNING_DEFAULT_POLICY_POLL_PERIOD | Integer | 自動プルーナーワーカーをレジストリーレベルで実行する期間。デフォルトでは、1 日に 1 回 (24 時間に 1 回) 実行されるように設定されています。値は秒単位で指定する必要があります。 |
FEATURE_IMAGE_EXPIRY_TRIGGER | Boolean |
ユーザーがイメージの有効期限の通知を設定できます。 |
タグの有効期限の例の YAML
# ... FEATURE_GARBAGE_COLLECTION: true TAG_EXPIRATION_OPTIONS: - 1w - 2w - 1m - 90d DEFAULT_TAG_EXPIRATION: 2w FEATURE_CHANGE_TAG_EXPIRATION: true FEATURE_AUTO_PRUNE: true NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES: 300 DEFAULT_NAMESPACE_AUTOPRUNE_POLICY: method: number_of_tags value: 10 AUTO_PRUNING_DEFAULT_POLICY_POLL_PERIOD: 86400 FEATURE_IMAGE_EXPIRY_TRIGGER: false # ...
# ...
FEATURE_GARBAGE_COLLECTION: true
TAG_EXPIRATION_OPTIONS:
- 1w
- 2w
- 1m
- 90d
DEFAULT_TAG_EXPIRATION: 2w
FEATURE_CHANGE_TAG_EXPIRATION: true
FEATURE_AUTO_PRUNE: true
NOTIFICATION_TASK_RUN_MINIMUM_INTERVAL_MINUTES: 300
DEFAULT_NAMESPACE_AUTOPRUNE_POLICY:
method: number_of_tags
value: 10
AUTO_PRUNING_DEFAULT_POLICY_POLL_PERIOD: 86400
FEATURE_IMAGE_EXPIRY_TRIGGER: false
# ...
- 1
- 残すタグ 10 個を指定します。
作成日のサンプル YAML によるレジストリーの自動プルーニングポリシー
# ... DEFAULT_NAMESPACE_AUTOPRUNE_POLICY: method: creation_date value: 1y # ...
# ...
DEFAULT_NAMESPACE_AUTOPRUNE_POLICY:
method: creation_date
value: 1y
# ...
- 1
- 作成日から 1 年後にプルーニングするタグを指定します。
9.10.2. 設定フィールドのミラーリング
Red Hat Quay のミラーリングにより、リポジトリーとアップストリームソースの自動同期が可能になります。この機能は、リモートコンテナーイメージのローカルミラーを維持して、切断された環境での可用性を確保したり、キャッシュによってパフォーマンスを向上したりするのに役立ちます。
関連情報
フィールド | 型 | 説明 |
---|---|---|
FEATURE_REPO_MIRROR | Boolean |
リポジトリーミラーリングを有効または無効にします。 |
REPO_MIRROR_INTERVAL | 数値 |
次にリポジトリーミラー候補をチェックするまでの秒数。 |
REPO_MIRROR_SERVER_HOSTNAME | String |
|
REPO_MIRROR_TLS_VERIFY | Boolean |
HTTPS を必要とし、ミラー時に Quay レジストリーの証明書を検証します。 |
REPO_MIRROR_ROLLBACK | Boolean |
デフォルト: |
ミラーリング設定例の YAML
# ... FEATURE_REPO_MIRROR: true REPO_MIRROR_INTERVAL: 30 REPO_MIRROR_SERVER_HOSTNAME: "openshift-quay-service" REPO_MIRROR_TLS_VERIFY: true REPO_MIRROR_ROLLBACK: false # ...
# ...
FEATURE_REPO_MIRROR: true
REPO_MIRROR_INTERVAL: 30
REPO_MIRROR_SERVER_HOSTNAME: "openshift-quay-service"
REPO_MIRROR_TLS_VERIFY: true
REPO_MIRROR_ROLLBACK: false
# ...
9.10.3. ModelCache 設定フィールド
ModelCache は、アクセスデータを保存し、データベースの負荷を軽減するために Red Hat Quay が使用するキャッシュメカニズムです。Quay は、デフォルトの Memcache、Redis および Redis クラスターなど、キャッシュ用の複数のバックエンドをサポートします。
- memcache (デフォルト): 追加の設定は必要ありません。
- Redis: 単一のインスタンスまたは読み取り専用レプリカとして設定できます。
- Redis クラスター: 大規模なデプロイメント用に高可用性およびシャーディングを提供します。
フィールド | 型 | 説明 |
---|---|---|
DATA_MODEL_CACHE_CONFIG.engine | String |
キャッシュバックエンドエンジン。 |
.redis_config.primary.host | String |
|
.redis_config.primary.port | 数値 | プライマリー Redis インスタンスが使用するポート。 |
.redis_config.primary.password | String |
プライマリー Redis インスタンスで認証するためのパスワード。 |
.redis_config.primary.ssl | Boolean | プライマリー Redis 接続に SSL/TLS を使用するかどうか。 |
.redis_config.startup_nodes | マップの配列 |
|
redis_config.password | String |
Redis クラスターでの認証に使用されるパスワード。 |
.redis_config.read_from_replicas | Boolean | Redis クラスターレプリカからの読み取り操作を許可するかどうか。 |
.redis_config.skip_full_coverage_check | Boolean | true に設定した場合は、Redis クラスターのフルカバレッジチェックを省略します。 |
.redis_config.ssl | Boolean | Redis クラスターの通信に SSL/TLS を使用するかどうか。 |
.replica.host | String | Redis レプリカインスタンスのホスト名。オプション: |
.replica.port | 数値 | Redis レプリカインスタンスによって使用されるポート。 |
.replica.password | String |
Redis レプリカのパスワード。 |
.replica.ssl | Boolean | Redis レプリカ接続に SSL/TLS を使用するかどうか。 |
オプションのレプリカサンプル YAML を備えた単一の Redis
# ... DATA_MODEL_CACHE_CONFIG: engine: redis redis_config: primary: host: <redis-primary.example.com> port: 6379 password: <redis_password>> ssl: true replica: host: <redis-replica.example.com> port: 6379 password: <redis_password> ssl: true # ...
# ...
DATA_MODEL_CACHE_CONFIG:
engine: redis
redis_config:
primary:
host: <redis-primary.example.com>
port: 6379
password: <redis_password>>
ssl: true
replica:
host: <redis-replica.example.com>
port: 6379
password: <redis_password>
ssl: true
# ...
クラスター化された Redis サンプル YAML
# ... DATA_MODEL_CACHE_CONFIG: engine: <rediscluster> redis_config: startup_nodes: - host: <redis-node-1.example.com> port: 6379 - host: <redis-node-2.example.com> port: 6379 password: <cluster_password> read_from_replicas: true skip_full_coverage_check: true ssl: true # ...
# ...
DATA_MODEL_CACHE_CONFIG:
engine: <rediscluster>
redis_config:
startup_nodes:
- host: <redis-node-1.example.com>
port: 6379
- host: <redis-node-2.example.com>
port: 6379
password: <cluster_password>
read_from_replicas: true
skip_full_coverage_check: true
ssl: true
# ...
9.11. スキャナーおよびメタデータ
このセクションでは、Red Hat Quay 内のセキュリティースキャン、メタデータの提示、およびアーティファクト関係に関連する設定フィールドを説明します。
これらの設定により、Red Hat Quay を次のように実行できるようにすることで可視性とセキュリティーが強化されます。
- 脆弱性スキャナーと統合して、既知の CVE のコンテナーイメージを評価します。
- レジストリーに保存されているモデルカードを使用して、AI/ML モデルのメタデータをレンダリングします。
- OCI アーティファクト仕様に合わせて、参照元 API を使用してコンテナーアーティファクト間の関係を公開します。
これらの機能を組み合わせることで、ソフトウェアサプライチェーンの透過性が向上し、セキュリティーポリシーを実施し、メタデータ駆動型のワークフローをサポートできるようになります。
9.11.1. Clair セキュリティースキャナー設定フィールド
Red Hat Quay は、Clair セキュリティースキャナー を利用して、コンテナーイメージの脆弱性を検出できます。これらの設定フィールドは、スキャナーを有効にする方法、新しいコンテンツをインデックス化する頻度、使用されるエンドポイント、および通知の処理方法を制御します。
フィールド | 型 | 説明 |
---|---|---|
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 でインデックス化する必要のあるマニフェストに対してそのデータベースをクエリーします。これには、インデックス付けされていないマニフェストや、以前にインデックス付けに失敗したマニフェストが含まれます。 |
FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX | Boolean |
新しいプッシュの脆弱性に関する通知の送信を許可するかどうか。 |
SECURITY_SCANNER_V4_MANIFEST_CLEANUP | Boolean |
Red Hat Quay ガベージコレクターが、他のタグまたはマニフェストによって参照されていないマニフェストを削除するかどうか。 |
NOTIFICATION_MIN_SEVERITY_ON_NEW_INDEX | String |
検出された脆弱性に関する新しい通知の最低セキュリティーレベルを設定します。最初のインデックスの後に大量の通知が作成されるのを回避します。定義されていない場合は、デフォルトで |
SECURITY_SCANNER_V4_INDEX_MAX_LAYER_SIZE | String |
インデックス化に許可される最大レイヤーサイズ。レイヤーサイズが設定済みのサイズを超えると、Red Hat Quay UI は、 |
セキュリティースキャナーの YAML 設定
# ... FEATURE_SECURITY_NOTIFICATIONS: true FEATURE_SECURITY_SCANNER: true FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX: true ... SECURITY_SCANNER_INDEXING_INTERVAL: 30 SECURITY_SCANNER_V4_MANIFEST_CLEANUP: true SECURITY_SCANNER_V4_ENDPOINT: http://quay-server.example.com:8081 SECURITY_SCANNER_V4_PSK: MTU5YzA4Y2ZkNzJoMQ== SERVER_HOSTNAME: quay-server.example.com SECURITY_SCANNER_V4_INDEX_MAX_LAYER_SIZE: 8G # ...
# ...
FEATURE_SECURITY_NOTIFICATIONS: true
FEATURE_SECURITY_SCANNER: true
FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX: true
...
SECURITY_SCANNER_INDEXING_INTERVAL: 30
SECURITY_SCANNER_V4_MANIFEST_CLEANUP: true
SECURITY_SCANNER_V4_ENDPOINT: http://quay-server.example.com:8081
SECURITY_SCANNER_V4_PSK: MTU5YzA4Y2ZkNzJoMQ==
SERVER_HOSTNAME: quay-server.example.com
SECURITY_SCANNER_V4_INDEX_MAX_LAYER_SIZE: 8G
# ...
- 1
- 推奨される最大値は
10G
です。
9.11.1.1. Clair v4 によるインデックスの再作成
Clair v4 がマニフェストをインデックス化する場合は、結果として、決定論的なものである必要があります。たとえば、同じマニフェストが同じインデックスレポートを生成する必要があります。これは、異なるスキャナーを使用するとレポートで返される特定のマニフェストに関連して異なる情報を生成するため、スキャナーが変更されるまで True となります。そのため、Clair v4 はインデックスエンジン (/indexer/api/v1/index_state
) の状態表現を公開し、スキャナー設定が変更されたかどうかを判別します。
Red Hat Quay は、Quay のデータベースの解析時にこれをインデックスレポートに保存し、このインデックス状態を活用します。以前にスキャンされてからこの状態が変更された場合、Red Hat Quay は定期的なインデックスプロセス時にマニフェストの再作成を試行します。
デフォルトでは、このパラメーターは 30 秒に設定されています。インデックス作成のプロセスをより頻繁に実行する場合は、時間を短縮します。たとえば、新規タグをプッシュしてから、30 秒待たずに、UI でセキュリティースキャンの結果を表示する場合などです。また、ユーザーは要求パターンを Clair に制御し、Red Hat Quay データベースで実行されるデータベース操作のパターンをより詳細に制御する必要がある場合にパラメーターを変更することもできます。
9.11.2. モデルカードレンダリング設定フィールド
Red Hat Quay は、機械学習ワークフローで一般的に使用されるモデルカード -a 形式のメタデータドキュメントのレンダリングをサポートしています。これにより、OCI 準拠のイメージ内のモデル関連のコンテンツの可視性と管理が向上します。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_UI_MODELCARD | Boolean |
UI で Model card イメージタブを有効にします。デフォルトは |
UI_MODELCARD_ARTIFACT_TYPE | String | モデルカードアーティファクトタイプを定義します。 |
UI_MODELCARD_ANNOTATION | Object | このオプションフィールドは、OCI イメージに格納されているモデルカードのレイヤーアノテーションを定義します。 |
UI_MODELCARD_LAYER_ANNOTATION | Object | このオプションフィールドは、OCI イメージに格納されているモデルカードのレイヤーアノテーションを定義します。 |
モデルカードの例 YAML
FEATURE_UI_MODELCARD: true UI_MODELCARD_ARTIFACT_TYPE: application/x-mlmodel UI_MODELCARD_ANNOTATION: org.opencontainers.image.description: "Model card metadata" UI_MODELCARD_LAYER_ANNOTATION: org.opencontainers.image.title: README.md
FEATURE_UI_MODELCARD: true
UI_MODELCARD_ARTIFACT_TYPE: application/x-mlmodel
UI_MODELCARD_ANNOTATION:
org.opencontainers.image.description: "Model card metadata"
UI_MODELCARD_LAYER_ANNOTATION:
org.opencontainers.image.title: README.md
- 1
- UI で Model Card イメージタブを有効にします。
- 2
- モデルカードアーティファクトタイプを定義します。この例では、アーティファクトタイプは
application/x-mlmodel
です。 - 3
- オプション: イメージに
artifactType
が定義されていない場合、このフィールドはマニフェストレベルでチェックされます。一致するアノテーションが見つかった場合、システムはUI_MODELCARD_LAYER_ANNOTATION
に一致するアノテーションを持つレイヤーを検索します。 - 4
- オプション: イメージに
artifactType
が定義されており、レイヤーが複数ある場合、このフィールドを使用して、モデルカードを含む特定のレイヤーを検索します。
9.11.3. Open Container Initiative referrers API 設定フィールド
Open Container Initiative (OCI)参照者 API は、参照者の取得と管理を支援することで、コンテナーイメージ管理を改善するのに役立ちます。
関連情報
フィールド | 型 | 説明 |
---|---|---|
FEATURE_REFERRERS_API | Boolean | OCI 1.1 のリファラー API を有効にします。 |
OCI 参照者の有効化 YAML の例
# ... FEATURE_REFERRERS_API: True # ...
# ...
FEATURE_REFERRERS_API: True
# ...
9.12. クォータ管理およびプロキシーキャッシュ機能
このセクションでは、ストレージ制限の実施と、プロキシーのキャッシュによるイメージの可用性の向上に関連する設定フィールドの概要を説明します。
これらの機能は、レジストリー管理者に役立ちます。
- 設定可能なクォータで、ユーザーが消費するストレージアカウントおよびユーザーの量を制御します。
- リモートコンテンツをプロキシーキャッシュでローカルにキャッシュすることで、アップストリームのイメージへのアクセスを改善します。
- 分散環境全体でリソース消費と可用性を監視および管理します。
全体的に、これらの機能により、コンテナーイメージワークフローの管理におけるパフォーマンス、ガバナンス、および回復性が向上します。
9.12.1. クォータ管理設定フィールド
次の設定フィールドは、Red Hat Quay のクォータ管理機能を有効にし、カスタマイズします。クォータ管理は、管理者が使用制限の設定、ブロブサイズの算出、およびタグ削除の動作の制御を許可することで、組織レベルでストレージ使用状況ポリシーを実施するのに役立ちます。
フィールド | 型 | 説明 |
---|---|---|
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 |
子マニフェストを対象とする一時タグの有効期限をリセットします。この機能を
デフォルト: |
クォータ管理の例 YAML
# ... FEATURE_QUOTA_MANAGEMENT: true DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: "100gb" QUOTA_BACKFILL: true QUOTA_TOTAL_DELAY_SECONDS: "3600" PERMANENTLY_DELETE_TAGS: true RESET_CHILD_MANIFEST_EXPIRATION: true # ...
# ...
FEATURE_QUOTA_MANAGEMENT: true
DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: "100gb"
QUOTA_BACKFILL: true
QUOTA_TOTAL_DELAY_SECONDS: "3600"
PERMANENTLY_DELETE_TAGS: true
RESET_CHILD_MANIFEST_EXPIRATION: true
# ...
9.12.2. プロキシーキャッシュ設定フィールド
Red Hat Quay のプロキシーキャッシュ設定により、Red Hat Quay はアップストリームコンテナーレジストリーのプルスルーキャッシュとして機能できます。FEATURE_PROXY_CACHE
が有効になっている場合、Red Hat Quay は外部レジストリーからプルしたイメージをキャッシュし、帯域幅の消費を減らし、後続の要求におけるイメージの取得速度を向上させることができます。
フィールド | 型 | 説明 |
---|---|---|
FEATURE_PROXY_CACHE | Boolean | Red Hat Quay がアップストリームレジストリーのプルスルーキャッシュとして機能できるようにします。
デフォルト: |
プロキシーキャッシュの例 YAML
# ... FEATURE_PROXY_CACHE: true # ...
# ...
FEATURE_PROXY_CACHE: true
# ...
9.13. QuayIntegration 設定フィールド
QuayIntegration
カスタムリソースを使用すると、OpenShift Container Platform クラスターと Red Hat Quay レジストリーインスタンス間の統合が可能になります。
名前 | 説明 | スキーマ |
---|---|---|
allowlistNamespaces | 含める namespace のリスト。 | アレイ |
clusterID | このクラスターに関連付けられている ID。 | String |
credentialsSecret.key | Quay レジストリーと通信するための認証情報を含む秘密。 | Object |
denylistNamespaces | 除外する namespace のリスト。 | アレイ |
insecureRegistry | Quay レジストリーへの TLS 検証をスキップするかどうか | Boolean |
quayHostname | Quay レジストリーのホスト名。 | String |
scheduledImageStreamImport | イメージストリームのインポートを有効にするかどうか。 | Boolean |
QuayIntegration の例の CR
apiVersion: quay.redhat.com/v1 kind: QuayIntegration metadata: name: example-quayintegration spec: clusterID: 1df512fc-bf70-11ee-bb31-001a4a160100 quayHostname: quay.example.com credentialsSecret: name: quay-creds-secret key: token allowlistNamespaces: - dev-team - prod-team denylistNamespaces: - test insecureRegistry: false scheduledImageStreamImport: true
apiVersion: quay.redhat.com/v1
kind: QuayIntegration
metadata:
name: example-quayintegration
spec:
clusterID: 1df512fc-bf70-11ee-bb31-001a4a160100
quayHostname: quay.example.com
credentialsSecret:
name: quay-creds-secret
key: token
allowlistNamespaces:
- dev-team
- prod-team
denylistNamespaces:
- test
insecureRegistry: false
scheduledImageStreamImport: true
9.14. メール設定フィールド
アカウントの確認、パスワードのリセット、セキュリティーアラートなどの Red Hat Quay インスタンスからのメール通知を有効にするには、以下を実行します。この設定により、Red Hat Quay は SMTP サーバーに接続し、レジストリーの代わりにアウトバウンドメッセージを送信できます。
フィールド | 型 | 説明 |
---|---|---|
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 を使用するかどうか。 |
メールの例 YAML
# ... FEATURE_MAILING: true MAIL_DEFAULT_SENDER: "support@example.com" MAIL_SERVER: "smtp.example.com" MAIL_PORT: 587 MAIL_USERNAME: "smtp-user@example.com" MAIL_PASSWORD: "your-smtp-password" MAIL_USE_TLS: true # ...
# ...
FEATURE_MAILING: true
MAIL_DEFAULT_SENDER: "support@example.com"
MAIL_SERVER: "smtp.example.com"
MAIL_PORT: 587
MAIL_USERNAME: "smtp-user@example.com"
MAIL_PASSWORD: "your-smtp-password"
MAIL_USE_TLS: true
# ...
第10章 環境変数の設定
Red Hat Quay は、ランタイムの動作とパフォーマンスチューニングを制御する限定された環境変数のセットをサポートします。これらの値で、プロセスごとの動作、接続数、または地域の設定を動的に調整する必要がある特定のシナリオで柔軟性が得られます。
環境変数の使用には注意が必要です。これらのオプションは通常、既存の設定メカニズムを上書きまたは拡張します。
このセクションでは、以下のコンポーネントに関連する環境変数について説明します。
- Geo レプリケーションの設定
- データベース接続プール
- HTTP 接続コンカレンシー。
- ワーカープロセスのスケーリング
10.1. Geo レプリケーション
Red Hat Quay は、複数のインスタンスが地理的に分散したサイトで動作するマルチリージョンデプロイメントをサポートします。これらのシナリオでは、各サイトは同じ設定とメタデータを共有しますが、ストレージバックエンドはリージョンによって異なる場合があります。
これに対応するために、Red Hat Quay では、環境変数を使用してデプロイメントごとに優先されるストレージエンジンを指定できます。これにより、メタデータはすべてのリージョンで同期されますが、各リージョンは個別の設定ファイルを必要とせずに最適化された独自のストレージバックエンドを使用できます。
DISTRIBUTED_STORAGE_CONFIG
で定義されているように、QUAY_DISTRIBUTED_STORAGE_PREFERENCE
環境変数を使用して、ID によって優先されるストレージエンジンを明示的に設定します。
変数 | 型 | 説明 |
---|---|---|
QUAY_DISTRIBUTED_STORAGE_PREFERENCE | String | 使用する優先されるストレージ (DISTRIBUTED_STORAGE_CONFIG の ID 別) |
10.2. データベース接続プール
Red Hat Quay は、すべてが同じコンテナー内で実行する多くの異なるプロセスで構成されています。これらのプロセスの多くは、データベースと連動しています。
データベース接続プールはデフォルトで有効になっており、データベースと対話する各プロセスには接続プールが含まれます。これらのプロセスごとのコネクションプールは、最大 20 個の接続を維持するように設定されています。高負荷時には、Red Hat Quay コンテナー内のすべてのプロセスの接続プールを満たすことが可能です。特定のデプロイメントおよび負荷では、Red Hat Quay が設定されたデータベースの最大接続数を超えないようにするための分析が必要になる場合があります。
時間が経つと、接続プールはアイドル状態の接続を解放します。すべての接続をすぐに解除するには、Red Hat Quay の再起動が必要です。
変数 | 型 | 説明 |
---|---|---|
DB_CONNECTION_POOLING | String |
データベース接続プールを有効にするか無効にするかを指定します。デフォルトは true です。使用可能な値は |
データベース接続プーリングが有効な場合は、接続プールの最大サイズを変更することができます。これは、以下の config.yaml
オプションを使用して実行できます。
データベース接続プールの例
# ... DB_CONNECTION_ARGS: max_connections: 10 # ...
# ...
DB_CONNECTION_ARGS:
max_connections: 10
# ...
10.2.1. スタンドアロンデプロイメントでのデータベースプールの無効化
スタンドアロンの Red Hat Quay デプロイメントの場合、デプロイメントの開始時にデータベース接続プールをオフに切り替えることができます。以下に例を示します。
sudo podman run -d --rm -p 80:8080 -p 443:8443 \ --name=quay \ -v $QUAY/config:/conf/stack:Z \ -v $QUAY/storage:/datastorage:Z \ -e DB_CONNECTION_POOLING=false
$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
--name=quay \
-v $QUAY/config:/conf/stack:Z \
-v $QUAY/storage:/datastorage:Z \
-e DB_CONNECTION_POOLING=false
registry.redhat.io/quay/quay-rhel8:v3.12.1
10.2.2. OpenShift Container Platform での Red Hat Quay のデータベースプールの無効化
Red Hat Quay on OpenShift Container Platform では、QuayRegistry
カスタムリソース定義 (CRD) を変更することでデータベース接続プールを設定できます。以下に例を示します。
QuayRegistry CRD の例
spec: components: - kind: quay managed: true overrides: env: - name: DB_CONNECTION_POOLING value: "false"
spec:
components:
- kind: quay
managed: true
overrides:
env:
- name: DB_CONNECTION_POOLING
value: "false"
10.3. HTTP 接続回数
環境変数を使用して、Red Hat Quay が処理する同時 HTTP 接続の数を制御できます。これらの制限は、グローバルに適用されるか、個々のコンポーネント(レジストリー、Web UI、またはセキュリティースキャン)に限定することができます。デフォルトでは、各ワーカープロセスでは最大 50
個の並列接続が許可されます。
この設定は ワーカープロセスの数とは異なります。
これらの接続関連の環境変数は、デプロイメントの種類に応じて異なる方法で設定できます。
-
スタンドアロンデプロイメント では、
config.yaml
ファイルで接続数を設定します。 -
OpenShift Container Platform デプロイメントの Red Hat Quay で、
QuayRegistry
CR のenv
ブロックに 値を定義します。
変数 | 型 | 説明 |
---|---|---|
WORKER_CONNECTION_COUNT | 数値 |
ワーカープロセスごとの HTTP 接続の最大数のグローバルデフォルト。 |
WORKER_CONNECTION_COUNT_REGISTRY | 数値 |
レジストリーワーカーごとの HTTP 接続。 |
WORKER_CONNECTION_COUNT_WEB | 数値 |
Web UI ワーカーごとの HTTP 接続。 |
WORKER_CONNECTION_COUNT_SECSCAN | 数値 |
Clair セキュリティースキャナーワーカーごとの HTTP 接続。 |
スタンドアロン Red Hat Quay デプロイメントの HTTP 接続設定
WORKER_CONNECTION_COUNT: 10 WORKER_CONNECTION_COUNT_REGISTRY: 10 WORKER_CONNECTION_COUNT_WEB: 10 WORKER_CONNECTION_COUNT_SECSCAN: 10
WORKER_CONNECTION_COUNT: 10
WORKER_CONNECTION_COUNT_REGISTRY: 10
WORKER_CONNECTION_COUNT_WEB: 10
WORKER_CONNECTION_COUNT_SECSCAN: 10
OpenShift Container Platform での Red Hat Quay の HTTP 接続設定
env: - name: WORKER_CONNECTION_COUNT value: "10" - name: WORKER_CONNECTION_COUNT_REGISTRY value: "10" - name: WORKER_CONNECTION_COUNT_WEB value: "10" - name: WORKER_CONNECTION_COUNT_SECSCAN value: "10"
env:
- name: WORKER_CONNECTION_COUNT
value: "10"
- name: WORKER_CONNECTION_COUNT_REGISTRY
value: "10"
- name: WORKER_CONNECTION_COUNT_WEB
value: "10"
- name: WORKER_CONNECTION_COUNT_SECSCAN
value: "10"
10.4. ワーカープロセス数
環境変数を使用して、Red Hat Quay で受信リクエストを処理するワーカープロセスの数を制御できます。これらの値は、レジストリー、Web UI、セキュリティースキャンなど、システムのさまざまなコンポーネントのタスクを処理するために開始する並列プロセスの数を定義します。
明示的に設定されていない場合、Red Hat Quay は利用可能な CPU コアの数に基づいてワーカープロセスの数を自動的に計算します。この動的スケーリングにより、大規模なマシンでパフォーマンスを最適化できますが、小規模な環境で不要なリソース使用量が生じる可能性もあります。
OpenShift Container Platform デプロイメントの Red Hat Quay では、Operator は以下のデフォルト値を設定します。
-
WORKER_COUNT_REGISTRY
: 8 -
WORKER_COUNT_WEB
: 4 -
WORKER_COUNT_SECSCAN
: 2
変数 | 型 | 説明 |
---|---|---|
WORKER_COUNT | 数値 | プロセス数の汎用上書き |
WORKER_COUNT_REGISTRY | 数値 |
|
WORKER_COUNT_WEB | 数値 |
コンテナー内の UI/Web リクエストを処理するプロセス数を指定します。 |
WORKER_COUNT_SECSCAN | 数値 |
コンテナー内のセキュリティースキャン (Clair など) の統合を処理するプロセス数を指定します。 |
スタンドアロン Red Hat Quay デプロイメントのワーカー数の設定
WORKER_COUNT: 10 WORKER_COUNT_REGISTRY: 16 WORKER_COUNT_WEB: 8 WORKER_COUNT_SECSCAN: 4
WORKER_COUNT: 10
WORKER_COUNT_REGISTRY: 16
WORKER_COUNT_WEB: 8
WORKER_COUNT_SECSCAN: 4
OpenShift Container Platform での Red Hat Quay のワーカー数の設定
env: - name: WORKER_COUNT value: "10" - name: WORKER_COUNT_REGISTRY value: "16" - name: WORKER_COUNT_WEB value: "8" - name: WORKER_COUNT_SECSCAN value: "4"
env:
- name: WORKER_COUNT
value: "10"
- name: WORKER_COUNT_REGISTRY
value: "16"
- name: WORKER_COUNT_WEB
value: "8"
- name: WORKER_COUNT_SECSCAN
value: "4"
第11章 Clair セキュリティースキャナー
Clair の設定フィールドは、Clair 設定の概要 に移動されました。この章は、Red Hat Quay の今後のバージョンでは削除される予定です。