Red Hat Quay の設定

Red Hat Quay 3.6

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

概要

Red Hat Quay の設定

第1章 設定の使用

Red Hat Quay は、スタンドアロン方法でデプロイすることも、Operator を使用して既存の OpenShift クラスターにデプロイできます。使用しているデプロイメントのタイプに応じて、Red Hat Quay 設定の作成、取得、更新、検証に使用する方法は若干異なります。ただし、コアとなる設定オプションは基本的にどのタイプのデプロイメントでも同じで、以下のオプションを操作できます。

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 に戻すことが簡単にできます。

設定を変更する手順には、以下の操作が必要です。

  1. 現在のエンドポイントおよびシークレットの決定
  2. Red Hat Quay が OpenShift にすでにデプロイされている場合、既存の設定バンドルのダウンロード
  3. config.yaml 設定ファイルの作成または更新
  4. Quay に必要な SSL 証明書またはサービスに必要なカスタム SSL 証明書のアセンブル
  5. 設定ファイルおよび証明書を使用した新規設定バンドルシークレットの作成
  6. レジストリーの作成または更新、新規設定バンドルシークレットの参照、およびコンポーネント管理用の過程の指定
  7. デプロイメントを監視して正常に完了し、設定の変更が反映されていることを確認します。

または、設定エディター 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) および設定エディターツールのパスワードが含まれるシークレット

設定エディターツールのユーザー名とパスワードを確認するには、以下を実行します。

  1. シークレットを取得します。 

    $ oc get secret -n quay-enterprise example-registry-quay-config-editor-credentials-kk55dc7299 -o yaml

apiVersion: v1
data:
  password: SkZwQkVKTUN0a1BUZmp4dA==
  username: cXVheWNvbmZpZw==
kind: Secret

  2. ユーザー名をデコードします。 

    $ echo 'cXVheWNvbmZpZw==' | base64 --decode

quayconfig

  3. パスワードをデコードします。 

    $ echo 'SkZwQkVKTUN0a1BUZmp4dA==' | base64 --decode

JFpBEJMCtkPTfjxt

1.4.2. 既存設定のダウンロード

現在の設定にアクセスする方法は複数あります。

  1. 設定エディターのエンドポイントを使用して、設定エディターのユーザー名とパスワードを指定します。 

    $ 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..."
    }
}

  2. 設定バンドルシークレットの使用

    1. シークレットデータを取得します。 

      $ 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"
}

    2. データをデコードします。 

      $ 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 を含める必要があります。

  1. 埋め込みデータまたはファイルを使用してシークレットを作成します。

    1. 設定の詳細を 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

    2. または、必要な情報が含まれるファイルを作成し、それらのファイルからシークレットを作成できます。 

      $ 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

  2. 作成した 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

  3. 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
(必須)

文字列

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

値:
Database、LDAP、JWT、Keystone、OIDC のいずれか。

デフォルト: Database

PREFERRED_URL_SCHEME
(必須)

文字列

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

値:
http、https のいずれか。

デフォルト: http

SERVER_HOSTNAME
(必須)

文字列

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

例:
quay-server.example.com

DATABASE_SECRET_KEY
(必須)

文字列

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

SECRET_KEY
(必須)

文字列

データベース内およびランタイム時に機密性の高いフィールドを暗号化するために使用するキー。設定後に値を変更できません。設定しないと、暗号化されたパスワード認証情報など、すべての信頼できるフィールドが無効になります。

SETUP_COMPLETE
(必須)

ブール値

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

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

スレッドローカル接続を使用するかどうか

常に true を指定すること。

   .threadlocals

Boolean

自動ロールバック接続

。常に true に指定するかどうか。

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 に設定されている場合は、リポジトリーミラーリングが有効になる

デフォルト: False

FEATURE_PROXY_STORAGE

Boolean

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

デフォルト: False

FEATURE_STORAGE_REPLICATION

Boolean

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

のデフォルト: False

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 別)。優先されるエンジンとは、プルのチェックが行われ、イメージがプッシュされることを意味します。

デフォルト: false

