Red Hat Quay の設定
設定オプションを使用した Red Hat Quay のカスタマイズ
概要
第1章 設定の使用
Red Hat Quay は、スタンドアロン方法でデプロイすることも、Operator を使用して既存の OpenShift クラスターにデプロイできます。使用しているデプロイメントのタイプに応じて、Red Hat Quay 設定の作成、取得、更新、検証に使用する方法は若干異なります。ただし、コアとなる設定オプションは基本的にどのタイプのデプロイメントでも同じで、以下のオプションを操作できます。
-
config.yaml
ファイルを編集して直接実行する。設定ファイルの編集 を参照してください。 - プログラムでコンフィグレーション API を使用する。コンフィグレーション API の使用 セクションを参照してください。
- 視覚的に設定ツール UI を使用する。設定ツールの使用 のセクションを参照してください。
Operator はレジストリーをデプロイするため、初期設定を指定せずに、Quay を OpenShift にインストールできます。ただし、スタンドアロンデプロイメントの場合は、レジストリーを起動する前に最低限の設定を指定する必要があります。最小要件は、コンフィグレーション API を使用して決定でき、その内容は本セクションに記載されています。
Quay を初期設定でデプロイした後に、システムの再起動またはアップグレード時に今後必要となる追加の値が含まれる可能性があるため、実行中のシステムから全設定を取得して保存する必要があります。
1.1. Quay 3.6 の設定更新
1.1.1. 新規設定フィールド
-
FEATURE_EXTENDED_REPOSITORY_NAMES: ネストされたリポジトリーおよび拡張リポジトリー名のサポートが追加されました。この変更により、特定の OpenShift Container Platform ユースケースに必要なリポジトリー名で
/
を使用できるようになります。詳細は、ネストされたリポジトリーの設定 を参照してください。 -
FEATURE_USER_INITIALIZE: true に設定される場合、最初のユーザーアカウントは API
/api/v1/user/initialize
で作成できます。詳細は、自動化のための Quay の事前設定 を参照してください。 -
ALLOWED_OCI_ARTIFACT_TYPES: Helm、cosign、および ztsd 圧縮スキームのアーティファクトはデフォルトで Red Hat Quay 3.6 に組み込まれています。デフォルトでサポートされていない他の OCI メディアタイプについては、Quay の
config.yaml
のALLOWED_OCI_ARTIFACT_TYPES
設定に追加できます。詳細は、Quay への他の OCI メディアタイプの追加 を参照してください。 -
CREATE_PRIVATE_REPO_ON_PUSH: レジストリーユーザーは、セキュリティーのニーズに応じて、config.yaml の
CREATE_PRIVATE_REPO_ON_PUSH
をTrue
またはFalse
に設定できるようになりました。 - CREATE_NAMESPACE_ON_PUSH: プッシュした組織が存在しない場合に、組織を自動的に作成するように設定できるようになりました。
1.1.2. 非推奨の設定フィールド
-
FEATURE_HELM_OCI_SUPPORT: このオプションは非推奨になり、Red Hat Quay の将来のバージョンで削除される予定です。Red Hat Quay 3.6 では、Helm アーティファクトがデフォルトでサポートされ、
FEATURE_GENERAL_OCI_SUPPORT
プロパティーに含まれています。ユーザーは、サポートを有効にするために config.yaml ファイルを更新する必要がなくなりました。
1.2. 設定ファイルの編集
スタンドアロンモードでレジストリーをデプロイするには、最小限の設定が必要です。「最小設定」 のセクションを参照してください。
設定ファイルはレジストリーの起動時に検証され、問題があれば、出力に強調表示されます。
コンフィグレーション API を使用して設定を検証することもできますが、これには Quay コンテナーを設定モードで起動する必要があります。
変更を有効にするには、レジストリーを再起動する必要があります。
1.3. スタンドアロンデプロイメントにおける設定ファイルの場所
スタンドアロンデプロイメントの場合は、Quay レジストリーの起動時に config.yaml
ファイルを指定する必要があります。このファイルは、設定ボリュームに配置されるので、以下の例では、設定ファイルは $QUAY/config/config.yaml
にあります。
$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \ --name=quay \ -v $QUAY/config:/conf/stack:Z \ -v $QUAY/storage:/datastorage:Z \ registry.redhat.io/quay/quay-rhel8:v3.6.8
1.4. コマンドラインおよび API を使用した OpenShift での Quay の設定
デプロイされたら、Quay 設定バンドルシークレット spec.configBundleSecret
を編集して Quay アプリケーションを設定し、QuayRegistry リソースの spec.components
オブジェクトのコンポーネントの管理ステータスを変更することもできます。
Operator は spec.configBundleSecret
リソースの変更の有無を監視しないため、新しい Secret
リソースに設定変更が行われ、spec.configBundleSecret
フィールドが変更を反映するように更新することが推奨されます。新しい設定で問題が発生した場合は、spec.configBundleSecret
の値を以前の Secret
に戻すことが簡単にできます。
設定を変更する手順には、以下の操作が必要です。
- 現在のエンドポイントおよびシークレットの決定
- Red Hat Quay が OpenShift にすでにデプロイされている場合、既存の設定バンドルのダウンロード
-
config.yaml
設定ファイルの作成または更新 - Quay に必要な SSL 証明書またはサービスに必要なカスタム SSL 証明書のアセンブル
- 設定ファイルおよび証明書を使用した新規設定バンドルシークレットの作成
- レジストリーの作成または更新、新規設定バンドルシークレットの参照、およびコンポーネント管理用の過程の指定
- デプロイメントを監視して正常に完了し、設定の変更が反映されていることを確認します。
または、設定エディター UI を使用して、セクション 4章設定ツールを使用した OpenShift における Quay の再設定 で説明されているように Quay アプリケーションを設定できます。
1.4.1. QuayRegistry エンドポイントおよびシークレットの決定
oc describe quayregistry
または oc get quayregistry -o yaml
を使用して QuayRegistry リソースを検査し、現在のエンドポイントおよびシークレットを判別します。
$ oc get quayregistry example-registry -n quay-enterprise -o yaml apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: ... name: example-registry namespace: quay-enterprise ... spec: components: ... configBundleSecret: example-registry-quay-config-bundle-fjpnm status: configEditorCredentialsSecret: example-registry-quay-config-editor-credentials-kk55dc7299 configEditorEndpoint: https://example-registry-quay-config-editor-quay-enterprise.apps.docs.quayteam.org currentVersion: 3.6.0 lastUpdated: 2021-09-21 11:18:13.285192787 +0000 UTC registryEndpoint: https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org unhealthyComponents: {}
関連するフィールドは以下のとおりです。
-
registryEndpoint
: レジストリーの URL、レジストリー UI へのブラウザーアクセス、およびレジストリー API エンドポイント -
configBundleSecret
:config.yaml
ファイルと SSL 証明書を含む設定バンドルシークレット -
configEditorEndpoint
: 設定エディターツールの URL、設定ツールへのブラウザーアクセス、および設定 API -
configEditorCredentialsSecret
: ユーザー名 (通常はquayconfig
) および設定エディターツールのパスワードが含まれるシークレット
設定エディターツールのユーザー名とパスワードを確認するには、以下を実行します。
シークレットを取得します。
$ oc get secret -n quay-enterprise example-registry-quay-config-editor-credentials-kk55dc7299 -o yaml apiVersion: v1 data: password: SkZwQkVKTUN0a1BUZmp4dA== username: cXVheWNvbmZpZw== kind: Secret
ユーザー名をデコードします。
$ echo 'cXVheWNvbmZpZw==' | base64 --decode quayconfig
パスワードをデコードします。
$ echo 'SkZwQkVKTUN0a1BUZmp4dA==' | base64 --decode JFpBEJMCtkPTfjxt
1.4.2. 既存設定のダウンロード
現在の設定にアクセスする方法は複数あります。
設定エディターのエンドポイントを使用して、設定エディターのユーザー名とパスワードを指定します。
$ curl -k -u quayconfig:JFpBEJMCtkPTfjxt https://example-registry-quay-config-editor-quay-enterprise.apps.docs.quayteam.org/api/v1/config
{ "config.yaml": { "ALLOW_PULLS_WITHOUT_STRICT_LOGGING": false, "AUTHENTICATION_TYPE": "Database", ... "USER_RECOVERY_TOKEN_LIFETIME": "30m" }, "certs": { "extra_ca_certs/service-ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURVVENDQWptZ0F3SUJBZ0lJRE9kWFhuUXFjMUF3RFFZSktvWklodmNOQVFFTEJRQXdOakUwTURJR0ExVUUKQXd3cmIzQmxibk5vYVdaMExYTmxjblpwWTJVdGMyVnlkbWx1WnkxemFXZHVaWEpBTVRZek1UYzNPREV3TXpBZQpGdzB5TVRBNU1UWXdOelF4TkRKYUZ..." } }
設定バンドルシークレットの使用
シークレットデータを取得します。
$ oc get secret -n quay-enterprise example-registry-quay-config-bundle-jkfhs -o jsonpath='{.data}'
{ "config.yaml": "QUxMT1dfUFVMTFNfV0lUSE9VVF9TVFJJQ1RfTE9HR0lORzogZmFsc2UKQVVUSEVOVElDQVRJT05fVFlQRTogRGF0YWJhc2UKQVZBVEFSX0tJTkQ6IGxvY2FsCkRBVEFCQVNFX1NFQ1JFVF9LRVk6IHhlOEc1VDBNbkllaGxNQzNkTjd3MWR5WWxwVmo0a0R2enlxZ3l6Ulp5ZjFpODBmWWU3VDUxU1FPZ3hXelpocFlqYlVxNzRKaDllVVVEVWpyCkRFR ... OgotIDJ3ClRFQU1fUkVTWU5DX1NUQUxFX1RJTUU6IDYwbQpURVNUSU5HOiBmYWxzZQpVU0VSX1JFQ09WRVJZX1RPS0VOX0xJRkVUSU1FOiAzMG0K", "extra_ca_cert_service-ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURVVENDQWptZ0F3SUJBZ0lJRE9kWFhuUXFjMUF3RFFZSktvWklodmNOQVFFTEJRQXdOakUwTURJR0ExVUUKQXd3cmIzQmxibk5vYVdaMExYTmxjblpwWTJVdGMyVnlkbWx1WnkxemFXZHVaWEpBTVRZek1UYzNPREV3TXpBZQpGdzB5TVRBNU1UWXdOelF4TkRKYUZ3MHl ... XSW1jaApkQXZTWGpFUnZOZEZzN3pHK1VzTmZwN0ZIQkJVWkY4L2RZNWJCR2MwWTVaY0J6bFNjQT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K" }
データをデコードします。
$ echo 'QUxMT1dfUFVMTFN...U1FOiAzMG0K' | base64 --decode
ALLOW_PULLS_WITHOUT_STRICT_LOGGING: false AUTHENTICATION_TYPE: Database ... TAG_EXPIRATION_OPTIONS: - 2w TEAM_RESYNC_STALE_TIME: 60m TESTING: false USER_RECOVERY_TOKEN_LIFETIME: 30m
1.4.3. 設定バンドルを使用したカスタム SSL 証明書の設定
カスタム SSL 証明書は、新規設定バンドルシークレットを作成して、初回のデプロイメント前または Red Hat Quay を OpenShift にデプロイする前に設定できます。既存のデプロイメントに証明書を追加する場合は、設定を変更しなくても、新規の設定バンドルシークレットに完全な既存の config.yaml
を含める必要があります。
埋め込みデータまたはファイルを使用してシークレットを作成します。
設定の詳細を Secret リソース YAML ファイルに直接組み込みます。以下に例を示します。
custom-ssl-config-bundle.yaml
apiVersion: v1 kind: Secret metadata: name: custom-ssl-config-bundle-secret namespace: quay-enterprise data: config.yaml: | ALLOW_PULLS_WITHOUT_STRICT_LOGGING: false AUTHENTICATION_TYPE: Database ... extra_ca_cert_my-custom-ssl.crt: | -----BEGIN CERTIFICATE----- MIIDsDCCApigAwIBAgIUCqlzkHjF5i5TXLFy+sepFrZr/UswDQYJKoZIhvcNAQEL BQAwbzELMAkGA1UEBhMCSUUxDzANBgNVBAgMBkdBTFdBWTEPMA0GA1UEBwwGR0FM .... -----END CERTIFICATE-----
次に、YAML ファイルからシークレットを作成します。
$ oc create -f custom-ssl-config-bundle.yaml
または、必要な情報が含まれるファイルを作成し、それらのファイルからシークレットを作成できます。
$ oc create secret generic custom-ssl-config-bundle-secret \ --from-file=config.yaml \ --from-file=extra_ca_cert_my-custom-ssl.crt=my-custom-ssl.crt
作成した Secret を参照する QuayRegistry YAML ファイル
quayregistry.yaml
を作成または更新します。以下はその例です。quayregistry.yaml
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: custom-ssl-config-bundle-secret
YAML ファイルを使用してレジストリーをデプロイまたは更新します。
oc apply -f quayregistry.yaml
1.5. 最小設定
スタンドアロンデプロイメントには、以下の機能に設定オプションが必要です。
- サーバーのホスト名
- HTTP または HTTPS
- 認証タイプ (データベースまたは LDAP など)
- データ暗号化用の秘密鍵
- イメージのストレージ
- メタデータ用のデータベース
- ビルドログおよびユーザーイベント用の Redis
- タグの有効期限オプション
1.5.1. 最小設定ファイルの例
イメージのローカルストレージを使用する最小設定ファイルの例を以下に示します。
$QUAY/config/config.yaml
AUTHENTICATION_TYPE: Database BUILDLOGS_REDIS: host: quay-server.example.com password: strongpassword port: 6379 DATABASE_SECRET_KEY: 0ce4f796-c295-415b-bf9d-b315114704b8 DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay DEFAULT_TAG_EXPIRATION: 2w DISTRIBUTED_STORAGE_CONFIG: default: - LocalStorage - storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default PREFERRED_URL_SCHEME: http SECRET_KEY: e8f9fe68-1f84-48a8-a05f-02d72e6eccba SERVER_HOSTNAME: quay-server.example.com SETUP_COMPLETE: true TAG_EXPIRATION_OPTIONS: - 0s - 1d - 1w - 2w - 4w USER_EVENTS_REDIS: host: quay-server.example.com password: strongpassword port: 6379
SETUP_COMPLETE
フィールドは、設定が検証されたことを示します。レジストリーを起動する前に、設定エディターツールを使用して設定を検証する必要があります。
1.5.2. ローカルストレージ
イメージへのローカルストレージの使用は、概念実証の目的のためにレジストリーをデプロイする場合に限り推奨されます。この場合、ストレージはレジストリーの起動時にコマンドラインで指定され、ローカルディレクトリー $QUAY/storage
をコンテナーの /datastorage
パスにマッピングします。
$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \ --name=quay \ -v $QUAY/config:/conf/stack:Z \ -v $QUAY/storage:/datastorage:Z \ registry.redhat.io/quay/quay-rhel8:v3.6.8
1.5.3. クラウドストレージ
ストレージの設定は、イメージストレージ セクションを参照してください。Google Cloud Platform などでクラウドストレージを使用する場合の相違点を比較すると便利です。
$QUAY/config/config.yaml
DISTRIBUTED_STORAGE_CONFIG: default: - GoogleCloudStorage - access_key: GOOGQIMFB3ABCDEFGHIJKLMN bucket_name: quay_bucket secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
クラウドストレージを使用してレジストリーを起動する場合は、コマンドラインでの設定が必要ありません。
$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \ --name=quay \ -v $QUAY/config:/conf/stack:Z \ registry.redhat.io/quay/quay-rhel8:v3.6.8
第2章 設定フィールド
2.1. 必須の設定フィールド
必須フィールドは、以下のセクションで説明されています。
2.2. 自動化オプション
2.3. 任意の設定フィールド
任意のフィールドについては、以下のセクションで説明します。
2.4. 一般的な必須フィールド
表2.1 一般的な必須フィールド
フィールド | タイプ | 説明 |
---|---|---|
AUTHENTICATION_TYPE | 文字列 |
認証情報の認証に使用する認証エンジン |
PREFERRED_URL_SCHEME | 文字列 |
Red Hat Quay へのアクセスに使用する URL スキーム |
SERVER_HOSTNAME | 文字列 |
スキームなしで Red Hat Quay にアクセスできる URL |
DATABASE_SECRET_KEY | 文字列 | データベース内で機密フィールドを暗号化するのに使用されるキー。この値は、一旦設定したら変更しないでください。変更すると、リポジトリーのミラーユーザー名やパスワード設定など、すべての信頼できるフィールドが無効になります。 |
SECRET_KEY | 文字列 | データベース内およびランタイム時に機密性の高いフィールドを暗号化するために使用するキー。設定後に値を変更できません。設定しないと、暗号化されたパスワード認証情報など、すべての信頼できるフィールドが無効になります。 |
SETUP_COMPLETE | ブール値 |
これは、以前のバージョンのソフトウェアからそのまま残っているアーティファクトで、現時点では値を |
2.5. データベースの設定
DB_CONNECTION_ARGS 構造で必要な DB_URI フィールドおよび任意の接続引数を使用して、データベースへの接続を設定します。DB_CONNECTION_ARGS で定義されたキーと値のペアは汎用的なものも、データベース固有のものもあります。特に、SSL 設定は、デプロイするデータベースや、PostgreSQL および MySQL のサンプルによって異なります。
2.5.1. データベース URI
表2.2 データベース URI
フィールド | タイプ | 説明 |
---|---|---|
DB_URI | 文字列 | 認証情報を含む、データベースにアクセスするための URI |
例:
postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
2.5.2. データベース接続引数
表2.3 データベース接続引数
フィールド | タイプ | 説明 |
---|---|---|
DB_CONNECTION_ARGS | オブジェクト | タイムアウトや SSL などのデータベースの任意の接続引数 |
.autorollback | Boolean |
スレッドローカル接続を使用するかどうか |
.threadlocals | Boolean |
自動ロールバック接続 |
2.5.2.1. PostgreSQL SSL 接続引数
PostgreSQL SSL の設定例は以下のようになります。
DB_CONNECTION_ARGS: sslmode: verify-ca sslrootcert: /path/to/cacert
sslmode
オプションは、セキュアな SSL/IP 接続がサーバーにネゴシエートされるかどうか、その優先度を決定します。モードは 6 つあります。
- Disable: SSL 以外の接続のみを試行する。
- allow: 初回は SSL 以外の接続を試行して、それに失敗すると SSL 接続を試行する。
- preferred: (デフォルト) 初回は SSL を試行して、それに失敗すると SSL 以外の接続を試行する。
- require: SSL 接続のみを試行する。ルート CA ファイルが存在する場合は、verify-ca が指定されているときと同じように、証明書を確認します。
- verify-ca: SSL 接続のみを試行し、信頼された認証局 (CA) によりサーバー証明書が発行されていることを確認します。
- verify-full: SSL 接続のみを試行します。信頼された CA によりサーバー証明書が発行され、要求されたサーバーのホスト名が証明書と一致することを確認します。
PostgreSQL の有効な引数び詳細は、https://www.postgresql.org/docs/current/libpq-connect.html を参照してください。
2.5.2.2. MySQL SSL 接続引数
MySQL SSL の設定例:
DB_CONNECTION_ARGS: ssl: ca: /path/to/cacert
MySQL の有効な接続引数の詳細は、https://dev.mysql.com/doc/refman/8.0/en/connecting-using-uri-or-key-value-pairs.html を参照してください。
2.6. イメージストレージ
2.6.1. イメージストレージ機能
表2.4 ストレージ設定機能
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_REPO_MIRROR | Boolean |
true に設定されている場合は、リポジトリーミラーリングが有効になる |
FEATURE_PROXY_STORAGE | Boolean |
レジストリー nginx を使用して、ストレージ内のすべての直接ダウンロード URL をプロキシーするかどうか |
FEATURE_STORAGE_REPLICATION | Boolean |
ストレージエンジン間で自動的にレプリケートするかどうか |
2.6.2. イメージストレージ設定フィールド
DISTRIBUTED_STORAGE_CONFIG フィールドですべてのストレージエンジンの一覧を指定し、DISTRIBUTED_STORAGE_PREFERENCE フィールドでストレージエンジンを優先的に選択します。
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS フィールドは、デフォルトでイメージがレプリケートされる場所を制御するために使用されます。
表2.5 ストレージ設定フィールド
フィールド | タイプ | 説明 |
---|---|---|
DISTRIBUTED_STORAGE_CONFIG | オブジェクト |
Red Hat Quay で使用するストレージエンジンの設定。各キーは、ストレージエンジンの一意の ID を表します。この値は、ストレージエンジンパラメーターを記述するオブジェクトのタプル (キー、値) で設定されます。 |
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS | 文字列の配列 | イメージをデフォルトで他のすべてのストレージエンジンに対して完全にレプリケートする必要のあるストレージエンジンの一覧 (DISTRIBUTED_STORAGE_CONFIG の ID 別)。 |
DISTRIBUTED_STORAGE_PREFERENCE | 文字列の配列 |
使用する優先されるストレージ (DISTRIBUTED_STORAGE_CONFIG の ID 別)。優先されるエンジンとは、プルのチェックが行われ、イメージがプッシュされることを意味します。 |
MAXIMUM_LAYER_SIZE | 文字列 |
イメージ層の最大許容サイズ |
2.6.3. ローカルストレージ
DISTRIBUTED_STORAGE_CONFIG: default: - LocalStorage - storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
2.6.4. OCS/NooBaa
DISTRIBUTED_STORAGE_CONFIG: rhocsStorage: - RHOCSStorage - access_key: access_key_here secret_key: secret_key_here bucket_name: quay-datastore-9b2108a3-29f5-43f2-a9d5-2872174f9a56 hostname: s3.openshift-storage.svc.cluster.local is_secure: 'true' port: '443' storage_path: /datastorage/registry
2.6.5. Ceph / RadosGW Storage / Hitachi HCP:
DISTRIBUTED_STORAGE_CONFIG: radosGWStorage: - RadosGWStorage - access_key: access_key_here secret_key: secret_key_here bucket_name: bucket_name_here hostname: hostname_here is_secure: 'true' port: '443' storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
2.6.6. AWS S3 ストレージ
DISTRIBUTED_STORAGE_CONFIG: s3Storage: - S3Storage - host: s3.us-east-2.amazonaws.com s3_access_key: ABCDEFGHIJKLMN s3_secret_key: OL3ABCDEFGHIJKLMN s3_bucket: quay_bucket storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - s3Storage
2.6.7. Google クラウドストレージ
DISTRIBUTED_STORAGE_CONFIG: googleCloudStorage: - GoogleCloudStorage - access_key: GOOGQIMFB3ABCDEFGHIJKLMN bucket_name: quay-bucket secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - googleCloudStorage
2.6.8. Azure ストレージ
DISTRIBUTED_STORAGE_CONFIG: azureStorage: - AzureStorage - azure_account_name: azure_account_name_here azure_account_key: azure_account_key_here azure_container: azure_container_here sas_token: some/path/ storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - azureStorage
2.6.9. Swift ストレージ:
DISTRIBUTED_STORAGE_CONFIG: swiftStorage: - SwiftStorage - swift_user: swift_user_here swift_password: swift_password_here swift_container: swift_container_here auth_url: https://example.org/swift/v1/quay auth_version: 1 ca_cert_path: /conf/stack/swift.cert" storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - swiftStorage
2.7. Redis 設定フィールド
2.7.1. ビルドログ
表2.6 ビルドログの設定
フィールド | タイプ | 説明 |
---|---|---|
BUILDLOGS_REDIS | オブジェクト | ビルドログキャッシュ用の Redis 接続の詳細 |
.host | 文字列 |
Redis にアクセスできるホスト名 |
.port | 数値 |
Redis にアクセスできるポート |
.password | 文字列 |
Redis にアクセスできるポート |
2.7.2. ユーザーイベント
表2.7 ユーザーイベント設定
フィールド | タイプ | 説明 |
---|---|---|
USER_EVENTS_REDIS | オブジェクト | ユーザーイベント処理の Redis 接続の詳細 |
.host | 文字列 |
Redis にアクセスできるホスト名 |
.port | 数値 |
Redis にアクセスできるポート |
.password | 文字列 |
Redis にアクセスできるポート |
2.7.3. redis の設定例
BUILDLOGS_REDIS: host: quay-server.example.com password: strongpassword port: 6379 USER_EVENTS_REDIS: host: quay-server.example.com password: strongpassword port: 6379
2.8. タグの有効期限オプション
表2.8 タグの有効期限の設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_GARBAGE_COLLECTION | Boolean |
リポジトリーのガベージコレクションが有効であるかどうか |
|
|
|
TAG_EXPIRATION_OPTIONS | 文字列の配列 |
ユーザーが namespace でタグの有効期限について選択できるオプション |
DEFAULT_TAG_EXPIRATION | 文字列 |
タイムマシンのデフォルトの設定可能なタグの有効期限 |
|
|
|
FEATURE_CHANGE_TAG_EXPIRATION | Boolean |
ユーザーおよび組織が namespace のタグの有効期限を変更できるかどうか |
例:
DEFAULT_TAG_EXPIRATION: 2w TAG_EXPIRATION_OPTIONS: - 0s - 1d - 1w - 2w - 4w
2.9. 自動化のための Quay の事前設定
Quay には、自動化をサポートする数多くの設定オプションがあります。これらのオプションはデプロイメントの前に設定でき、ユーザーインターフェイスとの対話の必要性を最小限に抑えることができます。
2.9.1. API による最初のユーザー作成の許可
設定オプション FEATURE_USER_INITIALIZE
を true
に設定し、API /api/v1/user/initialize
を使用して最初のユーザーを作成できるようにします。この API エンドポイントは、既存の組織の OAuth アプリケーションによって生成される OAuth トークンを必要とする他のすべてのレジストリー API 呼び出しとは異なり、認証は必要ありません。
Quay をデプロイしたら、API を使用してユーザーを作成できます (例: quayadmin
)。他のユーザーが作成されていない場合です。詳細は、API を使用した最初のユーザーの作成 のセクションを参照してください。
2.9.2. API 一般アクセスの有効化
Quay レジストリー API への一般アクセス を許可するように、BROWSER_API_CALLS_XHR_ONLY
を false
に設定します。
2.9.3. スーパーユーザーの追加
デプロイメント後はユーザーを作成することはできませんが、最初のユーザーが完全なパーミッションを持つ管理者となるようにしておくと便利です。SUPER_USER
設定オブジェクトを使用すると、事前にこの設定を事前に設定できます。
2.9.4. ユーザー作成の制限
スーパーユーザーを設定したら、新規ユーザーを作成する機能をスーパーユーザーグループに制限できます。ユーザー作成を制限するには、FEATURE_USER_CREATION
を false
に設定します。
2.9.5. 自動化の推奨設定
適切な設定が含まれる config.yaml
設定ファイルを作成します。
config.yaml
... FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false ...
2.9.6. 初期設定を使用した Operator のデプロイ
設定ファイルを使用してシークレットを作成します。
$ oc create secret generic --from-file config.yaml=./config.yaml init-config-bundle-secret
QuayRegistry YAML ファイル
quayregistry.yaml
を作成し、管理対象外コンポーネントを特定し、作成された Secret も参照します。以下に例を示します。quayregistry.yaml
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: init-config-bundle-secret
レジストリーをデプロイします。
$ oc create -f quayregistry.yaml
-
API を使用して最初のユーザー
quayadmin
を作成します。
2.9.7. API を使用した最初のユーザーの作成
API を使用して最初のユーザーを作成する場合には、以下の条件を満たしている必要があります。
-
設定オプション
FEATURE_USER_INITIALIZE
をtrue
に設定する。 - データベースにユーザーが存在していない。
デプロイメントの事前設定に関する詳細は、自動化のための Quay の事前設定 セクションを参照してください。
2.9.7.1. API の呼び出し
status.registryEndpoint
URL を使用して、ユーザー名、パスワード、およびメールアドレスを渡して /api/v1/user/initialize
API を呼び出します。"access_token": true
を指定して OAuth トークンを要求することもできます。
$ curl -X POST -k https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"quaypass123", "email": "quayadmin@example.com", "access_token": true}'
{"access_token":"6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED", "email":"quayadmin@example.com","encrypted_password":"1nZMLH57RIE5UGdL/yYpDOHLqiNCgimb6W9kfF8MjZ1xrfDpRyRs9NUnUuNuAitW","username":"quayadmin"}
成功すると、メソッドはユーザー名、メール、および暗号化されたパスワードを持つオブジェクトを返します。データベースにユーザーが存在している場合は、エラーが返されます。
$ curl -X POST -k https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayuser2", "password":"quaypass123", "email": "quayuser2@example.com"}'
{"message":"Cannot initialize user in a non-empty database"}
パスワードは 8 文字以上で、空白文字は使用しないでください。
$ curl -X POST -k https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"pass123", "email": "quayadmin@example.com"}'
{"message":"Failed to initialize user: Invalid password, password must be at least 8 characters and contain no whitespace."}
2.9.7.2. OAuth トークンの使用
返された OAuth コードを指定して残りの Quay API を呼び出すことができます。たとえば、現在のユーザーの一覧を取得するには、以下を実行します。
$ curl -X GET -k -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/superuser/users/
{ "users": [ { "kind": "user", "name": "quayadmin", "username": "quayadmin", "email": "quayadmin@example.com", "verified": true, "avatar": { "name": "quayadmin", "hash": "3e82e9cbf62d25dec0ed1b4c66ca7c5d47ab9f1f271958298dea856fb26adc4c", "color": "#e7ba52", "kind": "user" }, "super_user": true, "enabled": true } ] }
このインスタンスでは、これまで作成した唯一のユーザーであるため、quayadmin
ユーザーの詳細が返されます。
2.9.7.2.1. 組織の作成
組織を作成するには、api/v1/organization/
エンドポイントへの POST 呼び出しを使用します。
$ curl -X POST -k --header 'Content-Type: application/json' -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/organization/ --data '{"name": "testorg", "email": "testorg@example.com"}'
"Created"
2.9.7.2.2. 組織の詳細の取得
作成した組織の詳細を取得するには、以下を実行します。
$ curl -X GET -k --header 'Content-Type: application/json' -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://min-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/organization/testorg
{ "name": "testorg", "email": "testorg@example.com", "avatar": { "name": "testorg", "hash": "5f113632ad532fc78215c9258a4fb60606d1fa386c91b141116a1317bf9c53c8", "color": "#a55194", "kind": "user" }, "is_admin": true, "is_member": true, "teams": { "owners": { "name": "owners", "description": "", "role": "admin", "avatar": { "name": "owners", "hash": "6f0e3a8c0eb46e8834b43b03374ece43a030621d92a7437beb48f871e90f8d90", "color": "#c7c7c7", "kind": "team" }, "can_view": true, "repo_count": 0, "member_count": 1, "is_synced": false } }, "ordered_teams": [ "owners" ], "invoice_email": false, "invoice_email_address": null, "tag_expiration_s": 1209600, "is_free_account": true }
2.10. 基本設定
表2.9 基本設定
フィールド | タイプ | 説明 |
---|---|---|
REGISTRY_TITLE | 文字列 |
指定されている場合は、レジストリーの長いタイトル |
REGISTRY_TITLE_SHORT | 文字列 |
指定されている場合は、短縮形のレジストリーのタイトル |
|
|
|
BRANDING | オブジェクト | Red Hat Quay UI のロゴおよび URL のカスタムブランディング |
.logo | 文字列 |
主なロゴイメージ URL |
.footer_img | 文字列 |
UI フッターのロゴ |
.footer_url | 文字列 |
フッターイメージのリンク |
|
|
|
CONTACT_INFO | 文字列の配列 | 指定されている場合は、連絡先ページに表示される連絡先情報。連絡先が 1 つしか指定されていない場合は、連絡先のフッターが直接リンクされます。 |
[0] | 文字列 |
メール送信のリンクを追加します |
[1] | 文字列 |
IRC チャット部屋にアクセスするときのリンクを追加します。 |
[2] | 文字列 |
呼び出し先の電話番号へのリンクを追加します。 |
[3] | 文字列 |
定義された URL へのリンクを追加します。 |
2.11. SSL 設定フィールド
表2.10 SSL 設定
フィールド | タイプ | 説明 |
---|---|---|
PREFERRED_URL_SCHEME | String |
|
SERVER_HOSTNAME | 文字列 |
スキームなしで Red Hat Quay にアクセスできる URL |
SSL_CIPHERS | 文字列の配列 |
指定されている場合、有効化および無効化する SSL 暗号の nginx 定義の一覧 |
SSL_PROTOCOLS | 文字列の配列 |
指定されている場合、nginx は、一覧で定義される SSL プロトコルの一覧を有効にするように設定されます。リストから SSL プロトコルを削除すると、Red Hat Quay の起動時にそのプロトコルが無効になります。 |
SESSION_COOKIE_SECURE | ブール値 |
セッションクッキーに |
2.11.1. SSL の設定
証明書ファイルとプライマリーキーファイルを設定ディレクトリーにコピーして、それぞれ
ssl.cert
とssl.key
という名前が付けられていることを確認します。$ cp ~/ssl.cert $QUAY/config $ cp ~/ssl.key $QUAY/config $ cd $QUAY/config
config.yaml
ファイルを編集し、Quay で TLS を処理できるように指定します。config.yaml
... SERVER_HOSTNAME: quay-server.example.com ... PREFERRED_URL_SCHEME: https ...
-
Quay
コンテナーを停止し、レジストリーを再起動します。
2.12. Red Hat Quay コンテナーへの TLS 証明書の追加
カスタム TLS 証明書を Red Hat Quay に追加するには、Red Hat Quay の config ディレクトリーの下に extra_ca_certs/
という名前の新しいディレクトリーを作成します。必要なサイト固有の TLS 証明書をこの新しいディレクトリーにコピーします。
2.12.1. TLS 証明書を Red Hat Quay に追加
コンテナーに追加される証明書を表示します。
$ cat storage.crt -----BEGIN CERTIFICATE----- MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV [...] -----END CERTIFICATE-----
certs ディレクトリーを作成し、そこに証明書をコピーします。
$ mkdir -p quay/config/extra_ca_certs $ cp storage.crt quay/config/extra_ca_certs/ $ tree quay/config/ ├── config.yaml ├── extra_ca_certs │ ├── storage.crt
Quay
コンテナーのCONTAINER ID
をpodman ps
で取得します。$ sudo podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS 5a3e82c4a75f <registry>/<repo>/quay:v3.6.8 "/sbin/my_init" 24 hours ago Up 18 hours 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 443/tcp grave_keller
その ID でコンテナーを再起動します。
$ sudo podman restart 5a3e82c4a75f
コンテナーの名前空間にコピーされた証明書を調べます。
$ sudo podman exec -it 5a3e82c4a75f cat /etc/ssl/certs/storage.pem -----BEGIN CERTIFICATE----- MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV
2.13. LDAP 設定フィールド
表2.11 LDAP の設定
フィールド | タイプ | 説明 |
---|---|---|
AUTHENTICATION_TYPE | 文字列 |
|
FEATURE_TEAM_SYNCING | ブール値 |
認証エンジン (LDAP または Keystone) のバッキンググループからチームメンバーシップを同期するかどうか |
FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP | ブール値 |
有効にすると、スーパーユーザー以外のユーザーは LDAP を使用してチームの同期を設定できます。 |
|
|
|
LDAP_ADMIN_DN | 文字列 | LDAP 認証の管理 DN。 |
LDAP_ADMIN_PASSWD | 文字列 | LDAP 認証の管理パスワード。 |
LDAP_ALLOW_INSECURE_FALLBACK | ブール値 | LDAP 認証で SSL の非セキュアなフォールバックを許可するかどうか。 |
LDAP_BASE_DN | 文字列の配列 | LDAP 認証のベース DN。 |
LDAP_EMAIL_ATTR | 文字列 | LDAP 認証のメール属性。 |
LDAP_UID_ATTR | 文字列 | LDAP 認証の uid 属性。 |
LDAP_URI | 文字列 | LDAP URI。 |
LDAP_USER_FILTER | 文字列 | LDAP 認証のユーザーフィルター。 |
LDAP_USER_RDN | 文字列の配列 | LDAP 認証のユーザー RDN。 |
TEAM_RESYNC_STALE_TIME | 文字列 |
チームの同期が有効になっている場合に、必要に応じてメンバーシップを確認して再同期する頻度 |
2.13.1. LDAP 設定の例
$QUAY/config/config.yaml
AUTHENTICATION_TYPE: LDAP ... LDAP_ADMIN_DN: uid=testuser,ou=Users,o=orgid,dc=jumpexamplecloud,dc=com LDAP_ADMIN_PASSWD: samplepassword LDAP_ALLOW_INSECURE_FALLBACK: false LDAP_BASE_DN: - o=orgid - dc=example - dc=com LDAP_EMAIL_ATTR: mail LDAP_UID_ATTR: uid LDAP_URI: ldap://ldap.example.com:389 LDAP_USER_RDN: - ou=Users
2.14. 設定フィールドのミラーリング
表2.12 ミラーリング設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_REPO_MIRROR | ブール値 |
リポジトリーミラーリングの有効化または無効化を行います。 |
|
|
|
REPO_MIRROR_INTERVAL | 数値 |
次にリポジトリーミラー候補をチェックするまでの秒数 |
REPO_MIRROR_SERVER_HOSTNAME | 文字列 |
|
REPO_MIRROR_TLS_VERIFY | ブール値 |
HTTPS を必要とし、ミラー時に Quay レジストリーの証明書を検証します。 |
2.15. セキュリティースキャナー設定フィールド
表2.13 セキュリティースキャナーの設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_SECURITY_SCANNER | ブール値 |
セキュリティースキャナー |
FEATURE_SECURITY_NOTIFICATIONS | ブール値 |
セキュリティースキャナーが有効になっている場合は、セキュリティー通知を有効にするか、オフにします。 |
SECURITY_SCANNER_V4_REINDEX_THRESHOLD | 文字列 |
このパラメーターは、最終のインデックス作成から状態が変更されたか、以前に失敗したマニフェストのインデックスをもう一度作成するまで待機する最小時間を判断するのに使用します。データは manifestsecuritystatus テーブルの |
SECURITY_SCANNER_V4_ENDPOINT | 文字列 |
V4 セキュリティースキャナーのエンドポイント |
SECURITY_SCANNER_V4_PSK | 文字列 | Clair 用に生成された共有キー (PSK) |
SECURITY_SCANNER_INDEXING_INTERVAL | 数値 |
セキュリティースキャナーのインデックス作成の間隔 (秒単位) |
SECURITY_SCANNER_ENDPOINT | 文字列 |
V2 セキュリティースキャナーのエンドポイント |
SECURITY_SCANNER_INDEXING_INTERVAL | 文字列 | このパラメーターは、セキュリティースキャナーのインデックス作成の間隔 (秒単位) を決定するために使用されます。インデックスがトリガーされると、Red Hat Quay は、Clair でインデックス化する必要のあるマニフェストに対してそのデータベースをクエリーします。これには、インデックス化されていないマニフェストや、以前にインデックスに失敗したマニフェストが含まれます。 |
以下は、インデックス変更の特別なケースです。
Clair v4 がマニフェストをインデックス化する場合は、結果として、決定論的なものである必要があります。たとえば、同じマニフェストが同じインデックスレポートを生成する必要があります。これは、異なるスキャナーを使用するとレポートで返される特定のマニフェストに関連して異なる情報を生成するため、スキャナーが変更されるまで True となります。そのため、Clair v4 はインデックスエンジン (/indexer/api/v1/index_state
) の状態表現を公開し、スキャナー設定が変更されたかどうかを判別します。
Red Hat Quay は、Quay のデータベースの解析時にこれをインデックスレポートに保存し、このインデックス状態を活用します。以前にスキャンされてからこの状態が変更された場合、Quay は定期的なインデックスプロセス時にマニフェストの再作成を試行します。
デフォルトでは、このパラメーターは 30 秒に設定されています。インデックス作成のプロセスをより頻繁に実行する場合は、時間を短縮します。たとえば、新規タグをプッシュしてから、30 秒待たずに、UI でセキュリティースキャンの結果を表示する場合などです。また、ユーザーは要求パターンを Clair に制御し、Quay データベースで実行されるデータベース操作のパターンをより詳細に制御する必要がある場合にパラメーターを変更することもできます。
2.16. OCI および Helm の設定
Helm のサポートが FEATURE_GENERAL_OCI_SUPPORT
プロパティーでサポートされるようになりました。機能を明示的に有効にする必要がある場合 (機能が無効にされている場合や、デフォルトで有効にされていないバージョンからアップグレードした場合など) は、OCI アーティファクトの使用を有効にするために 2 つのプロパティーを Quay 設定に追加する必要があります。
FEATURE_GENERAL_OCI_SUPPORT: true FEATURE_HELM_OCI_SUPPORT: true
表2.14 OCI および Helm の設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_GENERAL_OCI_SUPPORT | ブール値 |
OCI アーティファクトのサポートを有効にします。 |
FEATURE_HELM_OCI_SUPPORT | ブール値 |
Helm アーティファクトのサポートを有効にします。 |
Red Hat Quay 3.6 の時点で、FEATURE_HELM_OCI_SUPPORT
は非推奨になり、Red Hat Quay の今後のバージョンで削除される予定です。Red Hat Quay 3.6 では、Helm アーティファクトがデフォルトでサポートされ、FEATURE_GENERAL_OCI_SUPPORT
プロパティーに含まれています。ユーザーは、サポートを有効にするために config.yaml ファイルを更新する必要がなくなりました。
2.17. アクションログ設定フィールド
2.17.1. アクションログストレージ設定
表2.15 アクションログストレージ設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_LOG_EXPORT | ブール値 |
アクションログのエクスポートを許可するかどうか |
|
|
|
LOGS_MODEL | 文字列 |
セキュリティースキャナーを有効または無効にします。 |
LOGS_MODEL_CONFIG | オブジェクト | アクションログのログモデル設定 |
LOGS_MODEL_CONFIG [オブジェクト]: アクションログ用のログモデル設定
elasticsearch_config [オブジェクト]: Elasticsearch クラスターの設定
access_key [文字列] :Elasticsearch のユーザー (AWS ES の場合は IAM キー)
-
例:
some_string
-
例:
ホスト [文字列]: Elasticsearch クラスターのエンドポイント
-
例:
host.elasticsearch.example
-
例:
index_prefix [文字列]。Elasticsearch のインデックスの接頭辞
-
例:
logentry_
-
例:
- index_settings [オブジェクト]: Elasticsearch のインデックス設定
use_ssl [ブール値]。Elasticsearch に ssl を使用します。デフォルトは true です。
-
例:
True
-
例:
secret_key [文字列] :Elasticsearch のパスワード (AWS ES の場合は IAM シークレット)
-
例:
some_secret_string
-
例:
aws_region [文字列]: Amazon Web サービスの地域
-
例:
us-east-1
-
例:
port [番号]: Elasticsearch クラスターのエンドポイントポート
-
例:
1234
-
例:
kinesis_stream_config [オブジェクト]: AWS Kinesis ストリームの設定
aws_secret_key [文字列]: AWS の秘密鍵
-
例:
some_secret_key
-
例:
stream_name [文字列]: アクションログの送信先となる Kinesis ストリーム
-
例:
logentry-kinesis-stream
-
例:
aws_access_key [文字列]: AWS アクセスキー
-
例:
some_access_key
-
例:
retries [番号]: 一回のリクエストに対する最大試行回数
-
例:
5
-
例:
read_timeout [番号]: 接続の読み込み時にタイムアウトするまでの秒数
-
例:
5
-
例:
max_pool_connections [番号]: コネクションプールに保持するコネクションの最大数
-
例:
10
-
例:
aws_region [文字列]: AWS のリージョン
-
例:
us-east-1
-
例:
connect_timeout [番号]: 接続を試みる際のタイムアウトまでの秒数
-
例:
5
-
例:
producer [文字列]: Elasticsearch にロギングする場合は、producer を記録します。
- enum: kafka、elasticsearch、kinesis_stream
-
例:
kafka
kafka_config [オブジェクト]: Kafka クラスターの設定
topic [文字列]: ログエントリーを公開する Kafka トピック
-
例:
logentry
-
例:
- bootstrap_servers [配列]: クライアントをブートストラップさせる Kafka ブローカーのリスト
max_block_seconds [番号]:
send()
の実行中に、バッファーがいっぱいになったり、メタデータが利用できないなどの理由でブロックする最大秒数-
例:
10
-
例:
2.17.2. アクションログのローテーションおよびアーカイブ設定
表2.16 アクションログのローテーションおよびアーカイブ設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_ACTION_LOG_ROTATION | ブール値 |
ログローテーションおよび archival を有効にすると、30 日以上経過したすべてのログをストレージに移動します。 |
|
|
|
ACTION_LOG_ARCHIVE_LOCATION | 文字列 |
アクションログのアーカイブが有効な場合は、アーカイブされたデータを配置するストレージエンジン |
ACTION_LOG_ARCHIVE_PATH | 文字列 |
アクションログのアーカイブが有効な場合は、アーカイブされたデータを配置するストレージのパス |
ACTION_LOG_ROTATION_THRESHOLD | 文字列 |
ログをローテーションする間隔 |
2.18. ビルドログ
表2.17 ビルドログ
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_READER_BUILD_LOGS | ブール値 |
true に設定されている場合は、書き込みアクセスや管理アクセスがある場合だけでなく、リポジトリーへの読み取りアクセスを持つユーザーがビルドログを読み取ることができます。 |
|
|
|
LOG_ARCHIVE_LOCATION | 文字列 |
アーカイブされたビルドログを配置する、DISTRIBUTED_STORAGE_CONFIG で定義されたストレージの場所 |
LOG_ARCHIVE_PATH | 文字列 |
アーカイブされたビルドログを JSON 形式で配置する、設定されたストレージエンジンの下のパス |
2.19. Dockerfile ビルドトリガーフィールド
表2.18 Dockerfile ビルドのサポート
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_BUILD_SUPPORT | ブール値 |
Dockerfile ビルドをサポートするかどうか |
SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD | 数値 |
None ではない場合に、ビルドトリガーが自動的に無効にされる前に、連続で失敗できる回数 |
SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD | 数値 |
None ではない場合に、ビルドトリガーが自動的に無効にされる前に、連続で発生可能な内部エラーの回数 |
2.19.1. GitHub ビルドトリガー
表2.19 GitHub ビルドトリガー
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_GITHUB_BUILD | ブール値 |
GitHub ビルドトリガーをサポートしているかどうか |
|
|
|
GITHUB_TRIGGER_CONFIG | オブジェクト | ビルドトリガーに GitHub (Enterprise) を使用するための設定 |
.GITHUB_ENDPOINT | 文字列 |
GitHub (Enterprise) のエンドポイント |
.API_ENDPOINT | 文字列 |
使用する GitHub (Enterprise) API のエンドポイント。 |
.CLIENT_ID | 文字列 | この Red Hat Quay インスタンスの登録されたクライアント ID。GITHUB_LOGIN_CONFIG と共有にすることはできません。 |
.CLIENT_SECRET | 文字列 | この Red Hat Quay インスタンスの登録されたクライアントシークレット。 |
2.19.2. Bitbucket ビルドトリガー
表2.20 Bitbucket ビルドトリガー
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_BITBUCKET_BUILD | ブール値 |
Bitbucket ビルドトリガーをサポートしているかどうか |
|
|
|
BITBUCKET_TRIGGER_CONFIG | オブジェクト | ビルドトリガーに BitBucket を使用するための設定 |
.CONSUMER_KEY | 文字列 | この Quay インスタンスの登録されたコンシューマーキー (クライアント ID) |
.CONSUMER_SECRET | 文字列 | この Quay インスタンスの、登録されたコンシューマーシークレット (クライアントシークレット) |
2.19.3. GitLab ビルドトリガー
表2.21 GitLab ビルドトリガー
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_GITLAB_BUILD | ブール値 |
GitLab ビルドトリガーをサポートしているかどうか |
|
|
|
GITLAB_TRIGGER_CONFIG | オブジェクト | ビルドトリガーに Gitlab を使用するための設定 |
.GITLAB_ENDPOINT | 文字列 | Gitlab (Enterprise) が実行されているエンドポイント |
.CLIENT_ID | 文字列 | この Quay インスタンスの、登録されたクライアント ID |
.CLIENT_SECRET | 文字列 | この Quay インスタンスの、登録されたクライアントシークレット |
2.20. OAuth の設定
表2.22 OAuth フィールド
フィールド | タイプ | 説明 |
---|---|---|
DIRECT_OAUTH_CLIENTID_WHITELIST | 文字列の配列 | ユーザーの承認なしに直接 OAuth 承認を実行できる Red Hat Quay 管理 アプリケーションのクライアント ID の一覧。 |
2.20.1. GitHub OAuth
表2.23 GitHub OAuth フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_GITHUB_LOGIN | ブール値 |
GitHub ログインがサポートされるかどうか |
GITHUB_LOGIN_CONFIG | オブジェクト | 外部ログインプロバイダーとして GitHub (Enterprise) を使用するための設定 |
.ALLOWED_ORGANIZATIONS | 文字列の配列 | ORG_RESTRICT オプションを使用するためにホワイトリスト化された GitHub (Enterprise) 組織の名前 |
.API_ENDPOINT | 文字列 |
使用する GitHub (Enterprise) API のエンドポイント。github.com に対して上書きする必要があります。 |
.CLIENT_ID | 文字列 |
この Red Hat Quay インスタンスの登録されたクライアント ID。GITHUB_TRIGGER_CONFIG とは共有できません。 |
.CLIENT_SECRET | 文字列 |
Red Hat Quay インスタンスの登録クライアントシークレット |
.GITHUB_ENDPOINT | 文字列 |
GitHub (Enterprise) のエンドポイント |
.ORG_RESTRICT | ブール値 | true の場合、このプロバイダーを使用してログインできるのは組織のホワイトリスト内のユーザーのみです。 |
2.20.2. Google OAuth
表2.24 Google OAuth フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_GOOGLE_LOGIN | ブール値 |
Google ログインがサポートされるかどうか |
GOOGLE_LOGIN_CONFIG | オブジェクト | 外部認証に Google を使用するための設定 |
.CLIENT_ID | 文字列 |
この Red Hat Quay インスタンスの登録されたクライアント ID |
.CLIENT_SECRET | 文字列 |
Red Hat Quay インスタンスの登録クライアントシークレット |
2.21. ネストされたリポジトリーの設定
Red Hat Quay 3.6 では、ネストされたリポジトリーパス名のサポートが FEATURE_EXTENDED_REPOSITORY_NAMES
プロパティーに追加されました。このオプションの設定は、ユーザーがサポートを有効にするために config.yaml に手動で追加する必要があります。有効にすると、リポジトリー名で /
を使用できます。
FEATURE_EXTENDED_REPOSITORY_NAMES: true
表2.25 OCI およびネストされたリポジトリーの設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_EXTENDED_REPOSITORY_NAMES | Boolean |
ネストされたリポジトリーのサポートを有効にします。 |
2.22. その他の OCI メディアタイプの Quay への追加
Helm、cosign、および ztsd 圧縮スキームアーティファクトはデフォルトで Red Hat Quay 3.6 に組み込まれています。デフォルトでサポートされていない他の OCI メディアタイプでは、以下の形式を使用して Quay の config.yaml の ALLOWED_OCI_ARTIFACT_TYPES
設定に追加できます。
ALLOWED_OCI_ARTIFACT_TYPES: <oci config type 1>: - <oci layer type 1> - <oci layer type 2> <oci config type 2>: - <oci layer type 3> - <oci layer type 4> ...
たとえば、以下を config.yaml に追加して Singularity (SIF) サポートを追加できます。
... ALLOWED_OCI_ARTIFACT_TYPES: application/vnd.oci.image.config.v1+json - application/vnd.dev.cosign.simplesigning.v1+json application/vnd.cncf.helm.config.v1+json - application/tar+gzip application/vnd.sylabs.sif.config.v1+json - application/vnd.sylabs.sif.layer.v1+tar ...
デフォルトで設定されていない OCI メディアタイプを追加する場合、ユーザーは必要に応じて cosign と Helm のサポートも手動で追加する必要があります。ztsd 圧縮スキームはデフォルトでサポートされているため、ユーザーはサポートを有効にするためにその OCI メディアタイプを config.yaml に追加する必要はありません。
2.23. メール設定
表2.26 メールフィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_MAILING | ブール値 |
メールが有効であるかどうか |
|
|
|
MAIL_DEFAULT_SENDER | 文字列 |
これが指定されている場合は、Red Hat Quay がメールを送信する際の |
MAIL_PASSWORD | 文字列 | メールの送信時に使用する SMTP パスワード。 |
MAIL_PORT | 数値 | 使用する SMTP ポート。指定されていない場合は、デフォルトの 587 になります。 |
MAIL_SERVER | 文字列 |
メールの送信に使用する SMTP サーバー。FEATURE_MAILING が true に設定されている場合のみ必要です。 |
MAIL_USERNAME | 文字列 | メールの送信時に使用する SMTP ユーザー名 |
MAIL_USE_TLS | ブール値 |
指定されている場合は、電子メールの送信に TLS を使用するかどうか |
2.24. ユーザー設定フィールド
表2.27 ユーザー設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_SUPER_USERS | ブール値 |
スーパーユーザーがサポートされるかどうか |
FEATURE_USER_CREATION | ブール値 |
ユーザーを作成するかどうか (スーパーユーザー以外) |
FEATURE_USER_LAST_ACCESSED | ブール値 |
ユーザーが最後にアクセスした時間を記録するかどうか |
FEATURE_USER_LOG_ACCESS | ブール値 |
true に設定すると、ユーザーは namespace の監査ログにアクセスできます。 |
FEATURE_USER_METADATA | ブール値 |
ユーザーメタデータを収集してサポートするかどうか |
FEATURE_USERNAME_CONFIRMATION | ブール値 |
true に設定すると、生成されたユーザー名を確認できます。 |
FEATURE_USER_RENAME | ブール値 |
true に設定されている場合、ユーザーは独自の namespace の名前に変更できます。 |
FEATURE_INVITE_ONLY_USER_CREATION | ブール値 |
作成するユーザーは別のユーザーから招待を受ける必要があります。 |
|
|
|
FRESH_LOGIN_TIMEOUT | 文字列 |
新規ログインでユーザーがパスワードの再入力に必要な時間 |
USERFILES_LOCATION | 文字列 |
ユーザーがアップロードしたファイルを配置するストレージエンジンの ID |
USERFILES_PATH | 文字列 |
ユーザーがアップロードしたファイルを配置するストレージの下のパス。 |
USER_RECOVERY_TOKEN_LIFETIME | 文字列 |
ユーザーアカウントを復元するためのトークンが有効な期間 |
2.25. reCAPTCHA 設定
表2.28 reCAPTCHA フィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_RECAPTCHA | ブール値 |
ユーザーログインおよびリカバリーに Recaptcha が必要かどうか |
|
|
|
RECAPTCHA_SECRET_KEY | 文字列 | recaptcha が有効にされている場合は、Recaptcha サービスのシークレットキー |
RECAPTCHA_SITE_KEY | 文字列 | recaptcha が有効にされている場合は、Recaptcha サービスのサイトキー |
2.26. ACI 設定
表2.29 ACI 設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_ACI_CONVERSION | ブール値 |
ACI への変換を有効にするかどうか |
|
|
|
GPG2_PRIVATE_KEY_FILENAME | 文字列 | ACI の復号化に使用される秘密鍵のファイル名 |
GPG2_PRIVATE_KEY_NAME | 文字列 | ACI に署名するために使用されるプライベートキーの名前 |
GPG2_PUBLIC_KEY_FILENAME | 文字列 | ACI の暗号化に使用する公開鍵のファイル名 |
2.27. JTW 設定
表2.30 JWT 設定
フィールド | タイプ | 説明 |
---|---|---|
JWT_AUTH_ISSUER | 文字列 |
JWT ユーザーのエンドポイント |
JWT_GETUSER_ENDPOINT | 文字列 |
JWT ユーザーのエンドポイント |
JWT_QUERY_ENDPOINT | 文字列 |
JWT クエリーのエンドポイント |
JWT_VERIFY_ENDPOINT | 文字列 |
JWT 検証のエンドポイント |
2.28. アプリケーショントークン
表2.31 アプリケーショントークンの設定
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_APP_SPECIFIC_TOKENS | ブール値 |
有効な場合には、ユーザーは Docker CLI で使用するトークンを作成できます。 |
|
|
|
APP_SPECIFIC_TOKEN_EXPIRATION | 文字列 |
外部アプリケーショントークンの有効期限 |
EXPIRED_APP_SPECIFIC_TOKEN_GC | 文字列 |
期限切れとなった外部アプリケーションがガべージコレクションが行われるまでに留まる期間。 |
2.29. その他のフィールド
表2.32 その他のフィールド
フィールド | タイプ | 説明 |
---|---|---|
ALLOW_PULLS_WITHOUT_STRICT_LOGGING | 文字列 |
true に指定すると、プルの監査ログのエントリーに書き込みできない場合でも、プルは成功します。これは、データベースが読み取り専用の状態にフォールバックし、その間プルを続行する必要がある場合に便利です。 |
AVATAR_KIND | 文字列 |
表示する avatar のタイプ。インライン (ローカル) または Gravatar (gravatar) |
BROWSER_API_CALLS_XHR_ONLY | ブール値 |
有効にされている場合は、ブラウザーから XHR による呼び出しとしてマークが付けられた API のみが許可されます。 |
DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT | 数値 |
namespace でキューに入れることができるデフォルトの最大ビルド数です。 |
ENABLE_HEALTH_DEBUG_SECRET | 文字列 | 指定されている場合は、スーパーユーザーとして認証されていない場合に詳細なデバッグ情報を表示するために正常性エンドポイントに指定できるシークレット |
EXTERNAL_TLS_TERMINATION | ブール値 | TLS がサポートされているが、Quay の前の層で終了する場合は true に設定します。 |
FRESH_LOGIN_TIMEOUT | 文字列 |
新規ログインでユーザーがパスワードの再入力に必要な時間 |
HEALTH_CHECKER | 文字列 |
設定済みのヘルスチェック |
PROMETHEUS_NAMESPACE | 文字列 |
公開されているすべての Prometheus メトリクスに適用される接頭辞 |
PUBLIC_NAMESPACES | 文字列の配列 | namespace がパブリック namespace 一覧に定義されている場合に、それはユーザーが namespace のメンバーであるかどうかに関係なく、すべての ユーザーのリポジトリー一覧ページに表示されます。一般的には、企業のお客様がよく知られた名前空間のセットを設定する際に使用されます。 |
REGISTRY_STATE | 文字列 |
レジストリーの状態 |
SEARCH_MAX_RESULT_PAGE_COUNT | 数値 |
ユーザーが検索で表示できる最大ページ数 |
SEARCH_RESULTS_PER_PAGE | 数値 |
検索ページでページごとに返される結果数 |
V1_PUSH_WHITELIST | 文字列の配列 | FEATURE_RESTRICTED_V1_PUSH が true に設定されている場合に V1 push をサポートする namespace 名の配列。 |
V2_PAGINATION_SIZE | 数値 | V2 レジストリー API のページごとに返される結果の数 |
WEBHOOK_HOSTNAME_BLACKLIST | 文字列の配列 | 検証時に、ローカルホスト以外に Webhook から禁止するホスト名のセット |
CREATE_PRIVATE_REPO_ON_PUSH | ブール値 |
プッシュで作成された新規リポジトリーがプライベート表示に設定されているかどうか |
CREATE_NAMESPACE_ON_PUSH | ブール値 |
既存の組織への新規プッシュで namespace を作成するかどうか |
NON_RATE_LIMITED_NAMESPACES | 文字列の配列 |
|
2.30. レガシー設定フィールド
一部のフィールドは非推奨または廃止されています。
表2.33 レガシーフィールド
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_BLACKLISTED_EMAILS | ブール値 | true に設定すると、メールドメインがブラックリストに指定されている場合には、新しいユーザーアカウントが作成されません。 |
BLACKLISTED_EMAIL_DOMAINS | 文字列の配列 |
FEATURE_BLACKLISTED_EMAILS が true に設定されている場合に使用されるメールアドレスドメインの一覧 |
BLACKLIST_V2_SPEC | 文字列 |
Red Hat Quay が V2 は サポート対象外 であることを示す応答を返す Docker CLI バージョン |
DOCUMENTATION_ROOT | 文字列 | ドキュメントリンクのルート URL |
SECURITY_SCANNER_V4_NAMESPACE_WHITELIST | 文字列 | セキュリティースキャナーを有効にする namespace |
第3章 環境変数
Red Hat Quay は、動的に設定する多数の環境変数をサポートします。
3.1. Geo レプリケーション
ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、QUAY_DISTRIBUTED_STORAGE_PREFERENCE
環境変数を使用して明示的に設定できます。
表3.1 Geo レプリケーションの設定
変数 | 型 | 説明 |
---|---|---|
QUAY_DISTRIBUTED_STORAGE_PREFERENCE | 文字列 | 使用する優先されるストレージ (DISTRIBUTED_STORAGE_CONFIG の ID 別) |
3.2. データベース接続プール
Red Hat Quay は、すべてが同じコンテナー内で実行する多くの異なるプロセスで設定されています。これらのプロセスの多くは、データベースと連動しています。
有効にすると、データベースと対話する各プロセスには、コネクションプールが含まれます。これらのプロセスごとのコネクションプールは、最大 20 個の接続を維持するように設定されています。高負荷時には、Red Hat Quay コンテナー内のすべてのプロセスの接続プールを満たすことが可能です。特定の展開や負荷の下では、Red Hat Quay がデータベースの設定された最大接続数を超えないようにするための分析が必要になる場合があります。
時間が経つと、接続プールはアイドル接続を解放します。すべての接続をすぐに解除するには、Red Hat Quay の再起動が必要です。
データベース接続プールは、環境変数 DB_CONNECTION_POOLING={true|false} を設定して切り替えることができます。
表3.2 データベース接続プールの設定
変数 | 型 | 説明 |
---|---|---|
DB_CONNECTION_POOLING | ブール値 | データベース接続プールの有効化または無効化 |
データベース接続プーリングが有効な場合は、接続プールの最大サイズを変更することができます。これは、以下の config.yaml オプションを使用して実行できます。
config.yaml
... DB_CONNECTION_ARGS: max_connections: 10 ...
3.3. HTTP 接続回数
環境変数を使用して、HTTP の同時接続数を指定することができます。これらは、全体として、または特定のコンポーネントに対して指定することができます。それぞれのデフォルトは、1 プロセスあたり 50 並列接続です。
表3.3 HTTP 接続数の設定
変数 | 型 | 説明 |
---|---|---|
WORKER_CONNECTION_COUNT | 数値 |
同時 HTTP 接続 |
WORKER_CONNECTION_COUNT_REGISTRY | 数値 |
レジストリーの同時 HTTP 接続 |
WORKER_CONNECTION_COUNT_WEB | 数値 |
Web UI の同時 HTTP 接続 |
WORKER_CONNECTION_COUNT_SECSCAN | 数値 |
Clair の同時 HTTP 接続 |
3.4. ワーカーカウント変数
表3.4 ワーカーカウント変数
変数 | 型 | 説明 |
---|---|---|
WORKER_COUNT | 数値 | プロセス数の汎用上書き |
WORKER_COUNT_REGISTRY | 数値 |
|
WORKER_COUNT_WEB | 数値 |
コンテナー内の UI/Web リクエストを処理するプロセス数を指定します。 |
WORKER_COUNT_SECSCAN | 数値 |
コンテナー内のセキュリティースキャン (Clair など) の統合を処理するプロセス数を指定します。 |
第4章 設定ツールを使用した OpenShift における Quay の再設定
4.1. 設定エディターへのアクセス
QuayRegistry 画面の Details セクションには、設定エディターのエンドポイントと、設定エディターへのログインに使用する認証情報などのシークレットのリンクがあります。
4.1.1. 設定エディターの認証情報の取得
設定エディターシークレットのリンクをクリックします。
Secret details 画面の Data セクションで、
Reveal values
をクリックし、設定エディターへのログインに使用する認証情報を表示します。
4.1.2. 設定エディターへのログイン
設定エディターエンドポイントを参照し、設定ツールにアクセスする時に使用するユーザー名 (通常は quayconfig
)、および対応するパスワードを入力します。
4.1.3. 設定の変更
設定の更新例では、設定エディターツールを使用してスーパーユーザーを追加しています。
時間マシン機能に関する有効期限 (
4w
など) を追加します。-
Validate Configuration Changes
を選択して、変更が有効であることを確認します。 Reconfigure Quay
ボタンを押して変更を適用します。設定ツールは、変更が Quay に送信されていることを通知します。
設定ツール UI を使用して Red Hat Quay を再設定すると、更新された設定が適用されている間にレジストリーが短期間利用できなくなる可能性があります。
4.2. UI での再設定の監視
4.2.1. QuayRegistry リソース
Operator の再設定後に、QuayRegistry の特定インスタンスの YAML タブで再デプロイの進捗を追跡できます (この場合は example-registry
)。
ステータスが変わるたびに、データをリロードして更新されたバージョンを表示するように求められます。最終的に、Operator は変更を調整し、正常でないコンポーネントが報告されることはありません。
4.2.2. イベント
QuayRegistry の Events タブには、再デプロイに関連するイベントが表示されます。
再設定の影響を受ける namespace のすべてのリソースのストリーミングイベントは、Home → Events の OpenShift コンソールで利用できます。
4.3. 再設定後に更新された情報へのアクセス
4.3.1. UI で更新された設定ツールの認証情報へのアクセス
新しい Pod が設定ツール用に作成され、新規シークレットが作成されるので、次回ログインの試行時に更新されたパスワードを使用する必要があります。
4.3.2. UI で更新された config.yaml へのアクセス
設定バンドルを使用して、更新された config.yaml
ファイルにアクセスします。
- QuayRegistry の詳細画面で、Config Bundle Secret をクリックします。
-
Secret の詳細画面の Data セクションで、Reveal values をクリックし、
config.yaml
ファイルを表示します。 変更が適用されていることを確認します。この場合、
4w
はTAG_EXPIRATION_OPTIONS
の一覧に存在するはずです。... SERVER_HOSTNAME: example-quay-openshift-operators.apps.docs.quayteam.org SETUP_COMPLETE: true SUPER_USERS: - quayadmin TAG_EXPIRATION_OPTIONS: - 2w - 4w ...
第5章 Quay Operator コンポーネント
Quay は強力なコンテナーレジストリープラットフォームであるため、多くの依存関係が存在します。これらには、データベース、オブジェクトストレージ、Redis などが含まれます。Quay Operator は、Kubernetes 上で Quay とその依存関係に指向したデプロイメントを管理します。これらの依存関係は コンポーネント として処理され、QuayRegistry
API で設定されます。
QuayRegistry
カスタムリソースでは、spec.components
フィールドでコンポーネントを設定します。各コンポーネントには、kind
(コンポーネントの名前) と managed
(コンポーネントのライフサイクルを Operator が処理するかどうかを示すブール値) の 2 つのフィールドがあります。(このフィールドを省略する) デフォルトでは、すべてのコンポーネントが管理され、調整時に表示できるように自動的に入力されます。
spec: components: - managed: true kind: clair - managed: true kind: postgres - managed: true kind: objectstorage - managed: true kind: redis - managed: true kind: horizontalpodautoscaler - managed: true kind: route - managed: true kind: mirror - managed: true kind: monitoring - managed: true kind: tls
5.1. 管理コンポーネントの使用
QuayRegistry
カスタムリソースを指定しないと、Operator は以下の管理コンポーネントについてデフォルトを使用します。
- postgres: レジストリーメタデータを保存するには、Software Collections から Postgres 10 のバージョンを使用します。
- redis: Quay ビルダーの調整および一部の内部ロギングを処理します。
-
ObjectStorage: イメージレイヤー Blob を格納するには、Noobaa/RHOCS によって提供される
ObjectBucketClaim
Kubernetes API を使用します。 - clair: イメージの脆弱性スキャンを提供します。
- horizontalpodautoscaler: メモリー/CPU の消費に応じて Quay Pod 数を調整します。
- mirror: リポジトリーミラーワーカーを設定します (オプションのリポジトリーミラーリングをサポートするため)。
- route: OpenShift の外部から Quay レジストリーへの外部エントリーポイントを提供します。
- monitoring: Grafana ダッシュボード、個別のメトリクスへのアクセス、Quay Pod が頻繁に再起動されていることを通知するアラートなどが含まれます。
- tls: Red Hat Quay または OpenShift が TLS を処理するかどうかを設定します。
Operator は Red Hat Quay が管理コンポーネントを使用するために必要な設定およびインストール作業を処理します。Quay Operator によって実行される事前に設定されたデプロイメントがお使いの環境に適さない場合、以下のセクションで説明されているように Operator に unmanaged
のリソース (オーバーライド) を指定できます。
5.2. 依存関係向けの管理対象外コンポーネントの使用
Quay で使用する Postgres、Redis、またはオブジェクトストレージなどの既存のコンポーネントがある場合は、まず Quay 設定バンドル (config.yaml
) 内でそれらを設定し、QuayRegistry
でバンドルを参照します (Kubernetes Secret
)。これは、非管理対象のコンポーネントを示します。
Quay 設定エディターを使用して、既存の設定バンドルを作成または変更したり、Kubernetes Secret
の更新プロセスを単純化したりできます。Quay の設定が設定エディターで変更され、Operator に送信されると、Quay デプロイメントは新規の設定を反映するように更新されます。
5.2.1. 既存の Postgres データベースの使用
必要なデータベースフィールドを使用して設定ファイル
config.yaml
を作成します。config.yaml:
DB_URI: postgresql://test-quay-database:postgres@test-quay-database:5432/test-quay-database
設定ファイルを使用してシークレットを作成します。
$ kubectl create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
postgres
コンポーネントを管理対象外としてマークし、作成された Secret を参照する QuayRegistry YAML ファイルquayregistry.yaml
を作成します。quayregistry.yaml
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: postgres managed: false
- 以下のセクションで説明されているようにレジストリーをデプロイします。
5.2.2. NooBaa アンマネージドストレージ
- Storage → Object Bucket Claims のコンソールで NooBaa Object Bucket Claim を作成します。
- アクセスキー、バケット名、エンドポイント (ホスト名)、およびシークレットキーを含む Object Bucket Claim データの詳細を取得します。
Object Bucket Claim (オブジェクトバケット要求) の情報を使用して
config.yaml
設定ファイルを作成します。DISTRIBUTED_STORAGE_CONFIG: default: - RHOCSStorage - access_key: WmrXtSGk8B3nABCDEFGH bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef hostname: s3.openshift-storage.svc.cluster.local is_secure: true port: "443" secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
5.2.3. Horizontal Pod Autoscaler の無効化
HorizontalPodAutoscalers
が Clair、Quay、Mirror Pod に追加され、負荷の急上昇時に自動的にスケーリングされるようになりました。
HPA はデフォルトで managed
に設定され、Quay の Pod 数、Clair およびリポジトリーのミラーリングは 2 に設定されます。これにより、Operator 経由で Quay を更新/再設定する際や、イベントの再スケジュール時にダウンタイムを回避しやすくなります。
自動スケーリングを無効にするか、独自の HorizontalPodAutoscaler
を作成する場合は、コンポーネントを単純に QuayRegistry
インスタンスでアンマネージドとして指定します。
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: components: - kind: horizontalpodautoscaler managed: false
5.3. Kubernetes へのデプロイ時に証明書を追加
Kubernetes にデプロイすると、Red Hat Quay は config アセットを保存するボリュームとしてシークレットにマウントします。残念ながら、これは現在、スーパーユーザーパネルの証明書のアップロード機能に干渉します。
このエラーを回避するには、Red Hat Quay が展開された 後に base64 エンコードされた証明書をシークレットに追加します。以下に、実行する方法を説明します。
まず、証明書の内容を Base64 エンコードします。
$ cat ca.crt -----BEGIN CERTIFICATE----- MIIDljCCAn6gAwIBAgIBATANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5MQUIu TElCQ09SRS5TTzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2 MDExMjA2NTkxMFoXDTM2MDExMjA2NTkxMFowOTEXMBUGA1UECgwOTEFCLkxJQkNP UkUuU08xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZI [...] -----END CERTIFICATE----- $ cat ca.crt | base64 -w 0 [...] c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
kubectl
ツールを使用して、quay-enterprise-config-secret を編集します。$ kubectl --namespace quay-enterprise edit secret/quay-enterprise-config-secret
証明書のエントリーを追加し、エントリーの下に base64 エンコードされた文字列を完全に貼り付けます。
custom-cert.crt: c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
-
最後に、すべての Red Hat Quay Pod をリサイクルします。
kubectl delete
を使用して、すべての Red Hat Quay Pod を削除します。Red Hat Quay Deployment は、新しい証明書データを使用して交換用 Pod を自動的にスケジュールします。
5.4. Operator を使用した OCI および Helm の設定
Quay の設定のカスタマイズは、設定バンドルを含むシークレットで提供できます。以下のコマンドを実行して、quay-config-bundle
という新規シークレットを適切な namespace に作成します。これには、OCI サポートを有効にするために必要なプロパティーが含まれます。
quay-config-bundle.yaml
apiVersion: v1 stringData: config.yaml: | FEATURE_GENERAL_OCI_SUPPORT: true FEATURE_HELM_OCI_SUPPORT: true kind: Secret metadata: name: quay-config-bundle namespace: quay-enterprise type: Opaque
Red Hat Quay 3.6 の時点で、FEATURE_HELM_OCI_SUPPORT
: このオプションは非推奨になり、Red Hat Quay の今後のバージョンで削除される予定です。Red Hat Quay 3.6 では、Helm アーティファクトがデフォルトでサポートされ、FEATURE_GENERAL_OCI_SUPPORT
プロパティーに含まれています。ユーザーは、サポートを有効にするために config.yaml ファイルを更新する必要がなくなりました。
シークレットを適切な namespace に作成します (この例では quay-enterprise
です)。
$ oc create -n quay-enterprise -f quay-config-bundle.yaml
spec.configBundleSecret
フィールドのシークレットを指定します。
quay-registry.yaml
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: quay-config-bundle
指定された設定でレジストリーを作成します。
$ oc create -n quay-enterprise -f quay-registry.yaml
5.5. ボリュームサイズのオーバーライド
Red Hat Quay v3.6.2 以降、管理対象コンポーネントにプロビジョニングされるストレージリソースの必要なサイズを指定できます。Clair および Quay PostgreSQL データベースのデフォルトサイズは 50Gi
です。パフォーマンス上の理由がある場合や、ストレージバックエンドにサイズ変更機能がない場合など、十分な容量を事前に選択できるようになりました。
以下の例では、Clair および Quay PostgreSQL データベースのボリュームサイズは 70Gi
に設定されています。
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: quay-example namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: objectstorage managed: false - kind: route managed: true - kind: tls managed: false - kind: clair managed: true overrides: volumeSize: 70Gi - kind: postgres managed: true overrides: volumeSize: 70Gi
第6章 コンフィグレーション API の利用
コンフィグレーションツールは、設定の構築、検証、バンドル、およびデプロイに使用できる 4 つのエンドポイントを示します。config-tool の API は、https://github.com/quay/config-tool/blob/master/pkg/lib/editor/API.md に記載されています。ここでは、API を使用して現在の設定を取得する方法と、変更した内容を検証する方法について説明します。
6.1. 初期設定値の取得
初めてコンフィグレーションツールを実行するときに、既存のコンフィグレーションがない場合は、デフォルトのコンフィグレーションを取得することができます。コンテナーをコンフィグモードで起動します。
$ sudo podman run --rm -it --name quay_config \ -p 8080:8080 \ registry.redhat.io/quay/quay-rhel8:v3.6.8 config secret
デフォルトを取得するには、コンフィグレーション API の config
エンドポイントを使用します。
$ curl -X GET -u quayconfig:secret http://quay-server:8080/api/v1/config | jq
返される値は、JSON 形式によるデフォルト設定です。
{ "config.yaml": { "AUTHENTICATION_TYPE": "Database", "AVATAR_KIND": "local", "DB_CONNECTION_ARGS": { "autorollback": true, "threadlocals": true }, "DEFAULT_TAG_EXPIRATION": "2w", "EXTERNAL_TLS_TERMINATION": false, "FEATURE_ACTION_LOG_ROTATION": false, "FEATURE_ANONYMOUS_ACCESS": true, "FEATURE_APP_SPECIFIC_TOKENS": true, .... } }
6.2. 現在の設定の取得
すでに Quay レジストリーを設定してデプロイしている場合は、コンテナーを停止してコンフィグレーションモードで再起動し、既存のコンフィグレーションをボリュームとして読み込みます。
$ sudo podman run --rm -it --name quay_config \ -p 8080:8080 \ -v $QUAY/config:/conf/stack:Z \ registry.redhat.io/quay/quay-rhel8:v3.6.8 config secret
現在の設定を取得するには、API の config
エンドポイントを使用します。
$ curl -X GET -u quayconfig:secret http://quay-server:8080/api/v1/config | jq
返される値は、データベースと Redis の設定データを含む、JSON 形式の現在の設定です。
{ "config.yaml": { .... "BROWSER_API_CALLS_XHR_ONLY": false, "BUILDLOGS_REDIS": { "host": "quay-server", "password": "strongpassword", "port": 6379 }, "DATABASE_SECRET_KEY": "4b1c5663-88c6-47ac-b4a8-bb594660f08b", "DB_CONNECTION_ARGS": { "autorollback": true, "threadlocals": true }, "DB_URI": "postgresql://quayuser:quaypass@quay-server:5432/quay", "DEFAULT_TAG_EXPIRATION": "2w", .... } }
6.3. API による設定の検証
設定を検証するには、config/validate
エンドポイントに設定を投稿します。
curl -u quayconfig:secret --header 'Content-Type: application/json' --request POST --data ' { "config.yaml": { .... "BROWSER_API_CALLS_XHR_ONLY": false, "BUILDLOGS_REDIS": { "host": "quay-server", "password": "strongpassword", "port": 6379 }, "DATABASE_SECRET_KEY": "4b1c5663-88c6-47ac-b4a8-bb594660f08b", "DB_CONNECTION_ARGS": { "autorollback": true, "threadlocals": true }, "DB_URI": "postgresql://quayuser:quaypass@quay-server:5432/quay", "DEFAULT_TAG_EXPIRATION": "2w", .... } } http://quay-server:8080/api/v1/config/validate | jq
返される値は、設定で見つかったエラーを含む配列です。設定が有効であれば、空の配列 []
が返されます。
6.4. 必須項目の決定
空の設定構造を config/validate
エンドポイントに投稿することで、必須フィールドを決定することができます。
curl -u quayconfig:secret --header 'Content-Type: application/json' --request POST --data ' { "config.yaml": { } } http://quay-server:8080/api/v1/config/validate | jq
返される値は、どのフィールドが必須であるかを示す配列です。
[ { "FieldGroup": "Database", "Tags": [ "DB_URI" ], "Message": "DB_URI is required." }, { "FieldGroup": "DistributedStorage", "Tags": [ "DISTRIBUTED_STORAGE_CONFIG" ], "Message": "DISTRIBUTED_STORAGE_CONFIG must contain at least one storage location." }, { "FieldGroup": "HostSettings", "Tags": [ "SERVER_HOSTNAME" ], "Message": "SERVER_HOSTNAME is required" }, { "FieldGroup": "HostSettings", "Tags": [ "SERVER_HOSTNAME" ], "Message": "SERVER_HOSTNAME must be of type Hostname" }, { "FieldGroup": "Redis", "Tags": [ "BUILDLOGS_REDIS" ], "Message": "BUILDLOGS_REDIS is required" } ]
第7章 コンフィグレーションツールの使用
7.1. カスタム SSL 証明書 UI
コンフィグツールを使用してカスタム証明書を読み込み、外部データベースなどのリソースへのアクセスを容易にします。アップロードするカスタム証明書を選択し、拡張子 .crt
を使用して PEM 形式のものであることを確認します。
設定ツールには、アップロードされた証明書の一覧が表示されます。カスタムの SSL 証明書をアップロードすると、その証明書が一覧に表示されます。
7.2. 基本設定
7.2.1. お問い合わせ先
7.3. サーバー設定
7.3.1. サーバー設定の選択肢
7.3.2. TLS 設定
7.4. データベースの設定
PostGreSQL と MySQL のいずれかを選択できます。
MySQL および MariaDB データベースは、Red Hat Quay 3.6 で非推奨となりました。これらのデータベースのサポートは、Red Hat Quay の将来のバージョンで削除される予定です。Red Hat Quay の新規インストールを開始する場合は、Postgre SQL を使用することを強くお勧めします。
7.4.1. PostgreSQL の設定
データベースへの接続情報を入力します。
これにより、postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
形式の DB_URI フィールドが生成されます。
接続引数を詳細に制御する必要がある場合は、設定ガイドのデータベース接続引数のセクションを参照してください。
7.5. データの整合性
7.6. タイムマシン設定
7.7. Redis の設定
7.8. リポジトリーのミラーリングの設定
7.9. レジストリーのストレージ設定
- プロキシーストレージ
- ストレージの Geo レプリケーション
- ストレージエンジン
7.9.1. ストレージレプリケーションの有効化
-
スクロールダウンして、
Registry Storage
というセクションに進みます。 -
Enable Storage Replication
をクリックします。 - データを複製するストレージエンジンをそれぞれ追加します。使用するすべてのストレージエンジンをリストに載せる必要があります。
-
すべてのイメージをすべてのストレージエンジンに完全にレプリケートする必要がある場合は、各ストレージエンジンの設定の下で
Replicate to storage engine by default
をクリックします。これにより、すべてのイメージがそのストレージエンジンにレプリケートされます。代わりに名前空間ごとのレプリケーションを有効にするには、サポートにお問い合わせください。 -
完了したら、
Save Configuration Changes
をクリックします。設定変更は、Red Hat Quay が次回再起動したときに有効になります。 ストレージを追加し、Geo レプリケーションの Replicate to storage engine by default を有効にした後、既存のイメージデータをすべてのストレージで同期する必要があります。そのためには、コンテナーに
oc exec
(または docker/kubectl exec) して実行する必要があります。# scl enable python27 bash # python -m util.backfillreplication
この操作は、新しいストレージを追加した後にコンテンツを同期するための 1 回限りの操作です。
7.9.2. ストレージエンジン
7.9.2.1. ローカルストレージ
7.9.2.2. Amazon S3 ストレージ
7.9.2.3. Azure Blob ストレージ
7.9.2.4. Google クラウドストレージ
7.9.2.5. Ceph オブジェクトゲートウェイ (RADOS) ストレージ
7.9.2.6. OpenStack (Swift) ストレージ設定
7.9.2.7. CloudFront + Amazon S3 ストレージ設定
7.10. アクションログの設定
7.10.1. アクションログストレージ設定
7.10.1.1. データベースアクションログストレージ
7.10.1.2. Elasticsearch アクションログストレージ
7.10.2. アクションログのローテーションおよびアーカイブ
7.11. セキュリティースキャナーの設定
7.12. アプリケーションレジストリーの設定
7.13. メール設定
7.14. 内部認証設定
7.14.1. LDAP
7.14.2. Keystone (OpenStack identity)
7.14.3. JWT カスタム認証
7.14.4. 外部アプリケーショントークン
7.15. 外部認証 (OAUTH) の設定
7.15.1. GitHub (Enterprise) 認証
7.15.2. Google 認証
7.16. アクセス設定
7.17. Dockerfile ビルドのサポート
7.17.1. GitHub (Enterprise) ビルドトリガー
7.17.2. Bitbucket ビルドトリガー
7.17.3. GitLab ビルドトリガー