Menu Close

Red Hat Quay の管理

Red Hat Quay 3.7

Red Hat Quay の管理

概要

Red Hat Quay の管理

序文

Red Hat Quay レジストリーをデプロイしたら、そのデプロイメントをさらに設定し、管理する方法は多数あります。ここで取り上げるトピックには以下が含まれます。

  • Red Hat Quay の高度な設定
  • 新規 Red Hat Quay リリースについてのアラートを送信するための通知の設定
  • SSL および TLS 証明書による接続のセキュリティー保護
  • アクションログのストレージの Elasticsearch へのダイレクト
  • Clair でのイメージセキュリティースキャンの設定
  • コンテナーセキュリティー Operator での Pod イメージのスキャン
  • Quay Bridge Operator を使用した Red Hat Quay の OpenShift への統合
  • リポジトリーミラーリングを使用したイメージのミラーリング
  • BitTorrent サービスとの Quay イメージの共有
  • LDAP を使用したユーザーの認証
  • Prometheus および Grafana メトリクスの Quay の有効化
  • Geo-replication のセットアップ
  • Quay のトラブルシューティング

第1章 Red Hat Quay の高度な設定

初期導入後の Red Hat Quay は、いくつかの異なるインターフェイスを使用して設定できます。

  • Red Hat Quay Config Tool: config モードで Quay コンテナーを実行すると、Red Hat Quay クラスターを設定するための Web ベースのインターフェースが表示されます。この方法は、Red Hat Quay サービス自体のほとんどの構成に推奨される方法です。
  • config.yaml の編集: config.yaml ファイルは、Red Hat Quay クラスターの設定情報の大部分を保持します。このファイルを直接編集することはできますが、これは Config Tool で利用できない高度なチューニングやパフォーマンス機能のみに推奨されます。
  • Red Hat Quay API: 一部の Red Hat Quay 設定は API 経由で実行できます。

特定の機能の設定は個別のセクションで説明されますが、本セクションでは、それらのインターフェースのそれぞれを使用し、より高度な設定を行う方法を説明します。

1.1. Red Hat Quay Config Tool を使用した Red Hat Quay の変更

Red Hat Quay Config Tool は、通常の Red Hat Quay サービスと共に config モードで Quay コンテナーを実行して利用できます。Config Tool の実行は、OpenShift 上で動作する Red Hat Quay クラスターの場合は、ホストシステム上で直接動作する場合とは異なります。

1.1.1. Red Hat Quay Operator からの Config Tool の実行

OpenShift で Red Hat Quay Operator を実行している場合、Config Tool はすでに使用可能な状態である可能性があります。Config Tool にアクセスするには、以下を実行します。

  1. OpenShift コンソールから、Red Hat Quay が実行されているプロジェクトを選択します。例: quay-enterprise
  2. 左側の列から Networking → Routes を選択します。以下の図に示されるように、Red Hat Quay アプリケーションと Config Tool の両方へのルートが表示されるはずです。

    View the route to the Red Hat Quay Config Tool

  3. Config Tool へのルート (例: example-quayecosystem-quay-config) を選択し、これを選択します。ブラウザーで Config ツールの Web UI を開きます。
  4. Modify configuration for this cluster を選択します。以下の図に示されるように、Config Tool が表示され、Red Hat Quay クラスターの機能を変更する準備ができます。

    Modify Red Hat Quay cluster settings from the Config Tool

  5. 必要な変更を加えたら、Save Configuration Changes を選択します。Config Tool は変更を検証します。
  6. Continue Editing または Next を選択して続行し、必要な修正を加えます。
  7. プロンプトが表示されたら、Download Configuration を選択することが推奨されます。これにより、新規の config.yaml の tarball が Red Hat Quay 設定で使用される証明書およびキーと共にダウンロードされます。
  8. Go to deployment rollout を選択してから、Populate the configuration to deployments を選択します。Red Hat Quay Pod が再起動し、変更が有効にされます。

保存した config.yaml ファイルを使用して、設定に詳細の変更を加えるか、今後の参照用にこれを維持することができます。

1.1.2. コマンドラインでの Config Tool の実行

初回の Red Hat Quay デプロイメントの後に、podman コマンドまたは docker コマンドなどのツールを使用して、ホストシステムから直接 Red Hat Quay を実行している場合、Config Tool を再起動して Red Hat Quay クラスターを変更することができます。以下に、これを実行する方法を示します。

  1. quay をコンフィグモードで起動: 最初の quay ノードで以下を実行し、my-secret-password をあなたのパスワードに置き換えます。既存の設定バンドルを変更する場合は、レジストリーモードの場合と同様に、設定ディレクトリーを Quay コンテナーに簡単にマウントすることができます。

    # podman run --rm -it --name quay_config -p 8080:8080 \
        -v path/to/config-bundle:/conf/stack \
        registry.redhat.io/quay/quay-rhel8:v3.7.3 config my-secret-password
  2. ブラウザを開く: Quay のコンフィグレーションツールが起動したら、コンフィグレーションツールを実行しているシステムの URL およびポート 8080 に向けてブラウザを開きます (例: https://myquay.example.com:8080)。ユーザー名とパスワードを求めるプロンプトが出されます。

この時点で、上記のように Red Hat Quay クラスターの変更を開始できます。

1.2. API を使用した Red Hat Quay の変更

Red Hat Quay API へのアクセス方法については、『Red Hat Quay API ガイド』を参照してください。

1.3. Red Hat Quay を編集するための config.yaml ファイルの編集

Config Tool で利用できない詳細な Red Hat Quay 設定は、config.yaml ファイルを直接編集して実行できます。使用できる設定については、「Red Hat Quay 設定のスキーマ」に記載されています。以下は、config.yaml ファイルで直接変更できる設定の例です。

1.3.1. 名前および会社名を Red Hat Quay サインインに追加

以下を設定すると、初回のサインイン時に、ユーザーには名前と会社名の入力を求めるプロンプトが出されます。これはオプションですが、Red Hat Quay ユーザーに関する追加データが提供されます。

+ FEATURE_USER_METADATA: true

1.3.2. TLS プロトコルの無効化

SSL_PROTOCOLS 設定を変更して、Red Hat Quay インスタンスでサポートする必要のない SSL プロトコルを削除できます。たとえば、デフォルトの SSL_PROTOCOLS : ['TLSv1','TLSv1.1','TLSv1.2'] から TLSv1 サポートを削除するには、以下のように変更します。

+ SSL_PROTOCOLS : ['TLSv1.1','TLSv1.2']

1.3.3. レート制限 API 呼び出し

FEATURE_RATE_LIMITS パラメーターを config.yaml に追加すると、nginx は特定の API 呼び出しを毎秒 30 に制限します。この機能が設定されていない場合、API 呼び出しは毎秒 300 に制限されます (実質的には無制限)。利用可能なリソースでトラフィックが一杯にならないようにする必要がある場合に、レート制限は重要な機能になります。

namespace によっては、無制限のアクセスを必要とする場合があります(CI/CD に重要な場合や優先度が高い場合など)。この場合、それらの namespace は NON_RATE_LIMITED_NAMESPACES の config.yaml の一覧に配置できます。

1.3.4. データベース接続プールの調整

Red Hat Quay は、すべてが同じコンテナー内で実行される多くの異なるプロセスで構成されます。これらのプロセスの多くはデータベースと対話します。

有効にすると、データベースと対話する各プロセスには接続プールが含まれます。これらのプロセスごとの接続プールは、最大 20 の接続を維持するように設定されます。負荷が大きい場合、Red Hat Quay コンテナー内のすべてのプロセスに対して接続プールを埋めることができます。特定のデプロイメントや負荷の下では、Red Hat Quay が設定されたデータベースの最大接続数を超えないように分析が必要になる場合があります。

一定期間が経過すると、接続プールはアイドル状態の接続を解放します。すべての接続を即時に解放するには、Red Hat Quay で再起動が必要になります。

データベース接続プールは、環境変数 DB_CONNECTION_POOLING={true|false} を設定して切り替えることができます。

データベース接続プールが有効にされている場合、接続プールの最大サイズを変更することができます。これは、以下の config.yaml オプションを使用して実行できます。

DB_CONNECTION_ARGS:
  max_connections: 10

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

config.yaml ファイルで、Red Hat Quay データベース接続の設定をカスタマイズできます。これらは psycopg2 (Postgres 用) および pymysql (MySQL 用) などの基礎となるデータベースドライバーに完全に依存します。また、以下のように、Peewee のコネクションプーリング機構が使用する引数を渡すことも可能です。

DB_CONNECTION_ARGS:
  max_connections: n  # Max Connection Pool size. (Connection Pooling only)
  timeout: n  # Time to hold on to connections. (Connection Pooling only)
  stale_timeout: n  # Number of seconds to block when the pool is full. (Connection Pooling only)

1.3.4.2. データベース SSL 設定

DB_CONNECTION_ARGS で定義されたキーと値のペアは汎用的なものも、データベース固有のものもあります。特に、SSL 設定は、デプロイするデータベースによって異なります。

1.3.4.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 を参照してください。

1.3.4.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 を参照してください。

1.3.4.3. HTTP 接続回数

環境変数を使用して同時 HTTP 接続の数を指定できます。これらは全体として、または特定のコンポーネントに対して指定できます。それぞれのデフォルトは、1 プロセスあたり 50 並列接続です。

環境変数:

WORKER_CONNECTION_COUNT_REGISTRY=n
WORKER_CONNECTION_COUNT_WEB=n
WORKER_CONNECTION_COUNT_SECSCAN=n
WORKER_CONNECTION_COUNT=n
注記

特定のコンポーネントのカウントを指定すると、WORKER_CONNECTION_COUNT で設定された値が上書きされます。

1.3.4.4. 動的プロセス数

動的に設定されたサイズのプロセス数を見積もるには、以下の計算がデフォルトで使用されます。

注記

Red Hat Quay は、マシン全体から利用可能な CPU 数をクエリーします。kubernetes その他の非仮想化メカニズムを使用して適用される制限はこの動作には影響しません。Red Hat Quay は、ノード上のプロセッサーの合計数に基づいて計算を行います。一覧表示されるデフォルト値は単にターゲットですが、最大値を超えないか、または最小値より低くなりません。

以下のプロセス数のそれぞれは、以下に指定される環境変数を使用して上書きすることができます。

  • レジストリー: レジストリーのアクションを処理する HTTP エンドポイントを提供します。

    • 最小: 8
    • 最大: 64
    • default: $CPU_COUNT x 4
    • 環境変数: WORKER_COUNT_REGISTRY
  • web: Web ベースのインターフェースの HTTP エンドポイントを提供します。

    • 最小: 2
    • 最大: 32
    • デフォルト: $CPU_COUNT x 2
    • environment_variable: WORKER_COUNT_WEB
  • secscan: Clair との対話

    • 最小: 2
    • 最大: 4
    • デフォルト: $CPU_COUNT x 2
    • 環境変数: WORKER_COUNT_SECSCAN

1.3.4.5. 環境変数

Red Hat Quay では、環境変数を使用したデフォルト動作を許可します。この表は、それぞれの変数および予想される値を一覧表示し、これらを説明します。

表1.1 Worker count 環境変数

変数説明

WORKER_COUNT_REGISTRY

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

8 ~ 64 の整数

WORKER_COUNT_WEB

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

2 から 32 の間の整数

WORKER_COUNT_SECSCAN

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

2 から 4 の間の整数

DB_CONNECTION_POOLING

データベース接続プールの切り替え3.4 では、これはデフォルトで無効にされます。

"true" または "false"

1.3.4.6. 接続プールをオフにする

多数のユーザーアクティビティーを伴う Red Hat Quay デプロイメントは、2k の最大データベース接続の制限に定期的に達する可能性があります。このような場合、Red Hat Quay でデフォルトで有効にされる接続プールにより、データベース接続数が指数関数的に増加し、接続プールをオフにすることが必要になる可能性があります。

接続プールをオフにするだけでは 2k のデータベース接続の制限に達することを防ぐことができない場合は、追加の手順を実行して問題に対処する必要があります。この場合、ワークロードに合わせて最大データベース接続数を増やす必要がある場合があります。

第2章 設定 API の使用

設定ツールは、設定のビルド、検証、バンドルおよびデプロイに使用できる 4 つのエンドポイントを公開します。config-tool API は、https://github.com/quay/config-tool/blob/master/pkg/lib/editor/API.md で説明されています。本セクションでは、API を使用して現在の設定を取得する方法、および加えた変更を検証する方法について説明します。

2.1. デフォルト設定の取得

設定ツールを初めて実行し、既存の設定がない場合に、デフォルト設定を取得できます。コンテナーをコンフィグモードで起動します。

$ sudo podman run --rm -it --name quay_config \
  -p 8080:8080 \
  registry.redhat.io/quay/quay-rhel8:v3.7.3 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,
    ....
  }

}

2.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.7.3 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",
    ....


  }

}

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

返される値は、設定で見つかったエラーを含む配列です。設定が有効な場合は、空の配列 [] が返されます。

2.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"
  }
]

第3章 Red Hat Quay のリリース通知の取得

最新の Red Hat Quay リリースや、Red Hat Quay に関連するその他の変更に対応するには、Red Hat カスタマーポータルで更新通知にサインアップできます。通知へのサインアップ後に、Red Hat Quay の新規バージョン、ドキュメントの更新、またはその他の Red Hat Quay に関する最新情報の通知を受信できます。

  1. Red Hat カスタマーポータルアカウントの認証情報を使用して Red Hat カスタマーポータルにログインします。
  2. ユーザー名 (右上隅) を選択すると、Red Hat Account とカスタマーポータルの選択項目が表示されます。 View account and portal selections
  3. 「Notifications」を選択します。プロファイルアクティビティーページが表示されます。
  4. 「Notifications」タブを選択します。
  5. 「Manage Notifications」を選択します。
  6. 「Follow」を選択してから、ドロップダウンメニューから「Products」を選択します。
  7. 製品の横にあるドロップダウンボックスで、Red Hat Quay を検索して選択します。 Select Products from notifications box
  8. 「SAVE NOTIFICATION」ボタンを選択します。今後は、新しいリリースなどの Red Hat Quay 製品に変更が加えられた場合に通知が送信されます。

第4章 SSL を使用した Red Hat Quay への接続の保護

4.1. SSL の使用について

自己署名証明書で Red Hat Quay を設定するには、認証局 (CA) を作成し、必要なキーおよび証明書ファイルを生成する必要があります。

以下の例では、/etc/hosts ファイルにエントリーを追加するなど、DNS または別の命名メカニズムを使用してサーバーホスト名 quay-server.example.com を設定していることを前提としています。

$ cat /etc/hosts
...
192.168.1.112   quay-server.example.com

4.2. 認証局を作成して証明書に署名

この手順の最後に、証明書ファイルと、ssl.cert および ssl.key という名前のプライマリーキーファイルがあります。

