Red Hat Quay Operator の OpenShift Container Platform へのデプロイ


Red Hat Quay 3.14

Red Hat Quay Operator の OpenShift Container Platform へのデプロイ

Red Hat OpenShift Documentation Team

概要

Red Hat Quay Operator を OpenShift Container Platform クラスターにデプロイします。

はじめに

Red Hat Quay は、エンタープライズレベルの品質の高いコンテナーレジストリー製品です。Red Hat Quay を使用してコンテナーイメージをビルドし、保存してから、企業全体にデプロイできるようにします。

Red Hat Quay Operator は、OpenShift クラスターで Red Hat Quay をデプロイし、管理する簡単な方法を提供します。

Red Hat Quay 3.4.0 のリリースに伴い、エクスペリエンスの強化と Day 2 運用に対するサポートの追加を目的として、Red Hat Quay Operator が再記述されました。その結果、Red Hat Quay Operator の操作性が向上し、デフォルト部分が増加して使いやすくなりました。Red Hat Quay 3.4.0 と前のバージョンとの主な違いは次のとおりです。

  • QuayEcosystem カスタムリソースが QuayRegistry カスタムリソースに置き換えられました。
  • デフォルトのインストールオプションで、実稼働環境での使用に対応した管理対象の依存関係 (データベース、キャッシュ、オブジェクトストレージなど) が含まれる、完全にサポートされた Red Hat Quay 環境が生成されます。

    注記

    一部のコンポーネントは、高可用性を備えていない可能性があります。

  • Red Hat Quay の設定用の新しい検証ライブラリー。
  • オブジェクトストレージは、ObjectBucketClaim Kubernetes API を使用して Red Hat Quay Operator が管理できるようになりました。

    注記

    Red Hat OpenShift Data Foundation を使用して、この API がサポートされる実装を OpenShift Container Platform 上で提供できます。

  • テストおよび開発シナリオ用にデプロイされた Pod で使用されるコンテナーイメージのカスタマイズ。

第1章 Red Hat Quay Operator の概要

この章の内容を使用して、以下を実行します。

  • Red Hat Quay Operator を使用して Red Hat Quay on OpenShift Container Platform をインストールする
  • 管理対象または管理対象外のオブジェクトストレージを設定する
  • データベース、Redis、ルート、TLS などの管理対象外のコンポーネントを設定する
  • Red Hat Quay Operator を使用して Red Hat Quay レジストリーを OpenShift Container Platform にデプロイする
  • Red Hat Quay でサポートされている高度な機能を使用する
  • Red Hat Quay Operator を使用して Red Hat Quay レジストリーをアップグレードする

1.1. Red Hat Quay on OpenShift Container Platform 設定の概要

OpenShift Container Platform で Operator を使用して Red Hat Quay をデプロイする場合、設定は QuayRegistry カスタムリソース (CR) を通じて宣言的に管理されます。このモデルにより、クラスター管理者は、有効化するコンポーネント、ストレージバックエンド、SSL/TLS 設定、その他のコア機能など、Red Hat Quay デプロイメントの望ましい状態を定義できます。

Operator を使用して Red Hat Quay on OpenShift Container Platform をデプロイした後、管理者は config.yaml ファイルを更新し、Kubernetes シークレットで参照することで、レジストリーをさらにカスタマイズできます。この設定バンドルは、configBundleSecret フィールドを通じて QuayRegistry CR にリンクされます。

Operator は、QuayRegistry CR で定義された状態とそれに関連付けられた設定を調整し、必要に応じてレジストリーコンポーネントを自動的にデプロイまたは更新します。

このガイドでは、QuayRegistry CR の基本的な概念と、Red Hat Quay on OpenShift Container Platform デプロイメントにおける config.yaml ファイルの変更方法について説明します。QuayRegistry CR 内での管理対象外コンポーネントの使用などのより高度なトピックについては、Red Hat Quay Operator on OpenShift Container Platform のデプロイ を参照してください。

1.2. 管理対象コンポーネント

デフォルトでは、Operator は Red Hat Quay の管理対象コンポーネントに必要なすべての設定とインストールを処理します。

Red Hat Quay Operator が実行する独自のデプロイメントが環境に適さない場合は、管理対象外コンポーネントの使用 で説明されているように、Red Hat Quay Operator に unmanaged リソース (またはオーバーライド) を指定できます。

Expand
表1.1 QuayRegistry の必須フィールド
フィールド説明

quay

Boolean

環境変数やレプリカの数など、Red Hat Quay on OpenShift Container Platform のデプロイメントのオーバーライドを保持します。このコンポーネントは、管理対象外 (managed: false) に設定できません。

postgres

Boolean

レジストリーメタデータを保存するために使用されます。現在、PostgreSQL バージョン 13 が使用されています。

clair

Boolean

イメージの脆弱性スキャンを提供します。

redis

Boolean

ストレージライブビルダーログとガベージコレクションに必要なロックメカニズム。

horizontalpodautoscaler

Boolean

メモリーと CPU の消費量に応じて Quay Pod の数を調整します。

objectstorage

Boolean

イメージレイヤーの Blob を保存します。managed: true に設定すると、NooBaa または Red Hat OpenShift Data Foundation によって提供される ObjectBucketClaim Kubernetes API が使用されます。このフィールドを managed: false に設定するには、独自のオブジェクトストレージを提供する必要があります。

route

Boolean

OpenShift Container Platform の外部から Red Hat Quay レジストリーへの外部エントリーポイントを提供します。

mirror

Boolean

オプションのリポジトリーミラーリングをサポートするようにリポジトリーミラーワーカーを設定します。

monitoring

Boolean

Grafana ダッシュボード、個々のメトリクスへのアクセス、quay Pod の頻繁な再起動に関する通知などの機能があります。

tls

Boolean

SSL/TLS が自動的に処理されるかどうかを設定します。

clairpostgres

Boolean

管理された Clair データベースを設定します。これは、Red Hat Quay のデプロイに使用される PostgreSQL データベースとは別のデータベースです。

次の例は、Red Hat Quay Operator によって提供される QuayRegistry カスタムリソースのデフォルト設定を示しています。これは、OpenShift Container Platform Web コンソールで利用できます。

QuayRegistry カスタムリソースの例

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: <example_registry>
  namespace: <namespace>
  spec:
    configBundleSecret: config-bundle-secret
    components:
    - kind: quay
      managed: true
    - kind: postgres
      managed: true
    - kind: clair
      managed: true
    - kind: redis
      managed: true
    - kind: horizontalpodautoscaler
      managed: true
    - kind: objectstorage
      managed: true
    - kind: route
      managed: true
    - kind: mirror
      managed: true
    - kind: monitoring
      managed: true
    - kind: tls
      managed: true
    - kind: clairpostgres
      managed: true
Copy to Clipboard Toggle word wrap

1.3. 依存関係向けのマネージド外コンポーネントの使用

Red Hat Quay で使用する PostgreSQL、Redis、オブジェクトストレージなどの既存のコンポーネントがある場合は、まず Red Hat Quay 設定バンドル (config.yaml) 内でそれらを設定します。次に、どのコンポーネントが管理対象外であるかを示しながら、QuayRegistry バンドル内で (Kubernetes Secret として) 参照する必要があります。

注記

アンマネージド PostgreSQL データベースを使用していて、バージョンが PostgreSQL 10 である場合は、PostgreSQL 13 へのアップグレードが強く推奨されます。PostgreSQL 10 は 2022 年 11 月 10 日に最終リリースとなり、サポートされなくなりました。詳細は、PostgreSQL のバージョン管理ポリシー を参照してください。

管理対象外コンポーネントの設定は、以下のセクションを参照してください。

1.4. configBundleSecret について

spec.configBundleSecret フィールドは、QuayRegistry リソースと同じ namespace 内の Secret の名前へのオプションの参照です。この Secret には、config.yaml キー/値のペアが含まれている必要があります。値は Red Hat Quay 設定ファイルです。

configBundleSecret には config.yaml ファイルが保存されます。Red Hat Quay 管理者は、config.yaml ファイルを通じて次の設定を定義できます。

  • 認証バックエンド (OIDC、LDAP など)
  • 外部 TLS Termination 設定
  • リポジトリー作成ポリシー
  • 機能フラグ
  • 通知設定

Red Hat Quay は、以下の理由でこのシークレットを更新する可能性があります。

  • 新しい認証方法の有効化
  • カスタム SSL/TLS 証明書の追加
  • 機能の有効化
  • セキュリティースキャン設定の変更

このフィールドを省略すると、Red Hat Quay Operator はデフォルト値と管理対象コンポーネントの設定に基づいて、設定シークレットを自動的に生成します。フィールドが指定されている場合、config.yaml の内容が基本設定として使用され、管理対象コンポーネントの値とマージされて最終的な設定が形成され、それが quay アプリケーション Pod にマウントされます。