MAXIMUM_LAYER_SIZE

文字列

イメージ層の最大許容サイズ

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

例:100G

デフォルト: 20G

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 にアクセスできるホスト名
 
例:
quay-server.example.com

   .port
(必須)

数値

Redis にアクセスできるポート

例:
6379

   .password

文字列

Redis にアクセスできるポート

例:
strongpassword

2.7.2. ユーザーイベント

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

フィールドタイプ説明

USER_EVENTS_REDIS
(必須)

オブジェクト

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

   .host
(必須)

文字列

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

   .port
(必須)

数値

Redis にアクセスできるポート

例:
6379

   .password

文字列

Redis にアクセスできるポート

例:
strongpassword

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

リポジトリーのガベージコレクションが有効であるかどうか

デフォルト: True

 

 

 

TAG_EXPIRATION_OPTIONS
(必須)

文字列の配列

ユーザーが namespace でタグの有効期限について選択できるオプション

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

DEFAULT_TAG_EXPIRATION
(必須)

文字列

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

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

 

 

 

FEATURE_CHANGE_TAG_EXPIRATION

Boolean

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

デフォルト: True

例: 

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 のデプロイ

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

    $ oc create secret generic --from-file config.yaml=./config.yaml init-config-bundle-secret

  2. 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

  3. レジストリーをデプロイします。 

    $ oc create -f quayregistry.yaml
  4. 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

文字列

指定されている場合は、レジストリーの長いタイトル

デフォルト:
Quay Enterprise

REGISTRY_TITLE_SHORT

文字列

指定されている場合は、短縮形のレジストリーのタイトル

デフォルト:
Quay Enterprise

 

 

 

BRANDING

オブジェクト

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

   .logo
(必須)

文字列

主なロゴイメージ URL

例:
/static/img/quay-horizontal-color.svg

   .footer_img

文字列

UI フッターのロゴ

例:
/static/img/RedHat.svg

   .footer_url

文字列

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

例:
https://redhat.com

 

 

 

CONTACT_INFO

文字列の配列

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

   [0]

文字列

メール送信のリンクを追加します

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

   [1]

文字列

IRC チャット部屋にアクセスするときのリンクを追加します。

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

   [2]

文字列

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

   [3]

文字列

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

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

2.11. SSL 設定フィールド

表2.10 SSL 設定

フィールドタイプ説明

PREFERRED_URL_SCHEME

String

http, https

のいずれか。デフォルト: http

SERVER_HOSTNAME
(必須)

文字列

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

例:
quay-server.example.com

SSL_CIPHERS

文字列の配列

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

例:
[CAMELLIA, !3DES]

SSL_PROTOCOLS

文字列の配列

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

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

SESSION_COOKIE_SECURE

ブール値

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

デフォルト:
False

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

2.11.1. SSL の設定

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

    $ cp ~/ssl.cert $QUAY/config
$ cp ~/ssl.key $QUAY/config
$ cd $QUAY/config

  2. config.yaml ファイルを編集し、Quay で TLS を処理できるように指定します。

    config.yaml

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

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

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 に追加

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

    $ cat storage.crt
-----BEGIN CERTIFICATE-----
MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV
[...]
-----END CERTIFICATE-----

  2. certs ディレクトリーを作成し、そこに証明書をコピーします。 

    $ mkdir -p quay/config/extra_ca_certs
$ cp storage.crt quay/config/extra_ca_certs/
$ tree quay/config/
├── config.yaml
├── extra_ca_certs
│   ├── storage.crt

  3. Quay コンテナーの CONTAINER 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

  4. その ID でコンテナーを再起動します。 

    $ sudo podman restart 5a3e82c4a75f

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

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

2.13. LDAP 設定フィールド

表2.11 LDAP の設定

フィールドタイプ説明

AUTHENTICATION_TYPE
(必須)

文字列

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

FEATURE_TEAM_SYNCING

ブール値

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

デフォルト: true

FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP

ブール値

有効にすると、スーパーユーザー以外のユーザーは LDAP を使用してチームの同期を設定できます。

デフォルト値: false

 

 

 

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