4.2.1. 認証局の作成

  1. ルート CA キーを生成します。

    $ openssl genrsa -out rootCA.key 2048
  2. ルート CA 証明書を生成します。

    $ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem
  3. サーバーのホスト名など、証明書の要求に組み込まれる情報を入力します。以下に例を示します。

    Country Name (2 letter code) [XX]:IE
    State or Province Name (full name) []:GALWAY
    Locality Name (eg, city) [Default City]:GALWAY
    Organization Name (eg, company) [Default Company Ltd]:QUAY
    Organizational Unit Name (eg, section) []:DOCS
    Common Name (eg, your name or your server's hostname) []:quay-server.example.com

4.2.2. 証明書に署名

  1. サーバーキーを生成します。

    $ openssl genrsa -out ssl.key 2048
  2. 署名要求を生成します。

    $ openssl req -new -key ssl.key -out ssl.csr
  3. サーバーのホスト名など、証明書の要求に組み込まれる情報を入力します。以下に例を示します。

    Country Name (2 letter code) [XX]:IE
    State or Province Name (full name) []:GALWAY
    Locality Name (eg, city) [Default City]:GALWAY
    Organization Name (eg, company) [Default Company Ltd]:QUAY
    Organizational Unit Name (eg, section) []:DOCS
    Common Name (eg, your name or your server's hostname) []:quay-server.example.com
  4. 以下のようにサーバーのホスト名を指定して、設定ファイルの openssl.cnf を作成します。

    openssl.cnf

    [req]
    req_extensions = v3_req
    distinguished_name = req_distinguished_name
    [req_distinguished_name]
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = nonRepudiation, digitalSignature, keyEncipherment
    subjectAltName = @alt_names
    [alt_names]
    DNS.1 = quay-server.example.com
    IP.1 = 192.168.1.112

  5. 設定ファイルを使用して、証明書 ssl.cert を生成します。

    $ openssl x509 -req -in ssl.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out ssl.cert -days 356 -extensions v3_req -extfile openssl.cnf

4.3. コマンドラインを使用した SSL の設定

別のオプションとして、コマンドラインインターフェースを使用できます。

  1. 証明書ファイルとプライマリーキーファイルを設定ディレクトリーにコピーして、それぞれ ssl.certssl.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 コンテナーを停止し、レジストリーを再起動します。

    $ sudo podman rm -f quay
    $ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
      --name=quay \
      -v $QUAY/config:/conf/stack:Z \
      -v $QUAY/storage:/datastorage:Z \
      registry.redhat.io/quay/quay-rhel8:v3.7.3

4.4. UI を使用した SSL の設定

このセクションでは、Quay UI を使用して SSL を設定します。コマンドラインインターフェースを使用して SSL を設定するには、以下のセクションを参照してください。

  1. Quay コンテナーを設定モードで起動します。

    $ sudo podman run --rm -it --name quay_config -p 80:8080 -p 443:8443 registry.redhat.io/quay/quay-rhel8:v3.7.3 config secret
  2. Server Configuration セクションで、TLS に Red Hat Quay handle TLS を選択します。先に作成した証明書ファイルとプライベートキーファイルをアップロードし、証明書の作成時に Server Hostname が使用された値と一致することを確認します。更新された設定の検証およびダウンロード
  3. Quay コンテナーを停止し、レジストリーを再起動します。

    $ sudo podman rm -f quay
    $ sudo podman run -d --rm -p 80:8080 -p 443:8443 \
    --name=quay \
    -v $QUAY/config:/conf/stack:Z \
    -v $QUAY/storage:/datastorage:Z \
    registry.redhat.io/quay/quay-rhel8:v3.7.3

4.5. コマンドラインを使用した SSL 設定のテスト

  • podman login コマンドを使用して、SSL が有効になっている Quay レジストリーへのログインを試みます。

    $ sudo podman login quay-server.example.com
    Username: quayadmin
    Password:
    
    Error: error authenticating creds for "quay-server.example.com": error pinging docker registry quay-server.example.com: Get "https://quay-server.example.com/v2/": x509: certificate signed by unknown authority
  • Podman は自己署名証明書を信頼しません。回避策として、--tls-verify オプションを使用します。

    $ sudo podman login --tls-verify=false quay-server.example.com
    Username: quayadmin
    Password:
    
    Login Succeeded!

ルート認証局 (CA) を信頼するように Podman を設定する方法は、後続のセクションで説明します。

4.6. ブラウザーを使用した SSL 設定のテスト

Quay レジストリーへのアクセスを試みると (この場合は https://quay-server.example.com)、ブラウザーは潜在的なリスクについて警告します。

Potential risk

画面にログインすると、ブラウザーは接続が安全ではないことを通知します。

Connection not secure

ルート認証局 (CA) を信頼するようにシステムを設定する方法は、後続のセクションで説明します。

4.7. 認証局を信頼するように podman を設定する

Podman は、/etc/containers/certs.d/ および /etc/docker/certs.d/ の 2 つのパスを使用して CA ファイルを見つけます。

  • ルート CA ファイルをこれらの場所のいずれかにコピーし、サーバーのホスト名によって判別されるパスを使用して、ca.crt ファイルに名前を付けます。

    $ sudo cp rootCA.pem /etc/containers/certs.d/quay-server.example.com/ca.crt
  • または、Docker を使用している場合は、ルート CA ファイルを同等の Docker ディレクトリーにコピーします。

    $ sudo cp rootCA.pem /etc/docker/certs.d/quay-server.example.com/ca.crt

レジストリーにログインする際に、--tls-verify=false オプションを使用する必要がなくなります。

$ sudo podman login quay-server.example.com

Username: quayadmin
Password:
Login Succeeded!

4.8. 認証局を信頼するようにシステムを設定

  1. ルート CA ファイルを統合されたシステム全体のトラストストアにコピーします。

    $ sudo cp rootCA.pem /etc/pki/ca-trust/source/anchors/
  2. システム全体のトラストストア設定を更新します。

    $ sudo update-ca-trust extract
  3. trust list コマンドを使用して、Quay サーバーが設定されていることを確認できます。

    $ trust list | grep quay
        label: quay-server.example.com

    https://quay-server.example.com でレジストリーを参照すると、接続が安全であることを示すロックアイコンが表示されます。

    Connection not secure

  4. システム全体の信頼からルート CA を削除するには、ファイルを削除し、設定を更新します。

    $ sudo rm /etc/pki/ca-trust/source/anchors/rootCA.pem
    $ sudo update-ca-trust extract
    $ trust list | grep quay
    $

詳細は、RHEL 8 のドキュメントの 共有システム証明書の使用 について参照してください。

第5章 Red Hat Quay コンテナーへの TLS 証明書の追加

カスタム TLS 証明書を Red Hat Quay に追加するには、Red Hat Quay 設定ディレクトリーの下に extra_ca_certs/ という名前の新規ディレクトリーを作成します。必要なサイト固有の TLS 証明書をこの新しいディレクトリーにコピーします。

5.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 IDpodman ps で取得します。

    $ sudo podman ps
    CONTAINER ID        IMAGE                                COMMAND                  CREATED             STATUS              PORTS
    5a3e82c4a75f        <registry>/<repo>/quay:v3.7.3 "/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

5.2. Kubernetes へのデプロイ時に証明書を追加

Kubernetes にデプロイされると、Red Hat Quay は設定アセットを保存するためのボリュームとしてシークレットにマウントします。ただし、現時点でこれを実行すると、スーパーユーザーパネルの証明書アップロード機能に障害が発生します。

このエラーを回避するには、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 を新しい証明書データで自動的にスケジュールします。

第6章 Elasticsearch 用のアクションログストレージの設定

デフォルトで、過去 3 カ月間の使用ログは Red Hat Quay データベースに保存され、Web UI から組織およびリポジトリーレベルで公開されます。ログエントリーを表示するには、適切な管理者権限が必要です。多数のログに記録された操作を使用するデプロイメントの場合、使用ログは Red Hat Quay データベースバックエンドではなく Elasticsearch に保存できるようになりました。これを実行するには、独自の Elasticsearch スタックを提供する必要があります。これはカスタマイズ可能なコンポーネントとして Red Hat Quay に含まれていないためです。

Elasticsearch ロギングは、Red Hat Quay デプロイメント時または Red Hat Quay Config Tool を使用してデプロイメント後に有効にできます。生成される設定は config.yaml ファイルに保存されます。設定後は、リポジトリーや組織用に Web UI を使用して使用ログのアクセスが引き続き提供されます。

以下は、デフォルトの Red Hat Quay データベースから Elasticsearch を使用するようにアクションログストレージを設定する方法です。

  1. Elasticsearch アカウントを取得します。
  2. Red Hat Quay Config Tool を開きます (Red Hat Quay のデプロイメント時またはその後のいずれか)。
  3. Action Log Storage Configuration 設定までスクロールし、Database ではなく Elasticsearch を選択します。以下の図は、表示される Elasticsearch 設定を示しています。

    Choose Elasticsearch to view settings to store logs

  4. Elasticsearch インスタンスについて以下の情報を入力します。

    • Elasticsearch hostname: Elasticsearch サービスを提供するシステムのホスト名または IP アドレス。
    • Elasticsearch port: 入力したホストで Elasticsearch サービスを提供するポート番号。ポートは、Red Hat Quay レジストリーを実行しているすべてのシステムからアクセスできる必要があることに注意してください。デフォルトは TCP ポート 9200 です。
    • Elasticsearch access key: Elastic 検索サービスへのアクセスに必要なアクセスキー (必要な場合)。
    • Elasticsearch secret key: Elastic 検索サービスへのアクセスに必要なシークレットキー (必要な場合)。
    • AWS region: AWS で実行している場合は、AWS リージョンを設定します (それ以外の場合は、空白のままにします)。
    • Index prefix: ログエントリーに割り当てるプレフィックスを選択します。
    • Log Producer: Elasticsearch (デフォルト) または Kinesis のいずれかを選択し、AWS の中間 Kinesis ストリームにログをダイレクトします。ログを Kinesis から Elasticsearch (例: Logstash) に送信するために独自のパイプラインを設定する必要があります。以下の図は、Kinesis についての入力に必要な追加のフィールドを示しています。

      On AWS optionally set up an intermediate Kinesis stream

  5. Elasticsearch を Logs Producer として選択した場合、追加の設定は必要ありません。Kinesis を選択する場合は、以下を入力します。

    • Stream name: Kinesis ストリームの名前。
    • AWS access key: Kinesis ストリームへのアクセスを取得するために必要な AWS アクセスキーの名前 (必要な場合)。
    • AWS secret key: Kinesis ストリームへのアクセスを取得するために必要な AWS シークレットキーの名前 (必要な場合)。
    • AWS region: AWS リージョン。
  6. 完了したら、設定を保存します。Config Tool は設定を確認します。Elasticsearch または Kinesis サービスへの接続に問題がある場合には、エラーが表示され、編集を続行できます。それ以外の場合、クラスターが新規設定で再起動された後に、ロギングは Elasticsearch 設定にダイレクトされます。

第7章 Clair セキュリティースキャン

Clair は、Red Hat Quay と共に使用できるマイクロサービスのセットで、一連の Linux オペレーティングシステムに関連付けられたコンテナーイメージの脆弱性スキャンを実行します。Clair のマイクロサービスは、設計上、企業環境に合わせてコンポーネントを個別に拡張できる拡張性の高い設定で実行することに適しています。

Clair は、以下の脆弱性データベースを使用して、イメージ内で問題の有無をスキャンします。

  • Alpine SecDB データベース
  • AWS UpdateInfo
  • Debian Oval データベース
  • Oracle Oval データベース
  • RHEL Oval データベース
  • SUSE Oval データベース
  • Ubuntu Oval データベース
  • Pyup.io (python) データベース

Clair が各種のデータベースでセキュリティーマッピングを行う方法についての詳細は、「 ClairCore Severity Mapping」を参照してください。

注記

Red Hat Quay 3.4 のリリースでは、新規の Clair V4 (イメージ registry.redhat.io/quay/clair-rhel8 は以前の Clair V2 (イメージ quay.io/redhat/clair-jwt) を完全に置き換えます。V4 の更新中に V2 をリードオンリーモードで動作させる方法は以下を参照してください。

7.1. Red Hat Quay OpenShift デプロイメントでの Clair の設定

7.1.1. Quay Operator によるデプロイ

OpenShift で新規の Red Hat Quay デプロイメントに Clair V4 を設定するには、Quay Operator を使用することが強く推奨されます。デフォルトで Quay Operator は Red Hat Quay デプロイメントと共に Clair デプロイメントをインストールまたはアップグレードし、Clair セキュリティースキャンを自動的に設定します。

7.1.2. Clair の手動によるデプロイ

Clair V2 を実行する既存の Red Hat Quay OpenShift デプロイメントで Clair V4 を設定するには、最初に Red Hat Quay が少なくともバージョン 3.4.0 にアップグレードされていることを確認します。次に、以下の手順を使用して Clair V4 を Clair V2 と共に手動で設定します。

  1. 現在のプロジェクトを Red Hat Quay が実行されているプロジェクトの名前に設定します。以下は例になります。

    $ oc project quay-enterprise
  2. Clair v4 用の Postgres デプロイファイル (例: clairv4-postgres.yaml) を以下のように作成します。

    clairv4-postgres.yaml

    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: clairv4-postgres
      namespace: quay-enterprise
      labels:
        quay-component: clairv4-postgres
    spec:
      replicas: 1
      selector:
        matchLabels:
          quay-component: clairv4-postgres
      template:
        metadata:
          labels:
            quay-component: clairv4-postgres
        spec:
          volumes:
            - name: postgres-data
              persistentVolumeClaim:
                claimName: clairv4-postgres
          containers:
            - name: postgres
              image: postgres:11.5
              imagePullPolicy: "IfNotPresent"
              ports:
                - containerPort: 5432
              env:
                - name: POSTGRES_USER
                  value: "postgres"
                - name: POSTGRES_DB
                  value: "clair"
                - name: POSTGRES_PASSWORD
                  value: "postgres"
                - name: PGDATA
                  value: "/etc/postgres/data"
              volumeMounts:
                - name: postgres-data
                  mountPath: "/etc/postgres"
    ---
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: clairv4-postgres
      labels:
        quay-component: clairv4-postgres
    spec:
      accessModes:
        - "ReadWriteOnce"
      resources:
        requests:
          storage: "5Gi"
        volumeName: "clairv4-postgres"
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: clairv4-postgres
      labels:
        quay-component: clairv4-postgres
    spec:
      type: ClusterIP
      ports:
        - port: 5432
          protocol: TCP
          name: postgres
          targetPort: 5432
      selector:
        quay-component: clairv4-postgres

  3. 以下のように、postgres データベースをデプロイします。

    $ oc create -f ./clairv4-postgres.yaml
  4. Clair v4 で使用する Clair config.yaml ファイルを作成します。以下は例になります。

    config.yaml

    introspection_addr: :8089
    http_listen_addr: :8080
    log_level: debug
    indexer:
      connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
      scanlock_retry: 10
      layer_scan_concurrency: 5
      migrations: true
    matcher:
      connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
      max_conn_pool: 100
      run: ""
      migrations: true
      indexer_addr: clair-indexer
    notifier:
      connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
      delivery: 1m
      poll_interval: 5m
      migrations: true
    auth:
      psk:
        key: MTU5YzA4Y2ZkNzJoMQ== 1
        iss: ["quay"]
    # tracing and metrics
    trace:
      name: "jaeger"
      probability: 1
      jaeger:
        agent_endpoint: "localhost:6831"
        service_name: "clair"
    metrics:
      name: "prometheus"

    1
    Clair の PSK (pre-shared key) を生成するには、ユーザーインターフェースの Security Scanner セクションで scanning を有効にし、Generate PSK をクリックします。

Clair の設定フォーマットの詳細は、アップストリームの Clair ドキュメント に記載されています。

  1. Clair の config.yaml からシークレットを作成します。

    $ oc create secret generic clairv4-config-secret --from-file=./config.yaml
  2. Clair v4のデプロイメントファイル (例: clair-combo.yaml) を作成し、必要に応じて修正します。

    clair-combo.yaml

    ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      labels:
        quay-component: clair-combo
      name: clair-combo
    spec:
      replicas: 1
      selector:
        matchLabels:
          quay-component: clair-combo
      template:
        metadata:
          labels:
            quay-component: clair-combo
        spec:
          containers:
            - image: registry.redhat.io/quay/clair-rhel8:v3.7.3  1
              imagePullPolicy: IfNotPresent
              name: clair-combo
              env:
                - name: CLAIR_CONF
                  value: /clair/config.yaml
                - name: CLAIR_MODE
                  value: combo
              ports:
                - containerPort: 8080
                  name: clair-http
                  protocol: TCP
                - containerPort: 8089
                  name: clair-intro
                  protocol: TCP
              volumeMounts:
                - mountPath: /clair/
                  name: config
          imagePullSecrets:
            - name: redhat-pull-secret
          restartPolicy: Always
          volumes:
            - name: config
              secret:
                secretName: clairv4-config-secret
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: clairv4 2
      labels:
        quay-component: clair-combo
    spec:
      ports:
        - name: clair-http
          port: 80
          protocol: TCP
          targetPort: 8080
        - name: clair-introspection
          port: 8089
          protocol: TCP
          targetPort: 8089
      selector:
        quay-component: clair-combo
      type: ClusterIP

    1
    イメージを最新のクレアのイメージ名とバージョンに変更します。
    2
    サービスを clairv4 に設定すると、Clair v4 のスキャナーエンドポイントは、Red Hat Quay の config.yaml の SECURITY_SCANNER_V4_ENDPOINThttp://clairv4 と入力します。
  3. 以下のように Clair v4 の配置を作成します。

    $ oc create -f ./clair-combo.yaml
  4. Red Hat Quay 配置の config.yaml ファイルを変更して、最後に以下のエントリを追加します。

    FEATURE_SECURITY_NOTIFICATIONS: true
    FEATURE_SECURITY_SCANNER: true
    SECURITY_SCANNER_V4_ENDPOINT: http://clairv4 1
    1
    Clair v4 サービスエンドポイントを特定します。
  5. 修正した config.yaml を、そのファイルを含むシークレット (たとえば quay-enterprise-config-secret) に再デプロイします。

    $ oc delete secret quay-enterprise-config-secret
    $ oc create secret generic quay-enterprise-config-secret --from-file=./config.yaml
  6. 新しい config.yaml を有効にするには、Red Hat Quay の Pod を再起動する必要があります。quay-app Pod を削除するだけで、更新された設定を持つ Pod がデプロイされます。

この時点で、namespace ホワイトリストで特定される組織内のイメージが Clair v4 によってスキャンされます。

7.2. OpenShift 以外の Red Hat Quay デプロイメントでの Clair のセットアップ

Red Hat Quay デプロイメントが OpenShift で実行されていない場合、Clair セキュリティースキャンを手動で設定することができます。Clair V2 をすでに実行している Red Hat Quay デプロイメントは、以下の手順に従って Clair V4 をデプロイメントに追加できます。

  1. (可能であれば、耐障害性のある) Postgres データベースサーバーをデプロイします。Clair では、uuid-ossp 拡張をその Postgres データベースに追加する必要があることに注意してください。Clair の config.yaml で指定されるユーザーに拡張を作成するのに必要な権限がある場合、これは Clair 自体によって自動的に追加されます。そうでない場合は、拡張を Clair の起動前に追加する必要があります。この拡張子がない場合は、Clair を起動しようとすると以下のエラーが表示されます。

    ERROR: Please load the "uuid-ossp" extension. (SQLSTATE 42501)
  2. 特定のフォルダーで Clair 設定ファイルを作成します (例: /etc/clairv4/config/config.yaml)。

    config.yaml

    introspection_addr: :8089
    http_listen_addr: :8080
    log_level: debug
    indexer:
      connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
      scanlock_retry: 10
      layer_scan_concurrency: 5
      migrations: true
    matcher:
      connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
      max_conn_pool: 100
      run: ""
      migrations: true
      indexer_addr: clair-indexer
    notifier:
      connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
      delivery_interval: 1m
      poll_interval: 5m
      migrations: true
    
    # tracing and metrics
    trace:
      name: "jaeger"
      probability: 1
      jaeger:
        agent_endpoint: "localhost:6831"
        service_name: "clair"
    metrics:
      name: "prometheus"

Clair の設定フォーマットに関する詳細は、アップストリームの Clair ドキュメントを参照してください。

  1. コンテナーイメージ経由で Clair を実行し、作成したファイルから設定をマウントします。

    $ podman run -p 8080:8080 -p 8089:8089 -e CLAIR_CONF=/clair/config.yaml -e CLAIR_MODE=combo -v /etc/clair4/config:/clair -d registry.redhat.io/quay/clair-rhel8:v3.7.3
  2. 新しい Clair V4 エンドポイントを使用するために Red Hat Quay を設定するには、前のセクションの残りの指示に従ってください。

この形で複数の Clair コンテナーを実行することも可能ですが、1 つのコンテナーを超えるデプロイメントシナリオでは、Kubernetes や OpenShift などのコンテナーオーケストレーターの使用を強く推奨します。

7.3. 高度な Clair 設定

7.3.1. 管理されていない Clair 設定

Red Hat Quay 3.7 を使用すると、ユーザーは Red Hat Quay OpenShift Container Platform Operator でアンマネージド Clair 設定を実行できます。この機能により、ユーザーはアンマネージド Clair データベースを作成したり、アンマネージドデータベースなしでカスタム Clair 設定を実行したりできます。

7.3.1.1. Clair データベースの管理を解除

アンマネージド Clair データベースにより、Red Hat Quay は geo-replicated environment で作業できます。この環境では、Operator の複数のインスタンスが同じデータベースと通信する必要があります。管理されていない Clair データベースは、ユーザーがクラスターの外部に存在する高可用性 (HA) Clair データベースを必要とする場合にも使用できます。

手順

  • Quay Operator で、QuayRegistry カスタムリソースの clairpostgres コンポーネントを unmanaged に設定します。

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: quay370
    spec:
      configBundleSecret: config-bundle-secret
      components:
        - kind: objectstorage
          managed: false
        - kind: route
          managed: true
        - kind: tls
          managed: false
        - kind: clairpostgres
          managed: false

7.3.1.2. カスタム Clair データベースの設定

Red Hat Quay Operator for OpenShift Container Platform を使用すると、ユーザーは configBundleSecret パラメーターを編集して独自の Clair 設定を提供できます。

手順

  1. clair-config.yaml を含む Quay 設定バンドルシークレットを作成します。

    $ oc create secret generic --from-file config.yaml=./config.yaml --from-file extra_ca_cert_rds-ca-2019-root.pem=./rds-ca-2019-root.pem --from-file clair-config.yaml=./clair-config.yaml --from-file ssl.cert=./ssl.cert --from-file ssl.key=./ssl.key config-bundle-secret

    clair-config.yaml 設定の例:

    indexer:
        connstring: host=quay-server.example.com port=5432 dbname=quay user=quayrdsdb password=quayrdsdb sslrootcert=/run/certs/rds-ca-2019-root.pem sslmode=verify-ca
        layer_scan_concurrency: 6
        migrations: true
        scanlock_retry: 11
    log_level: debug
    matcher:
        connstring: host=quay-server.example.com port=5432 dbname=quay user=quayrdsdb password=quayrdsdb sslrootcert=/run/certs/rds-ca-2019-root.pem sslmode=verify-ca
        migrations: true
    metrics:
        name: prometheus
    notifier:
        connstring: host=quay-server.example.com port=5432 dbname=quay user=quayrdsdb password=quayrdsdb sslrootcert=/run/certs/rds-ca-2019-root.pem sslmode=verify-ca
        migrations: true
    注記
    • データベース証明書は、clair-config.yaml の Clair アプリケーション Pod の /run/certs/rds-ca-2019-root.pem の下にマウントされます。clair-config.yaml を設定するときに指定する必要があります。
    • clair-config.yaml の例は、OpenShift 設定の Clair にあります。
  2. clair-config.yamlconfigBundleSecret という名前のバンドルシークレットに追加します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: config-bundle-secret
      namespace: quay-enterprise
    data:
      config.yaml: <base64 encoded Quay config>
      clair-config.yaml: <base64 encoded Clair config>
      extra_ca_cert_<name>: <base64 encoded ca cert>
      clair-ssl.crt: >-
      clair-ssl.key: >-
    注記

    更新されると、提供された clair-config.yaml が Clair Pod にマウントされます。提供されていないフィールドには、Clair 設定モジュールを使用してデフォルトが自動的に入力されます。

適切に設定した後、Clair アプリケーション Pod は Ready 状態に戻るはずです。

7.3.2. managed データベースを使用したカスタム Clair 設定の実行

場合によっては、ユーザーは managed データベースを使用してカスタム Clair 設定を実行したい場合があります。これは、以下のシナリオで役に立ちます。

  • ユーザーがアップデーターを無効にしたい場合
  • ユーザーがエアギャップ環境で実行している場合

    注記
    • エアギャップ環境で Quay を実行している場合は、clair-config.yamlairgap パラメーターを true に設定する必要があります。
    • エアギャップ環境で Quay を実行している場合は、すべてのアップデーターを無効にする必要があります。

clairpostgresmanaged に設定されている場合は、「カスタム Clair データベースの設定」の手順を使用してデータベースを設定します。

エアギャップ環境での Clair の実行の詳細は、エアギャップ OpenShift クラスターでの Clair データベースへのアクセスの設定 を参照してください。

7.4. Clair CRDA 設定

7.4.1. Clair CRDA の有効化

Red Hat Quay 3.7 では、Java スキャンにデフォルトの CRDA 共有キーが含まれなくなり、デフォルトで有効になりません。次の手順を使用して、より高い RPS をサポートする Quay 固有の CRDA リモートマッチャーをフェッチし、Java スキャンで CRDA を手動で有効にします。

前提条件

  • Red Hat Quay 3.7

手順

  1. API キーリクエストフォーム を送信して、Quay 固有の CRDA リモートマッチャーを取得します。
  2. clair-config.yaml ファイルで CRDA 設定を設定します。

    ```
    matchers:
           crda:
             url: https://f8a-analytics-2445582058137.production.gw.apicast.io/api/v2/
             source: quay.io
             key: 9e7da76708fe374d8c10fa752e72989f
    ```

7.5. クレールの使用

  1. Red Hat Quay クラスターにログインし、Clair スキャンを設定している組織を選択します。
  2. イメージを保持する組織からリポジトリーを選択し、左側のナビゲーションから「Tags」を選択します。以下の図は、スキャンされた 2 つのイメージがあるリポジトリーの例を示しています。

    Security scan information appears for scanned repository images

  3. 脆弱性が見つかった場合は、イメージの「Security Scan」列の下で選択し、すべての脆弱性または修正可能な脆弱性のいずれかを確認します。以下の図は、検出されるすべての脆弱性の情報を示しています。

    See all vulnerabilities or only those that are fixable

7.6. 脆弱性情報データベース (NVD: National Vulnerability Database) の CVE 評価

Clair v4.2 では、エンリッチメントデータを Quay UI で表示できるようになりました。さらに、Clair v4.2 は、検出された脆弱性について National Vulnerability Database から CVSS スコアを追加します。

この変更により、脆弱性の CVSS スコアがディストリビューションのスコアの 2 レベル以内である場合は、デフォルトで Quay UI present が、ディストリビューションのスコアになります。以下は例になります。

Clair v4.2 data display

これは以前のインターフェイスとは異なり、以下の情報のみを表示します。

Clair v4 data display

7.7. 切断された環境のための Clair の設定

Clair は Updaters と呼ばれる一連のコンポーネントを使用して、さまざまな脆弱性データベースからのデータのフェッチと解析に対応します。これらの Updaters は、インターネットから脆弱性データをプルし、追加の設定なしに機能するようにデフォルトで設定されます。インターネットに直接アクセスせずに非接続環境を使用される場合は、これは問題となる可能性があります。Clair は、ネットワークの分離を考慮に入れた各種の更新ワークフローと連動する機能を使用してこれらの環境をサポートします。clairctl コマンドラインユーティリティーを使用すると、プロセスはオープンホスト経由でインターネットから Updater データを簡単にフェッチし、データを分離されたホストに安全に転送し、分離したホストの Updater データを Clair 自体にインポートできます。

この手順は以下の通りです。

  1. まず、Clair 設定によって Updatoer の実行が無効にされていることを確認します。

    config.yaml

    matcher:
      disable_updaters: true

  2. 最新の Updater データをローカルアーカイブにエクスポートします。このためには、バイナリーとして直接実行するか、Clair コンテナーイメージを介して実行できる clairctl ツールが必要です。Clair の設定が /etc/clairv4/config/config.yaml にあり、コンテナーイメージ経由で実行できるとします。

    $ podman run -it --rm -v /etc/clairv4/config:/cfg:Z -v /path/to/output/directory:/updaters:Z --entrypoint /bin/clairctl registry.redhat.io/quay/clair-rhel8:v3.7.3 --config /cfg/config.yaml export-updaters  /updaters/updaters.gz

    なお、Clair の設定を細かく参照する必要があります。これにより、Updater アーカイブが /etc/clairv4/updaters/updaters.gz に作成されます。ソースデータベースからエラーなしにアーカイブが作成されたことを確認する場合は、--strict フラグを clairctl に指定できます。アーカイブファイルは、Clair を実行している非接続ホストからアクセスできるボリュームにコピーする必要があります。切断されたホストから、今度は同じ手順で Clair にアーカイブをインポートします。

    $ podman run -it --rm -v /etc/clairv4/config:/cfg:Z -v /path/to/output/directory:/updaters:Z --entrypoint /bin/clairctl registry.redhat.io/quay/clair-rhel8:v3.7.3 --config /cfg/config.yaml import-updaters /updaters/updaters.gz

7.7.1. リポジトリーの Common Product Enumeration (CPE) 情報へのマッピング

Clair の RHEL スキャナーは、一致する結果を生成するために、Common Product Enumeration (CPE) ファイルに依存して RPM パッケージを対応するセキュリティーデータに適切にマッピングします。スキャナーが RPM を適切に処理するには、このファイルが存在するか、ファイルへのアクセスが許可されている必要があります。ファイルが存在しない場合、コンテナーイメージにインストールされている RPM はスキャンされません。

Red Hat は、JSON マッピングファイルを https://www.redhat.com/security/data/metrics/repository-to-cpe.json で公開しています。

非接続 Clair のデータベースに CVE 情報をアップロードする以外に、マッピングファイルをローカルで利用可能にする必要もあります。

  • スタンドアロン Quay および Clair デプロイメントの場合は、マッピングファイルを Clair Pod に読み込む必要があります。
  • Operator ベースのデプロイメントの場合は、Clair コンポーネントを unmanaged に設定する必要があります。次に、Clair を手動でデプロイし、マッピングファイルのローカルコピーを読み込むように設定します。

Clair 設定の repo2cpe_mapping_file フィールドを使用してファイルを指定します。

indexer:
  scanner:
    repo:
      rhel-repository-scanner:
        repo2cpe_mapping_file: /path/to/repository-to-cpe.json

詳細は、Red Hat の How to accurately match OVAL security data to installed RPMs を参照してください。

7.8. Clair アップデーター URL

以下は、Clair がデフォルト設定で対話を試みる HTTP ホストおよびパスです。一部のサーバーではリダイレクトが実行されたり、一部の要求 URL は動的に構築されるため、この一覧はすべてを網羅している訳ではありません。

  • https://secdb.alpinelinux.org/
  • http://repo.us-west-2.amazonaws.com/2018.03/updates/x86_64/mirror.list
  • https://cdn.amazonlinux.com/2/core/latest/x86_64/mirror.list
  • https://www.debian.org/security/oval/
  • https://linux.oracle.com/security/oval/
  • https://packages.vmware.com/photon/photon_oval_definitions/
  • https://github.com/pyupio/safety-db/archive/
  • https://catalog.redhat.com/api/containers/
  • https://www.redhat.com/security/data/
  • https://support.novell.com/security/oval/
  • https://people.canonical.com/~ubuntu-security/oval/

7.9. 追加情報

マイクロサービスを構成する方法などの、Clair の内部についての詳細は、アップストリームの Clair および ClairCore ドキュメントを参照してください。

第8章 コンテナーセキュリティー Operator での Pod イメージのスキャン

Container Security Operator (CSO) を使用すると、既知の脆弱性について OpenShift(4.2 以降)および他の Kubernetes プラットフォームで実行されるアクティブな Pod に関連付けられたコンテナーイメージをスキャンできます。CSO:

  • すべての namespace または指定された namespace の Pod に関連付けられたコンテナーを監視します。
  • イメージのレジストリーがイメージスキャンをサポートしている場合(例: Clair スキャンを含む Quay レジストリー)、脆弱性の情報についてコンテナーの出所となったコンテナーレジストリーをクエリーします。
  • Kubernetes API の ImageManifestVuln オブジェクトを使用して脆弱性を公開します。

この手順を使用すると、CSO は marketplace-operators namespace にインストールされ、OpenShift クラスターのすべての namespace で利用可能になります。

注記

CSO を Kubernetes にインストールする手順を表示するには、Container Security OperatorHub.io ページから「Install」ボタンを選択します。

8.1. OpenShift での CSO の実行

OpenShift で CSO の使用を開始するには、以下を実行します。

  1. Operators → OperatorHub(「Security」を選択します)に移動し、利用可能な Container Security Operator を表示します。
  2. Container Security Operator を選択し、Install を選択して 「Create Operator Subscription」ページに移動します。
  3. 設定(デフォルトではすべての namespace および自動承認ストラテジー)をチェックし、「Subscribe」を選択します。Container Security は、Installed Operators 画面に数分後に表示されます。
  4. オプションで、カスタム証明書を CSO に追加できます。以下の例では、現在のディレクトリーに quay.crt という名前の証明書を作成します。その後、次のコマンドを実行して、CSO に証明書を追加します (新しい証明書を有効にするために、Operator Pod を再起動します)。

    $ oc create secret generic container-security-operator-extra-certs --from-file=quay.crt -n openshift-operators
  5. OpenShift Dashboard を開きます (Home → Dashboards)。「Image Security」へのリンクが status セクションに表示され、これまでに見つかった脆弱性の数の一覧が表示されます。以下の図のように、リンクを選択してセキュリティーの内訳を表示します。

    Access SCO scanning data from OpenShift dashboard

  6. この時点で、検出された脆弱性をフォローするために以下の 2 つのいずれかの操作を実行できます。

    • 脆弱性へのリンクを選択します。コンテナーを取得したコンテナーレジストリー、Red Hat Quay または他のレジストリーにアクセスし、脆弱性についての情報を確認できます。以下の図は、Quay.io レジストリーから検出された脆弱性の例を示しています。

      The CSO points you to a registry containing the vulnerable image

    • namespaces リンクを選択し、ImageManifestVuln 画面に移動します。ここでは、選択されたイメージの名前、およびイメージが実行されているすべての namespace を確認できます。以下の図は、特定の脆弱なイメージが 2 つの namespace で実行されていることを示しています。

      View namespaces a vulnerable image is running in

この時点では、脆弱性のあるイメージや、イメージの脆弱性を解決するために必要なこと、およびイメージが実行されたすべての namespace を確認できます。以下を実行することができます。

  • 脆弱性を修正する必要のあるイメージを実行しているユーザーに警告します。
  • (イメージが置かれている Pod を起動したデプロイメントまたは他のオブジェクトを削除して) イメージの実行を停止します。

Pod を削除すると、Dashboard で脆弱性のある状態がリセットされるまで数分かかる場合があります。

8.2. CLI でのイメージ脆弱性のクエリー

コマンドラインからセキュリティーに関する情報をクエリーできます。検出された脆弱性を照会するには、次のように入力します。

$ oc get vuln --all-namespaces
NAMESPACE     NAME              AGE
default       sha256.ca90...    6m56s
skynet        sha256.ca90...    9m37s

特定の脆弱性の詳細を表示するには、脆弱性の 1 つを特定し、その名前空間および describe オプションを指定します。以下の例は、イメージに脆弱性のある RPM パッケージが含まれるアクティブなコンテナーを示しています。

$ oc describe vuln --namespace mynamespace sha256.ac50e3752...
Name:         sha256.ac50e3752...
Namespace:    quay-enterprise
...
Spec:
  Features:
    Name:            nss-util
    Namespace Name:  centos:7
    Version:         3.44.0-3.el7
    Versionformat:   rpm
    Vulnerabilities:
      Description: Network Security Services (NSS) is a set of libraries...

第9章 Quay Bridge Operator を使用した OpenShift Container Platform の Red Hat Quay への統合

Quay Bridge Operator を使用すると、Red Hat Quay の統合コンテナーレジストリーを OpenShift Container Platform レジストリーに置き換えることができます。これを実行することにより、統合 OpenShift コンテナープラットフォームレジストリーは、強化された RBAC(ロールベースアクセス制御)機能を備えた可用性の高い、エンタープライズレベルの Red Hat Quay レジストリーになります。

Quay Bridge Operator の主な目標は、統合された OpenShift Container Platform レジストリーの機能を新しい Red Hat Quay レジストリーに複製することです。Quay Bridge Operator で有効になる機能は次のとおりです。

  • OpenShift Container Platform namespace を Red Hat Quay 組織として同期します。
  • 各デフォルト namespace サービスアカウント用のロボットアカウントの作成。
  • 作成された各ロボットアカウントのシークレットの作成 (各ロボットシークレットを Mountable Image Pull Secret としてサービスアカウントに関連付ける)
  • OpenShift Container Platform イメージストリームを Red Hat Quay リポジトリーとして同期します。
  • Red Hat Quay への出力に ImageStream を使用した新規ビルドの自動再作成
  • ビルド完了後の image stream タグの自動インポート

以下の手順を使用することにより、Red Hat Quay と OpenShift Container Platform クラスター間の双方向通信を有効にします。

9.1. Quay Bridge Operator 用の Red Hat Quay のセットアップ

この手順では、専用の Red Hat Quay 組織を作成し、その組織内で作成された新しいアプリケーションから、OpenShift Container Platform の OpenShift Container Platform で使用される OAuth トークンを生成します。

手順

  1. WebUI を介して Red Hat Quay にログインします。
  2. 外部アプリケーションを設定する組織を選択します。
  3. ナビゲーションペインで、Applications を選択します。
  4. Create New Application を選択し、新規アプリケーションの名前を入力します (例: openshift)。
  5. OAuth Applications ページで、アプリケーション (openshift など) を選択します。
  6. ナビゲーションペインで、Generate Token を選択します。
  7. 次のフィールドを選択します。

    • Administer Organization
    • Administer Repositories
    • Create Repositories
    • View all visible repositories
    • Read/Write to any accessible repositories
    • Administer User
    • Read User Information
  8. 割り当てられた権限を確認します。
  9. Authorize Application を選択し、Authorize Application を選択して認証を確認します。
  10. 生成されたアクセストークンを保存します。

    重要

    Red Hat Quay 3.7 の時点では、トークン管理はありません。トークンを一覧表示したり、トークンを削除したり、トークンを変更したりすることはできません。生成されたアクセストークンは 1 回だけ表示され、ページを閉じた後に再取得することはできません。

9.2. OpenShift Container Platform への OpenShift Container Platform のインストール

この手順では、Quay Bridge Operator を OpenShift Container Platform にインストールします。

前提条件

  • Red Hat Quay をセットアップし、アクセストークンを取得した。
  • クラスター管理者権限を持っている OpenShift Container Platform 4.6 の環境。

手順

  1. Web コンソールの Administrator パースペクティブを開き、ナビゲーションペインで OperatorOperatorHub に移動します。
  2. Quay Bridge Operator を検索し、Quay Bridge Operator のタイトルをクリックして、Install をクリックします。
  3. インストールするバージョン (たとえば、stable-3.7) を選択し、Install をクリックします。
  4. インストールが完了したら、View Operator をクリックして、Quay Bridge Operator の Details ページに移動します。または、Installed OperatorsRed Hat Quay Bridge Operator をクリックして、Details ページに移動することもできます。

9.3. OAuth トークンの OpenShift Container Platform シークレットの作成

この手順では、以前に取得したアクセストークンを追加して、Red Hat Quay デプロイメントと通信します。アクセストークンは、OpenShift Container Platform 内にシークレットとして保存されます。

前提条件

  • Red Hat Quay をセットアップし、アクセストークンを取得しました。
  • OpenShift Container Platform に OpenShift Container Platform をデプロイしました。
  • クラスター管理者権限を持っている OpenShift Container Platform 4.6 の環境。
  • OpenShift CLI (oc) がインストールされている。

手順

  • openshift-operators namespace にアクセストークンを含むシークレットを作成します。

    $ oc create secret -n openshift-operators generic <secret-name> --from-literal=token=<access_token>

9.4. QuayIntegration カスタムリソースの作成

この手順では、QuayIntegration カスタムリソースを作成します。これは、Web コンソールまたはコマンドラインから実行できます。

前提条件

  • Red Hat Quay をセットアップし、アクセストークンを取得しました。
  • OpenShift Container Platform に OpenShift Container Platform をデプロイしました。
  • クラスター管理者権限を持っている OpenShift Container Platform 4.6 の環境。
  • オプション: OpenShift CLI (oc) をインストールしました。

9.4.1. オプション: CLI を使用して QuayIntegration カスタムリソースを作成する

この手順に従って、コマンドラインを使用して QuayIntegration カスタムリソースを作成します。

手順

  1. quay-integration.yaml を作成します:

    $ touch quay-integration.yaml
  2. QuayIntegration カスタムリソースの最小限のデプロイメントには、次の設定を使用します。

      apiVersion: quay.redhat.com/v1
      kind: QuayIntegration
      metadata:
        name: example-quayintegration
      spec:
        clusterID: openshift  1
        credentialsSecret:
          namespace: openshift-operators
          name: quay-integration2
        quayHostname: https://<QUAY_URL>   3
        insecureRegistry: false 4
    1
    clusterID の値はエコシステム全体で一意である必要があります。この値は必須であり、デフォルトは openshift です。
    2
    credentialsSecret プロパティーは、以前に作成されたトークンが含まれるシークレットの namespace および名前を参照します。
    3
    QUAY_URL を Red Hat Quay インスタンスのホスト名に置き換えます。
    4
    Red Hat Quay が自己署名証明書を使用している場合は、プロパティーを insecureRegistry: true に設定します。

    すべての設定フィールドのリストについては、QuayIntegration configuration fields を参照してください。

  3. QuayIntegration カスタムリソースを作成します。

    $ oc create -f quay-integration.yaml

9.4.2. オプション:Web コンソールを使用して QuayIntegration カスタムリソースを作成する

この手順に従って、Web コンソールを使用して QuayIntegration カスタムリソースを作成します。

手順

  1. Web コンソールの Administrator パースペクティブを開き、OperatorsInstalled Operators に移動します。
  2. Red Hat Quay Bridge Operator をクリックします。
  3. Quay Bridge Operator の Details ページで、Quay Integration API カードの Create Instance をクリックします。
  4. Create QuayIntegration ページで、Form view または YAML view のいずれかに以下の必須情報を入力します。

    • Name: QuayIntegration カスタムリソースオブジェクトを参照する名前。
    • Cluster ID: このクラスターに関連付けられている ID。この値は、エコシステム全体で一意である必要があります。指定しない場合、デフォルトで openshift になります。
    • Credentials secret: 以前に作成されたトークンを含むシークレットの名前空間と名前を参照します。
    • Quay hostname: Quay レジストリーのホスト名。

      すべての設定フィールドのリストについては、QuayIntegration configuration fields を参照してください。

QuayIntegration カスタムリソースが作成されると、OpenShift Container Platform クラスターが Red Hat Quay インスタンスにリンクされます。Red Hat Quay レジストリー内の組織は、OpenShift Container Platform 環境の関連する namespace 用に作成する必要があります。

9.5. QuayIntegration 設定フィールド

QuayIntegration カスタムリソースでは、次の設定フィールドを使用できます。

名前説明スキーマ

allowlistNamespaces
(オプション)

含める namespace のリスト。

アレイ

clusterID
(必須)

このクラスターに関連付けられている ID。

文字列

credentialsSecret.key
(必須)

Quay レジストリーと通信するための資格情報を含む秘密。

オブジェクト

denylistNamespaces
(オプション)

除外する namespace のリスト。

アレイ

insecureRegistry
(オプション)

Quay レジストリーへの TLS 検証をスキップするかどうか

Boolean

quayHostname
(必須)

Quay レジストリーのホスト名。

文字列

scheduledImageStreamImport
(Optional)

イメージストリームのインポートを有効にするかどうか。

Boolean

第10章 リポジトリーのミラーリング

10.1. リポジトリーのミラーリング

Red Hat Quay リポジトリーミラーリングを使用すると、外部コンテナーレジストリー (または別のローカルレジストリー) から Red Hat Quay クラスターにイメージをミラーリングできます。リポジトリーミラーリングを使用すると、リポジトリー名とタグに基づいてイメージを Red Hat Quay に同期できます。

リポジトリーミラーリングが有効にされた Red Hat Quay クラスターから、以下を実行できます。

  • 外部レジストリーからミラーリングするリポジトリーを選択する。
  • 外部レジストリーにアクセスするための認証情報を追加する。
  • 同期する特定のコンテナーイメージリポジトリー名とタグを特定する。
  • リポジトリーが同期される間隔を設定する。
  • 同期の現在の状態を確認する。

ミラーリング機能を使用するには、以下を行う必要があります。

  • Red Hat Quay 設定でリポジトリーのミラーリングを有効にします。
  • リポジトリーミラーリングワーカーを実行します。
  • ミラーリングされたリポジトリーを作成します。

すべてのリポジトリーミラーリングの設定は、コンフィグレーションツールの UI または Red Hat Quay API を使用して行うことができます。

10.2. リポジトリーのミラーリングと geo レプリケーションの比較

Red Hat Quay の geo レプリケーションは、データベースが共有されている間に、2 つ以上の異なるストレージバックエンド間でイメージストレージのバックエンドデータ全体をミラーリングします(2 つの異なる blob ストレージエンドポイントを持つ 1 つの Red Hat Quay レジストリー)。geo レプリケーションの主なユースケースは以下のとおりです。

  • 地理的に分散する設定向けのバイナリー Blob へのアクセスのスピードアップ
  • イメージのコンテンツがリージョン全体で同じであることを保証する

リポジトリーのミラーリングは、選択されたリポジトリー(またはリポジトリーのサブセット)をあるレジストリーから別のレジストリーに同期します。レジストリーは固有であり、各レジストリーには個別のデータベースおよび個別のイメージストレージがあります。ミラーリングの主なユースケースは、以下のとおりです。

  • 異なるデータセンターまたはリージョンでの独立したレジストリーのデプロイメント。ここでは、すべてのコンテンツの特定のサブセットがデータセンター/リージョン間で共有されることになっています。
  • 外部レジストリーからローカル Red Hat Quay デプロイメントへの選択された (ホワイトリスト化された) アップストリームリポジトリーの自動同期またはミラーリング。
注記

リポジトリーのミラーリングと geo レプリケーションを同時に使用できます。

表10.1 Red Hat Quay リポジトリーのミラーリングと Geo レプリケーションの比較

機能と性能Geo レプリケーションリポジトリーのミラーリング

設計されている機能

共有される、グローバルレジストリー

個別の異なるレジストリー

レプリケーションまたはミラーリングが完了しないとどうなるか?

リモートコピーが使用される (スピードが遅くなる)。

イメージは提供されない。

両方のリージョンのすべてのストレージバックエンドへのアクセスが必要か?

Yes (すべての Red Hat Quay ノード)

No (個別のストレージ)

ユーザーは両方のサイトから同じリポジトリーにイメージをプッシュできるか?

Yes

No

すべてのレジストリーのコンテンツと設定はすべてのリージョンで同一か (共有データベース)?

Yes

No

ユーザーはミラーリングする個別の namespace またはリポジトリーを選択できるか?

ユーザーはフィルターを同期ルールに適用できるか?

No

各リージョンで許可されている個別/異なる RBAC 設定か?

Yes

10.3. リポジトリーミラーリングの使用

ここでは、Red Hat Quay リポジトリーミラーリングの機能と制限について説明します。

  • リポジトリーのミラーリングでは、リポジトリー全体をミラーリングしたり、同期するイメージを選択的に制限したりできます。フィルターは、タグのコンマ区切りの一覧、タグの範囲、または正規表現でタグを特定する他の方法によります。
  • ミラーリングされたリポジトリーとして設定されると、そのリポジトリーに他のイメージを手動で追加することはできません。
  • ミラーリングされたリポジトリーは設定するリポジトリーとタグをベースとするため、そのリポジトリー/タグのペアで表されるコンテンツのみを保持します。つまり、リポジトリーの一部のイメージがこれ以上一致しないようにタグを変更すると、これらのイメージは削除されます。
  • 指定されたロボットのみがイメージをミラーリングされたリポジトリーにプッシュでき、これはリポジトリーに設定されたロールベースのアクセス制御パーミッションよりも優先されます。
  • ミラーリングされたリポジトリーを使用すると、ユーザーはリポジトリーからイメージをプルできますが (読み取りパーミッションが付与される)、イメージをリポジトリーにプッシュすることはできません。
  • ミラーリングされたリポジトリーの設定の変更は、作成するミラーリングされたリポジトリーの Repositories → Mirrors タブを使用して Red Hat Quay UI で実行できます。
  • イメージは設定される間隔で同期されますが、随時必要に応じて同期することもできます。

10.4. 設定のミラーリング UI

  1. 設定モードで Quay コンテナーを起動し、Enable Repository Mirroring チェックボックスを選択します。HTTPS 通信を必要とし、ミラーリング時に証明書を検証する必要がある場合は、HTTPS を選択し、証明書の検証のチェックボックスを選択します。

    Enable mirroring and require HTTPS and verified certificates

  2. configuration を検証し、ダウンロードしてから、更新された設定ファイルを使用してレジストリーモードで Quay を再起動します。

10.5. 設定フィールドのミラーリング

表10.2 ミラーリング設定

フィールドタイプ説明

FEATURE_REPO_MIRROR

Boolean

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

デフォルト: false

 

 

 

REPO_MIRROR_INTERVAL

数値

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

REPO_MIRROR_SERVER_HOSTNAME

文字列

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

デフォルト: None

:
openshift-quay-service

REPO_MIRROR_TLS_VERIFY

Boolean

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

デフォルト: false

10.6. ミラーリングワーカー

  • リポジトリーのミラーリングワーカーを実行するには、repomirror オプションを指定して Quay Pod を起動します。

    $ sudo podman run -d --name mirroring-worker \
      -v $QUAY/config:/conf/stack:Z \
      registry.redhat.io/quay/quay-rhel8:v3.7.3 repomirror
  • 証明書 /root/ca.crt を使用して TLS 通信を設定している場合、以下の例ではミラーリングワーカーの起動方法を示します。

    $ sudo podman run -d --name mirroring-worker \
      -v $QUAY/config:/conf/stack:Z \
      -v /root/ca.crt:/etc/pki/ca-trust/source/anchors/ca.crt \
      registry.redhat.io/quay/quay-rhel8:v3.7.3 repomirror

10.7. ミラーリングされたリポジトリーの作成

以下のセクションで説明する手順は、Red Hat Quay クラスターの設定でリポジトリーのミラーリングが有効にされており、リポジトリーミラーリングワーカーをデプロイしていることを前提としています。

外部コンテナーレジストリーからリポジトリーをミラーリングする場合は、新しいプライベートリポジトリーを作成します。通常、ターゲットリポジトリーと同じ名前が使用されます (例: quay-rhel8)。

Create new Red Hat Quay repo

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

  1. Settings タブで、Repository State を Mirror に設定します。

    Create a new Red Hat Quay repo mirror

  2. Mirror タブで、タグ、スケジューリング、およびアクセス情報と共に外部レジストリーに接続するための情報を入力します。

    Repository mirroring

  3. 必要に応じて、以下のフィールドに詳細を入力します。

    • Registry Location: ミラーリングする外部リポジトリー (例: registry.redhat.io/quay/quay-rhel8)。
    • Tags: このフィールドは必須です。個別のタグまたはタグパターンのコンマ区切りの一覧を入力できます。(詳細は、「タグパターン」のセクションを参照してください)。

      注記

      Quay がリモートリポジトリーのタグの一覧を取得するには、以下のいずれかの要件を満たす必要があります。

      • 「latest」タグのあるイメージがリモートリポジトリー OR に存在している必要があります
      • パターンの一致のない少なくとも 1 つの明示的なタグが、指定するタグの一覧に存在する必要があります。
    • Start Date: ミラーリングが開始する日付。現在の日時がデフォルトで使用されます。
    • Sync Interval: デフォルトで 24 時間ごとの同期に設定されます。これは時間または日に基づいて変更できます。
    • Robot User: 新しい robot アカウントを作成するか、または既存の robot アカウントを選択してミラーリングを実行します。
    • Username: ミラーリングするリポジトリーを保持する外部レジストリーにアクセスするためのユーザー名。
    • Password: ユーザー名に関連付けられたパスワード。パスワードにはエスケープ文字 (\) を必要とする文字を含めることができないことに注意してください。

10.7.2. 詳細設定

  • Advanced Settings セクションで、必要な場合は TLS およびプロキシーを設定します。
  • Verify TLS: ターゲットリモートレジストリーと通信する際に、HTTPS が必要であり、証明書を検証する必要がある場合にこのボックスにチェックを付けます。
  • HTTP Proxy: リモートサイトへのアクセスに必要な HTTP プロキシーサーバーを特定します (必要な場合)。
  • HTTP Proxy: リモートサイトへのアクセスに必要な HTTPS プロキシーサーバーを特定します (必要な場合)。
  • No Proxy: プロキシーを必要としない場所の一覧。

10.7.3. 今すぐ同期する

  • 即時にミラーリング操作を実行するには、リポジトリーの Mirroring タブで Sync Now ボタンを押します。ログは、Usage Logs タブで利用できます。

    Usage logs

    ミラーリングが完了すると、イメージは Tags タブに表示されます。

    Repository mirroring tags

    以下は、完了した Repository Mirroring 画面の例です。

    Repository mirroring details

10.8. ミラーリングのイベント通知

リポジトリーミラーリングには、3 つの通知イベントがあります。

  • リポジトリーミラーリングの開始
  • リポジトリーのミラーリングの成功
  • リポジトリーミラーリングの失敗

イベントの設定は、各リポジトリーの Settings タブ内で行うことができ、メール、slack、Quay UI、Web フックなど、既存のすべての通知方法に対応しています。

10.9. タグパターンのミラーリング

上述のように、少なくとも 1 つのタグが明示的に入力されている (つまりタグパターンではない)、または タグ latest がレポートリポジトリーに存在している必要があります。(タグ「latest」はタグの一覧に指定されていない限り同期されません)。これは、Quay でミラーリングに使用する指定の一覧との比較用にリモートリポジトリーでタグ一覧を取得するために必要です。

10.9.1. パターン構文

パターン

説明

*

すべての文字に一致します。

?

任意の 1 文字に一致します。

[seq]

seq の任意の文字と一致します。

[!sEQ]

seq にない文字と一致します。

10.9.2. タグのパターン例

パターン例

一致例

v3*

v32、v3.1、v3.2、v3.2-4beta、v3.3

v3.*

v3.1、v3.2、v3.2-4beta

v3.?

v3.1、v3.2、v3.3

v3.[12]

v3.1、v3.2

v3.[12]*

v3.1、v3.2、v3.2-4beta

v3.[!1]*

v3.2、v3.2-4beta、v3.3

10.10. ミラーリングされたリポジトリーの使用

ミラーリングされたリポジトリーの作成後は、そのリポジトリーを使用する複数の方法を実行できます。「Repositories」ページからミラーリングされたリポジトリーを選択し、以下のいずれかを行います。

  • リポジトリーの有効化/無効化: 左列の「Mirroring」ボタンを選択してから「Enabled」チェックボックスを切り替え、一時的にリポジトリーを有効または無効にします。
  • ミラーログの確認: ミラーリングされたリポジトリーが適切に機能していることを確認するために、ミラーログを確認できます。これを実行するには、左側の列の「Usage Logs」ボタンを選択します。以下に例を示します。

    View logs for your Red Hat Quay repo mirror

  • 今すぐミラー同期を実行する: リポジトリーのイメージをすぐに同期するには、「Sync Now」ボタンを選択します。
  • 認証情報の変更: ユーザー名およびパスワードを変更するには、「Credentials」行で「DELETE」を選択します。次に、「None」を選択し、プロンプトが出されたら外部レジストリーにログインするために必要なユーザー名およびパスワードを追加します。
  • ミラーリングの取り消し: ミラーリングを停止する (現在利用できるイメージを維持しながら新しいイメージが同期されないようにする) には、「CANCEL」ボタンを選択します。
  • ロボットパーミッションの設定: Red Hat Quay ロボットアカウントには、外部リポジトリーにアクセスするために認証情報を保持するトークンが指定されます。ロボットに認証情報を割り当てることで、そのロボットを同じ外部レジストリーにアクセスする必要のある複数のミラーリングされたリポジトリーで使用することができます。

    「Account Settings」に移動し、左側の列の 「Robot Accounts」アイコンを選択して、既存のロボットをリポジトリーに割り当てることができます。ロボットアカウントには、「REPOSITORIES」列にあるリンクを選択します。ポップアップウィンドウから、以下を行うことができます。

    • そのロボットに割り当てられているリポジトリーを確認します。
    • この図に示されている「PERMISSION」フィールドから対象のロボットに読み取り、書き込み、または管理者権限を割り当てます。 Assign a robot to mirrored repo
  • ロボット認証情報の変更: ロボットは、Kubernetes シークレット、Docker ログイン情報、および Mesos バンドルなどの認証情報を保持できます。ロボットの認証情報を変更するには、「Robot Accounts」ウインドウのロボットのアカウント行にある「Options」歯車を選択し、「View Credentials」を選択します。ロボットがアクセスする必要のある外部リポジトリーの適切な認証情報を追加します。

    Assign permission to a robot

  • 一般的な設定の確認および変更: ミラーリングされたリポジトリーページの左側の列から「Settings」ボタン (歯車アイコン) を選択します。生成されるページでは、ミラーリングされたリポジトリーに関連付けられた設定を変更することができます。特に、ユーザーやロボットのパーミッションを変更して、どのユーザーやロボットがレポジトリーを読み書きできるかを正確に指定することができます。

10.11. リポジトリーのミラーリングの推奨事項

リポジトリーミラーリングのベストプラクティスには、以下が含まれます。

  • リポジトリーミラーリング Pod は任意のノードで実行できます。つまり、Red Hat Quay がすでに実行されているノードでミラーリングを実行することもできます。
  • リポジトリーのミラーリングは、データベースでスケジュールされ、一括して実行されます。その結果、ワーカーが増えれば、より多くのバッチが処理されるため、ミラーリングが速くなる可能性があります。
  • ミラーリング Pod の最適な数は、以下の要素により変わります。

    • ミラーリングされるリポジトリーの合計数
    • リポジトリー内のイメージやタグの数と変更の頻度
    • 並列バッチ
  • すべてのミラーリングされたリポジトリーが同時に起動しないように、ミラーリングのスケジュールをバランスよく設定する必要があります。
  • ユーザー数が約 1000 人、リポジトリー数が約 1000 個、ミラーリングされたリポジトリー数が約 100 個の中規模のデプロイメントでは、3 ~ 5 個のミラーリング Pod を使用し、必要に応じて 10 Pod にスケールアップすることを想定しています。

第11章 Red Hat Quay の LDAP 認証設定

LDAP (Lightweight Directory Access Protocol) は、インターネットプロトコル (IP) ネットワークで分散ディレクトリー情報サービスにアクセスし、これを維持するために使用するオープンな、ベンダーに依存しない業界標準のアプリケーションプロトコルです。Red Hat Quay は ID プロバイダーとして LDAP の使用をサポートしています。

11.1. LDAP を有効にする前の考慮事項

11.1.1. 既存の Quay デプロイメント

ユーザーがすでに設定されている既存の Quay デプロイメントで LDAP を有効にすると、ユーザー名との競合が発生する可能性があります。LDAP を有効にする前に、Quay で特定のユーザー alice を手動作成したシナリオを考慮してください。ユーザー名 alice が LDAP ディレクトリーにも存在する場合に、alice が LDAP を使用して初回ログインしたときに、Quay は新規ユーザー alice-1 を作成し、LDAP 認証情報をこのアカウントにマップします。これは、整合性の理由から望ましくない可能性があり、LDAP を有効にする前に、Quay からローカルのアカウント名で競合する可能性のある名前を削除することを推奨します。

11.1.2. 手動ユーザーの作成と LDAP 認証

Quay が LDAP 用に設定されていて、設定オプション FEATURE_USER_CREATIONtrue に設定されている場合は、LDAP 認証ユーザーが最初のログイン時に Quay のデータベースに自動的に作成されます。このオプションを false に設定すると、LDAP ユーザーの自動ユーザー作成に失敗し、ユーザーはログインできません。このシナリオでは、スーパーユーザーが最初に必要なユーザーアカウントを作成する必要があります。一方、FEATURE_USER_CREATIONtrue に設定されている場合は、LDAP に同等のユーザーがある場合でも、ユーザーは Quay ログイン画面からもアカウントを作成できます。

11.2. LDAP の設定

設定ツールで、「Authentication」セクションを見つけ、ドロップダウンメニューから「LDAP」を選択します。必要に応じて LDAP 設定フィールドを更新します。

Fill in LDAP information

  • 以下は、config.yaml ファイルの結果としてのエントリの例です。
AUTHENTICATION_TYPE: LDAP

11.2.1. 完全な LDAP URI

LDAP server URI LDAP server SSL

  • ldap:// または ldaps:// プレフィックスが含まれる完全な LDAP URI。
  • ldaps:// で始まる URI は、TLS 設定に指定される SSL 証明書を使用します。
  • 以下は、config.yaml ファイルの結果としてのエントリの例です。
LDAP_URI: ldaps://ldap.example.org

11.2.2. チームシンクロナイゼーション

Team synchronization

  • 有効にすると、スーパーユーザーでもある組織管理者は、チームをメンバーシップが LDAP のバッキンググループと同期するように設定できます。

Team synchronization

  • 再同期の期間は、チームを再同期する必要のある期間です。期間の文字列の形式 30m、1h、1d で表記する必要があります。
  • オプションで、スーパーユーザー以外のユーザーは、自らが管理者である組織でチームの同期を有効にし、管理することができます。
  • 以下は、config.yaml ファイルの結果としてのエントリーの例です。
FEATURE_TEAM_SYNCING: true
TEAM_RESYNC_STALE_TIME: 60m
FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP: true

11.2.3. ベースおよび相対的な区別された名前

Distinguished Names

  • 識別名パスはすべての LDAP レコードを検索するためのベースパスを構成します。例: dc=my,dc=domain,dc=com
  • 識別名パスのオプションの一覧は、上記で定義されたベース DN と関連して、すべてのユーザー LDAP レコードを検索するためのセカンダリーベースパスを構成します。ユーザーがプライマリーの相対 DN で見つからない場合に、これらのパスが試行されます。
  • ユーザーの相対 DN は BaseDN に相対します。例: ou=NYC not ou=NYC,dc=example,dc=org
  • ユーザーオブジェクトが置かれている組織単位が複数ある場合に、複数の「セカンダリーユーザー相対 DN」を入力します。組織単位に入力して「Add」ボタンをクリックし、複数の RDN (相対 DN) を追加します。例: ou=Users,ou=NYC and ou=Users,ou=SFO
  • 「ユーザー相対 DN」では、サブツリーの範囲を指定して検索します。たとえば、組織に「Users OU」下に組織単位 NYC および SFO がある場合 (ou=SFO,ou=Users および ou=NYC,ou=Users)、Red Hat Quay は、ユーザー相対 DN がユーザーに設定されている場合 (ou=Users)、 NYC および SFO 組織単位のどちらのユーザーも認証できます。
  • 以下は、config.yaml ファイルの結果としてのエントリーの例です。
LDAP_BASE_DN:
- dc=example
- dc=com
LDAP_USER_RDN:
- ou=users
LDAP_SECONDARY_USER_RDNS:
- ou=bots
- ou=external

11.2.4. ユーザーフィルターの追加

User filters

  • 指定されている場合は、すべてのユーザー検索クエリーに使用される追加のフィルターになります。フィルターで使用されるすべての識別名は 完全 パスである必要があることに注意してください。ベース DN は自動的に追加されません。括弧でラップする 必要があります。例: (&(someFirstField=someValue)(someOtherField=someOtherValue))
  • 以下は、config.yaml ファイルの結果としてのエントリの例です。
LDAP_USER_FILTER: (memberof=cn=developers,ou=groups,dc=example,dc=com)

11.2.5. 管理者 DN

Administrator DN

  • 管理者アカウントの識別名およびパスワード。このアカウントは、すべてのユーザーアカウントのレコードにログインし、表示できる必要があります。例: uid=admin,ou=employees,dc=my,dc=domain,dc=com
  • パスワードは config.yaml 内の プレーンテキスト に保管されるため、専用のアカウントを設定するか、またはパスワードハッシュを使用することが推奨されます。
  • 以下は、config.yaml ファイルの結果としてのエントリーの例です。
LDAP_ADMIN_DN: cn=admin,dc=example,dc=com
LDAP_ADMIN_PASSWD: changeme

11.2.6. UID およびメール属性

UID and Mail

  • UID 属性は、username として使用する LDAP ユーザーレコードのプロパティーフィールドの名前です。通常は「uid」です。
  • Mail 属性は、ユーザーのメールアドレスを保存する LDAP ユーザーレコードのプロパティーフィールドの名前です。通常は「mail」です。
  • これらはいずれもログイン時に使用できます。
  • ログインしたユーザー名は「User Relative DN」(ユーザー相対 DN) に存在する必要があります。
  • sAMAccountName は、Microsoft Active Directory 設定に対する UID 属性です。
  • 以下は、config.yaml ファイルの結果としてのエントリーの例です。
LDAP_UID_ATTR: uid
LDAP_EMAIL_ATTR: mail

11.2.7. 検証

設定が完了したら、「Save Configuration Changes」ボタンをクリックして設定を検証します。

Fill in LDAP information

すべての検証を正常に実行したから続行する必要があります。または、「Continue Editing」ボタンを選択して追加の設定を実行することができます。

11.3. 一般的な問題

無効な認証情報

管理者 DN または管理者 DN パスワードの値が正しくありません。

スーパーユーザー %USERNAME% の検証が失敗する: ユーザーが見つかりません。ユーザーはリモート認証システムに存在しないか、または LDAP 認証の設定が正しくありません。

Red Hat Quay は、「Administrator DN」フィールドに指定された Username/Password を使用して LDAP サーバーに接続できますが、「User Relative DN Path」の「UID Attribute」または「Mail Attribute」フィールドで現在ログインしているユーザーを見つけることはできません。現在ログインしているユーザーが「User Relative DN Path」に存在しないか、または管理者 DN ユーザーにこの LDAP パスの検索/読み取り権限がありません。

11.4. LDAP ユーザーをスーパーユーザーとして設定する

LDAP が設定されたら、有効な LDAP のユーザー名およびパスワードを使用して Red Hat Quay インスタンスにログインすることができます。以下の図のように、Red Hat Quay のユーザー名を確認することを求めるプロンプトが出されます。

Confirm LDAP username for Red Hat Quay

LDAP ユーザーにスーパーユーザー権限を割り当てるには、config.yaml ファイルをユーザー名で変更します。以下は例になります。

SUPER_USERS:
- testadmin

更新された config.yaml ファイルを使用して Red Hat Quay コンテナーを再起動します。次回のログイン時には、そのユーザーはスーパーユーザーの権限を持つことになります。

第12章 Red Hat Quay の Prometheus および Grafana メトリクス

Red Hat Quay は、各インスタンスで Prometheus および Grafana 互換エンドポイントをエクスポートし、モニターおよびアラートを容易にします。

12.1. Prometheus エンドポイントの公開

12.1.1. スタンドアロン Red Hat Quay

podman run を使用して Quay コンテナーを起動する場合は、メトリクスポート 9091 を公開します。

$ sudo podman run -d --rm -p 80:8080 -p 443:8443  -p 9091:9091\
   --name=quay \
   -v $QUAY/config:/conf/stack:Z \
   -v $QUAY/storage:/datastorage:Z \
   registry.redhat.io/quay/quay-rhel8:v3.7.3

これでメトリクスが利用可能になります。

$ curl quay.example.com:9091/metrics

Quay のリポジトリーカウントを監視するための Prometheus および Grafana の設定については、Monitoring Quay with Prometheus and Grafana を参照してください。

12.1.2. Red Hat Quay Operator

quay-metrics サービスのクラスター IP を判別します。

$ oc get services -n quay-enterprise
NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                             AGE
example-registry-clair-app            ClusterIP   172.30.61.161    <none>        80/TCP,8089/TCP                     18h
example-registry-clair-postgres       ClusterIP   172.30.122.136   <none>        5432/TCP                            18h
example-registry-quay-app             ClusterIP   172.30.72.79     <none>        443/TCP,80/TCP,8081/TCP,55443/TCP   18h
example-registry-quay-config-editor   ClusterIP   172.30.185.61    <none>        80/TCP                              18h
example-registry-quay-database        ClusterIP   172.30.114.192   <none>        5432/TCP                            18h
example-registry-quay-metrics         ClusterIP   172.30.37.76     <none>        9091/TCP                            18h
example-registry-quay-redis           ClusterIP   172.30.157.248   <none>        6379/TCP                            18h

クラスターに接続し、quay-metrics サービスのクラスター IP およびポートを使用してメトリクスにアクセスします。

$ oc debug node/master-0

sh-4.4# curl 172.30.37.76:9091/metrics

# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 4.0447e-05
go_gc_duration_seconds{quantile="0.25"} 6.2203e-05
...

12.1.3. Prometheus がメトリクスを消費するための設定

Prometheus では、クラスターで実行されているすべての Red Hat Quay インスタンスにアクセスできるようにする必要があります。通常の設定では、これは単一の named DNS エントリーの Red Hat Quay インスタンスの一覧 (これは Prometheus に渡されます) を表示して実行します。

12.1.4. Kubernetes での DNS 設定

シンプルな Kubernetes service を設定して、Prometheus の DNS エントリーを提供することができます。

12.1.5. 手動クラスターの DNS 設定

SkyDNS は、 Kubernetes を使用していない場合にこの DNS レコードを管理するための単純なソリューションです。SkyDNS は etcd クラスター上で実行できます。クラスターの各 Red Hat Quay インスタンスのエントリーは etcd ストアで追加および削除できます。SkyDNS はそこから定期的に読み込んで、それに応じて DNS レコードの Quay インスタンスのリストを更新します。

12.2. メトリクスの概要

Red Hat Quay には、一般的なレジストリーの使用、アップロード、ダウンロード、ガベージコレクション、および認証についてのメトリクスなど、レジストリーの監視に役立つメトリクスが同梱されています。

12.2.1. 一般レジストリーの統計

一般的なレジストリー統計で、どの程度レジストリーが拡大しているかが分かります。

メトリクス名説明

quay_user_rows

データベースのユーザー数

quay_robot_rows

データベースのロボットアカウントの数

quay_org_rows

データベースの組織数

quay_repository_rows

データベースのリポジトリー数

quay_security_scanning_unscanned_images_remaining_total

最新のセキュリティースキャナーによってスキャンされないイメージの数

メトリクスの出力サンプル

# HELP quay_user_rows number of users in the database
# TYPE quay_user_rows gauge
quay_user_rows{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="65",process_name="globalpromstats.py"} 3

# HELP quay_robot_rows number of robot accounts in the database
# TYPE quay_robot_rows gauge
quay_robot_rows{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="65",process_name="globalpromstats.py"} 2

# HELP quay_org_rows number of organizations in the database
# TYPE quay_org_rows gauge
quay_org_rows{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="65",process_name="globalpromstats.py"} 2

# HELP quay_repository_rows number of repositories in the database
# TYPE quay_repository_rows gauge
quay_repository_rows{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="65",process_name="globalpromstats.py"} 4

# HELP quay_security_scanning_unscanned_images_remaining number of images that are not scanned by the latest security scanner
# TYPE quay_security_scanning_unscanned_images_remaining gauge
quay_security_scanning_unscanned_images_remaining{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 5

12.2.2. キューアイテム

キューアイテム メトリクスでは、作業管理用に Quay が使用する複数のキューに関する情報が分かります。

メトリクス名説明

quay_queue_items_available

特定のキュー内のアイテム数

quay_queue_items_locked

実行中のアイテム数

quay_queue_items_available_unlocked

処理を待機しているアイテム数

メトリックラベル

  • QUEUE_NAME: キューの名前。以下のいずれかになります。

    • exportactionlogs: アクションログをエクスポートするためのキューに追加されている要求。これらのログは処理され、ストレージに配置されます。その後、リンクがメールを介して要求元に送信されます。
    • namespacegc: キューに追加されてガベージコレクションされる namespace
    • notification: リポジトリー通知が送信されるキュー
    • repositorygc: ガベージコレクションを行うレポジトリーでキューに追加されているもの
    • secscanv4: Clair V4 に固有の通知キュー
    • dockerfilebuild: Quay docker ビルドのキュー
    • imagestoragereplication: 複数のストレージで複製されるようにキューに追加されている Blob
    • chunk_cleanup: 削除する必要があり、キューに追加されている Blog セグメント。これは、一部のストレージ実装 (Swift など) でのみ使用されます。

たとえば、キューラベルの repositorygc には、リポジトリーのガべージコレクションワーカーによって削除対象としてマークされたリポジトリーが含まれます。repositorygcqueue_name ラベル付きのメトリクスの場合は、以下のようになります。

  • quay_queue_items_locked は、現在削除されているリポジトリーの数です。
  • quay_queue_items_available_unlocked は、ワーカーが処理するのを待機するリポジトリーの数です。

メトリクスの出力サンプル

# HELP quay_queue_items_available number of queue items that have not expired
# TYPE quay_queue_items_available gauge
quay_queue_items_available{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="63",process_name="exportactionlogsworker.py",queue_name="exportactionlogs"} 0
...

# HELP quay_queue_items_available_unlocked number of queue items that have not expired and are not locked
# TYPE quay_queue_items_available_unlocked gauge
quay_queue_items_available_unlocked{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="63",process_name="exportactionlogsworker.py",queue_name="exportactionlogs"} 0
...

# HELP quay_queue_items_locked number of queue items that have been acquired
# TYPE quay_queue_items_locked gauge
quay_queue_items_locked{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="63",process_name="exportactionlogsworker.py",queue_name="exportactionlogs"} 0

12.2.3. ガベージコレクションメトリクス

これらのメトリクスは、ガベージコレクション (gc) から削除されたリソースの数を示します。ここでは、gc ワーカーが実行した回数と、削除された namespace、リポジトリー、および Blob の数が示されます。

メトリクス名説明

quay_gc_iterations_total

GCWorker による反復の数

quay_gc_namespaces_purged_total

NamespaceGCWorker によってパージされる namespace 数

quay_gc_repos_purged_total

RepositoryGCWorker または NamespaceGCWorker がパージするリポジトリーの数

quay_gc_storage_blobs_deleted_total

削除されたストレージ Blob の数

メトリクスの出力サンプル

# TYPE quay_gc_iterations_created gauge
quay_gc_iterations_created{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 1.6317823190189714e+09
...

# HELP quay_gc_iterations_total number of iterations by the GCWorker
# TYPE quay_gc_iterations_total counter
quay_gc_iterations_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 0
...

# TYPE quay_gc_namespaces_purged_created gauge
quay_gc_namespaces_purged_created{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 1.6317823190189433e+09
...

# HELP quay_gc_namespaces_purged_total number of namespaces purged by the NamespaceGCWorker
# TYPE quay_gc_namespaces_purged_total counter
quay_gc_namespaces_purged_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 0
....

# TYPE quay_gc_repos_purged_created gauge
quay_gc_repos_purged_created{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 1.631782319018925e+09
...

# HELP quay_gc_repos_purged_total number of repositories purged by the RepositoryGCWorker or NamespaceGCWorker
# TYPE quay_gc_repos_purged_total counter
quay_gc_repos_purged_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 0
...

# TYPE quay_gc_storage_blobs_deleted_created gauge
quay_gc_storage_blobs_deleted_created{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 1.6317823190189059e+09
...

# HELP quay_gc_storage_blobs_deleted_total number of storage blobs deleted
# TYPE quay_gc_storage_blobs_deleted_total counter
quay_gc_storage_blobs_deleted_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 0
...

12.2.3.1. マルチパートアップロードメトリクス

マルチパートアップロードメトリクスは、ストレージへの Blob アップロードの数 (S3、Raddos、GoogleCloudStorage、RHOCS) を表示します。これらは、Quay が Blob をストレージに正しくアップロードできない場合の問題を特定するのに役立ちます。

メトリクス名説明

quay_multipart_uploads_started_total

起動した Quay ストレージへのマルチパートアップロードの数

quay_multipart_uploads_completed_total

完了した Quay ストレージへのマルチパートアップロードの数

メトリクスの出力サンプル

# TYPE quay_multipart_uploads_completed_created gauge
quay_multipart_uploads_completed_created{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 1.6317823308284895e+09
...

# HELP quay_multipart_uploads_completed_total number of multipart uploads to Quay storage that completed
# TYPE quay_multipart_uploads_completed_total counter
quay_multipart_uploads_completed_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 0

# TYPE quay_multipart_uploads_started_created gauge
quay_multipart_uploads_started_created{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 1.6317823308284352e+09
...

# HELP quay_multipart_uploads_started_total number of multipart uploads to Quay storage that started
# TYPE quay_multipart_uploads_started_total counter
quay_multipart_uploads_started_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 0
...

12.2.4. イメージのプッシュ/プルのメトリクス

イメージのプッシュおよびプルに関連する数多くのメトリクスを利用できます。

12.2.4.1. イメージプルの合計

メトリクス名説明

quay_registry_image_pulls_total

レジストリーからダウンロードされたイメージの数

メトリックラベル

  • プロトコル: 使用するレジストリープロトコル (常に v2 に指定する)
  • ref: -tag マニフェストのプルに使用する ref
  • status: 要求の http 戻りコード

12.2.4.2. プルしたイメージ (バイト)

メトリクス名説明

quay_registry_image_pulled_estimated_bytes_total

レジストリーからダウンロードされたバイト数

メトリックラベル

  • プロトコル: 使用するレジストリープロトコル (常に v2 に指定する)

12.2.4.3. イメージのプッシュ合計

メトリクス名説明

quay_registry_image_pushes_total

レジストリーからアップロードされたイメージの数

メトリックラベル

  • プロトコル: 使用するレジストリープロトコル (常に v2 に指定する)
  • pstatus: 要求の http 戻りコード
  • pmedia_type: アップロードしたマニフェストタイプ

12.2.4.4. プッシュされたイメージバイト

メトリクス名説明

quay_registry_image_pushed_bytes_total

レジストリーにアップロードされたバイト数

メトリクスの出力サンプル

# HELP quay_registry_image_pushed_bytes_total number of bytes pushed to the registry
# TYPE quay_registry_image_pushed_bytes_total counter
quay_registry_image_pushed_bytes_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="221",process_name="registry:application"} 0
...

12.2.5. 認証メトリクス

認証メトリクスでは、タイプ別にラベルが付けられた認証要求の数と、成功したかどうかが分かります。たとえば、このメトリックを使用して、失敗した Basic 認証要求を監視できます。

メトリクス名説明

quay_authentication_attempts_total

レジストリーおよび API 全体で認証を試行する回数

メトリックラベル

  • auth_kind: 使用される認証のタイプ。以下が含まれます。

    • basic
    • oauth
    • credentials
  • 成功: true または false

メトリクスの出力サンプル

# TYPE quay_authentication_attempts_created gauge
quay_authentication_attempts_created{auth_kind="basic",host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="221",process_name="registry:application",success="True"} 1.6317843039374158e+09
...

# HELP quay_authentication_attempts_total number of authentication attempts across the registry and API
# TYPE quay_authentication_attempts_total counter
quay_authentication_attempts_total{auth_kind="basic",host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="221",process_name="registry:application",success="True"} 2
...

第13章 Red Hat Quay のクォータ管理および施行

Red Hat Quay 3.7 では、ユーザーは、設定されたストレージクォータ制限を確立することにより、ストレージ消費を報告し、レジストリーの増加を抑えることができます。オンプレミス Quay ユーザーには、環境の容量制限を管理するために以下の機能が追加されました。

  • クォータレポート: この機能を使用すると、スーパーユーザーはすべての組織のストレージ消費量を追跡できます。さらに、ユーザーは割り当てられた組織のストレージ消費量を追跡できます。
  • クォータ管理: この機能を使用すると、スーパーユーザーは Red Hat Quay ユーザーのソフトチェックとハードチェックを定義できます。ソフトチェックは、組織のストレージ消費量が設定されたしきい値に達しているかどうかをユーザーに通知します。ハードチェックは、ストレージ消費量が設定された制限に達したときにユーザーがレジストリーにプッシュするのを防ぎます。

これらの機能を組み合わせることで、Quay レジストリーのサービス所有者は、サービスレベル契約を定義し、健全なリソース予算をサポートできます。

13.1. クォータ管理設定

クォータ管理は FEATURE_QUOTA_MANAGEMENT プロパティーでサポートされるようになり、デフォルトでオフになっています。クォータ管理を有効にするには、config.yaml の機能フラグを true に設定します。

FEATURE_QUOTA_MANAGEMENT: true
注記

Red Hat Quay 3.7 では、クォータを作成、更新、削除するにはスーパーユーザー権限が必要です。クォータはユーザーと組織に設定できますが、Red Hat Quay UI を使用して ユーザー クォータを再設定することはできず、代わりに API を使用する必要があります。

13.1.1. デフォルトのクォータ

すべての組織およびユーザーに適用されるシステム全体のデフォルトのストレージクォータを指定するには、DEFAULT_SYSTEM_REJECT_QUOTA_BYTES 設定フラグを使用します。

表13.1 デフォルトのクォータ設定

フィールドタイプ説明

DEFAULT_SYSTEM_REJECT_QUOTA_BYTES

文字列

すべての組織およびユーザーに適用するクォータサイズ

デフォルトでは、制限は設定されていません。

組織またはユーザーに特定のクォータを設定してから、そのクォータを削除すると、システム全体のデフォルトのクォータが設定されている場合に適用されます。同様に、組織またはユーザーに特定のクォータを設定してから、システム全体のデフォルトクォータを変更した場合、更新されたシステム全体のデフォルトは特定の設定を上書きします。

13.2. クォータ管理アーキテクチャー

RepositorySize データベーステーブルは、組織内の Red Hat Quay リポジトリーのストレージ消費量をバイト単位で保持します。組織のすべてのリポジトリーサイズの合計は、Red Hat Quay 組織の現在のストレージサイズを定義します。イメージプッシュが初期化されると、ユーザーの組織ストレージが検証され、設定されたクォータ制限を超えているかどうかがチェックされます。イメージプッシュが定義されたクォータ制限を超えると、ソフトチェックまたはハードチェックが発生します。

  • ソフトチェックの場合は、ユーザーに通知されます。
  • ハードチェックの場合は、プッシュが停止します。

ストレージ消費量が設定済みのクォータ制限内にある場合は、プッシュを続行できます。

イメージマニフェストの削除も同様のフローに従い、関連するイメージタグとマニフェストの間のリンクが削除されます。さらに、イメージマニフェストが削除された後、リポジトリーサイズが再計算され、RepositorySize テーブルで更新されます。

13.3. Red Hat Quay UI でクォータの確立

次の手順では、ストレージ消費量をレポートし、ストレージクォータ制限を設定する方法を説明します。

前提条件

  • Red Hat Quay レジストリー
  • スーパーユーザーアカウント
  • クォータ制限の要求を満たすのに十分なストレージ

手順

  1. 新しい組織を作成するか、既存の組織を選択します。Organization Settings タブに表示されているように、最初はクォータが設定されていません。

    No Quota Configured

  2. スーパーユーザーとしてレジストリーにログインし、Super User Admin PanelManage Organizations タブに移動します。ストレージクォータ制限を作成する組織の Options アイコンをクリックします。

    Organization options

  3. Configure Quota をクリックして、初期クォータ (たとえば 10 MB) を入力します。次に、Apply をクリックしてから Close をクリックします。

    Initial quota

  4. スーパーユーザーパネルの Manage Organizations タブで、消費されたクォータが 10MB のうち 0 を示していることを確認します。

    Initial consumed quota

    消費されたクォータ情報は、組織ページから直接入手することもできます。

    最初に消費されたクォータ

    Initial consumed quota

  5. クォータを 100MB に増やすには、スーパーユーザーパネルの Manage Organizations タブに移動します。Options アイコンをクリックし、Configure Quota を選択して、クォータを 100 MB に設定します。Apply をクリックしてから Close をクリックします。

    Increase quota

  6. コマンドラインからサンプルイメージを組織にプッシュします。

    サンプルコマンド

    $ podman pull ubuntu:18.04
    
    $ podman tag docker.io/library/ubuntu:18.04 example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:18.04
    
    $ podman push --tls-verify=false example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:18.04

  7. スーパーユーザーパネルには、組織ごとに消費されたクォータが表示されます。

    Total Quota Consumed for first image

  8. 組織ページには、イメージで使用されているクォータの合計比率が表示されます。

    最初のイメージで消費された合計クォータ

    Total Quota Consumed for first image

  9. 2 番目のイメージをプル、タグ付け、プッシュします。たとえば、nginx です。

    サンプルコマンド

    $ podman pull nginx
    
    $ podman tag docker.io/library/nginx example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/nginx
    
    $ podman push --tls-verify=false example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/nginx

  10. 組織ページには、その組織の各リポジトリーで使用されているクォータの合計比率が表示されます。

    各リポジトリーで消費された合計クォータ

    Total Quota Consumed for each repository

  11. 拒否警告 の制限を作成します。

    スーパーユーザーパネルから、Manage Organizations タブに移動します。組織の Options アイコンをクリックし、Configure Quota を選択します。Quota Policy セクションで、Action タイプを Reject に設定し、Quota Threshold80 に設定して、Add Limit をクリックします。

    Reject limit

  12. 警告 制限を作成するには、Action タイプに Warning を選択し、Quota Threshold70 に設定して、Add Limit をクリックします。

    Warning limit

  13. クォータポップアップで Close をクリックします。制限は、Organization ページの Settings タブで表示できますが、編集することはできません。

    Quota policy in organization settings

  14. 拒否制限を超えたイメージをプッシュします。

    拒否制限 (80%) が現在のリポジトリーサイズ (~83%) 未満に設定されているため、次のプッシュは自動的に拒否されます。

    サンプルイメージプッシュ

    $ podman pull ubuntu:20.04
    
    $ podman tag docker.io/library/ubuntu:20.04 example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:20.04
    
    $ podman push --tls-verify=false example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:20.04

    クォータを超えたときのサンプル出力

    Getting image source signatures
    Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB
    Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB
    Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB
    WARN[0002] failed, retrying in 1s ... (1/3). Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace
    Getting image source signatures
    Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB
    Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB
    Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB
    WARN[0005] failed, retrying in 1s ... (2/3). Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace
    Getting image source signatures
    Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB
    Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB
    Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB
    WARN[0009] failed, retrying in 1s ... (3/3). Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace
    Getting image source signatures
    Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB
    Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB
    Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB
    Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace

  15. 制限を超えると、UI に通知が表示されます。

    クォータ通知

    Quota notifications

13.4. Red Hat Quay API を使用したクォータの確立

組織が最初に作成されたとき、割り当ては適用されていません。/api/v1/organization/{organization}/quota エンドポイントを使用します。

サンプルコマンド

$ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json'  https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota  | jq

出力例

[]

13.4.1. クォータの設定

組織の割り当てを設定するには、データを /api/v1/organization/{orgname}/quota エンドポイントに POST します。以下はコマンド例です。

$ curl -k -X POST -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' -d '{"limit_bytes": 10485760}'  https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/organization/testorg/quota | jq

出力例

"Created"

13.4.2. クォータの表示

適用されたクォータを確認するには、/api/v1/organization/{orgname}/quota エンドポイントからデータを GET します。

サンプルコマンド

$ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json'  https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota  | jq

出力例

[
  {
    "id": 1,
    "limit_bytes": 10485760,
    "default_config": false,
    "limits": [],
    "default_config_exists": false
  }
]

13.4.3. クォータの変更

既存の割り当てを変更する (ここでは 10MB から 100MB に) には、データを /api/v1/organization/{orgname}/quota/{quota_id} エンドポイントに PUT します。

サンプルコマンド

$ curl -k -X PUT -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' -d '{"limit_bytes": 104857600}'  https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota/1 | jq

出力例

{
  "id": 1,
  "limit_bytes": 104857600,
  "default_config": false,
  "limits": [],
  "default_config_exists": false
}

13.4.4. イメージのプッシュ

消費されたストレージを確認するには、さまざまなイメージを組織にプッシュします。

13.4.4.1. ubuntu:18.04 のプッシュ

コマンドラインから組織に ubuntu:18.04 をプッシュします。

サンプルコマンド

$ podman pull ubuntu:18.04

$ podman tag docker.io/library/ubuntu:18.04 example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:18.04

$ podman push --tls-verify=false example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:18.04

13.4.4.2. API を使用してクォータの使用状況の表示

消費されたストレージを表示するには、/api/v1/repository エンドポイントからデータを GET します。

サンプルコマンド

$ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' 'https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/repository?last_modified=true&namespace=testorg&popularity=true&public=true&quota=true' | jq

出力例

{
  "repositories": [
    {
      "namespace": "testorg",
      "name": "ubuntu",
      "description": null,
      "is_public": false,
      "kind": "image",
      "state": "NORMAL",
      "quota_report": {
        "quota_bytes": 27959066,
        "configured_quota": 104857600
      },
      "last_modified": 1651225630,
      "popularity": 0,
      "is_starred": false
    }
  ]
}

13.4.4.3. 別のイメージをプッシュ

  1. 2 番目のイメージをプル、タグ付け、プッシュします。たとえば、nginx です。

    サンプルコマンド

    $ podman pull nginx
    
    $ podman tag docker.io/library/nginx example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/nginx
    
    $ podman push --tls-verify=false example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/nginx

  2. 組織内のリポジトリーのクォータレポートを表示するには、/api/v1/repository エンドポイントを使用します。

    サンプルコマンド

    $ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' 'https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/repository?last_modified=true&namespace=testorg&popularity=true&public=true&quota=true'

    出力例

    {
      "repositories": [
        {
          "namespace": "testorg",
          "name": "ubuntu",
          "description": null,
          "is_public": false,
          "kind": "image",
          "state": "NORMAL",
          "quota_report": {
            "quota_bytes": 27959066,
            "configured_quota": 104857600
          },
          "last_modified": 1651225630,
          "popularity": 0,
          "is_starred": false
        },
        {
          "namespace": "testorg",
          "name": "nginx",
          "description": null,
          "is_public": false,
          "kind": "image",
          "state": "NORMAL",
          "quota_report": {
            "quota_bytes": 59231659,
            "configured_quota": 104857600
          },
          "last_modified": 1651229507,
          "popularity": 0,
          "is_starred": false
        }
      ]
    }

  3. 組織の詳細でクォータ情報を表示するには、/api/v1/organization/{orgname} エンドポイントを使用します。

    サンプルコマンド

    $ curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' 'https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg' | jq

    出力例

    {
      "name": "testorg",
      ...
      "quotas": [
        {
          "id": 1,
          "limit_bytes": 104857600,
          "limits": []
        }
      ],
      "quota_report": {
        "quota_bytes": 87190725,
        "configured_quota": 104857600
      }
    }

13.4.5. クォータ制限を使用してプッシュの拒否

イメージプッシュが定義されたクォータ制限を超えると、ソフトチェックまたはハードチェックが発生します。

  • ソフトチェックまたは 警告 の場合は、ユーザーに通知されます。
  • ハードチェックまたは 拒否 の場合、プッシュは終了します。

13.4.5.1. 拒否および警告の制限の設定

拒否 および 警告 の制限を設定するには、データを /api/v1/organization/{orgname}/quota/{quota_id}/limit エンドポイントに POST します。

サンプル拒否制限コマンド

$ curl -k -X POST -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' -d '{"type":"Reject","threshold_percent":80}'  https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota/1/limit

警告制限コマンドの例

$ curl -k -X POST -H "Authorization: Bearer <token>" -H 'Content-Type: application/json' -d '{"type":"Warning","threshold_percent":50}'  https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota/1/limit

13.4.5.2. 拒否および警告の制限の表示

拒否 および 警告 の制限を表示するには、/api/v1/Organization/{orgname}/quota エンドポイントを使用します。

クォータ制限の表示

$  curl -k -X GET -H "Authorization: Bearer <token>" -H 'Content-Type: application/json'  https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/api/v1/organization/testorg/quota | jq

クォータ制限のサンプル出力

[
  {
    "id": 1,
    "limit_bytes": 104857600,
    "default_config": false,
    "limits": [
      {
        "id": 2,
        "type": "Warning",
        "limit_percent": 50
      },
      {
        "id": 1,
        "type": "Reject",
        "limit_percent": 80
      }
    ],
    "default_config_exists": false
  }
]

13.4.5.3. 拒否制限を超えたときにイメージをプッシュ

この例では、拒否制限 (80%) が現在のリポジトリーサイズ (~83%) 未満に設定されているため、次のプッシュは自動的に拒否されます。

コマンドラインからサンプルイメージを組織にプッシュします。

サンプルイメージプッシュ

$ podman pull ubuntu:20.04

$ podman tag docker.io/library/ubuntu:20.04 example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:20.04

$ podman push --tls-verify=false example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org/testorg/ubuntu:20.04

クォータを超えたときのサンプル出力

Getting image source signatures
Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB
Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB
Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB
WARN[0002] failed, retrying in 1s ... (1/3). Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace
Getting image source signatures
Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB
Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB
Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB
WARN[0005] failed, retrying in 1s ... (2/3). Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace
Getting image source signatures
Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB
Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB
Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB
WARN[0009] failed, retrying in 1s ... (3/3). Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace
Getting image source signatures
Copying blob d4dfaa212623 [--------------------------------------] 8.0b / 3.5KiB
Copying blob cba97cc5811c [--------------------------------------] 8.0b / 15.0KiB
Copying blob 0c78fac124da [--------------------------------------] 8.0b / 71.8MiB
Error: Error writing blob: Error initiating layer upload to /v2/testorg/ubuntu/blobs/uploads/ in example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org: denied: Quota has been exceeded on namespace

13.4.5.4. 制限を超えた場合の通知

制限を超えると、通知が表示されます。

クォータ通知

Quota notifications

13.5. クォータ管理の制限

クォータ管理は、組織がリソース消費を維持するのに役立ちます。クォータ管理の制限の 1 つは、プッシュでリソース消費を計算すると、計算がプッシュのクリティカルパスの一部になることです。これがないと、使用状況データがドリフトする可能性があります。

最大ストレージクォータサイズは、選択したデータベースによって異なります。

表13.2 ワーカー数の環境変数

変数説明

Postgres

8388608 TB

MySQL

8388608 TB

SQL Server

16777216 TB

第14章 Geo レプリケーション

Geo レプリケーションでは、地理的に分散した複数の Red Hat Quay デプロイメントを、クライアントやユーザーの視点から、単一のレジストリーとして動作させることができます。グローバルに分散された Red Hat Quay のセットアップにおいて、プッシュとプルのパフォーマンスが大幅に向上します。イメージデータはバックグラウンドで非同期的に複製され、クライアントには透過的なフェイルオーバー/リダイレクトが行われます。

Red Hat Quay 3.7 では、Geo レプリケーションを使用した Red Hat Quay のデプロイメントは、スタンドアロンおよびオペレーターデプロイメントによってサポートされます。

14.1. Geo レプリケーション機能

  • Geo レプリケーションが設定されていると、コンテナーイメージのプッシュはその Red Hat Quay インスタンスの推奨ストレージエンジンに書き込まれます (通常はリージョン内の最も近いストレージバックエンド)。
  • 最初のプッシュの後、イメージデータはバックグランドで他のストレージエンジンに複製されます。
  • レプリケーションロケーションのリストは設定可能で、それらは異なるストレージバックエンドにすることができます。
  • イメージプルでは、プルのパフォーマンスを最大化するために、常に利用可能な最も近いストレージエンジンを使用します。
  • レプリケーションがまだ完了していない場合、プルは代わりにソースストレージのバックエンドを使用します。

14.2. Geo レプリケーションの要件と制約

  • 1 つのデータベース、つまりすべてのメタデータと Quay の設定がすべてのリージョンで共有されます。
  • 1 つの Redis キャッシュは Quay のセットアップ全体で共有され、すべての Quay Pod からアクセスできる必要があります。
  • ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数を使用して明示的に設定できます。
  • Geo レプリケーションでは、各リージョンにオブジェクトストレージが必要です。ローカルストレージや NFS では動作しません。
  • 各リージョンは、各リージョンのすべてのストレージエンジンにアクセスできる必要があります (ネットワークパスが必要)。
  • また、ストレージプロキシオプションを使用することもできます。
  • ストレージのバックエンド全体 (すべての blob) が複製されます。これは、組織、リポジトリー、イメージに限定することができるリポジトリーミラーリングとは対照的です。
  • すべての Quay インスタンスは、ロードバランサーを介して同じエントリーポイントを共有する必要があります。
  • すべての Quay インスタンスは、共通の設定ファイルで定義された同じスーパーユーザーのセットを持つ必要があります。
  • Geo レプリケーションでは、Clair 設定を unmanaged に設定する必要があります。管理されていない Clair データベースにより、Red Hat Quay オペレーターは、Operator の複数のインスタンスが同じデータベースと通信する必要がある地理的に複製された環境で作業できます。詳細は、Advanced Clair configuration を参照してください。
  • Geo レプリケーションには、SSL/TSL 証明書とキーが必要です。詳細は、Using SSL to protect connections to Red Hat Quay を参照してください。

上記の要件を満たすことができない場合は、代わりに 2 つ以上の異なる Quay のデプロイメントを使用し、リポジトリーミラーリング機能を利用する必要があります。

14.3. スタンドアロン Red Hat Quay を使用した Geo レプリケーション

Georeplication

上記の例では、Quay は共通のデータベースおよび共通の Redis インスタンスを持つ 2 つのリージョンでスタンドアロンを実行します。ローカライズされたイメージストレージは各リージョンで提供され、最も近くにある利用可能なストレージエンジンからイメージプルが提供されます。コンテナーイメージのプッシュは、Quay インスタンスの推奨ストレージエンジンに書き込まれ、次にバックグラウンドで他のストレージエンジンに複製されます。

注記

たとえば米国のクラスターなど、1 つのクラスターで Clair に障害が発生した場合に、米国のユーザーに 2 番目のクラスター (EU) の脆弱性レポートを Quay を表示しません。これは、すべての Clair インスタンスの状態が同じであるためです。Clair に障害が発生した場合、通常はクラスター内の問題が原因です。

14.3.1. ストレージレプリケーションを有効にする - スタンドアロン Quay

  1. スクロールダウンして、Registry Storage というセクションに進みます。
  2. Enable Storage Replication をクリックします。
  3. データをレプリケートするストレージエンジンをそれぞれ追加します。使用するストレージエンジンをすべて一覧表示する必要があります。
  4. すべてのストレージエンジンに対してすべてのイメージの完全なレプリケーションが必要な場合は、各ストレージエンジンの設定の下で「Replicate to storage engine by default」をクリックします。これにより、すべてのイメージがそのストレージエンジンにレプリケートされます。namespace ごとのレプリケーションを有効にするには、サポートにお問い合わせください。
  5. これを実行した後に、「Save Configuration Changes」をクリックします。設定の変更は、Red Hat Quay の次回の再起動時に有効になります。
  6. ストレージを追加し、Georeplication について「Replicate to storage engine by default」を有効にした後に、すべてのストレージで既存のイメージデータを同期する必要があります。そのためには、コンテナーに oc exec (または docker/kubectl exec) して実行する必要があります。

    # scl enable python27 bash
    # python -m util.backfillreplication

    この操作は、新しいストレージを追加した後にコンテンツを同期するための1回限りの操作です。

14.3.2. ストレージの優先情報を使用した Red Hat Quay の実行

  1. Red Hat Quay を実行しているすべてのマシンに config.yaml をコピーします。
  2. 各リージョンの各マシンは、マシンが稼働しているリージョンの優先ストレージエンジンを持つ QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数を追加します。

    たとえば、ヨーロッパで稼働しているマシンで、ホスト上の config ディレクトリーが $QUAY/config から利用できる場合です。

    $ sudo podman run -d --rm -p 80:8080 -p 443:8443  \
       --name=quay \
       -v $QUAY/config:/conf/stack:Z \
       -e QUAY_DISTRIBUTED_STORAGE_PREFERENCE=europestorage \
       registry.redhat.io/quay/quay-rhel8:v3.7.3
    注記

    指定された環境変数の値は、コンフィグパネルで定義されたロケーション ID の名前と一致する必要があります。

  3. すべての Red Hat Quay コンテナーを再起動します。

14.4. Red Hat Quay Operator を使用した Geo レプリケーション

Georeplication architecture

上記の例では、Red Hat Quay Operator は、共通のデータベースと共通の Redis インスタンスを使用して、2 つの別々のリージョンにデプロイされています。ローカライズされたイメージストレージは各リージョンで提供され、最も近くにある利用可能なストレージエンジンからイメージプルが提供されます。コンテナーイメージのプッシュは、Quay インスタンスの推奨ストレージエンジンに書き込まれ、次にバックグラウンドで他のストレージエンジンに複製されます。

Operator は現在、Clair セキュリティースキャナーとそのデータベースを別々に管理しているため、Geo レプリケーションの設定を活用して、Clair データベースを管理しないようにすることができます。代わりに、外部共有データベースが使用されます。Red Hat Quay と Clair は、PostgreSQL のいくつかのプロバイダーとベンダーをサポートしています。これらは Red Hat Quay 3.x test matrix にあります。さらに、Operator は、デプロイメントに挿入できるカスタム Clair 設定もサポートします。これにより、ユーザーは外部データベースの接続資格情報を使用して Clair を設定できます。

14.4.1. Openshift での Geo レプリケーションの設定

手順

  1. Quaypostgres インスタンスをデプロイします。

    1. データベースにログインします。
    2. Quay のデータベースを作成します。

      CREATE DATABASE quay;
    3. データベース内で pg_trm 拡張機能を有効にします。

      \c quay;
      CREATE EXTENSION IF NOT EXISTS pg_trgm;
  2. Redis インスタンスをデプロイします。

    注記
    • クラウドプロバイダーに独自のサービスがある場合は、Redis インスタンスをデプロイする必要がない場合があります。
    • Builder を利用している場合は、Redis インスタンスをデプロイする必要があります。
    1. Redis 用の VM をデプロイします。
    2. Quay が実行されているクラスターからアクセスできることを確認してください。
    3. ポート 6379/TCP が開いている必要があります。
    4. インスタンス内で Redis を実行します。

      sudo dnf install -y podman
      podman run -d --name redis -p 6379:6379 redis
  3. クラスターごとに 1 つずつ、2 つのオブジェクトストレージバックエンドを作成します。

    理想的には、一方のオブジェクトストレージバケットは 1 番目のクラスター (プライマリー) の近くにあり、もう一方は 2 番目のクラスター (セカンダリー) の近くにあります。

  4. 環境変数のオーバーライドを使用して、同じ設定バンドルでクラスターをデプロイし、個々のクラスターに適切なストレージバックエンドを選択します。
  5. クラスターへの単一のエントリーポイントを提供するように、ロードバランサーを設定します。

14.4.1.1. 設定

config.yaml ファイルはクラスター間で共有され、一般的な PostgreSQL、Redis、およびストレージバックエンドの詳細が含まれます。

config.yaml

SERVER_HOSTNAME: <georep.quayteam.org or any other name> 1
DB_CONNECTION_ARGS:
  autorollback: true
  threadlocals: true
DB_URI: postgresql://postgres:password@10.19.0.1:5432/quay 2
BUILDLOGS_REDIS:
  host: 10.19.0.2
  port: 6379
USER_EVENTS_REDIS:
  host: 10.19.0.2
  port: 6379
DISTRIBUTED_STORAGE_CONFIG:
  usstorage:
    - GoogleCloudStorage
    - access_key: GOOGQGPGVMASAAMQABCDEFG
      bucket_name: georep-test-bucket-0
      secret_key: AYWfEaxX/u84XRA2vUX5C987654321
      storage_path: /quaygcp
  eustorage:
    - GoogleCloudStorage
    - access_key: GOOGQGPGVMASAAMQWERTYUIOP
      bucket_name: georep-test-bucket-1
      secret_key: AYWfEaxX/u84XRA2vUX5Cuj12345678
      storage_path: /quaygcp
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS:
  - usstorage
  - eustorage
DISTRIBUTED_STORAGE_PREFERENCE:
  - usstorage
  - eustorage
FEATURE_STORAGE_REPLICATION: true

1
ルートには適切な SERVER_HOSTNAME を使用する必要があり、グローバルロードバランサーのホスト名と一致する必要があります。
2
OpenShift Operator を使用してデプロイされた Clair インスタンスの設定ファイルを取得するには、Retrieving the Clair config 参照してください。

configBundleSecret を作成します。

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

各クラスターで、configBundleSecret を設定し、QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数のオーバーライドを使用して、そのクラスターに適切なストレージを設定します。

注記

両方のデプロイメント間の config.yaml ファイルは一致する必要があります。一方のクラスターに変更を加える場合は、もう一方のクラスターでも変更する必要があります。

米国のクラスター

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: georep-config-bundle
  components:
    - kind: objectstorage
      managed: false
    - kind: route
      managed: true
    - kind: tls
      managed: false
    - kind: postgres
      managed: false
    - kind: clairpostgres
      managed: false
    - kind: redis
      managed: false
    - kind: quay
      managed: true
      overrides:
        env:
          - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE
            value: usstorage

+

注記

TLS は管理されておらず、ルートは管理されているため、設定ツールを使用するか、設定バンドルで直接証明書を提供する必要があります。詳細は、Configuring TLS and routes を参照してください。

ヨーロッパのクラスター

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: georep-config-bundle
  components:
    - kind: objectstorage
      managed: false
    - kind: route
      managed: true
    - kind: tls
      managed: false
    - kind: postgres
      managed: false
    - kind: clairpostgres
      managed: false
    - kind: redis
      managed: false
    - kind: quay
      managed: true
      overrides:
        env:
          - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE
            value: eustorage

+

注記

TLS は管理されておらず、ルートは管理されているため、設定ツールを使用するか、設定バンドルで直接証明書を提供する必要があります。詳細は、Configuring TLS and routes を参照してください。

14.4.2. Geo レプリケーションのための複合ストレージ

Red Hat Quay の Geo レプリケーションは、異なる複数のレプリケーションターゲットの使用をサポートしています。たとえば、パブリッククラウドの AWS S3 ストレージとオンプレミスの Ceph ストレージを使用する、などです。これは、すべての Red Hat Quay Pod とクラスターノードからすべてのストレージバックエンドへのアクセスを許可するという重要な要件を複雑にします。その結果、以下が推奨されています。

  • VPN を使用して、内部ストレージの可視化を防ぐ。または
  • Quay が使用する指定のバケットへのアクセスのみを許可するトークンペアを使用する。

これにより、Red Hat Quay のパブリッククラウドインスタンスはオンプレミスのストレージにアクセスできるようになりますが、ネットワークは暗号化され、保護され、ACL を使用することで、セキュリティー要件を満たすことができます。

これらのセキュリティー対策を実施できない場合は、2 つの異なる Red Hat Quay レジストリーをデプロイし、Geo レプリケーションの代わりにリポジトリーミラーリングを使用することが推奨されます。

第15章 Red Hat Quay Operator によって管理される Red Hat Quay のバックアップおよび復元

OpenShift Container Platform で Red Hat Quay Operator によって管理される場合、このセクション内のコンテンツを使用して Red Hat Quay をバックアップおよび復元します。

15.1. Red Hat Quay のバックアップ

この手順では、Red Hat Quay Operator を使用して OpenShift Container Platform にデプロイされた Red Hat Quay のバックアップを作成する方法を説明します。

前提条件

  • Red Hat Quay Operator を使用して、OpenShift Container Platform で正常に Red Hat Quay がデプロイメントされている (状況条件 Availabletrueに設定されている)。
  • コンポーネント quaypostgres、および objectstoragemanaged: trueに設定されている。
  • コンポーネント clairmanaged: true に合、コンポーネント clairpostgresmanaged: true に設定されている (Red Hat Quay Operator v3.7 以降で開始)。
注記

デプロイメントに部分的に管理されていないデータベースまたはストレージコンポーネントが含まれ、Postgres または S3 互換オブジェクトストレージの外部サービスを使用している場合、Red Hat Quay デプロイメントを実行するには、サービスプロバイダーまたはベンダーのドキュメントを参照してデータのバックアップを作成してください。このガイドで説明されているツールは、外部 Postgres データベースまたはオブジェクトストレージのバックアップの開始点として参照できます。

15.1.1. Red Hat Quay 設定のバックアップ

  1. QuayRegistry カスタムリソースをエクスポートしてバックアップします。

    $ oc get quayregistry <quay-registry-name> -n <quay-namespace> -o yaml > quay-registry.yaml
  2. 作成される quayregistry.yaml を編集し、ステータスセクションおよび以下のメタデータフィールドを削除します。

      metadata.creationTimestamp
      metadata.finalizers
      metadata.generation
      metadata.resourceVersion
      metadata.uid
  3. 管理対象キーシークレットをバックアップします。

    注記

    Red Hat Quay 3.7.0 より前のバージョンを実行している場合は、この手順を省略できます。一部のシークレットは Quay の初回デプロイ時に自動的に生成されます。これらは QuayRegistry リソースの名前空間で、<quay-registry-name>-quay-registry-managed-secret-keys というシークレットに保存されます。

    $ oc get secret -n <quay-namespace> <quay-registry-name>-quay-registry-managed-secret-keys -o yaml > managed-secret-keys.yaml
  4. 作成された managed-secret-keys.yaml ファイルを編集し、エントリー metadata.ownerReferences を削除します。managed-secret-keys.yaml ファイルは、以下のようになります。

    apiVersion: v1
    kind: Secret
    type: Opaque
    metadata:
      name: <quayname>-quay-registry-managed-secret-keys
      namespace: <quay-namespace>
    data:
      CONFIG_EDITOR_PW: <redacted>
      DATABASE_SECRET_KEY: <redacted>
      DB_ROOT_PW: <redacted>
      DB_URI: <redacted>
      SECRET_KEY: <redacted>
      SECURITY_SCANNER_V4_PSK: <redacted>

    data プロパティーの情報はすべて同じままにする必要があります。

  5. 現在の Quay 設定をバックアップします。

    $ oc get secret -n <quay-namespace>  $(oc get quayregistry <quay-registry-name> -n <quay-namespace>  -o jsonpath='{.spec.configBundleSecret}') -o yaml > config-bundle.yaml

15.1.2. Red Hat Quay デプロイメントのスケールダウン

重要

この手順は、Red Hat Quay デプロイメントの状態の整合性のあるバックアップを作成するために必要になります。Postgres データベースや S3 互換オブジェクトストレージが外部サービスによって提供されるセットアップ (Operator の管理対象外) を含め、この手順を省略しないでください。

  1. Operator バージョン 3.7 以降: Red Hat Quay の自動スケーリングを無効にし、Red Hat Quay、ミラーワーカー、および Clair (管理対象の場合) のレプリカ数をオーバーライドすることでRed Hat Quay デプロイメントを縮小します。QuayRegistry リソースは、以下のようになります。

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: registry
      namespace: ns
    spec:
      components:
        …
        - kind: horizontalpodautoscaler
          managed: false 1
        - kind: quay
          managed: true
          overrides: 2
            replicas: 0
        - kind: clair
          managed: true
          overrides:
            replicas: 0
        - kind: mirror
          managed: true
          overrides:
            replicas: 0
        …
    1
    Quay、Clair、ミラーリングワーカーの自動スケーリングの無効化
    2
    データベースおよびオブジェクトストレージにアクセスするコンポーネントのレプリカ数を 0 に設定
  2. Operator バージョン 3.6 以前:まず Red Hat Quay Operator をスケールダウンしてから、管理対象の Red Hat Quay リソースをスケールダウンして Red Hat Quay デプロイメントを縮小します。

    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-operator-namespace>|awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/quay-app/ {print $1}') -n <quay-namespace>
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/quay-mirror/ {print $1}') -n <quay-namespace>
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/clair-app/ {print $1}') -n <quay-namespace>
  3. registry-quay-appregistry-quay-mirror、および registry-clair-app Pod (どのコンポーネントを Red Hat Quay Operator の管理対象として設定したかにより異なります) が非表示になるまで待機します。以下のコマンドを実行してステータスを確認できます。

    $ oc get pods -n <quay-namespace>

    出力例:

    $ oc get pod
    
    quay-operator.v3.7.1-6f9d859bd-p5ftc               1/1     Running     0             12m
    quayregistry-clair-postgres-7487f5bd86-xnxpr       1/1     Running     1 (12m ago)   12m
    quayregistry-quay-app-upgrade-xq2v6                0/1     Completed   0             12m
    quayregistry-quay-config-editor-6dfdcfc44f-hlvwm   1/1     Running     0             73s
    quayregistry-quay-database-859d5445ff-cqthr        1/1     Running     0             12m
    quayregistry-quay-redis-84f888776f-hhgms           1/1     Running     0             12m

15.1.3. Red Hat Quay 管理対象データベースのバックアップ

注記

Red Hat Quay デプロイメントが外部 (管理対象外) Postgres データベースで設定されている場合は、これらのデータベースの一貫したバックアップを作成する方法についてベンダーのドキュメントを参照してください。

  1. Quay PostgreSQL Pod 名を特定します。

    $ oc get pod -l quay-component=postgres -n <quay-namespace> -o jsonpath='{.items[0].metadata.name}'

    出力例:

    quayregistry-quay-database-59f54bb7-58xs7
  2. Quay データベース名を取得します。

    $ oc -n <quay-namespace> rsh $(oc get pod -l app=quay -o NAME -n <quay-namespace> |head -n 1) cat /conf/stack/config.yaml|awk -F"/" '/^DB_URI/ {print $4}'
    quayregistry-quay-database
  3. バックアップデータベースをダウンロードします。

    $ oc exec quayregistry-quay-database-59f54bb7-58xs7 -- /usr/bin/pg_dump -C quayregistry-quay-database  > backup.sql

15.1.3.1. Red Hat Quay 管理対象オブジェクトストレージのバックアップ

このセクションの手順は、以下の設定に適用されます。

  • スタンドアロンのマルチクラウドオブジェクトゲートウェイ設定
  • OpenShift Data Foundations ストレージでは、Red Hat Quay Operator が ObjectStorageBucketClaim API 経由で S3 オブジェクトストレージバケットをプロビジョニングしている必要があります。
注記

Red Hat Quay デプロイメントが外部 (管理対象外) オブジェクトストレージで設定されている場合は、Quay のストレージバケットのコンテンツのコピーを作成する方法についてベンダーのドキュメントを参照してください。

  1. AWS_ACCESS_KEY_ID をデコードし、エクスポートします。

    $ export AWS_ACCESS_KEY_ID=$(oc get secret -l app=noobaa -n <quay-namespace>  -o jsonpath='{.items[0].data.AWS_ACCESS_KEY_ID}' |base64 -d)
  2. AWS_SECRET_ACCESS_KEY_ID をデコードし、エクスポートします。

    $ export AWS_SECRET_ACCESS_KEY=$(oc get secret -l app=noobaa -n <quay-namespace> -o jsonpath='{.items[0].data.AWS_SECRET_ACCESS_KEY}' |base64 -d)
  3. 新しいディレクトリーを作成し、すべての Blob をそのディレクトリーにコピーします。

    $ mkdir blobs
    
    $ aws s3 sync --no-verify-ssl --endpoint https://$(oc get route s3 -n openshift-storage  -o jsonpath='{.spec.host}')  s3://$(oc get cm -l app=noobaa -n <quay-namespace> -o jsonpath='{.items[0].data.BUCKET_NAME}') ./blobs
注記

AWS コマンドラインユーティリティーの代わりに、rclone または sc3md を使用することもできます。

15.1.4. Red Hat Quay デプロイメントのバックアップのスケーリング

  1. Operator バージョン 3.7 以降: 自動スケーリングを再度有効にし、必要な場合は Quay、ミラーワーカー、および Clair のレプリカオーバーライドを適宜削除して、Red Hat Quay デプロイメントをスケールアップします。QuayRegistry リソースは、以下のようになります。

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: registry
      namespace: ns
    spec:
      components:
        …
        - kind: horizontalpodautoscaler
          managed: true 1
        - kind: quay 2
          managed: true
        - kind: clair
          managed: true
        - kind: mirror
          managed: true
        …
    1
    Quay、Clair、ミラーリングワーカーの自動スケーリングの再有効化 (必要に応じて)
    2
    Quay コンポーネントのバックアップをスケーリングするためにレプリカオーバーライドを再削除
  2. Operator バージョン 3.6 以前の場合: Red Hat Quay Operator を再度スケールアップして Red Hat Quay デプロイメントをスケールアップします。

    $ oc scale --replicas=1 deployment $(oc get deployment -n <quay-operator-namespace> | awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
  3. Red Hat Quay デプロイメントのステータスを確認します。

    $ oc wait quayregistry registry --for=condition=Available=true -n <quay-namespace>

    出力例:

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      ...
      name: registry
      namespace: <quay-namespace>
      ...
    spec:
      ...
    status:
      - lastTransitionTime: '2022-06-20T05:31:17Z'
        lastUpdateTime: '2022-06-20T17:31:13Z'
        message: All components reporting as healthy
        reason: HealthChecksPassing
        status: 'True'
        type: Available

15.2. Red Hat Quay の復元

この手順は、Red Hat Quay Operator がデータベースを管理する際に Red Hat Quay を復元するために使用されます。これは、Red Hat Quay レジストリーをバックアップした後に実行する必要があります。詳細は Backing up Red Hat Quay を参照してください。

前提条件

  • Red Hat Quay は、Red Hat Quay Operator を使用して OpenShift Container Platform にデプロイされている。
  • Red Hat Quay Red Hat Quay が管理する Red Hat Quay 設定のバックアップは、Red Hat Quay のバックアップ セクションの手順に従って作成されている。
  • Red Hat Quay データベースがバックアップされている。
  • Red Hat Quay で使用されるオブジェクトストレージバケットがバックアップされている。
  • コンポーネント quaypostgres、および objectstoragemanaged: true に設定されている。
  • コンポーネント clairmanaged: true に設定されている場合、コンポーネント clairpostgresmanaged: true に設定されている (Red Hat Quay Operator v3.7 以降で開始)。
  • OpenShift Container Platform クラスターのターゲット namespace で、Red Hat Quay Operator によって管理される Red Hat Quay デプロイメントを実行していない。
注記

デプロイメントに部分的に管理されていないデータベースまたはストレージコンポーネントが含まれ、Postgres または S3 互換オブジェクトストレージの外部サービスを使用している場合、Red Hat Quay デプロイメントを実行するには、サービスプロバイダーまたはベンダーのドキュメントを参照して、Red Hat Quay を複弁する前にバックアップからデータを復元してください。

15.2.1. バックアップからの Red Hat Quay およびその設定の復元

注記

これらの手順では、Red Hat Quay のバックアップ ガイドのプロセスに従い、同じ名前のバックアップファイルを作成していることを前提としています。

  1. バックアップされた Red Hat Quay 設定と生成されたキーをバックアップから復元します。

    $ oc create -f ./config-bundle.yaml
    
    $ oc create -f ./managed-secret-keys.yaml
    重要

    エラー Error from server (AlreadyExists): error when creating "./config-bundle.yaml": secrets "config-bundle-secret" already exists が発生した場合、$ oc delete Secret config-bundle-secret -n <quay-namespace> を使用して既存リソースを削除し、$ oc create -f ./config-bundle.yaml で再作成する必要があります。

  2. QuayRegistry カスタムリソースを復元します。

    $ oc create -f ./quay-registry.yaml
  3. Red Hat Quay デプロイメントのステータスを確認し、これが利用可能になるまで待機します。

    $ oc wait quayregistry registry --for=condition=Available=true -n <quay-namespace>

15.2.2. Red Hat Quay デプロイメントのスケールダウン

  1. Operator バージョン 3.7 以降: Red Hat Quay の自動スケーリングを無効にし、Red Hat Quay、ミラーワーカー、および Clair (管理対象の場合) のレプリカ数をオーバーライドすることで Quay デプロイメントを縮小します。QuayRegistry リソースは、以下のようになります。

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: registry
      namespace: ns
    spec:
      components:
        …
        - kind: horizontalpodautoscaler
          managed: false 1
        - kind: quay
          managed: true
          overrides: 2
            replicas: 0
        - kind: clair
          managed: true
          overrides:
            replicas: 0
        - kind: mirror
          managed: true
          overrides:
            replicas: 0
        …
    1
    Quay、Clair、ミラーリングワーカーの自動スケーリングの無効化
    2
    データベースおよびオブジェクトストレージにアクセスするコンポーネントのレプリカ数を 0 に設定
  2. Operator バージョン 3.6 以前: まず Red Hat Quay Operator をスケールダウンしてから、管理対象の Red Hat Quay リソースをスケールダウンして Red Hat Quay デプロイメントを縮小します。

    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-operator-namespace>|awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
    
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/quay-app/ {print $1}') -n <quay-namespace>
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/quay-mirror/ {print $1}') -n <quay-namespace>
    $ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace>|awk '/clair-app/ {print $1}') -n <quay-namespace>
  3. registry-quay-appregistry-quay-mirror、および registry-clair-app Pod (どのコンポーネントを Operator の管理対象として設定したかにより異なります) が非表示になるまで待機します。以下のコマンドを実行してステータスを確認できます。

    $ oc get pods -n <quay-namespace>

    出力例:

    registry-quay-config-editor-77847fc4f5-nsbbv   1/1     Running            0          9m1s
    registry-quay-database-66969cd859-n2ssm        1/1     Running            0          6d1h
    registry-quay-redis-7cc5f6c977-956g8           1/1     Running            0          5d21h

15.2.3. Red Hat Quay データベースの復元

  1. Quay データベース Pod を特定します。

    $ oc get pod -l quay-component=postgres -n  <quay-namespace> -o jsonpath='{.items[0].metadata.name}'

    出力例:

    quayregistry-quay-database-59f54bb7-58xs7
  2. ローカル環境および Pod にコピーして、バックアップをアップロードします。

    $ oc cp ./backup.sql -n <quay-namespace> registry-quay-database-66969cd859-n2ssm:/tmp/backup.sql
  3. データベースに対してリモートターミナルを開きます。

    $ oc rsh -n <quay-namespace> registry-quay-database-66969cd859-n2ssm
  4. psql を入力します。

    bash-4.4$ psql
  5. 以下のコマンドを実行してデータベースを一覧表示できます。

    postgres=# \l

    出力例:

                                                      List of databases
               Name            |           Owner            | Encoding |  Collate   |   Ctype    |   Access privileges
    ----------------------------+----------------------------+----------+------------+------------+-----------------------
    postgres                   | postgres                   | UTF8     | en_US.utf8 | en_US.utf8 |
    quayregistry-quay-database | quayregistry-quay-database | UTF8     | en_US.utf8 | en_US.utf8 |
  6. データベースを削除します。

    postgres=# DROP DATABASE "quayregistry-quay-database";

    出力例:

    DROP DATABASE
  7. postgres CLI を終了して bash-4.4 を再入力します。

    \q
  8. PostgreSQL データベースをバックアップデータベースにリダイレクトします。

    sh-4.4$ psql < /tmp/backup.sql
  9. bash を終了します。

    sh-4.4$ exit

15.2.4. Red Hat Quay オブジェクトストレージデータの復元

  1. AWS_ACCESS_KEY_ID をエクスポートします。

    $ export AWS_ACCESS_KEY_ID=$(oc get secret -l app=noobaa -n <quay-namespace>  -o jsonpath='{.items[0].data.AWS_ACCESS_KEY_ID}' |base64 -d)
  2. AWS_SECRET_ACCESS_KEY をエクスポートします。

    $ export AWS_SECRET_ACCESS_KEY=$(oc get secret -l app=noobaa -n <quay-namespace> -o jsonpath='{.items[0].data.AWS_SECRET_ACCESS_KEY}' |base64 -d)
  3. 以下のコマンドを実行して、すべての Blob をバケットにアップロードします。

    $ aws s3 sync --no-verify-ssl --endpoint https://$(oc get route s3 -n openshift-storage  -o jsonpath='{.spec.host}') ./blobs  s3://$(oc get cm -l app=noobaa -n <quay-namespace> -o jsonpath='{.items[0].data.BUCKET_NAME}')
注記

AWS コマンドラインユーティリティーの代わりに、rclone または sc3md を使用することもできます。

15.2.5. Red Hat Quay デプロイメントのスケールアップ

  1. Operator バージョン 3.7 以降: 自動スケーリングを再度有効にし、必要な場合は Quay、ミラーワーカー、および Clair のレプリカオーバーライドを適宜削除して、Red Hat Quay デプロイメントをスケールアップします。QuayRegistry リソースは、以下のようになります。

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      name: registry
      namespace: ns
    spec:
      components:
        …
        - kind: horizontalpodautoscaler
          managed: true 1
        - kind: quay 2
          managed: true
        - kind: clair
          managed: true
        - kind: mirror
          managed: true
        …
    1
    Red Hat Quay、Clair、ミラーリングワーカーの自動スケーリングの再有効化 (必要に応じて)
    2
    Red Hat Quay コンポーネントのバックアップをスケーリングするためにレプリカオーバーライドを再削除
  2. Operator バージョン 3.6 以前の場合: Red Hat Quay Operator を再度スケールアップして Red Hat Quay デプロイメントをスケールアップします。

    $ oc scale --replicas=1 deployment $(oc get deployment -n <quay-operator-namespace> | awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
  3. Red Hat Quay デプロイメントのステータスを確認します。

    $ oc wait quayregistry registry --for=condition=Available=true -n <quay-namespace>

    出力例:

    apiVersion: quay.redhat.com/v1
    kind: QuayRegistry
    metadata:
      ...
      name: registry
      namespace: <quay-namespace>
      ...
    spec:
      ...
    status:
      - lastTransitionTime: '2022-06-20T05:31:17Z'
        lastUpdateTime: '2022-06-20T17:31:13Z'
        message: All components reporting as healthy
        reason: HealthChecksPassing
        status: 'True'
        type: Available

第16章 スタンドアロン Quay デプロイメントから Red Hat Quay Operator 管理対象デプロイメントへの移行

以下の手順で、スタンドアロン Red Hat Quay デプロイメントをバックアップし、これを OpenShift Container Platform の Red Hat Quay Operator に移行できます。

16.1. Red Hat Quay のスタンドアロンデプロイメントのバックアップ

手順

  1. スタンドアロンデプロイメントの Quay config.yaml をバックアップします。

    $ mkdir /tmp/quay-backup
    $ cp /path/to/Quay/config/directory/config.yaml /tmp/quay-backup
  2. スタンドアロン Quay デプロイメントが使用しているデータベースのバックアップを作成します。

    $ pg_dump -h DB_HOST -p 5432 -d QUAY_DATABASE_NAME -U QUAY_DATABASE_USER -W -O > /tmp/quay-backup/quay-database-backup.sql
  3. AWS CLI がない場合はインストールします。
  4. ~/.aws/ ディレクトリーを作成します。

    $ mkdir ~/.aws/
  5. スタンドアロンデプロイメントの Quay config.yaml から access_key および secret_key を取得します。

    $ grep -i DISTRIBUTED_STORAGE_CONFIG -A10 /tmp/quay-backup/config.yaml

    出力例:

    DISTRIBUTED_STORAGE_CONFIG:
        minio-1:
            - RadosGWStorage
            - access_key: ##########
              bucket_name: quay
              hostname: 172.24.10.50
              is_secure: false
              port: "9000"
              secret_key: ##########
              storage_path: /datastorage/registry
  6. Quay config.yaml ファイルからの access_key および secret_key~/.aws ディレクトリーに保存します。

    $ touch ~/.aws/credentials
  7. オプション: access_key および secret_key が保存されていることを確認します。

    $ cat > ~/.aws/credentials << EOF
    [default]
    aws_access_key_id = ACCESS_KEY_FROM_QUAY_CONFIG
    aws_secret_access_key = SECRET_KEY_FROM_QUAY_CONFIG
    EOF

    出力例:

    aws_access_key_id = ACCESS_KEY_FROM_QUAY_CONFIG
    aws_secret_access_key = SECRET_KEY_FROM_QUAY_CONFIG
    注記

    aws cli`~/.aws/credentials file ファイルからaccess_key および secret_key を自動的に収集しない場合、aws configure を実行して手動でクレデンシャルを入力することで、それを設定できます。

  8. quay-backup ディレクトリーで、bucket_backup ディレクトリーを作成します。

    $ mkdir /tmp/quay-backup/bucket-backup
  9. S3 ストレージからすべての Blob をバックアップします。

    $ aws s3 sync --no-verify-ssl --endpoint-url https://PUBLIC_S3_ENDPOINT:PORT s3://QUAY_BUCKET/ /tmp/quay-backup/bucket-backup/
    注記

    PUBLIC_S3_ENDPOINT は、DISTRIBUTED_STORAGE_CONFIGhostname の下にある Quay config.yaml ファイルから読み取ることができます。エンドポイントがセキュアでない場合、エンドポイント URL の https ではなく http を使用します。

この時点で、すべての Quay データ、Blob、データベース、および config.yaml ファイルがローカルに保存された、完全なバックアップがあるはずです。次のセクションでは、スタンドアロンデプロイメントのバックアップを OpenShift Container Platform の Red Hat Quay に移行します。

16.2. バックアップされたスタンドアロンコンテンツを使用した OpenShift Container Platform への移行

前提条件

  • スタンドアロン Red Hat Quay のデータ、Blob、データベース、および config.yaml がバックアップされている。
  • Red Hat Quay は、Quay Operator を使用して OpenShift Container Platform にデプロイされている。
  • すべてのコンポーネントが managed に設定された QuayRegistry
手順

このドキュメントの手順では、quay-enterprise の namespace を使用します。

  1. Red Hat Quay Operator をスケールダウンします。

    $ oc scale --replicas=0 deployment quay-operator.v3.6.2 -n openshift-operators
  2. アプリケーションをスケールダウンし、デプロイメントをミラーリングします。

    $ oc scale --replicas=0 deployment QUAY_MAIN_APP_DEPLOYMENT QUAY_MIRROR_DEPLOYMENT
  3. データベース SQL バックアップを Quay PostgreSQL データベースインスタンスにコピーします。

    $ oc cp /tmp/user/quay-backup/quay-database-backup.sql quay-enterprise/quayregistry-quay-database-54956cdd54-p7b2w:/var/lib/pgsql/data/userdata
  4. オペレーターが作成した config.yaml ファイルからデータベースパスワードを取得します。

    $ oc get deployment quay-quay-app -o json | jq '.spec.template.spec.volumes[].projected.sources' | grep -i config-secret

    出力例:

          "name": "QUAY_CONFIG_SECRET_NAME"
    $ oc get secret quay-quay-config-secret-9t77hb84tb -o json | jq '.data."config.yaml"' | cut -d '"' -f2 | base64 -d -w0 > /tmp/quay-backup/operator-quay-config-yaml-backup.yaml
    cat /tmp/quay-backup/operator-quay-config-yaml-backup.yaml | grep -i DB_URI

    出力例:

    postgresql://QUAY_DATABASE_OWNER:PASSWORD@DATABASE_HOST/QUAY_DATABASE_NAME
  5. データベース Pod 内でシェルを実行します。

    # oc exec -it quay-postgresql-database-pod -- /bin/bash
  6. psql を入力します。

    bash-4.4$ psql
  7. データベースを削除します。

    postgres=# DROP DATABASE "example-restore-registry-quay-database";

    出力例:

    DROP DATABASE
  8. 新しいデータベースを作成し、所有者を同じ名前に設定します。

    postgres=# CREATE DATABASE "example-restore-registry-quay-database" OWNER "example-restore-registry-quay-database";

    出力例:

    CREATE DATABASE
  9. データベースに接続します。

    postgres=# \c "example-restore-registry-quay-database";

    出力例:

    You are now connected to database "example-restore-registry-quay-database" as user "postgres".
  10. Quay データベースの pg_trmg エクステンションを作成します。

    example-restore-registry-quay-database=# create extension pg_trgm ;

    出力例:

    CREATE EXTENSION
  11. postgres CLI を終了して bash-4.4 を再入力します。

    \q
  12. PostgreSQL デプロイメントのパスワードを設定します。

    bash-4.4$ psql -h localhost -d "QUAY_DATABASE_NAME" -U QUAY_DATABASE_OWNER -W < /var/lib/pgsql/data/userdata/quay-database-backup.sql

    出力例:

    SET
    SET
    SET
    SET
    SET
  13. bash モードを終了します。

    bash-4.4$ exit
  14. Red Hat Quay Operator の新規設定バンドルを作成します。

    $ touch config-bundle.yaml
  15. 新規の config-bundle.yaml で、LDAP 設定、キー、古いレジストリーのその他の変更など、レジストリーに必要なすべての情報を含めます。以下のコマンドを実行して secret_keyconfig-bundle.yaml に移動します。

    $ cat /tmp/quay-backup/config.yaml | grep SECRET_KEY > /tmp/quay-backup/config-bundle.yaml
    注記

    すべての LDAP、OIDC、およびその他の情報を手動でコピーし、それを /tmp/quay-backup/config-bundle.yaml ファイルに追加する必要があります。

  16. OpenShift クラスター内に設定バンドルシークレットを作成します。

    $ oc create secret generic new-custom-config-bundle --from-file=config.yaml=/tmp/quay-backup/config-bundle.yaml
  17. Quay Pod をスケールアップします。

    $ oc scale --replicas=1 deployment quayregistry-quay-app
    deployment.apps/quayregistry-quay-app scaled
  18. ミラー Pod をスケールアップします。

    $ oc scale --replicas=1  deployment quayregistry-quay-mirror
    deployment.apps/quayregistry-quay-mirror scaled
  19. QuayRegistry CRD にパッチを適用し、新規カスタム設定バンドルへの参照が含まれるようにします。

    $ oc patch quayregistry QUAY_REGISTRY_NAME --type=merge -p '{"spec":{"configBundleSecret":"new-custom-config-bundle"}}'
    注記

    Quay が 500 の内部サーバーエラーを返した場合、DISTRIBUTED_STORAGE_CONFIGlocationdefault に更新する必要がある場合があります。

  20. /.aws/ ディレクトリーに新しい AWScredentials.yaml を作成し、Operator が作成した config.yaml ファイルから access_keysecret_key を含めます。

    $ touch credentials.yaml
    $ grep -i DISTRIBUTED_STORAGE_CONFIG -A10 /tmp/quay-backup/operator-quay-config-yaml-backup.yaml
    $ cat > ~/.aws/credentials << EOF
    [default]
    aws_access_key_id = ACCESS_KEY_FROM_QUAY_CONFIG
    aws_secret_access_key = SECRET_KEY_FROM_QUAY_CONFIG
    EOF
    注記

    aws cli`~/.aws/credentials file ファイルからaccess_key および secret_key を自動的に収集しない場合、aws configure を実行して手動でクレデンシャルを入力することで、それを設定できます。

  21. NooBaa の公開されているエンドポイントを記録します。

    $ oc get route s3 -n openshift-storage -o yaml -o jsonpath="{.spec.host}{'\n'}"
  22. バックアップデータを NooBaa バックエンドストレージに同期します。

    $ aws s3 sync --no-verify-ssl --endpoint-url https://NOOBAA_PUBLIC_S3_ROUTE /tmp/quay-backup/bucket-backup/* s3://QUAY_DATASTORE_BUCKET_NAME
  23. Operator のバックアップを最大 1 Pod にスケールアップします。

    $ oc scale –replicas=1 deployment quay-operator.v3.6.4 -n openshift-operators

Operator は提供されるカスタム設定バンドルを使用し、すべてのシークレットおよびデプロイメントを調整します。OpenShift Container Platform での新規 Quay デプロイメントには、以前のデプロイメントに含まれるすべての情報が含まれている必要があります。すべてのイメージはプル可能でなければなりません。

第17章 Red Hat Quay ガベージコレクション

17.1. Red Hat Quay ガベージコレクションについて

Red Hat Quay には、自動で継続的なイメージガベージコレクションが含まれています。ガベージコレクションは、関連付けられていないイメージやタグなしのイメージ、リポジトリー、レイヤーやマニフェストなどのブロブなど、かなりの量のディスクスペースを占めるオブジェクトを削除することで、アクティブオブジェクトのリソースを効率的に使用できるようにします。Red Hat Quay によって実行されるガベージコレクションは、組織の環境でのダウンタイムを減らすことができます。

17.2. 実際の Red Hat Quay ガベージコレクション

現在、すべてのガベージコレクションは慎重に行われます。ガベージコレクションを手動で実行するコマンドはありません。Red Hat Quay は、さまざまなガベージコレクションワーカーのステータスを追跡するメトリックを提供します。

namespace とリポジトリーのガベージコレクションの場合、進行状況はそれぞれのキューのサイズに基づいて追跡されます。namespace とリポジトリーのガベージコレクションワーカーが機能するには、グローバルロックが必要です。その結果、パフォーマンス上の理由から、一度に 1 人のワーカーのみが実行されます。

タグ付きイメージのガベージコレクションは、namespace またはリポジトリーでのガベージコレクションとは動作が異なります。タグ付けされたイメージのガベージコレクションワーカーは、処理するアイテムのキューを用意するのではなく、非アクティブまたは期限切れのタグを持つリポジトリーをアクティブに検索してクリーンアップします。ガベージコレクションワーカーの各インスタンスはリポジトリーロックを取得します。これにより、リポジトリーごとに 1 つのワーカーが生成されます。

ガベージコレクションのタイプごとに、Red Hat Quay は、各ガベージコレクションワーカーによって削除されたテーブルごとの行数のメトリックを提供します。次のイメージは、Red Hat Quay が同じメトリックを使用してガベージコレクションをモニターする方法の例を示しています。

Garbage collection metrics

17.2.1. ストレージ再生の測定

Red Hat Quay には、ガベージコレクションによって解放されたスペースの量を追跡する方法がありません。現在、これを示す最良の指標は、提供されたメトリックで削除された blob の数を確認することです。

注記

Red Hat Quay メトリックの UploadedBlob テーブルは、リポジトリーに関連付けられているさまざまな BLOB を追跡します。BLOB がアップロードされると、PUSH_TEMP_TAG_EXPIRATION_SEC パラメーターで指定された時間より前にガベージコレクションされません。これは、進行中のプッシュの一部である BLOB を時期尚早に削除することを回避するためです。たとえば、ガベージコレクションが頻繁に実行されるように設定されていて、タグが 1 時間以内に削除された場合、関連するブロブがすぐにクリーンアップされない可能性があります。代わりに、PUSH_TEMP_TAG_EXPIRATION_SEC パラメーターで指定された時間が経過したと仮定すると、次にガベージコレクションが同じリポジトリーで実行されるときに、関連する blob が削除されます。

17.3. ガベージコレクション設定フィールド

次の設定フィールドを使用して、ガベージコレクションの内容、およびガベージコレクションが発生する頻度をカスタマイズできます。

名前説明スキーマ

FEATURE_GARBAGE_COLLECTION

イメージタグに対してガベージコレクションが有効になっているかどうか。デフォルト値は true です。

Boolean

FEATURE_NAMESPACE_GARBAGE_COLLECTION

namespace に対してガベージコレクションが有効になっているかどうか。デフォルト値は true です。

Boolean

FEATURE_REPOSITORY_GARBAGE_COLLECTION

リポジトリーでガベージコレクションが有効になっているかどうか。デフォルト値は true です。

Boolean

GARBAGE_COLLECTION_FREQUENCY

ガベージコレクションワーカーが実行される頻度 (秒単位)。ガベージコレクションワーカーにのみ影響します。デフォルトは 30 秒です。

文字列

PUSH_TEMP_TAG_EXPIRATION_SEC

アップロード後にブロブがガベージコレクションされない秒数。この機能は、ガベージコレクションがまだ参照されていないが進行中のプッシュの一部として使用されている blob をクリーンアップするのを防ぎます。

文字列

TAG_EXPIRATION_OPTIONS

有効なタグの有効期限の値のリスト。

文字列

DEFAULT_TAG_EXPIRATION

タイムマシンの有効期限にタグを付けます。

文字列

17.4. ガベージコレクションの無効化

イメージタグ、namespace、およびリポジトリーのガベージコレクション機能は、config.yaml ファイルに保存されます。これらの機能のデフォルトは true です。

まれに、ガベージコレクションを無効にして、ガベージコレクションを実行するタイミングを制御したい場合があります。GARBAGE_COLLECTION 機能を false に設定すると、ガベージコレクションを無効にできます。無効にすると、関連付けれていない、またはタグが付いていないイメージ、リポジトリー、名前空間、レイヤー、マニフェストは削除されません。これにより、環境のダウンタイムが増加する可能性があります。

注記

ガベージコレクションを手動で実行するコマンドはありません。代わりに、ガベージコレクション機能を無効にしてから再度有効にします。

17.5. ガベージコレクションとクォータ管理

Red Hat Quay は、3.7 でクォータ管理を導入しました。クォータ管理により、ユーザーは、設定されたストレージクォータ制限を確立することにより、ストレージ消費を報告し、レジストリーの増加を抑えることができます。

Red Hat Quay 3.7 以降、ガベージコレクションは、削除後にイメージ、リポジトリー、および BLOB に割り当てられたメモリーを再利用します。ガベージコレクション機能は削除後にメモリーを再利用するため、環境のディスクスペースに格納されているものと、クォータ管理が総消費量としてレポートしているものとの間に不一致があります。現在、この問題に対する回避策はありません。

17.6. Red Hat Quay のガベージコレクションメトリック

次のメトリックは、ガベージコレクションによって削除されたリソースの数を示しています。これらのメトリックは、ガベージコレクションワーカーが実行された回数と、削除された namespace、リポジトリー、および BLOB の数を示します。

メトリクス名説明

quay_gc_iterations_total

GCWorker による反復の数

quay_gc_namespaces_purged_total

NamespaceGCWorker によってパージされる namespace 数

quay_gc_repos_purged_total

RepositoryGCWorker または NamespaceGCWorker がパージするリポジトリーの数

quay_gc_storage_blobs_deleted_total

削除されたストレージ Blob の数

メトリクスの出力サンプル

# TYPE quay_gc_iterations_created gauge
quay_gc_iterations_created{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 1.6317823190189714e+09
...

# HELP quay_gc_iterations_total number of iterations by the GCWorker
# TYPE quay_gc_iterations_total counter
quay_gc_iterations_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 0
...

# TYPE quay_gc_namespaces_purged_created gauge
quay_gc_namespaces_purged_created{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 1.6317823190189433e+09
...

# HELP quay_gc_namespaces_purged_total number of namespaces purged by the NamespaceGCWorker
# TYPE quay_gc_namespaces_purged_total counter
quay_gc_namespaces_purged_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 0
....

# TYPE quay_gc_repos_purged_created gauge
quay_gc_repos_purged_created{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 1.631782319018925e+09
...

# HELP quay_gc_repos_purged_total number of repositories purged by the RepositoryGCWorker or NamespaceGCWorker
# TYPE quay_gc_repos_purged_total counter
quay_gc_repos_purged_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 0
...

# TYPE quay_gc_storage_blobs_deleted_created gauge
quay_gc_storage_blobs_deleted_created{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 1.6317823190189059e+09
...

# HELP quay_gc_storage_blobs_deleted_total number of storage blobs deleted
# TYPE quay_gc_storage_blobs_deleted_total counter
quay_gc_storage_blobs_deleted_total{host="example-registry-quay-app-6df87f7b66-9tfn6",instance="",job="quay",pid="208",process_name="secscan:application"} 0
...

第18章 Red Hat Quay のトラブルシューティング

一般的な障害モードおよびリカバリーのベストプラクティス。

第19章 Red Hat Quay 設定のスキーマ

ほとんどの Red Hat Quay 構成情報は、Red Hat Quay が最初に展開されたときにブラウザベースの config ツールを使用して作成される config.yaml ファイルに保存されます。

設定オプションは、Red Hat Quay 設定ガイドで説明しています。

関連情報