QuayRegistry CR の設定方法によって、Red Hat Quay on OpenShift Container Platform の configBundleSecret’s `config.yaml ファイルに含める必要があるフィールドが決まります。次の例は、すべてのコンポーネントが Operator によって管理される場合のデフォルトの config.yaml ファイルを示しています。この例は、コンポーネントが管理対象であるか管理対象外であるか (managed: false) によって異なることに注意してください。

Operator によって管理されるすべてのコンポーネントを含む YAML サンプル

ALLOW_PULLS_WITHOUT_STRICT_LOGGING: false
AUTHENTICATION_TYPE: Database
DEFAULT_TAG_EXPIRATION: 2w
ENTERPRISE_LOGO_URL: /static/img/RH_Logo_Quay_Black_UX-horizontal.svg
FEATURE_BUILD_SUPPORT: false
FEATURE_DIRECT_LOGIN: true
FEATURE_MAILING: false
REGISTRY_TITLE: Red Hat Quay
REGISTRY_TITLE_SHORT: Red Hat Quay
SETUP_COMPLETE: true
TAG_EXPIRATION_OPTIONS:
- 2w
TEAM_RESYNC_STALE_TIME: 60m
TESTING: false
Copy to Clipboard Toggle word wrap

場合によっては、オブジェクトストレージなど、特定のコンポーネントを自身で管理することを選択できます。このシナリオでは、QuayRegistry CR を次のように変更します。

管理対象外 objectstorage コンポーネント

# ...
    - kind: objectstorage
      managed: false
# ...
Copy to Clipboard Toggle word wrap

独自のコンポーネントを管理している場合は、そのコンポーネントに必要な情報またはリソースが含まれるようにデプロイメントを設定する必要があります。たとえば、objectstorage コンポーネントが managed: false に設定されている場合、config.yaml ファイル内に、ストレージプロバイダーに応じた関連情報を含めます。次の例は、Google Cloud Storage を使用した分散ストレージ設定を示しています。

objectstorage が管理対象外の場合に必要な情報

# ...
DISTRIBUTED_STORAGE_CONFIG:
    default:
        - GoogleCloudStorage
        - access_key: <access_key>
          bucket_name: <bucket_name>
          secret_key: <secret_key>
          storage_path: /datastorage/registry
# ...
Copy to Clipboard Toggle word wrap

同様に、horizontalpodautoscaler コンポーネントを管理している場合は、付随する HorizontalPodAutoscaler カスタムリソース を作成する必要があります。

1.5. Red Hat Quay on OpenShift Container Platform の前提条件

Red Hat Quay Operator を使用して OpenShift Container Platform に Red Hat Quay をデプロイする前に、次の前提条件を考慮してください。

1.5.1. OpenShift Container Platform クラスター

Red Hat Quay Operator をデプロイするには、OpenShift Container Platform 4.5 以降のクラスターと管理アカウントへのアクセス権が必要です。管理アカウントには、クラスタースコープで namespaces を作成する権限が必要です。

1.5.2. リソース要件

各 Red Hat Quay アプリケーション Pod には、以下のリソース要件があります。

  • 8 Gi のメモリー
  • 2000 ミリコアの CPU

Red Hat Quay Operator は、管理する Red Hat Quay デプロイメントごとに少なくとも 1 つのアプリケーション Pod を作成します。OpenShift Container Platform クラスターに、これらの要件に必要なコンピュートリソースがあることを確認してください。

1.5.3. オブジェクトストレージ

デフォルトで、Red Hat Quay Operator は ObjectBucketClaim Kubernetes API を使用してオブジェクトストレージをプロビジョニングします。この API を使用すると、Red Hat Quay Operator がベンダー固有の実装から切り離されます。この API は、Red Hat OpenShift Data Foundation の NooBaa コンポーネントを介して提供されます。NooBaa はこのドキュメント全体で例として使用されています。

Red Hat Quay は、次のような複数のストレージクラウドプロバイダーを使用するように手動で設定できます。

  • Amazon S3 (Red Hat Quay 用の S3 バケットポリシーの設定は S3 IAM Bucket Policy を参照)
  • Microsoft Azure Blob Storage
  • Google Cloud Storage
  • Ceph Object Gateway(RADOS)
  • OpenStack Swift
  • CloudFront + S3

オブジェクトストレージプロバイダーの完全なリストは、Quay Enterprise 3.x サポートマトリックス を参照してください。

1.5.4. StorageClass

Red Hat Quay Operator を使用して Quay および Clair PostgreSQL データベースをデプロイする場合、デフォルトの StorageClass がクラスター内に設定されます。

Red Hat Quay Operator によって使用されるデフォルトの StorageClass は、Quay および Clair データベースに必要な永続ボリューム要求をプロビジョニングします。これらの PVC はデータを永続的に保存するために使用され、Red Hat Quay レジストリーと Clair 脆弱性スキャナーが利用可能な状態を維持し、再起動や障害が発生してもその状態が維持されるようにします。

インストールを続行する前に、Quay および Clair コンポーネント用のストレージのシームレスなプロビジョニングを確保するために、クラスター内にデフォルトの StorageClass が設定されていることを確認してください。

第2章 OperatorHub からの Red Hat Quay Operator のインストール

以下の手順を使用して、OpenShift Container Platform OperatorHub から Red Hat Quay Operator をインストールします。

手順

  1. OpenShift Container Platform コンソールを使用して、OperatorsOperatorHub を選択します。
  2. 検索ボックスに Red Hat Quay と入力し、Red Hat が提供する公式の Red Hat Quay Operator を選択します。機能、前提条件、デプロイメント情報が記載されている Installation ページに移動します。
  3. Install を選択します。Operator Installation ページが表示されます。
  4. インストールのカスタマイズには、以下の選択肢を使用できます。

    1. Update Channel: 更新チャネルを選択します。たとえば、最新リリースの場合は stable-3.14 を選択します。
    2. インストールモード:

      1. Red Hat Quay Operator をクラスター全体で使用できるようにする場合は、All namespaces on the cluster を選択します。Red Hat Quay Operator をクラスター全体にインストールすることが推奨されます。単一 namespace を選択する場合、モニタリングコンポーネントはデフォルトで利用できなくなります。
      2. これを単一の namespace 内にのみデプロイする必要がある場合は、A specific namespace on the cluster を選択します。

        • Approval Strategy: 自動更新または手動更新のいずれかを承認します。自動更新ストラテジーが推奨されます。
  5. Install を選択します。

第3章 デプロイメント前に行う Red Hat Quay の設定

Red Hat Quay Operator は、OpenShift Container Platform にデプロイされると、すべての Red Hat Quay コンポーネントを管理できます。これはデフォルト設定ですが、セットアップをさらに制御する場合は、1 つ以上のコンポーネントを外部から管理できます。

次のパターンを使用して、管理対象外 Red Hat Quay コンポーネントを設定します。

手順

  1. 適切な設定で config.yaml 設定ファイルを作成します。最小限の設定は、以下を参照してください。

    $ touch config.yaml
    Copy to Clipboard Toggle word wrap
    AUTHENTICATION_TYPE: Database
    BUILDLOGS_REDIS:
        host: <quay-server.example.com>
        password: <strongpassword>
        port: 6379
        ssl: false
    DATABASE_SECRET_KEY: <0ce4f796-c295-415b-bf9d-b315114704b8>
    DB_URI: <postgresql://quayuser:quaypass@quay-server.example.com:5432/quay>
    DEFAULT_TAG_EXPIRATION: 2w
    DISTRIBUTED_STORAGE_CONFIG:
        default:
            - LocalStorage
            - storage_path: /datastorage/registry
    DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
    DISTRIBUTED_STORAGE_PREFERENCE:
        - default
    PREFERRED_URL_SCHEME: http
    SECRET_KEY: <e8f9fe68-1f84-48a8-a05f-02d72e6eccba>
    SERVER_HOSTNAME: <quay-server.example.com>
    SETUP_COMPLETE: true
    TAG_EXPIRATION_OPTIONS:
        - 0s
        - 1d
        - 1w
        - 2w
        - 4w
        - 3y
    USER_EVENTS_REDIS:
        host: <quay-server.example.com>
        port: 6379
        ssl: false
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、設定ファイルを使用して Secret を作成します。

    $ oc create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
    Copy to Clipboard Toggle word wrap
  3. quayregistry.yaml ファイルを作成し、管理対象外コンポーネントを特定し、作成された Secret を参照します。以下はその例です。

    QuayRegistry YAML ファイルの例

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: example-registry
      namespace: quay-enterprise
    spec:
      configBundleSecret: <config_bundle_secret>
      components:
        - kind: objectstorage
          managed: false
    # ...
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力し、quayregistry.yaml ファイルを使用してレジストリーをデプロイします。

    $ oc create -n quay-enterprise -f quayregistry.yaml
    Copy to Clipboard Toggle word wrap

3.1. 自動化用の事前設定オプション

Red Hat Quay は、レジストリー管理者が初期セットアップタスクと API アクセシビリティーを自動化できるようにする設定オプションを提供します。これらのオプションは、新しいデプロイメントや API 呼び出しの実行方法を制御するのに役立ちます。次のオプションは、自動化と管理制御をサポートします。

Expand
表3.1 自動化設定フィールド
フィールド説明

FEATURE_USER_INITIALIZE

Boolean

新しくデプロイされた Red Hat Quay レジストリーでの初期ユーザーブートストラップを有効にします。デプロイメント前に config.yaml ファイルでこのフィールドを True に設定すると、管理者は api/v1/user/initialize エンドポイントを呼び出して最初のユーザーを作成できます。

注記

既存の組織内の OAuth アプリケーションによって生成された OAuth 2 アクセストークン を必要とする他のすべてのレジストリー API 呼び出しとは異なり、api/v1/user/initialize エンドポイントでは認証は必要ありません。

BROWSER_API_CALLS_XHR_ONLY

Boolean

レジストリー API がブラウザーからの呼び出しのみを受け入れるかどうかを制御します。API への一般的なブラウザーベースのアクセスを許可するには、管理者はこのフィールドを False に設定する必要があります。True に設定すると、API 呼び出しがブロックされ、管理者とユーザーの両方が API を操作できなくなります。

SUPER_USERS

文字列

レジストリーへの完全な権限と無制限のアクセス権を持つ管理ユーザーまたはスーパーユーザーのリストを定義します。Red Hat Quay 管理者は、再デプロイを必要とせずに即時の管理アクセスを確保するために、デプロイメント前に config.yamlSUPER_USERS を設定する必要があります。デプロイメント後にこのフィールドを設定する場合、有効にするにはレジストリーを再起動する必要があります。

FEATURE_USER_CREATION

Boolean

このフィールドが False に設定されている場合、新規ユーザーの作成をスーパーユーザーにのみ許可します。この設定は、管理者がユーザーアクセスを手動でプロビジョニングする必要がある制御された環境で役立ちます。

次の YAML は、自動化のための推奨設定を示しています。

自動化の推奨設定

# ...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
# ...
Copy to Clipboard Toggle word wrap

3.2. オブジェクトストレージの設定

ストレージを管理するのが Red Hat Quay Operator かユーザーかにかかわらず、Red Hat Quay をインストールする前にオブジェクトストレージを設定する必要があります。

Red Hat Quay Operator にストレージの管理を任せたい場合は、マネージドストレージ セクションで、NooBaa および Red Hat OpenShift Data Foundation Operator のインストールと設定の詳細を参照してください。

別のストレージソリューションを使用している場合は、Operator の設定時に objectstorageunmanaged として設定します。以下のセクションを参照してください。既存のストレージの設定の詳細は、管理対象外ストレージ を参照してください。

3.2.1. 管理対象外ストレージの使用

このセクションでは、参考として管理対象外ストレージの設定例を示しています。オブジェクトストレージの設定方法の詳細は、Red Hat Quay 設定ガイドを参照してください。

3.2.1.1. AWS S3 ストレージ

Red Hat Quay デプロイメント用に 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
      s3_region: <region>
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - s3Storage
Copy to Clipboard Toggle word wrap
3.2.1.2. AWS Cloudfront ストレージ

Red Hat Quay デプロイメント用に AWS Cloudfront を設定する場合は、次の例を使用します。

注記
  • AWS Cloudfront ストレージを設定する場合、Red Hat Quay を適切に使用するには次の条件を満たす必要があります。

    • config.yaml ファイルで定義されている Red Hat Quay のストレージパスと一致するように Origin パス を設定する必要があります。この要件を満たさない場合、イメージを取得するときに 403 エラーが発生します。詳細は、Origin path を参照してください。
    • Bucket policyCross-origin resource sharing (CORS) ポリシーを設定する必要があります。

Cloudfront S3 の YAML サンプル

DISTRIBUTED_STORAGE_CONFIG:
    default:
      - CloudFrontedS3Storage
      - cloudfront_distribution_domain: <CLOUDFRONT_DISTRIBUTION_DOMAIN>
        cloudfront_key_id: <CLOUDFRONT_KEY_ID>
        cloudfront_privatekey_filename: <CLOUDFRONT_PRIVATE_KEY_FILENAME>
        host: <S3_HOST>
        s3_access_key: <S3_ACCESS_KEY>
        s3_bucket: <S3_BUCKET_NAME>
        s3_secret_key: <S3_SECRET_KEY>
        storage_path: <STORAGE_PATH>
        s3_region: <S3_REGION>
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
  - default
DISTRIBUTED_STORAGE_PREFERENCE:
  - default
Copy to Clipboard Toggle word wrap

バケットポリシーの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>/*"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>"
        }
    ]
}
Copy to Clipboard Toggle word wrap

3.2.1.3. Google Cloud storage

Red Hat Quay デプロイメント用に Google Cloud ストレージを設定する場合は、次の例を使用します。

DISTRIBUTED_STORAGE_CONFIG:
    googleCloudStorage:
        - GoogleCloudStorage
        - access_key: GOOGQIMFB3ABCDEFGHIJKLMN
          bucket_name: quay-bucket
          secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
          storage_path: /datastorage/registry
          boto_timeout: 120 
1

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - googleCloudStorage
Copy to Clipboard Toggle word wrap
1
オプション: 接続から読み取ろうとしたときにタイムアウト例外が出力されるまでの時間 (秒単位)。デフォルトは 60 秒です。また、接続を試行するときにタイムアウト例外が出力されるまでの時間 (秒単位) も含まれます。デフォルトは 60 秒です。
3.2.1.4. Microsoft Azure ストレージ

Red Hat Quay デプロイメント用に Microsoft Azure ストレージを設定する場合は、次の例を使用します。

DISTRIBUTED_STORAGE_CONFIG:
  azureStorage:
    - AzureStorage
    - azure_account_name: azure_account_name_here
      azure_container: azure_container_here
      storage_path: /datastorage/registry
      azure_account_key: azure_account_key_here
      sas_token: some/path/
      endpoint_url: https://[account-name].blob.core.usgovcloudapi.net 
1

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - azureStorage
Copy to Clipboard Toggle word wrap
1
Microsoft Azure ストレージの endpoint_url パラメーターは任意であり、Microsoft Azure Government (MAG) エンドポイントで使用できます。空白のままにすると、endpoint_url は通常の Microsoft リージョンに接続します。

Red Hat Quay 3.7 以降では、MAG Blob サービスのプライマリーエンドポイントを使用する必要があります。MAG Blob サービスのセカンダリーエンドポイントを使用すると、AuthenticationErrorDetail:Cannot find the claimed account when trying to GetProperties for the account whusc8-secondary エラーが発生します。

3.2.1.5. Ceph/RadosGW ストレージ

Red Hat Quay デプロイメント用に Ceph/RadosGW ストレージを設定する場合は、次の例を使用します。

DISTRIBUTED_STORAGE_CONFIG:
  radosGWStorage: #storage config name
    - RadosGWStorage #actual driver
    - access_key: access_key_here #parameters
      secret_key: secret_key_here
      bucket_name: bucket_name_here
      hostname: hostname_here
      is_secure: 'true'
      port: '443'
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE: #must contain name of the storage config
    - radosGWStorage
Copy to Clipboard Toggle word wrap
3.2.1.6. Swift ストレージ:

Red Hat Quay デプロイメント用に 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: 3
      os_options:
        tenant_id: <osp_tenant_id_here>
        user_domain_name: <osp_domain_name_here>
      ca_cert_path: /conf/stack/swift.cert"
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - swiftStorage
Copy to Clipboard Toggle word wrap
3.2.1.7. NooBaa 管理対象外ストレージ

次の手順を使用して、NooBaa を管理対象外のストレージ設定としてデプロイします。

手順

  1. Red Hat Quay コンソールで、StorageObject 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
    Copy to Clipboard Toggle word wrap

Object Bucket Claim の設定の詳細は、オブジェクトバケットクレーム を参照してください。

3.2.2. 管理対象外 NooBaa インスタンスの使用

以下の手順を使用して、Red Hat Quay デプロイメントに管理対象外 NooBaa インスタンスを使用します。

手順

  1. Storage → Object Bucket Claims のコンソールで NooBaa Object Bucket Claim を作成します。
  2. Access KeyBucket NameEndpoint (hostname)、および Secret Key を含む 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
    Copy to Clipboard Toggle word wrap

3.2.3. マネージドストレージ

Red Hat Quay Operator に Red Hat Quay のオブジェクトストレージを管理させる場合、クラスターは ObjectBucketClaim API を通じてオブジェクトストレージを提供できる必要があります。Red Hat OpenShift Data Foundation Operator を使用する場合は、サポートされている 2 つのオプションを使用できます。

  • ローカルの Kubernetes PersistentVolume ストレージでサポートされる Multi-Cloud Object Gateway のスタンドアロンインスタンス

    • 高可用性がない
    • Red Hat Quay サブスクリプションに含まれている
    • Red Hat OpenShift Data Foundation の別のサブスクリプションは不要
  • スケールアウト Object Service と Ceph を備えた Red Hat OpenShift Data Foundation の実稼働環境用デプロイメント

    • 高可用性がある
    • Red Hat OpenShift Data Foundation の別のサブスクリプションが必要

スタンドアロンのインスタンスオプションを使用するには、以下の読み取りを続行します。Red Hat OpenShift Data Foundation の実稼働環境用デプロイメントの詳細は、公式ドキュメント を参照してください。

注記

オブジェクトストレージのディスク容量は、50 GiB が Red Hat Quay Operator によって自動的に割り当てられます。この数は、ほとんどの小規模/中規模の Red Hat Quay インストールで利用可能なストレージの量を表しますが、実際のユースケースには十分ではない可能性があります。現在、Red Hat OpenShift Data Foundation ボリュームのサイズ変更は、Red Hat Quay Operator によって処理されません。詳細は、マネージドストレージのサイズ変更に関するセクションを参照してください。

Red Hat Quay サブスクリプションの一環として、Red Hat OpenShift Data Foundation Operator (旧称 OpenShift Container Storage Operator) の Multicloud Object Gateway コンポーネントを使用できます。このゲートウェイコンポーネントを使用すると、Kubernetes PersistentVolume ベースのブロックストレージがサポートする Red Hat Quay への S3 互換のオブジェクトストレージインターフェイスを指定できます。この使用は、Operator で管理される Red Hat Quay デプロイメントや、以下に示す Multicloud Object Gateway インスタンスの正確な仕様に限定されます。

Red Hat Quay はローカルファイルシステムのストレージをサポートしないため、ユーザーは代わりに Kubernetes PersistentVolume ストレージと組み合わせてゲートウェイを利用し、サポートされるデプロイメントを提供できます。PersistentVolume はオブジェクトストレージのバッキングストアとしてゲートウェイインスタンスに直接マウントされ、ブロックベースの StorageClass がサポートされます。

PersistentVolume の性質上、これはスケールアウトできる高可用性ソリューションではなく、Red Hat OpenShift Data Foundation などのスケールアウトストレージシステムを置き換えることはできません。ゲートウェイの単一インスタンスのみが実行されています。再スケジュール、更新、または予定外のダウンタイムが原因でゲートウェイを実行している Pod が利用できなくなると、接続された Red Hat Quay インスタンスのパフォーマンスが一時的に低下します。

Red Hat OpenShift Data Foundation を使用して OpenShift Container Platform に Red Hat Quay をデプロイするには、OpenShift Container Platform UI を使用してローカルストレージ Operator、Red Hat OpenShift Data Foundation Operator、および Multicloud Object Gateway をダウンロードする必要があります。以下の手順は、以下の Red Hat OpenShift Data Foundation ドキュメントを参照してください。

第4章 トラフィック受信の設定

4.1. SSL/TLS とルートの設定

OpenShift Container Platform の エッジターミネーション ルートのサポートが、新しい管理対象コンポーネントの tls によって追加されました。これにより、route コンポーネントが SSL/TLS から分離され、ユーザーは両方を個別に設定できるようになります。

EXTERNAL_TLS_TERMINATION: true は事前に設定された設定です。

注記
  • tls が管理対象の場合、デフォルトのクラスターワイルドカード証明書が使用されます。
  • tls が管理対象外の場合、ユーザーが指定したキーと証明書のペアがルートに挿入されます。

ssl.certssl.key が別の永続的なシークレットに移動し、キーと証明書のペアが調整のたびに再生成されなくなりました。キーと証明書のペアは edge ルートとしてフォーマットされ、Quay コンテナー内の同じディレクトリーにマウントされます。

SSL/TLS とルートを設定する場合は複数の置換が可能ですが、次のルールが適用されます。

  • SSL/TLS が managed になっている場合は、ルートも managed にする必要があります。
  • SSL/TLS が unmanaged の場合は、設定バンドルで証明書を直接指定する必要があります。

次の表に、有効なオプションを示します。

Expand
表4.1 TLS およびルートの有効な設定オプション
オプションRouteTLS証明書が提供されるか結果

独自のロードバランサーが TLS を処理する

管理対象

管理対象

いいえ

デフォルトのワイルドカード証明書を使用したエッジルート

Red Hat Quay が TLS を処理する

管理対象

管理対象外

はい

Pod 内にマウントされる証明書を含むパススルールート

Red Hat Quay が TLS を処理する

管理対象外

管理対象外

はい

証明書は quay Pod 内に設定されますが、ルートは手動で作成する必要があります。

4.1.1. SSL/TLS 証明書とキーのペアを使用した設定バンドルシークレットの作成

次の手順を使用して、独自の SSL/TLS 証明書とキーペアを含む設定バンドルシークレットを作成します。

手順

  • 次のコマンドを入力して、独自の SSL/TLS 証明書とキーペアを含む設定バンドルシークレットを作成します。

    $ oc create secret generic --from-file config.yaml=./config.yaml --from-file ssl.cert=./ssl.cert --from-file ssl.key=./ssl.key config-bundle-secret
    Copy to Clipboard Toggle word wrap

第5章 OpenShift Container Platform 上の管理対象コンポーネントのリソースの設定

以下のコンポーネントに実行中の Pod がある場合は、Red Hat Quay on OpenShift Container Platform でリソースを手動調整できます。

  • quay
  • clair
  • mirroring
  • clairpostgres
  • postgres

この機能により、ユーザーはより小規模なテストクラスターを実行したり、Quay Pod の機能が部分的に低下するのを避けるために事前にさらに多くのリソースを要求したりできるようになります。Kubernetes リソース単位 に応じて制限やリクエストを設定できます。

次のコンポーネントは、最小要件よりも低く設定しないでください。これにより、デプロイメントに問題が発生し、場合によっては Pod のデプロイメントが失敗する可能性があります。

  • quay: 最低 6 GB、2vCPU
  • clair: 2 GB のメモリー、2 つの vCPU を推奨
  • clairpostgres: 最低 200MB

リソース要求は、OpenShift Container Platform UI で設定することも、QuayRegistry YAML を直接更新して設定することもできます。

重要

これらのコンポーネントに設定されているデフォルト値は推奨値です。リソース要求の設定が高すぎるか低すぎると、それぞれリソースの使用効率やパフォーマンスが低する可能性があります。

5.1. OpenShift Container Platform UI を使用したリソース要求の設定

OpenShift Container Platform UI を使用してリソースを設定するには、次の手順に従います。

手順

  1. OpenShift Container Platform 開発者コンソールで、OperatorInstalled OperatorsRed Hat Quay をクリックします。
  2. QuayRegistry をクリックします。
  3. レジストリーの名前 (例: example-registry) をクリックします。
  4. YAML をクリックします。
  5. spec.components フィールドでは、.overrides.resources.limits および overrides.resources.requests フィールドに値を設定することで、quayclairmirroring clairpostgres、および postgres リソースのリソースをオーバーライドできます。以下に例を示します。

    spec:
      components:
        - kind: clair
          managed: true
          overrides:
            resources:
              limits:
                cpu: "5"     # Limiting to 5 CPU (equivalent to 5000m or 5000 millicpu)
                memory: "18Gi"  # Limiting to 18 Gibibytes of memory
              requests:
                cpu: "4"     # Requesting 4 CPU
                memory: "4Gi"   # Requesting 4 Gibibytes of memory
        - kind: postgres
          managed: true
          overrides:
            resources:
              limits: {} 
    1
    
              requests:
                cpu: "700m"   # Requesting 700 millicpu or 0.7 CPU
                memory: "4Gi"   # Requesting 4 Gibibytes of memory
        - kind: mirror
          managed: true
          overrides:
            resources:
              limits: 
    2
    
              requests:
                cpu: "800m"   # Requesting 800 millicpu or 0.8 CPU
                memory: "1Gi"   # Requesting 1 Gibibyte of memory
        - kind: quay
          managed: true
          overrides:
            resources:
              limits:
                cpu: "4"    # Limiting to 4 CPU
                memory: "10Gi"   # Limiting to 10 Gibibytes of memory
              requests:
                cpu: "4"   # Requesting 4 CPU
                memory: "10Gi"   # Requesting 10 Gibi of memory
        - kind: clairpostgres
          managed: true
          overrides:
            resources:
              limits:
                cpu: "800m"   # Limiting to 800 millicpu or 0.8 CPU
                memory: "3Gi"   # Limiting to 3 Gibibytes of memory
              requests: {}
    Copy to Clipboard Toggle word wrap
    1
    limits または requests フィールドを {} に設定すると、これらのリソースのデフォルト値が使用されます。
    2
    limits または requests フィールドを空のままにしておくと、これらのリソースに制限は設定されません。

5.2. QuayRegistry YAML の編集によるリソースリクエストの設定

レジストリーをデプロイした後で、Red Hat Quay を再設定してリソース要求を設定できます。これは、QuayRegistry YAML ファイルを直接編集し、レジストリーを再デプロイすることで実行できます。

手順

  1. オプション: QuayRegistry YAML ファイルのローカルコピーがない場合は、次のコマンドを入力して取得します。

    $ oc get quayregistry <registry_name> -n <namespace> -o yaml > quayregistry.yaml
    Copy to Clipboard Toggle word wrap
  2. この手順のステップ 1 で作成した quayregistry.yaml を開き、必要な変更を加えます。以下に例を示します。

        - kind: quay
          managed: true
          overrides:
            resources:
              limits: {}
              requests:
                cpu: "0.7"   # Requesting 0.7 CPU (equivalent to 500m or 500 millicpu)
                memory: "512Mi"   # Requesting 512 Mebibytes of memory
    Copy to Clipboard Toggle word wrap
  3. 変更を保存します。
  4. 次のコマンドを実行して、更新された設定を使用して Red Hat Quay レジストリーを適用します。

    $ oc replace -f quayregistry.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    quayregistry.quay.redhat.com/example-registry replaced
    Copy to Clipboard Toggle word wrap

第6章 データベースの設定

6.1. 既存の PostgreSQL データベースの使用

外部で管理されている PostgreSQL データベースを使用している場合、デプロイメントを成功させるには、pg_trgm 拡張機能を手動で有効にする必要があります。

重要

Red Hat Quay と Clair の両方のデプロイメントに、外部で管理される同じ PostgreSQL データベースを使用しないでください。また、Red Hat Quay や Clair などの接続集約型のワークロードがリソースを競合すると、PostgreSQL 側の自然な接続制限を使い果たしてしまう可能性があるため、PostgreSQL データベースを他のワークロードと共有しないでください。さらに、pgBouncer は Red Hat Quay または Clair ではサポートされていないため、この問題を解決するオプションではありません。

既存の PostgreSQL データベースをデプロイするには、次の手順を使用します。

手順

  1. 必要なデータベースフィールドを含む config.yaml ファイルを作成します。以下に例を示します。

    config.yaml ファイルの例:

    DB_URI: postgresql://test-quay-database:postgres@test-quay-database:5432/test-quay-database
    Copy to Clipboard Toggle word wrap

  2. 設定ファイルを使用して Secret を作成します。

    $ kubectl create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
    Copy to Clipboard Toggle word wrap
  3. postgres コンポーネントを unmanaged とマークし、作成した Secret を参照する 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
    Copy to Clipboard Toggle word wrap

次のステップ

  • 次のセクションに進み、レジストリーをデプロイします。

6.1.1. データベース設定フィールド

このセクションでは、Red Hat Quay デプロイメントで利用可能なデータベース設定フィールドを説明します。

6.1.1.1. データベース URI

Red Hat Quay では、必要な DB_URI フィールドを使用してデータベースへの接続を設定します。

以下の表は DB_URI 設定フィールドを説明します。

Expand
表6.1 データベース URI
フィールド説明

DB_URI
(必須)

文字列

認証情報を含む、データベースにアクセスするための URI。

DB_URI フィールドの例:

postgresql://quayuser:quaypass@quay-server.example.com:5432/quay

データベース URI の例

# ...
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
# ...
Copy to Clipboard Toggle word wrap

6.1.1.2. データベース接続引数

オプションの接続引数は、DB_CONNECTION_ARGS パラメーターで設定されます。DB_CONNECTION_ARGS で定義されたキーと値のペアの一部は汎用的なものも、データベース固有のものもあります。

Expand
表6.2 データベース接続引数
フィールド説明

DB_CONNECTION_ARGS

Object

タイムアウトや SSL/TLS などのデータベースの任意の接続引数。

.autorollback

Boolean

スレッドローカル接続を使用するかどうか。
常に True である必要があります。

.threadlocals

Boolean

自動ロールバック接続を使用するかどうか。
常に True である必要があります。

データベース接続引数の例

# ...
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
DB_CONNECTION_ARGS:
  autorollback: true
  threadlocals: true
# ...
Copy to Clipboard Toggle word wrap

6.1.1.2.1. SSL/TLS 接続引数

SSL/TLS では、設定はデプロイするデータベースによって異なります。

sslmode オプションは、セキュアな SSL/TLS TCP/IP 接続がサーバーにネゴシエートされるかどうか、その優先度を決定します。モードは 6 つあります。

Expand
表6.3 sslmode オプション
Mode説明

sslmode

セキュアな SSL/TLS または TCP/IP 接続をサーバーとネゴシエートするかどうか、またはネゴシエートする場合はどのような優先順位でネゴシエートするかを決定します。

   *: disable

この設定では、非 SSL/TLS 接続のみが試行されます。

   *: allow

設定では、まず非 SSL/TLS 接続が試行されます。失敗すると、SSL/TLS 接続が試行されます。

   *: prefer
    (Default)

設定では、まず SSL/TLS 接続が試行されます。失敗すると、非 SSL/TLS 接続が試行されます。

   *: require

設定では SSL/TLS 接続のみが試行されます。ルート CA ファイルが存在する場合は、verify-ca が指定されているのと同じ方法で証明書が検証されます。

   *: verify-ca

設定では SSL/TLS 接続のみが試行され、サーバー証明書が信頼された認証局 (CA) によって発行されたかどうかが検証されます。

   *: verify-full

SSL/TLS 接続のみを試行し、サーバー証明書が信頼できる CA によって発行されていること、および要求されたサーバーのホスト名が証明書内のホスト名と一致することが確認されます。

PostgreSQL の有効な引数の詳細は、Database Connection Control Functions を参照してください。

PostgreSQL SSL/TLS 設定

# ...
DB_CONNECTION_ARGS:
  sslmode: <value>
  sslrootcert: path/to/.postgresql/root.crt
# ...
Copy to Clipboard Toggle word wrap

6.1.2. マネージド PostgreSQL データベースの使用

Red Hat Quay 3.9 では、データベースが Red Hat Quay Operator によって管理されている場合、Red Hat Quay 3.8 から 3.9 に更新すると自動的に PostgreSQL 10 から PostgreSQL 13 にアップグレードされます。

重要
  • マネージドデータベースを使用しているユーザーは、PostgreSQL データベースを 10 から 13 にアップグレードする必要があります。
  • Red Hat Quay および Clair データベースが Operator によって管理されている場合、3.9.0 のアップグレードを成功させるには、各コンポーネントのデータベースのアップグレードが成功する必要があります。いずれかのデータベースのアップグレードが失敗すると、Red Hat Quay のバージョン全体のアップグレードが失敗します。この動作は想定されています。

Red Hat Quay Operator により PostgreSQL デプロイメントが PostgreSQL 10 から 13 にアップグレードされることを望まない場合は、quayregistry.yaml ファイルで PostgreSQL パラメーターを manage: false に設定する必要があります。データベースを管理対象外に設定する方法の詳細は、既存 Postgres データベースの使用 を参照してください。

重要
  • PostgreSQL 13 にアップグレードすることが強く推奨されます。PostgreSQL 10 は 2022 年 11 月 10 日に最終リリースとなり、サポートされなくなりました。詳細は、PostgreSQL のバージョン管理ポリシー を参照してください。

PostgreSQL データベースと Red Hat Enterprise Linux (RHEL) システムのバージョンを一致させるには、RHEL 8 の場合は PostgreSQL の RHEL 8 バージョンへの移行、RHEL 9 の場合は PostgreSQL の RHEL 9 バージョンへの移行 を参照してください。

Red Hat Quay 3.8 → 3.9 の手順の詳細は、Red Hat Quay Operator のアップグレードの概要 を参照してください。

6.1.2.1. PostgreSQL データベースの推奨事項

Red Hat Quay チームは、PostgreSQL データベースを管理するために以下を推奨します。

  • PostgreSQL イメージで提供されるツールまたは独自のバックアップインフラストラクチャーのいずれかを使用して、データベースのバックアップを定期的に実行する必要があります。Red Hat Quay Operator は現在、PostgreSQL データベースがバックアップされていることを保証していません。
  • バックアップからの PostgreSQL データベースの復元は、PostgreSQL のツールと手順を使用して行う必要があります。データベースを復元している間は、Quay Pods を実行できないことに注意してください。
  • データベースのディスク容量は、Red Hat Quay Operator によって 50 GiB が自動的に割り当てられます。この数は、ほとんどの小規模/中規模の Red Hat Quay インストールで利用可能なストレージの量を表しますが、実際のユースケースには十分ではない可能性があります。現在、データベースボリュームのサイズ変更は Red Hat Quay Operator で処理されません。

6.2. 外部 Redis の設定

このセクションの内容に沿って、外部 Redis デプロイメントをセットアップします。

6.2.1. 管理対象外 Redis データベースの使用

外部 Redis データベースをセットアップするには、次の手順を実行します。

手順

  1. 次の Redis フィールドを使用して config.yaml ファイルを作成します。

    # ...
    BUILDLOGS_REDIS:
        host: <quay-server.example.com>
        port: 6379
        ssl: false
    # ...
    USER_EVENTS_REDIS:
        host: <quay-server.example.com>
        port: 6379
        ssl: false
    # ...
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、設定ファイルを使用してシークレットを作成します。

    $ oc create secret generic --from-file config.yaml=./config.yaml config-bundle-secret
    Copy to Clipboard Toggle word wrap
  3. Redis コンポーネントを unmanaged に設定し、作成されたシークレットを参照する quayregistry.yaml ファイルを作成します。

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: example-registry
      namespace: quay-enterprise
    spec:
      configBundleSecret: config-bundle-secret
      components:
        - kind: redis
          managed: false
    # ...
    Copy to Clipboard Toggle word wrap
  4. Red Hat Quay レジストリーをデプロイします。

6.2.2. 管理対象外 Horizontal Pod Autoscaler の使用

Horizontal Pod Autoscaler (HPA) は ClairQuay、および Mirror Pod に含まれるようになり、負荷の急増時に自動的にスケーリングされるようになりました。

HPA はデフォルトで管理対象となるように設定されているため、ClairQuay、および Mirror の Pod 数は 2 に設定されています。これにより、Red Hat Quay Operator による Quay の更新または再設定時、またはイベントの再スケジューリング中のダウンタイムを容易に回避できます。

注記

HorizontalPodAutoscaler コンポーネントを無効にして、HPA リソース自体を編集し、minReplicas フィールドの値を増やそうとすると、既知の問題が発生します。このセットアップを試行すると、Quay アプリケーション Pod は管理されていない HPA によりスケールアウトされ、60 秒後にレプリカ数が Red Hat Quay Operator により調整されます。その結果、HPA Pod は Operator によって継続的に作成され、削除されます。

この問題を解決するには、Red Hat Quay デプロイメントを少なくともバージョン 3.12.5 または 3.13.1 にアップグレードし、次の例を使用して問題を回避する必要があります。

この問題は、Red Hat Quay の将来のバージョンで修正される予定です。詳細は、PROJQUAY-6474 を参照してください。

6.2.2.1. Horizontal Pod Autoscaler の無効化

自動スケーリングを無効にするか、独自の HorizontalPodAutoscaler コンポーネントを作成するには、QuayRegistry カスタムリソース定義でコンポーネントを unmanaged として指定します。上記の既知の問題を回避するには、QuayRegistry CRD オブジェクトを変更し、quayclair、および mirror コンポーネントのレプリカを null に設定する必要があります。

手順

  • QuayRegistry CRD を編集して、quay コンポーネントの場合は、次の replicas: null を含めます。

    $ oc edit quayregistry <quay_registry_name> -n <quay_namespace>
    Copy to Clipboard Toggle word wrap
    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
    name: quay-registry
    namespace: quay-enterprise
    spec:
    components:
      - kind: horizontalpodautoscaler
        managed: false
      - kind: quay
        managed: true
        overrides:
          replicas: null 
    1
    
      - kind: clair
        managed: true
        overrides:
          replicas: null
      - kind: mirror
        managed: true
        overrides:
          replicas: null
    # ...
    Copy to Clipboard Toggle word wrap
    1
    QuayRegistry CRD で replicas: null を設定すると、Quay アプリケーションのデプロイメントマニフェストが replicas: 1 に変更されるため、新しいレプリカセットが生成される場合があります。

検証

  1. カスタマイズされた HorizontalPodAutoscalers CRD を作成し、minReplicas の量をより高い値 (たとえば 3) に増やします。

    kind: HorizontalPodAutoscaler
    apiVersion: autoscaling/v2
    metadata:
      name: quay-registry-quay-app
      namespace: quay-enterprise
    spec:
      scaleTargetRef:
        kind: Deployment
        name: quay-registry-quay-app
        apiVersion: apps/v1
      minReplicas: 3
      maxReplicas: 20
      metrics:
        - type: Resource
          resource:
            name: memory
            target:
              type: Utilization
              averageUtilization: 90
        - type: Resource
          resource:
            name: cpu
            target:
              type: Utilization
              averageUtilization: 90
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、QuayRegistry アプリケーションが正常に起動したことを確認します。

    $ oc get pod | grep quay-app
    Copy to Clipboard Toggle word wrap

    出力例

    quay-registry-quay-app-5b8fd49d6b-7wvbk         1/1     Running     0          34m
    quay-registry-quay-app-5b8fd49d6b-jslq9         1/1     Running     0          3m42s
    quay-registry-quay-app-5b8fd49d6b-pskpz         1/1     Running     0          43m
    quay-registry-quay-app-upgrade-llctl            0/1     Completed   0          51m
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを入力して、HorizontalPodAutoscalers が正常に起動していることを確認します。

    $ oc get hpa
    Copy to Clipboard Toggle word wrap
    NAME                     REFERENCE                           TARGETS            MINPODS   MAXPODS   REPLICAS   AGE
    quay-registry-quay-app   Deployment/quay-registry-quay-app   67%/90%, 54%/90%   3         20        3          51m
    Copy to Clipboard Toggle word wrap

6.2.3. Route コンポーネントの無効化

Red Hat Quay Operator がルートを作成できないようにするには、次の手順を使用します。

手順

  1. コンポーネントを quayregistry.yaml ファイルで managed: false と設定します。

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: example-registry
      namespace: quay-enterprise
    spec:
      components:
        - kind: route
          managed: false
    Copy to Clipboard Toggle word wrap
  2. config.yaml ファイルを編集して、Red Hat Quay が SSL/TLS を処理するように指定します。以下に例を示します。

    # ...
    EXTERNAL_TLS_TERMINATION: false
    # ...
    SERVER_HOSTNAME: example-registry-quay-quay-enterprise.apps.user1.example.com
    # ...
    PREFERRED_URL_SCHEME: https
    # ...
    Copy to Clipboard Toggle word wrap

    管理対象外ルートを正しく設定しないと、次のエラーが返されます。

    {
      {
        "kind":"QuayRegistry",
        "namespace":"quay-enterprise",
        "name":"example-registry",
        "uid":"d5879ba5-cc92-406c-ba62-8b19cf56d4aa",
        "apiVersion":"quay.redhat.com/v1",
        "resourceVersion":"2418527"
      },
      "reason":"ConfigInvalid",
      "message":"required component `route` marked as unmanaged, but `configBundleSecret` is missing necessary fields"
    }
    Copy to Clipboard Toggle word wrap
注記

デフォルトルートを無効にするということは、Red Hat Quay インスタンスにアクセスするために RouteService、または Ingress を作成する必要があることを意味します。さらに、使用する DNS は Red Hat Quay 設定の SERVER_HOSTNAME と一致する必要があります。

6.2.4. モニタリングコンポーネントの無効化

Red Hat Quay Operator を単一の namaspace にインストールすると、モニタリングコンポーネントは自動的に managed: false に設定されます。監視を明示的に無効にするには、次の参照を使用してください。

管理外のモニタリング

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: monitoring
      managed: false
Copy to Clipboard Toggle word wrap

注記

Red Hat Quay Operator が単一の namespace にインストールされている場合、モニタリングは有効にできません。

6.2.5. ミラーリングコンポーネントの無効化

ミラーリングを無効にするには、次の YAML 設定を使用します。

管理対象外ミラーリングの YAML 設定の例

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: mirroring
      managed: false
Copy to Clipboard Toggle word wrap

第7章 Operator を使用した Red Hat Quay のデプロイ

Red Hat Quay は、コマンドラインインターフェイスを使用して、または OpenShift Container Platform コンソールから OpenShift Container Platform にデプロイできます。手順は基本的に同じです。

7.1. コマンドラインからの Red Hat Quay のデプロイ

コマンドラインインターフェイス (CLI) を使用して Red Hat Quay をデプロイするには、次の手順を実行します。

前提条件

  • CLI を使用して OpenShift Container Platform にログインしている。

手順

  1. 次のコマンドを入力して、namespace (例: quay-enterprise) を作成します。

    $ oc new-project quay-enterprise
    Copy to Clipboard Toggle word wrap
  2. オプション: Red Hat Quay デプロイメントで何かを事前に設定する場合は、設定バンドルの Secret を作成します。

    $ oc create secret generic quay-enterprise-config-bundle --from-file=config-bundle.tar.gz=/path/to/config-bundle.tar.gz
    Copy to Clipboard Toggle word wrap
  3. quayregistry.yaml という名前のファイルに QuayRegistry カスタムリソースを作成します。

    1. 最小限のデプロイメントでは、すべてのデフォルトを使用します。

      quayregistry.yaml:

      apiVersion: quay.redhat.com/v1
      kind: QuayRegistry
      metadata:
        name: example-registry
        namespace: quay-enterprise
      Copy to Clipboard Toggle word wrap

    2. オプション: 一部のコンポーネントを管理対象外にする必要がある場合、この情報を spec フィールドに追加します。最小デプロイメントは次の例のようになります。

      管理対象外コンポーネントを含む quayregistry.yaml の例

      apiVersion: quay.redhat.com/v1
      kind: QuayRegistry
      metadata:
        name: example-registry
        namespace: quay-enterprise
      spec:
        components:
          - kind: clair
            managed: false
          - kind: horizontalpodautoscaler
            managed: false
          - kind: mirror
            managed: false
          - kind: monitoring
            managed: false
      Copy to Clipboard Toggle word wrap

    3. オプション: 設定バンドル (例: init-config-bundle-secret) を作成している場合は、これを quayregistry.yaml ファイルで参照します。

      設定バンドルを含む quayregistry.yaml の例

      apiVersion: quay.redhat.com/v1
      kind: QuayRegistry
      metadata:
        name: example-registry
        namespace: quay-enterprise
      spec:
        configBundleSecret: init-config-bundle-secret
      Copy to Clipboard Toggle word wrap

    4. オプション: プロキシーを設定している場合は、Red Hat Quay、Clair、およびミラーリングのオーバーライドを使用して情報を追加できます。

      プロキシーが設定された quayregistry.yaml の例

        kind: QuayRegistry
        metadata:
          name: quay37
        spec:
          configBundleSecret: config-bundle-secret
          components:
            - kind: objectstorage
              managed: false
            - kind: route
              managed: true
            - kind: mirror
              managed: true
              overrides:
                env:
                  - name: DEBUGLOG
                    value: "true"
                  - name: HTTP_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
                  - name: HTTPS_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
                  - name: NO_PROXY
                    value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com
            - kind: tls
              managed: false
            - kind: clair
              managed: true
              overrides:
                env:
                  - name: HTTP_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
                  - name: HTTPS_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
                  - name: NO_PROXY
                    value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com
            - kind: quay
              managed: true
              overrides:
                env:
                  - name: DEBUGLOG
                    value: "true"
                  - name: NO_PROXY
                    value: svc.cluster.local,localhost,quay370.apps.quayperf370.perfscale.devcluster.openshift.com
                  - name: HTTP_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
                  - name: HTTPS_PROXY
                    value: quayproxy.qe.devcluster.openshift.com:3128
      Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力して、指定の namespace に QuayRegistry を作成します。

    $ oc create -n quay-enterprise -f quayregistry.yaml
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを入力して、status.registryEndpoint がいつ設定されるかを確認します。

    $ oc get quayregistry -n quay-enterprise example-registry -o jsonpath="{.status.registryEndpoint}" -w
    Copy to Clipboard Toggle word wrap

関連情報

7.1.1. API を使用した最初のユーザーの作成

以下の手順に従って、Red Hat Quay 組織で最初のユーザーを作成します。

前提条件

  • 設定オプション FEATURE_USER_INITIALIZETrue に設定する。
  • データベースにユーザーが存在していない。
手順

この手順では、"access_token": true を指定して OAuth トークンを要求します。

  1. Red Hat Quay 設定ファイルを開き、以下の設定フィールドを更新します。

    FEATURE_USER_INITIALIZE: true
    SUPER_USERS:
         -  quayadmin
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、Red Hat Quay サービスを停止します。

    $ sudo podman stop quay
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、Red Hat Quay サービスを開始します。

    $ sudo podman run -d -p 80:8080 -p 443:8443 --name=quay -v $QUAY/config:/conf/stack:Z  -v $QUAY/storage:/datastorage:Z {productrepo}/{quayimage}:{productminv}
    Copy to Clipboard Toggle word wrap
  4. 次の CURL コマンドを実行して、ユーザー名、パスワード、電子メール、およびアクセストークンを使用して新しいユーザーを生成します。

    $ curl -X POST -k  http://quay-server.example.com/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"quaypass12345", "email": "quayadmin@example.com", "access_token": true}'
    Copy to Clipboard Toggle word wrap

    成功すると、このコマンドはユーザー名、メール、および暗号化されたパスワードが含まれるオブジェクトを返します。以下に例を示します。

    {"access_token":"6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED", "email":"quayadmin@example.com","encrypted_password":"1nZMLH57RIE5UGdL/yYpDOHLqiNCgimb6W9kfF8MjZ1xrfDpRyRs9NUnUuNuAitW","username":"quayadmin"} # gitleaks:allow
    Copy to Clipboard Toggle word wrap

    データベースにユーザーが存在している場合は、エラーが返されます。

    {"message":"Cannot initialize user in a non-empty database"}
    Copy to Clipboard Toggle word wrap

    パスワードが 8 文字以上でない場合や、空白が含まれている場合には、エラーが返されます。

    {"message":"Failed to initialize user: Invalid password, password must be at least 8 characters and contain no whitespace."}
    Copy to Clipboard Toggle word wrap
  5. 以下のコマンドを入力して、Red Hat Quay デプロイメントにログインします。

    $ sudo podman login -u quayadmin -p quaypass12345 http://quay-server.example.com --tls-verify=false
    Copy to Clipboard Toggle word wrap

    出力例

    Login Succeeded!
    Copy to Clipboard Toggle word wrap

7.1.2. コマンドラインで作成されたコンポーネントの表示

デプロイされた Red Hat Quay コンポーネントを表示するには、次の手順を使用します。

前提条件

  • Red Hat Quay を OpenShift Container Platform にデプロイしている。

手順

  1. 次のコマンドを入力して、デプロイされたコンポーネントを表示します。

    $ oc get pods -n quay-enterprise
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                   READY   STATUS      RESTARTS   AGE
    example-registry-clair-app-5ffc9f77d6-jwr9s            1/1     Running     0          3m42s
    example-registry-clair-app-5ffc9f77d6-wgp7d            1/1     Running     0          3m41s
    example-registry-clair-postgres-54956d6d9c-rgs8l       1/1     Running     0          3m5s
    example-registry-quay-app-79c6b86c7b-8qnr2             1/1     Running     4          3m42s
    example-registry-quay-app-79c6b86c7b-xk85f             1/1     Running     4          3m41s
    example-registry-quay-app-upgrade-5kl5r                0/1     Completed   4          3m50s
    example-registry-quay-database-b466fc4d7-tfrnx         1/1     Running     2          3m42s
    example-registry-quay-mirror-6d9bd78756-6lj6p          1/1     Running     0          2m58s
    example-registry-quay-mirror-6d9bd78756-bv6gq          1/1     Running     0          2m58s
    example-registry-quay-postgres-init-dzbmx              0/1     Completed   0          3m43s
    example-registry-quay-redis-8bd67b647-skgqx            1/1     Running     0          3m42s
    Copy to Clipboard Toggle word wrap

7.1.3. Horizontal Pod 自動スケーリング

デフォルトのデプロイメントでは、以下の実行中の Pod が表示されます。

  • Red Hat Quay アプリケーション自体で使用する 2 つの Pod (example-registry-quay-app-*`)
  • Red Hat Quay ロギングに使用する 1 つの Redis Pod (example-registry-quay-redis-*)
  • Red Hat Quay がメタデータストレージに使用する PostgreSQL の 1 つのデータベース Pod (example-registry-quay-database-*)
  • 2 つの Quay ミラーリング Pod (example-registry-quay-mirror-*)
  • Clair アプリケーションの 2 つの Pod (example-registry-clair-app-*)
  • Clair 用の 1 つの PostgreSQL Pod (example-registry-clair-postgres-*)