文字列

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

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

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

ブール値

リポジトリーミラーリングの有効化または無効化を行います。

デフォルト: false

 

 

 

REPO_MIRROR_INTERVAL

数値

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

REPO_MIRROR_SERVER_HOSTNAME

文字列

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

デフォルト: None

例:
openshift-quay-service

REPO_MIRROR_TLS_VERIFY

ブール値

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

デフォルト: false

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

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

フィールドタイプ説明

FEATURE_SECURITY_SCANNER

ブール値

セキュリティースキャナー

デフォルト: false

FEATURE_SECURITY_NOTIFICATIONS

ブール値

セキュリティースキャナーが有効になっている場合は、セキュリティー通知を有効にするか、オフにします。

デフォルト値: false

SECURITY_SCANNER_V4_REINDEX_THRESHOLD

文字列

このパラメーターは、最終のインデックス作成から状態が変更されたか、以前に失敗したマニフェストのインデックスをもう一度作成するまで待機する最小時間を判断するのに使用します。データは manifestsecuritystatus テーブルの last_indexed datetime から計算されます。インデックス作成実行時に必ず、失敗したマニフェストのインデックスを再度作成しないように、このパラメーターを使用します。再インデックスのデフォルト時間は 300 秒です。

SECURITY_SCANNER_V4_ENDPOINT

文字列

V4 セキュリティースキャナーのエンドポイント

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

例:
http://192.168.99.101:6060

SECURITY_SCANNER_V4_PSK

文字列

Clair 用に生成された共有キー (PSK)

SECURITY_SCANNER_INDEXING_INTERVAL

数値

セキュリティースキャナーのインデックス作成の間隔 (秒単位)

デフォルト: 30

SECURITY_SCANNER_ENDPOINT

文字列

V2 セキュリティースキャナーのエンドポイント

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

例:
http://192.168.99.100:6060

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 アーティファクトのサポートを有効にします。

デフォルト: True

FEATURE_HELM_OCI_SUPPORT

ブール値

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

デフォルト: True

重要

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

ブール値

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

デフォルト: True

 

 

 

LOGS_MODEL

文字列

セキュリティースキャナーを有効または無効にします。

値: database、transition_reads_both_writes_es、elasticsearch のいずれか。
デフォルト: database

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 日以上経過したすべてのログをストレージに移動します。

デフォルト: false

 

 

 

ACTION_LOG_ARCHIVE_LOCATION

文字列

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

例: s3_us_east

ACTION_LOG_ARCHIVE_PATH

文字列

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

例: archives/actionlogs

ACTION_LOG_ROTATION_THRESHOLD

文字列

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

例: 30d

2.18. ビルドログ

表2.17 ビルドログ

フィールドタイプ説明

FEATURE_READER_BUILD_LOGS

ブール値

true に設定されている場合は、書き込みアクセスや管理アクセスがある場合だけでなく、リポジトリーへの読み取りアクセスを持つユーザーがビルドログを読み取ることができます。

デフォルト: False

 

 

 

LOG_ARCHIVE_LOCATION

文字列

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

例: s3_us_east

LOG_ARCHIVE_PATH

文字列

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

例: archives/buildlogs

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

表2.18 Dockerfile ビルドのサポート

フィールドタイプ説明

FEATURE_BUILD_SUPPORT

ブール値

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

デフォルト: False

SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD

数値

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

デフォルト: 100

SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD

数値

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

デフォルト: 5

2.19.1. GitHub ビルドトリガー

表2.19 GitHub ビルドトリガー

フィールドタイプ説明

FEATURE_GITHUB_BUILD

ブール値

GitHub ビルドトリガーをサポートしているかどうか

デフォルト: False

 

 

 

GITHUB_TRIGGER_CONFIG

オブジェクト

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

   .GITHUB_ENDPOINT
(必須)

文字列

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

例:https://github.com/

   .API_ENDPOINT

文字列

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

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

   .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 ビルドトリガーをサポートしているかどうか

デフォルト: False

 

 

 

BITBUCKET_TRIGGER_CONFIG

オブジェクト

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

   .CONSUMER_KEY
(必須)

文字列

この Quay インスタンスの登録されたコンシューマーキー (クライアント ID)

   .CONSUMER_SECRET
(必須)

文字列

この Quay インスタンスの、登録されたコンシューマーシークレット (クライアントシークレット)

2.19.3. GitLab ビルドトリガー

表2.21 GitLab ビルドトリガー

フィールドタイプ説明

FEATURE_GITLAB_BUILD

ブール値

GitLab ビルドトリガーをサポートしているかどうか

デフォルト: False

 

 

 

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 ログインがサポートされるかどうか

**デフォルト: False

GITHUB_LOGIN_CONFIG

オブジェクト

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

   .ALLOWED_ORGANIZATIONS

文字列の配列

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

   .API_ENDPOINT

文字列

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

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

   .CLIENT_ID
(必須)

文字列

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

例: 0e8dbe15c4c7630b6780

   .CLIENT_SECRET
(必須)

文字列

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

例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

   .GITHUB_ENDPOINT
(必須)

文字列

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

例: https://github.com/

   .ORG_RESTRICT

ブール値

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

2.20.2. Google OAuth

表2.24 Google OAuth フィールド

フィールドタイプ説明

FEATURE_GOOGLE_LOGIN

ブール値

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

**デフォルト: False

GOOGLE_LOGIN_CONFIG

オブジェクト

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

   .CLIENT_ID
(必須)

文字列

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

例: 0e8dbe15c4c7630b6780

   .CLIENT_SECRET
(必須)

文字列

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

例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

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

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

デフォルト: False

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

ブール値

メールが有効であるかどうか

デフォルト: False

 

 

 

MAIL_DEFAULT_SENDER

文字列

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

例: support@example.com

MAIL_PASSWORD

文字列

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

MAIL_PORT

数値

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

MAIL_SERVER

文字列

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

例: smtp.example.com

MAIL_USERNAME

文字列

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

MAIL_USE_TLS

ブール値

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

デフォルト: True

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

表2.27 ユーザー設定

フィールドタイプ説明

FEATURE_SUPER_USERS

ブール値

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

デフォルト: true

FEATURE_USER_CREATION

ブール値

ユーザーを作成するかどうか (スーパーユーザー以外)

デフォルト: true

FEATURE_USER_LAST_ACCESSED

ブール値

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

デフォルト: true

FEATURE_USER_LOG_ACCESS

ブール値

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

デフォルト: false

FEATURE_USER_METADATA

ブール値

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

デフォルト: false

FEATURE_USERNAME_CONFIRMATION

ブール値

true に設定すると、生成されたユーザー名を確認できます。

デフォルト: true

FEATURE_USER_RENAME

ブール値

true に設定されている場合、ユーザーは独自の namespace の名前に変更できます。

デフォルト: false

FEATURE_INVITE_ONLY_USER_CREATION

ブール値

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

デフォルト: false

 

 

 

FRESH_LOGIN_TIMEOUT

文字列

新規ログインでユーザーがパスワードの再入力に必要な時間

例:5m

USERFILES_LOCATION

文字列

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

例:s3_us_east

USERFILES_PATH

文字列

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

例:userfiles

USER_RECOVERY_TOKEN_LIFETIME

文字列

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

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

2.25. reCAPTCHA 設定

表2.28 reCAPTCHA フィールド

フィールドタイプ説明

FEATURE_RECAPTCHA

ブール値

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

デフォルト: False

 

 

 

RECAPTCHA_SECRET_KEY

文字列

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

RECAPTCHA_SITE_KEY

文字列

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

2.26. ACI 設定

表2.29 ACI 設定

フィールドタイプ説明

FEATURE_ACI_CONVERSION

ブール値

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

デフォルト: False

 

 

 

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 ユーザーのエンドポイント

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

JWT_GETUSER_ENDPOINT

文字列

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

JWT_QUERY_ENDPOINT

文字列

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

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

JWT_VERIFY_ENDPOINT

文字列

JWT 検証のエンドポイント

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

2.28. アプリケーショントークン