Horizontal PPod 自動スケーリングはデフォルトで managed に設定され、Quay、Clair、およびリポジトリーミラーリングの Pod 数は 2 に設定されます。これにより、Red Hat Quay Operator による Red Hat Quay の更新または再設定時、またはイベントの再スケジューリング中のダウンタイムを容易に回避できます。以下のコマンドを入力して、HPA オブジェクトに関する情報を表示できます。

$ oc get hpa -n quay-enterprise
Copy to Clipboard Toggle word wrap

出力例

NAME                           REFERENCE                                 TARGETS           MINPODS   MAXPODS   REPLICAS   AGE
example-registry-clair-app     Deployment/example-registry-clair-app     16%/90%, 0%/90%   2         10        2          13d
example-registry-quay-app      Deployment/example-registry-quay-app      31%/90%, 1%/90%   2         20        2          13d
example-registry-quay-mirror   Deployment/example-registry-quay-mirror   27%/90%, 0%/90%   2         20        2          13d
Copy to Clipboard Toggle word wrap

第8章 インフラストラクチャーノードへの Red Hat Quay のデプロイ

デフォルトで、quay関連のすべての Pod は OpenShift Container Platform クラスター内の利用可能なワーカーノードでスケジュールされます。一部の環境では、レジストリー、データベース、および Pod の監視など、インフラストラクチャーワークロード専用の特定のノード専用に割り当てて、パフォーマンスを改善し、重要なコンポーネントの分離やメンテナンスの簡素化が必要になる場合があります。

OpenShift Container Platform は、インフラストラクチャーマシンセットを使用したこのアプローチをサポートします。

OpenShift Container Platform 管理者は、ワーカーノードのラベル付けおよびテイントを使用して同じ結果を得ることができます。これにより、quay Pod などのインフラストラクチャーワークロードのみがこれらのノードでスケジュールされます。インフラストラクチャーノードを設定したら、ノードセレクターおよび容認を使用して quay Pod を実行する場所を制御できます。

以下の手順は、Red Hat Quay Operator を単一の namespace にインストールし、独自のバックエンドストレージを提供する新規のデプロイメントを対象としています。この手順では、ノードを準備し、専用のインフラストラクチャーノードに Red Hat Quay をデプロイする方法を説明します。この手順では、quay関連のすべての Pod が専用のインフラストラクチャーノードに配置されます。

8.1. インフラストラクチャー用ノードへのラベルとテインとの追加

次の手順を実行して、インフラストラクチャー用のノードにラベルとテインとを追加します。

注記

以下の手順では、3 つのワーカーノードに infra ラベルを付けます。環境に関連するリソースによっては、3 つ以上のワーカーノードに infra ラベルを付ける必要がある場合があります。

  1. 次のコマンドを入力して、デプロイメント内の ワーカー ノードのリストを取得します。

    $ oc get nodes | grep worker
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                              STATUS   ROLES                  AGE    VERSION
    ---
    example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal   Ready    worker                 401d   v1.31.11
    example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal   Ready    worker                 402d   v1.31.11
    example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal   Ready    worker                 401d   v1.31.11
    ---
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、node-role.kubernetes.io/infra= ラベルをワーカーノードに追加します。必要なインフラストラクチャーノードの数は、環境によって異なります。実稼働環境では、すべての quay関連のコンポーネントに対して高可用性と十分なリソースを確保するために、十分な infra ノードをプロビジョニングする必要があります。CPU、メモリー、およびストレージ使用率を監視して、追加のインフラノードが必要であるかどうかを判別します。

    $ oc label node --overwrite <infra_node_one> <infra_node_two> <infra_node_three> node-role.kubernetes.io/infra=
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、node-role.kubernetes.io/infra= ラベルが適切なノードに追加されていることを確認します。

    $ oc get node | grep infra
    Copy to Clipboard Toggle word wrap
    ---
    example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal   Ready    infra,worker           405d   v1.32.8
    example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal   Ready    infra,worker           406d   v1.32.8
    example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal   Ready    infra,worker           405d   v1.32.8
    ---
    Copy to Clipboard Toggle word wrap
  4. ワーカーノードに infra ロールが割り当てられている場合、ユーザーのワークロードが誤ってインフラノードに割り当てられる可能性があります。これを回避するには、infra ノードにテイントを適用し、制御する Pod に容認を追加します。次のコマンドを入力して、ワーカーノードに infra ラベルを付けます。

    $ oc adm taint nodes -l node-role.kubernetes.io/infra \
      node-role.kubernetes.io/infra=reserved:NoSchedule --overwrite
    Copy to Clipboard Toggle word wrap

    出力例

    node/example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal modified
    node/example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal modified
    node/example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal modified
    Copy to Clipboard Toggle word wrap