表2.31 アプリケーショントークンの設定

フィールドタイプ説明

FEATURE_APP_SPECIFIC_TOKENS

ブール値

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

デフォルト: True

 

 

 

APP_SPECIFIC_TOKEN_EXPIRATION

文字列

外部アプリケーショントークンの有効期限

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

EXPIRED_APP_SPECIFIC_TOKEN_GC

文字列

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

デフォルト: 1d

2.29. その他のフィールド

表2.32 その他のフィールド

フィールドタイプ説明

ALLOW_PULLS_WITHOUT_STRICT_LOGGING

文字列

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

デフォルト: False

AVATAR_KIND

文字列

表示する avatar のタイプ。インライン (ローカル) または Gravatar (gravatar)

値: local, gravatar

BROWSER_API_CALLS_XHR_ONLY

ブール値

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

デフォルト: True

DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT

数値

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

デフォルト: None

ENABLE_HEALTH_DEBUG_SECRET

文字列

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

EXTERNAL_TLS_TERMINATION

ブール値

TLS がサポートされているが、Quay の前の層で終了する場合は true に設定します。

FRESH_LOGIN_TIMEOUT

文字列

新規ログインでユーザーがパスワードの再入力に必要な時間

例:5m

HEALTH_CHECKER

文字列

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

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

PROMETHEUS_NAMESPACE

文字列

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

デフォルト:quay

PUBLIC_NAMESPACES

文字列の配列

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

REGISTRY_STATE

文字列

レジストリーの状態

値: normal または read-only

SEARCH_MAX_RESULT_PAGE_COUNT

数値

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

デフォルト: 10

SEARCH_RESULTS_PER_PAGE

数値

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

デフォルト: 10

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

ブール値

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

デフォルト: True

CREATE_NAMESPACE_ON_PUSH

ブール値

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

デフォルト: False

NON_RATE_LIMITED_NAMESPACES

文字列の配列

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

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

一部のフィールドは非推奨または廃止されています。

表2.33 レガシーフィールド

フィールドタイプ説明

FEATURE_BLACKLISTED_EMAILS

ブール値

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

BLACKLISTED_EMAIL_DOMAINS

文字列の配列

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

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

BLACKLIST_V2_SPEC

文字列

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

例: <1.8.0
デフォルト: <1.6.0

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 接続

デフォルト: 50

WORKER_CONNECTION_COUNT_REGISTRY

数値

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

デフォルト: WORKER_CONNECTION_COUNT

WORKER_CONNECTION_COUNT_WEB

数値

Web UI の同時 HTTP 接続

デフォルト: WORKER_CONNECTION_COUNT

WORKER_CONNECTION_COUNT_SECSCAN

数値

Clair の同時 HTTP 接続

デフォルト: WORKER_CONNECTION_COUNT

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

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

変数型説明

WORKER_COUNT

数値

プロセス数の汎用上書き

WORKER_COUNT_REGISTRY

数値

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

値: 8 から 64 までの整数

WORKER_COUNT_WEB

数値

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

値: 2 から 32 までの整数

WORKER_COUNT_SECSCAN

数値

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

値: 2 から 4 までの整数

第4章 設定ツールを使用した OpenShift における Quay の再設定

4.1. 設定エディターへのアクセス

QuayRegistry 画面の Details セクションには、設定エディターのエンドポイントと、設定エディターへのログインに使用する認証情報などのシークレットのリンクがあります。

Config editor details

4.1.1. 設定エディターの認証情報の取得

  1. 設定エディターシークレットのリンクをクリックします。

    Config editor secret

  2. Secret details 画面の Data セクションで、Reveal values をクリックし、設定エディターへのログインに使用する認証情報を表示します。

    Config editor secret reveal

4.1.2. 設定エディターへのログイン

設定エディターエンドポイントを参照し、設定ツールにアクセスする時に使用するユーザー名 (通常は quayconfig)、および対応するパスワードを入力します。

Config editor user interface

4.1.3. 設定の変更

設定の更新例では、設定エディターツールを使用してスーパーユーザーを追加しています。

  1. 時間マシン機能に関する有効期限 (4w など) を追加します。

    Add expiration period

  2. Validate Configuration Changes を選択して、変更が有効であることを確認します。

  3. Reconfigure Quay ボタンを押して変更を適用します。

    Reconfigure

  4. 設定ツールは、変更が Quay に送信されていることを通知します。

    Reconfigured

注記

設定ツール UI を使用して Red Hat Quay を再設定すると、更新された設定が適用されている間にレジストリーが短期間利用できなくなる可能性があります。

4.2. UI での再設定の監視

4.2.1. QuayRegistry リソース

Operator の再設定後に、QuayRegistry の特定インスタンスの YAML タブで再デプロイの進捗を追跡できます (この場合は example-registry)。

ui monitor deploy update

ステータスが変わるたびに、データをリロードして更新されたバージョンを表示するように求められます。最終的に、Operator は変更を調整し、正常でないコンポーネントが報告されることはありません。

ui monitor deploy done

4.2.2. イベント

QuayRegistry の Events タブには、再デプロイに関連するイベントが表示されます。

ui monitor deploy streaming events

再設定の影響を受ける namespace のすべてのリソースのストリーミングイベントは、Home → Events の OpenShift コンソールで利用できます。

ui monitor deploy streaming events

4.3. 再設定後に更新された情報へのアクセス

4.3.1. UI で更新された設定ツールの認証情報へのアクセス

新しい Pod が設定ツール用に作成され、新規シークレットが作成されるので、次回ログインの試行時に更新されたパスワードを使用する必要があります。

Config editor secret updated

4.3.2. UI で更新された config.yaml へのアクセス

設定バンドルを使用して、更新された config.yaml ファイルにアクセスします。

  1. QuayRegistry の詳細画面で、Config Bundle Secret をクリックします。
  2. Secret の詳細画面の Data セクションで、Reveal values をクリックし、config.yaml ファイルを表示します。

  3. 変更が適用されていることを確認します。この場合、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 データベースの使用

  1. 必要なデータベースフィールドを使用して設定ファイル config.yaml を作成します。

    config.yaml:

    DB_URI: postgresql://test-quay-database:postgres@test-quay-database:5432/test-quay-database

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

    $ kubectl create secret generic --from-file config.yaml=./config.yaml config-bundle-secret

  3. 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

  4. 以下のセクションで説明されているようにレジストリーをデプロイします。

5.2.2. NooBaa アンマネージドストレージ

  1. Storage → Object Bucket Claims のコンソールで NooBaa Object Bucket Claim を作成します。
  2. アクセスキー、バケット名、エンドポイント (ホスト名)、およびシークレットキーを含む Object Bucket Claim データの詳細を取得します。

  3. 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 エンコードされた証明書をシークレットに追加します。以下に、実行する方法を説明します。

  1. まず、証明書の内容を Base64 エンコードします。 

    $ cat ca.crt
-----BEGIN CERTIFICATE-----
MIIDljCCAn6gAwIBAgIBATANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5MQUIu
TElCQ09SRS5TTzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2
MDExMjA2NTkxMFoXDTM2MDExMjA2NTkxMFowOTEXMBUGA1UECgwOTEFCLkxJQkNP
UkUuU08xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZI
[...]
-----END CERTIFICATE-----

$ cat ca.crt | base64 -w 0
[...]
c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=

  2. kubectl ツールを使用して、quay-enterprise-config-secret を編集します。 

    $ kubectl --namespace quay-enterprise edit secret/quay-enterprise-config-secret

  3. 証明書のエントリーを追加し、エントリーの下に base64 エンコードされた文字列を完全に貼り付けます。 

      custom-cert.crt:
c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
  4. 最後に、すべての 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 形式のものであることを確認します。

Custom SSL certificates

設定ツールには、アップロードされた証明書の一覧が表示されます。カスタムの SSL 証明書をアップロードすると、その証明書が一覧に表示されます。

Custom SSL certificates

7.2. 基本設定

Basic configuration

7.2.1. お問い合わせ先

Basic configuration

7.3. サーバー設定