8.2. ノードセレクターと容認を使用したプロジェクト作成

以下の手順を使用して、node-selector および tolerations アノテーションでプロジェクトを作成します。

手順

  1. 次のコマンドを入力して、node-selector アノテーションを namespace に追加します。

    $ oc annotate namespace <namespace> openshift.io/node-selector='node-role.kubernetes.io/infra='
    Copy to Clipboard Toggle word wrap

    出力例

    namespace/<namespace> annotated
    Copy to Clipboard Toggle word wrap

  2. 以下のコマンドを入力して tolerations アノテーションを namespace に追加します。

    $ oc annotate namespace <namespace> scheduler.alpha.kubernetes.io/defaultTolerations='[{"operator":"Equal","value":"reserved","effect":"NoSchedule","key":"node-role.kubernetes.io/infra"},{"operator":"Equal","value":"reserved","effect":"NoExecute","key":"node-role.kubernetes.io/infra"}]' --overwrite
    Copy to Clipboard Toggle word wrap

    出力例

    namespace/<namespace> annotated
    Copy to Clipboard Toggle word wrap

    重要

    この例の容認は、一般的にインフラノードに適用される 2 つのテイントに固有のものです。お使いの環境で設定したテイントは異なる場合があります。それに応じて容認を設定して、インフラノードに適用されたテイントと一致させる必要があります。

8.3. アノテーションが付けられた名前空間への Red Hat Quay Operator のインストール

node-role.kubernetes.io/infra= ラベルをワーカーノードに追加し、node-selector および tolerations アノテーションを namespace に追加した後、その namespace に Red Hat Quay Operator をダウンロードする必要があります。

次の手順は、アノテーションが付けられた namespace に Red Hat Quay Operator をダウンロードし、インストールを正常に実行するためにサブスクリプションを更新する方法を示しています。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
  2. 検索ボックスに、Red Hat Quay と入力します。
  3. Red Hat QuayInstall をクリックします。
  4. 更新チャネルを選択します(例: stable-3.14 および version)。
  5. インストールモード のクラスターで特定の namespace をクリックし、node-selector および tolerations アノテーションを適用した namespace を選択します。
  6. Install をクリックします。
  1. 次のコマンドを入力して、Operator がインストールされていることを確認します。

    $ oc get pods -n <annotated_namespace> -o wide | grep quay-operator
    Copy to Clipboard Toggle word wrap

    出力例

    quay-operator.v3.15.1-858b5c5fdc-lf5kj   1/1     Running   0          29m   10.130.6.18   example-cluster-new-c5qqp-worker-f-mhngl.c.quay-devel.internal   <none>           <none>
    Copy to Clipboard Toggle word wrap