Server configuration

7.3.1. サーバー設定の選択肢

Server configuration choice

7.3.2. TLS 設定

TLS configuration

7.4. データベースの設定

PostGreSQL と MySQL のいずれかを選択できます。 Database choice

注記

MySQL および MariaDB データベースは、Red Hat Quay 3.6 で非推奨となりました。これらのデータベースのサポートは、Red Hat Quay の将来のバージョンで削除される予定です。Red Hat Quay の新規インストールを開始する場合は、Postgre SQL を使用することを強くお勧めします。

7.4.1. PostgreSQL の設定

データベースへの接続情報を入力します。

PostgreSQL configuration

これにより、postgresql://quayuser:quaypass@quay-server.example.com:5432/quay 形式の DB_URI フィールドが生成されます。

接続引数を詳細に制御する必要がある場合は、設定ガイドのデータベース接続引数のセクションを参照してください。

7.5. データの整合性

Data consistency

7.6. タイムマシン設定

Time machine configuration

7.7. Redis の設定

Redis configuration

7.8. リポジトリーのミラーリングの設定

Repository mirroring configuration

7.9. レジストリーのストレージ設定

  • プロキシーストレージ
  • ストレージの Geo レプリケーション
  • ストレージエンジン

7.9.1. ストレージレプリケーションの有効化

  1. スクロールダウンして、Registry Storage というセクションに進みます。
  2. Enable Storage Replication をクリックします。
  3. データを複製するストレージエンジンをそれぞれ追加します。使用するすべてのストレージエンジンをリストに載せる必要があります。
  4. すべてのイメージをすべてのストレージエンジンに完全にレプリケートする必要がある場合は、各ストレージエンジンの設定の下で Replicate to storage engine by default をクリックします。これにより、すべてのイメージがそのストレージエンジンにレプリケートされます。代わりに名前空間ごとのレプリケーションを有効にするには、サポートにお問い合わせください。
  5. 完了したら、Save Configuration Changes をクリックします。設定変更は、Red Hat Quay が次回再起動したときに有効になります。

  6. ストレージを追加し、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. ローカルストレージ

Local storage configuration

7.9.2.2. Amazon S3 ストレージ

Amazon S3 storage configuration

7.9.2.3. Azure Blob ストレージ

Azure blob storage configuration

7.9.2.4. Google クラウドストレージ

Google cloud storage configuration

7.9.2.5. Ceph オブジェクトゲートウェイ (RADOS) ストレージ

Ceph object gateway (RADOS) storage configuration

7.9.2.6. OpenStack (Swift) ストレージ設定

OpenStack (Swift) storage configuration

7.9.2.7. CloudFront + Amazon S3 ストレージ設定

Cloudfront + Amazon S3 storage configuration

7.10. アクションログの設定

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

7.10.1.1. データベースアクションログストレージ

Database action log storage configuration

7.10.1.2. Elasticsearch アクションログストレージ

Elasticsearch log storage configuration

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

Action log rotation and archiving configuration

Action log rotation and archiving storage choice

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

Security scanner configuration

7.12. アプリケーションレジストリーの設定

Application registry configuration

7.13. メール設定

Email configuration

7.14. 内部認証設定

Internal authentication configuration

Internal authentication choice

7.14.1. LDAP

LDAP authentication

7.14.2. Keystone (OpenStack identity)

Keystone authentication

7.14.3. JWT カスタム認証

JWT custom authentication

7.14.4. 外部アプリケーショントークン

External application token authentication

7.15. 外部認証 (OAUTH) の設定

7.15.1. GitHub (Enterprise) 認証

GitHub (Enterprise) authentication configuration

7.15.2. Google 認証

Google authentication configuration

7.16. アクセス設定

Access settings configuration

7.17. Dockerfile ビルドのサポート

Dockerfile build support

7.17.1. GitHub (Enterprise) ビルドトリガー

GitHub (Enterprise) Build Triggers

7.17.2. Bitbucket ビルドトリガー

BitBucket Build Triggers

7.17.3. GitLab ビルドトリガー

GitLab Build Triggers