8.4. Red Hat Quay レジストリーの作成

Red Hat Quay Operator をダウンロードしたら、Red Hat Quay レジストリーを作成する必要があります。レジストリーのコンポーネント( clairpostgresredis など)には、infra ワーカーノードにスケジュールできるように、Toleration アノテーションを適用する必要があります。

以下の手順は、インフラストラクチャーノードで実行される Red Hat Quay レジストリーを作成する方法を示しています。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled OperatorsRed Hat Quay をクリックします。
  2. Red Hat Quay Operator の詳細 ページで、Quay RegistryCreate QuayRegistry をクリックします。
  3. Create QuayRegistry ページで、monitoring および objectstorage フィールドを false に設定します。Red Hat Quay が単一の namespace にインストールされている場合、モニタリングコンポーネントを有効にすることはできません。以下に例を示します。

    # ...
        - kind: monitoring
          managed: false
        - kind: objectstorage
          managed: false
    # ...
    Copy to Clipboard Toggle word wrap
  4. Create をクリックします。
  1. オプション:Pod がインフラノードで実行されていることを確認します。

    1. 次のコマンドを入力して、すべての Quay関連の Pod とスケジュールされているノードを一覧表示します。

      $ oc get pods -n <annotated_namespace> -o wide | grep example-registry
      Copy to Clipboard Toggle word wrap

      出力例

      ...
      NAME                                               READY   STATUS      RESTARTS   AGE   IP             NODE                                                              NOMINATED NODE   READINESS GATES
      example-registry-clair-app-5f95d685bd-dgjf6        1/1     Running     0          52m   10.128.4.12    example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal   <none>           <none>
      ...
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、一覧表示されたノードに infra というラベルが付けられたノードのみが含まれていることを確認します。

      $ oc get nodes -l node-role.kubernetes.io/infra -o name
      Copy to Clipboard Toggle word wrap

      出力例

      node/example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal modified
      node/example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal modified
      node/example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal modified
      Copy to Clipboard Toggle word wrap

      注記

      いずれかの Pod がインフラ以外のノードに表示される場合は、namespace のアノテーションとデプロイメントのパッチを適用します。

  2. 次のコマンドを入力して、Red Hat Quay レジストリーのすべての Pod を再起動します。

    $ oc delete pod -n <annotated_namespace> --all
    Copy to Clipboard Toggle word wrap
  3. 以下のコマンドを実行して Pod のステータスを確認します。

    $ oc get pods -n <annotated_namespace>
    Copy to Clipboard Toggle word wrap

    出力例

    ...
    NAME                                               READY   STATUS      RESTARTS   AGE
    example-registry-clair-app-5f95d685bd-dgjf6        1/1     Running     0          5m4s
    ...
    Copy to Clipboard Toggle word wrap

第9章 デプロイメントプロセスの監視およびデバッグ

ユーザーは、デプロイメントフェーズ中に問題のトラブルシューティングを行えるようになりました。QuayRegistry オブジェクトのステータスは、デプロイメント時にコンポーネントの正常性をモニターするのに役立ちます。これにより、発生する可能性のある問題のデバッグに役立ちます。

手順

  1. 次のコマンドを入力して、デプロイメントのステータスを確認します。

    $ oc get quayregistry -n quay-enterprise -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    デプロイメント直後に、QuayRegistry オブジェクトに基本設定が表示されます。

    apiVersion: v1
    items:
    - apiVersion: quay.redhat.com/v1
      kind: QuayRegistry
      metadata:
        creationTimestamp: "2021-09-14T10:51:22Z"
        generation: 3
        name: example-registry
        namespace: quay-enterprise
        resourceVersion: "50147"
        selfLink: /apis/quay.redhat.com/v1/namespaces/quay-enterprise/quayregistries/example-registry
        uid: e3fc82ba-e716-4646-bb0f-63c26d05e00e
      spec:
        components:
        - kind: postgres
          managed: true
        - kind: clair
          managed: true
        - kind: redis
          managed: true
        - kind: horizontalpodautoscaler
          managed: true
        - kind: objectstorage
          managed: true
        - kind: route
          managed: true
        - kind: mirror
          managed: true
        - kind: monitoring
          managed: true
        - kind: tls
          managed: true
        - kind: clairpostgres
          managed: true
        configBundleSecret: example-registry-config-bundle-kt55s
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
    Copy to Clipboard Toggle word wrap
  2. oc get pods コマンドを使用して、デプロイされたコンポーネントの現在の状態を表示します。

    $ oc get pods -n quay-enterprise
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                   READY   STATUS              RESTARTS   AGE
    example-registry-clair-app-86554c6b49-ds7bl            0/1     ContainerCreating   0          2s
    example-registry-clair-app-86554c6b49-hxp5s            0/1     Running             1          17s
    example-registry-clair-postgres-68d8857899-lbc5n       0/1     ContainerCreating   0          17s
    example-registry-quay-app-upgrade-h2v7h                0/1     ContainerCreating   0          9s
    example-registry-quay-database-66f495c9bc-wqsjf        0/1     ContainerCreating   0          17s
    example-registry-quay-mirror-854c88457b-d845g          0/1     Init:0/1            0          2s
    example-registry-quay-mirror-854c88457b-fghxv          0/1     Init:0/1            0          17s
    example-registry-quay-postgres-init-bktdt              0/1     Terminating         0          17s
    example-registry-quay-redis-f9b9d44bf-4htpz            0/1     ContainerCreating   0          17s
    Copy to Clipboard Toggle word wrap

  3. デプロイメントが進行中、QuayRegistry オブジェクトに現在のステータスが表示されます。この場合、データベースの移行が行われ、その他のコンポーネントは完了するまで待機します。

      status:
        conditions:
        - lastTransitionTime: "2021-09-14T10:52:04Z"
          lastUpdateTime: "2021-09-14T10:52:04Z"
          message: all objects created/updated successfully
          reason: ComponentsCreationSuccess
          status: "False"
          type: RolloutBlocked
        - lastTransitionTime: "2021-09-14T10:52:05Z"
          lastUpdateTime: "2021-09-14T10:52:05Z"
          message: running database migrations
          reason: MigrationsInProgress
          status: "False"
          type: Available
        lastUpdated: 2021-09-14 10:52:05.371425635 +0000 UTC
        unhealthyComponents:
          clair:
          - lastTransitionTime: "2021-09-14T10:51:32Z"
            lastUpdateTime: "2021-09-14T10:51:32Z"
            message: 'Deployment example-registry-clair-postgres: Deployment does not have minimum availability.'
            reason: MinimumReplicasUnavailable
            status: "False"
            type: Available
          - lastTransitionTime: "2021-09-14T10:51:32Z"
            lastUpdateTime: "2021-09-14T10:51:32Z"
            message: 'Deployment example-registry-clair-app: Deployment does not have minimum availability.'
            reason: MinimumReplicasUnavailable
            status: "False"
            type: Available
          mirror:
          - lastTransitionTime: "2021-09-14T10:51:32Z"
            lastUpdateTime: "2021-09-14T10:51:32Z"
            message: 'Deployment example-registry-quay-mirror: Deployment does not have minimum availability.'
            reason: MinimumReplicasUnavailable
            status: "False"
            type: Available
    Copy to Clipboard Toggle word wrap
  4. デプロイメントプロセスが正常に終了すると、QuayRegistry オブジェクトのステータスには正常でないコンポーネントは表示されません。

      status:
        conditions:
        - lastTransitionTime: "2021-09-14T10:52:36Z"
          lastUpdateTime: "2021-09-14T10:52:36Z"
          message: all registry component healthchecks passing
          reason: HealthChecksPassing
          status: "True"
          type: Available
        - lastTransitionTime: "2021-09-14T10:52:46Z"
          lastUpdateTime: "2021-09-14T10:52:46Z"
          message: all objects created/updated successfully
          reason: ComponentsCreationSuccess
          status: "False"
          type: RolloutBlocked
        currentVersion: {producty}
        lastUpdated: 2021-09-14 10:52:46.104181633 +0000 UTC
        registryEndpoint: https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org
        unhealthyComponents: {}
    Copy to Clipboard Toggle word wrap

9.1. OpenShift Container Platform コンソールからの Red Hat Quay のデプロイ

  1. namespace (例: quay-enterprise) を作成します。
  2. OperatorsInstalled Operators を選択してから Quay Operator を選択し、Operator の詳細ビューに移動します。
  3. 'Provided API' の下にある 'Quay Registry' タイルの 'Create Instance' をクリックします。
  4. オプションで、QuayRegistry の 'Name' を変更します。これはレジストリーのホスト名に影響します。その他のフィールドはすべてデフォルトで入力されています。
  5. 'Create' をクリックし、Quay Operator によってデプロイされる QuayRegistry を送信します。
  6. QuayRegistry リストビューにリダイレクトされるはずです。作成した QuayRegistry をクリックし、詳細ビューを表示します。
  7. 'Registry Endpoint' の値が設定されたら、その値をクリックして UI で新規 Quay レジストリーにアクセスします。'Create Account' を選択して、ユーザーを作成し、サインインできるようになりました。

9.1.1. Red Hat Quay UI を使用した最初のユーザーの作成

Red Hat Quay UI で最初のユーザーを作成するには、次の手順を実行します。

注記

この手順では、FEATURE_USER_CREATION 設定オプションが false に設定されていることを前提としています。False の場合、UI での Create Account 機能が無効になり、API を使用して最初のユーザーを作成する必要があります。

手順

  1. OpenShift Container Platform コンソールで、適切な namespace /プロジェクトを使用して OperatorsInstalled Operators に移動します。
  2. 新しくインストールされた QuayRegistry オブジェクトをクリックして詳細を表示します。以下に例を示します。

    QuayRegistry details

  3. Registry Endpoint に値を設定したら、ブラウザーでこの URL に移動します。
  4. Red Hat Quay レジストリー UI で Create Account を選択し、ユーザーを作成します。以下に例を示します。

    Create Account

  5. UsernamePasswordEmail の詳細を入力し、Create Account をクリックします。以下に例を示します。

    Enter account details

最初のユーザーを作成すると、自動的に Red Hat Quay レジストリーにログインされます。以下に例を示します。

Initial log in

第10章 QuayRegistry オブジェクトのステータスの表示

特定の Red Hat Quay デプロイメントのライフサイクル可観測性は、対応する QuayRegistry オブジェクトの status セクションで報告されます。Red Hat Quay Operator はこのセクションを常に更新します。Red Hat Quay または管理対象の依存関係において問題や状態の変更がないかを確認する場合に、こちらの場所を最初に探すようにしてください。

10.1. レジストリーエンドポイントの表示

Red Hat Quay を使用する準備ができると、レジストリーの一般に利用可能なホスト名が status.registryEndpoint フィールドに設定されます。

10.2. 使用中の Red Hat Quay のバージョンの表示

実行中の Red Hat Quay の現行バージョンは status.currentVersion で報告されます。

10.3. Red Hat Quay デプロイメントの条件の表示

特定の条件は status.conditions で報告されます。

第11章 OpenShift Container Platform での Red Hat Quay のカスタマイズ

デプロイメント後に、Red Hat Quay 設定バンドルシークレット spec.configBundleSecret を編集して Red Hat Quay アプリケーションをカスタマイズできます。QuayRegistry リソースの spec.components オブジェクトで、コンポーネントの管理ステータスを変更したり、一部のコンポーネントのリソース要求を設定したりすることもできます。

11.1. OpenShift Container Platform コンソールでの設定バンドルシークレットの編集

OpenShift Container Platform コンソールで設定バンドルシークレットを編集するには、次の手順を実行します。

手順

  1. Red Hat Quay Registry の概要画面で、Config Bundle Secret のリンクをクリックします。

    Red Hat Quay Registry overview

  2. シークレットを編集するには、ActionsEdit Secret をクリックします。

    Edit secret

  3. 設定を変更して保存します

    Save changes

  4. デプロイメントを監視して、正常に完了したこと、および設定の変更が反映されていることを確認します。

11.2. QuayRegistry エンドポイントおよびシークレットの決定

次の手順を実行して、QuayRegistry エンドポイントとシークレットを見つけます。

手順

  1. 現在のエンドポイントとシークレットを見つけるには、次のコマンドを入力し、oc describe quayregistry または oc get quayregistry -o yaml を使用して QuayRegistry リソースを調べます。

    $ oc get quayregistry example-registry -n quay-enterprise -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      ...
      name: example-registry
      namespace: quay-enterprise
      ...
    spec:
      components:
      - kind: quay
        managed: true
      ...
      - kind: clairpostgres
        managed: true
      configBundleSecret: init-config-bundle-secret 
    1
    
    status:
      currentVersion: 3.7.0
      lastUpdated: 2022-05-11 13:28:38.199476938 +0000 UTC
      registryEndpoint: https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org 
    2
    Copy to Clipboard Toggle word wrap

    1
    config.yaml ファイルと SSL/TLS 証明書を含む設定バンドルのシークレット。
    2
    レジストリーの URL、レジストリー UI へのブラウザーアクセス、およびレジストリー API エンドポイント。

11.3. CLI を使用して設定ファイルを変更する

CLI を使用して既存の設定をダウンロードすることにより、configBundleSecret によって保存されている config.yaml ファイルを変更できます。変更を加えた後、configBundleSecret リソースを再度アップロードして、Red Hat Quay レジストリーに変更を加えることができます。

注記

configBundleSecret リソースによって保存される config.yaml ファイルを変更するには、既存の設定ファイルを base64 でデコードした後に変更をアップロードするという、複数のステップからなる手順が必要です。ほとんどの場合、OpenShift Container Platform Web コンソールを使用して config.yaml ファイルに変更を加える方が簡単です。

前提条件

  • 管理者権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている。

手順

  1. 次のコマンドを入力して、QuayRegistry リソースを記述します。

    $ oc describe quayregistry -n <quay_namespace>
    Copy to Clipboard Toggle word wrap
    # ...
      Config Bundle Secret:  example-registry-config-bundle-v123x
    # ...
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力してシークレットデータを取得します。

    $ oc get secret -n <quay_namespace> <example-registry-config-bundle-v123x> -o jsonpath='{.data}'
    Copy to Clipboard Toggle word wrap

    出力例

    {
        "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo="
    }
    Copy to Clipboard Toggle word wrap

  3. >> config.yaml フラグを渡して、データをカレントディレクトリーの YAML ファイルにデコードします。以下に例を示します。

    $ echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode >> config.yaml
    Copy to Clipboard Toggle word wrap
  4. config.yaml ファイルに必要な変更を加え、ファイルを config.yaml として保存します。
  5. 次のコマンドを入力して、新しい configBundleSecret YAML を作成します。

    $ touch <new_configBundleSecret_name>.yaml
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを入力し、config.yaml ファイルを渡して新しい configBundleSecret リソースを作成します。

    $ oc -n <namespace> create secret generic <secret_name> \
      --from-file=config.yaml=</path/to/config.yaml> \ 
    1
    
      --dry-run=client -o yaml > <new_configBundleSecret_name>.yaml
    Copy to Clipboard Toggle word wrap
    1
    <config.yaml>base64 でデコード された config.yaml ファイルです。
  7. 次のコマンドを入力して、configBundleSecret リソースを作成します。

    $ oc create -n <namespace> -f <new_configBundleSecret_name>.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    secret/config-bundle created
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを入力して、新しい configBundleSecret オブジェクトを参照するように QuayRegistry YAML ファイルを更新します。

    $ oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":{"configBundleSecret":"<new_configBundleSecret_name>"}}'
    Copy to Clipboard Toggle word wrap

    出力例

    quayregistry.quay.redhat.com/example-registry patched
    Copy to Clipboard Toggle word wrap

検証

  1. QuayRegistry CR が新しい configBundleSecret で更新されていることを確認します。

    $ oc describe quayregistry -n <quay_namespace>
    Copy to Clipboard Toggle word wrap

    出力例

    # ...
      Config Bundle Secret: <new_configBundleSecret_name>
    # ...
    Copy to Clipboard Toggle word wrap

    レジストリーにパッチを適用すると、Red Hat Quay Operator が自動的に変更を調整します。

第12章 Red Hat Quay on OpenShift Container Platform のカスタム SSL/TLS 証明書の設定

このコンテンツは、Red Hat Quay の保護 に移動されました。この章は、Red Hat Quay の今後のバージョンでは削除される予定です。

次のステップ

*Red Hat Quay の保護

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る