Menu Close

Red Hat Quayの管理

Red Hat Quay 3

Red Hat Quayの管理

概要

Red Hat Quayの管理

前書き

Red Hat Quay レジストリを展開した後、その展開をさらに設定、管理する方法は数多くあります。ここでは、以下のようなトピックを取り上げています。

  • Red Hat Quayの高度な設定
  • Red Hat Quay の新リリースを知らせる通知の設定
  • SSLおよびTLS証明書による接続の保護
  • アクションログのストレージをElasticsearchに誘導する
  • Clairによるイメージセキュリティスキャンの設定
  • Container Security Operator でポッドイメージをスキャン
  • Quay Bridge OperatorでRed Hat QuayをOpenShiftに統合します。
  • リポジトリミラーリングによるイメージの反映
  • BitTorrentサービスによるQuay画像の共有
  • LDAPによるユーザーの認証
  • PrometheusとGrafanaのメトリクスにQuayを有効にする
  • ジオレプリケーションの設定
  • 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がすでに利用可能になっていると思います。コンフィグツールにアクセスするには、次のようにします。

  1. OpenShift コンソールから、Red Hat Quay が実行されているプロジェクトを選択します。(例えば、quay-enterprise)
  2. 左の列からネットワーク→ルートを選択します。次の画像に示すように、Red Hat Quay アプリケーションと Config Tool の両方へのルートが表示されます。

    View the route to the Red Hat Quay Config Tool

  3. Config Toolへのルート(例: example-quayecosystem-quay-config)を選択し、選択します。ブラウザにConfig tool 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を選択します。コンフィグツールが変更内容を検証します。
  6. 必要に応じて、Continue Editingを選択して修正するか、Nextを選択して次に進みます。
  7. プロンプトが表示されたら、Download Configurationを選択することをお勧めします。これにより、新しいconfig.yamlと、Red Hat Quayのセットアップで使用された証明書や鍵を含むtarボールがダウンロードされます。
  8. Go to deployment rolloutを選択し、Populate the configuration to deploymentsを選択します。Red Hat Quay のポッドが再起動され、変更が有効になります。

保存されたconfig.yamlファイルは、設定の高度な変更を行うために使用することも、今後の参考のために保存しておくこともできます。

1.1.2. コマンドラインからのコンフィグツールの実行

podmanコマンドやdockerコマンドなどのツールを使用してホストシステムから直接 Red Hat Quay を実行している場合は、最初の 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.6.5 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 Guideを参照してください。

1.3. config.yamlファイルを編集して Red Hat Quay を変更します。

Config Toolでは利用できない高度なRed Hat Quayの設定は、config.yamlファイルを直接編集することで実現できます。利用可能な設定は、Schema for Red Hat Quay configurationに記載されています。以下は、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']からTLS v1のサポートを削除するには、以下のように変更します。

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

1.3.3. APIコールのレート制限

config.yamlにFEATURE_RATE_LIMITSパラメータを追加すると、nginxは特定のAPIコールを1秒あたり30回に制限します。この機能が設定されていない場合、APIコールは1秒間に300回に制限されます(事実上無制限)。利用可能なリソースがトラフィックで圧迫されないようにする必要がある場合、レート制限は重要な機能となります。

名前空間の中には、無制限のアクセスを必要とするものもあります(例えば、CI/CDにとって重要であり、優先順位が高いなど)。この場合、それらの名前空間は、config.yamlのNON_RATE_LIMITED_NAMESPACESのリストに配置することができます。

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. データベース接続引数

Red Hat Quay のデータベース接続設定はconfig.yamlファイル内でカスタマイズすることができます。これらは、Postgres用のpsycopg2やMySQL用のpymysqlのように、基礎となるデータベースドライバに完全に依存しています。また、以下のように、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はノード上のプロセッサの合計数に基づいて計算します。記載されているデフォルト値は単なる目標値であり、最大値を超えてはならず、最小値を下回ってはならない。

以下の各プロセス量は、以下の環境変数を使ってオーバーライドすることができます。

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

    • 最小値: 8
    • 最大値: 64
    • デフォルト: $CPU_COUNT x 4
    • 環境変数: WORKER_COUNT_REGISTRY
  • web - ウェブベースのインターフェース用のHTTPエンドポイントを提供します

    • 最小値: 2
    • 最大値: 32
    • デフォルト: $CPU_COUNT x 2
    • 環境変数: 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_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.6.5 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.6.5 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 Customer Portalでアップデート通知に登録してください。通知に登録すると、Red Hat Quay の新しいバージョン、ドキュメントの更新、その他の Red Hat Quay のニュースをお知らせする通知を受け取ることができます。

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

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

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

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

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 の config ディレクトリの下に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.6.5 "/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はconfigアセットを保存するボリュームとしてシークレットにマウントします。残念ながら、これは現在、スーパーユーザーパネルの証明書のアップロード機能に干渉します。

このエラーを回避するには、Red Hat Quay が展開された後にbase64 エンコードされた証明書をシークレットに追加します。以下に、実行する方法を説明します。

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

    $ cat ca.crt
    -----BEGIN CERTIFICATE-----
    MIIDljCCAn6gAwIBAgIBATANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5MQUIu
    TElCQ09SRS5TTzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2
    MDExMjA2NTkxMFoXDTM2MDExMjA2NTkxMFowOTEXMBUGA1UECgwOTEFCLkxJQkNP
    UkUuU08xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZI
    [...]
    -----END CERTIFICATE-----
    
    $ cat ca.crt | base64 -w 0
    [...]
    c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
  2. kubectlツールを使って、quay-enterprise-config-secretを編集します。

    $ kubectl --namespace quay-enterprise edit secret/quay-enterprise-config-secret
  3. 証明書のエントリを追加し、エントリの下にbase64エンコードされた文字列を完全に貼り付けます。

      custom-cert.crt:
    c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
  4. 最後に、すべての Red Hat Quay ポッドをリサイクルします。kubectl deleteを使用して、すべての Red Hat Quay ポッドを削除します。Red Hat Quay Deployment は、新しい証明書データを使用して交換用ポッドを自動的にスケジュールします。

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

デフォルトでは、過去3ヶ月分の使用ログがRed Hat Quayデータベースに保存され、組織レベルとリポジトリレベルでウェブ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: 必要に応じて、Elasticsearchサービスにアクセスするために必要なアクセスキーです。
    • Elasticsearch secret key: 必要に応じて、Elasticsearchサービスにアクセスするために必要な秘密鍵。
    • AWS region: AWS上で運用している場合は、AWSリージョンを設定します(そうでない場合は、空欄のままです)。
    • Index prefix: ログエントリに付けるプレフィックスを選択します。
    • Logs Producer: Elasticsearch(デフォルト)またはKinesisのいずれかを選択し、ログをAWS上の中間的なKinesisストリームに導きます。KinesisからElasticsearch(Logstashなど)にログを送るためには、独自のパイプラインを設定する必要があります。次の図は、Kinesisに必要な追加フィールドを示しています。

      On AWS optionally set up an intermediate Kinesis stream

  5. Logs ProducerとしてElasticsearchを選択した場合、これ以上の設定は必要ありません。Kinesisを選択した場合、以下を記入してください。

    • ストリーム名: Kinesisのストリームの名前です。
    • AWS access key: Kinesisストリームへのアクセスを得るために必要なAWSアクセスキーの名前(必要な場合)。
    • AWS secret key: Kinesisストリームにアクセスするために必要なAWSのシークレットキーの名前(必要な場合)。
    • AWS region: AWSのリージョンです。
  6. 完了したら、設定を保存します。Config Tool が設定内容を検証します。ElasticsearchまたはKinesisサービスへの接続に問題がある場合は、エラーが表示され、編集を続ける機会が与えられます。そうしないと、新しい設定に伴いでクラスタが再起動した後に、ロギングがあなたのElasticsearch設定に対して開始されます。

第7章 クレアセキュリティスキャン

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

クレアは、以下の脆弱性データベースを利用して、お客様の画像の問題点をスキャンします。

  • アルパイン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 (image registry.redhat.io/quay/clair-rhel8)が以前のClair V2 (image 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で使用するClairconfig.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の設定フォーマットについての詳細は、upstream Clair documentationに記載されています。

  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.6.5  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_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 のポッドを再起動する必要があります。quay-appのポッドを削除するだけで、更新された構成のポッドがデプロイされます。

この時点で、名前空間のホワイトリストで特定された組織の画像は、Clair v4によってスキャンされます。

7.2. OpenShiftではないRed Hat QuayのデプロイメントにClairをセットアップする

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

  1. (フォールトトレラントが望ましい)Postgresデータベースサーバを導入します。なお、ClairはPostgresデータベースにuuid-osspエクステンションを追加する必要があります。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の設定フォーマットについての詳細は、upstream Clair documentationに記載されています。

  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.6.5
  2. 新しいClair V4エンドポイントを使用するためにRed Hat Quayを設定するには、前のセクションの残りの指示に従ってください。

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

7.3. クレールの使用

  1. Red Hat Quayクラスターにログインし、Clairスキャンを設定した組織を選択します。
  2. その組織からいくつかの画像を保持するリポジトリを選択し、左のナビゲーションから「タグ」を選択します。次の図は、2枚の画像がスキャンされたリポジトリの例です。

    Security scan information appears for scanned repository images

  3. 脆弱性が発見された場合、画像のセキュリティスキャン欄を選択すると、すべての脆弱性または修正可能な脆弱性が表示されます。次の図は、見つかったすべての脆弱性の情報を示しています。

    See all vulnerabilities or only those that are fixable

7.4. 脆弱性情報データベース (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.5. 切断された環境のためのClairの設定

Clairは、アップデータと呼ばれる一連のコンポーネントを利用して、様々な脆弱性データベースからのデータのフェッチとパースを処理します。これらのアップデータは、インターネットから直接脆弱性データを取得するようにデフォルトで設定されており、すぐに使用することができます。インターネットに直接アクセスできない切断された環境にいるお客様にとっては、これは問題となります。クレアは、ネットワークの分離を考慮した様々なタイプのアップデートワークフローに対応することで、これらの環境をサポートします。clairctlコマンドラインユーティリティを使用すると、どのプロセスでも、オープンホスト経由でインターネットからアップデータを取得し、そのデータを隔離されたホストに安全に転送し、隔離されたホスト上のアップデータをClair本体にインポートすることが簡単にできます。

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

  1. まず、Clairの設定で、自動化されたアップデータの実行が無効になっていることを確認してください。

    config.yaml

    matcher:
      disable_updaters: true

  2. 最新のアップデータをローカルのアーカイブに書き出します。このためには、バイナリとして直接実行するか、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.6.5 --config /cfg/config.yaml export-updaters  /updaters/updaters.gz

    なお、Clairの設定を細かく参照する必要があります。これにより、/etc/clairv4/updaters/updaters.gzにアップデータのアーカイブが作成されます。ソースデータベースからエラーなくアーカイブが作成されたことを確認したい場合は、clairctl--strictフラグを指定します。アーカイブファイルは、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.6.5 --config /cfg/config.yaml import-updaters /updaters/updaters.gz

7.6. 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.7. 追加情報

マイクロサービスがどのように構成されているかなど、Clairの内部に関する詳細なドキュメントは、Upstream ClairおよびClairCoreのドキュメントを参照してください。

第8章 Container Security Operator でポッドイメージをスキャン

Container Security Operator(CSO)を使用すると、OpenShift(4.2以降)やその他のKubernetesプラットフォーム上で動作するアクティブなポッドに関連するコンテナイメージをスキャンし、既知の脆弱性を確認することができます。CSV

  • すべての 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 SecurityOperatorが表示されます。
  2. Container Security Operator を選択し、Install を選択して Create Operator Subscriptionページに移動します。
  3. 設定(デフォルトでは、全ネームスペースと自動承認戦略)を確認し、Subscribeを選択します。しばらくすると、Installed Operators画面にContainer Securityが表示されます。
  4. オプションで、カスタム証明書を CSO に追加できます。以下の例では、現在のディレクトリーに quay.crt という名前の証明書を作成します。その後、次のコマンドを実行して、CSOに証明書を追加します(新しい証明書を有効にするために、Operatorポッドを再起動します)。

    $ 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画面が表示され、選択したイメージの名前と、そのイメージが実行されているすべてのネームスペースが表示されます。次の図は、ある脆弱なイメージが2つのネームスペースで実行されていることを示しています。

      View namespaces a vulnerable image is running in

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

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

なお、ポッドを削除した場合、ダッシュボード上で脆弱性がリセットされるまでに数分かかることがあります。

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章 Bridge Operator でRed Hat QuayをOpenShiftに統合する

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

Bridge Operatorの主な目的は、統合されたOpenShiftレジストリの機能を、新しいRed Hat Quayレジストリに複製することです。このオペレーターで可能な機能は以下の通りです。

  • Red Hat Quay の組織として OpenShift の名前空間を同期させます。

    • デフォルトネームスペースのサービスアカウントごとのロボットアカウントの作成
    • 作成されたロボットアカウントごとにシークレットを作成(各ロボットシークレットをサービスアカウントにMountableとImage Pull Secretとして関連付ける)。
    • OpenShiftのImageStreamをQuayのリポジトリとして同期させる
  • Red Hat Quay に出力するために ImageStream を使用して新しいビルドを自動的に書き換えます。
  • ビルドが完了すると自動的にImageStreamタグをインポートする

Quay Bridge Operator でこの手順を使用すると、Red Hat Quay と OpenShift クラスター間の双方向通信が有効になります。

9.1. Quay Bridge Operator の実行

9.1.1. 前提条件

Bridge Operatorをセットアップする前に、以下のものを用意してください。

  • スーパーユーザー権限を持つ既存の Red Hat Quay 環境
  • クラスタ管理者権限を持つRed Hat OpenShift Container Platform環境(4.2以降を推奨)。
  • OpenShiftのコマンドラインツール(ocコマンド)

9.1.2. OpenShiftとRed Hat Quayのセットアップと設定

Red Hat QuayとOpenShiftの両方の設定が必要です。

9.1.3. Red Hat Quay のセットアップ

Red Hat Quay の専用組織を作成し、その組織内で作成した新規アプリケーションから、OpenShift の Quay Bridge Operator で使用する OAuth トークンを生成します。

  1. スーパーユーザー権限を持つユーザーとしてRed Hat Quayにログインし、外部アプリケーションを設定する組織を選択します。
  2. 左のナビゲーションで Applications を選択します。
  3. Create New Applicationを選択し、新しいアプリケーションの名前を入力します(例: openshift)。
  4. 新しいアプリケーションが表示された状態で、それを選択します。
  5. 左側のナビゲーションでGenerate Tokenを選択し、新しいOAuth2トークンを作成します。
  6. すべてのチェックボックスを選択して、統合に必要なアクセスを許可します。
  7. 割り当てられた権限を確認し、Authorize Applicationを選択して確認します。
  8. 生成されたAccess Tokenは、次のセクションで使用するためにコピーして保存します。

9.1.4. OpenShift のセットアップ

Quay Bridge OperatorにOpenShiftをセットアップするには、以下のようないくつかのステップが必要です。

9.1.4.1. Operator のデプロイ

Operator をデプロイする最も高速な方法は、OperatorHub からデプロイすることです。OpenShift Web コンソールの Administrator パースペクティブで、Operators タブに移動し、OperatorHub を選択します。

Quay Bridge Operator を検索し、Install を選択します。

Approval Strategy を選択して、Install を選択すると、Operator をクラスターにデプロイします。

9.1.4.2. OAuth トークンの OpenShift シークレットの作成

Operator は以前に取得したアクセストークンを使用して Quay と通信します。このトークンをシークレットとして OpenShift に保存します。

以下のコマンドを実行して、アクセストークンが含まれる token というキーを使用して、openshift-operators namespace に quay-integration というシークレットを作成します。

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

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

最後に、OpenShift と Quay の間のインテグレーションを完了するには、QuayIntegration カスタムリソースを作成する必要があります。これは、Web コンソールまたはコマンドラインから実行できます。

quay-integration.yaml

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
Quayが自己署名証明書を使用している場合、プロパティinsecureRegistry: trueを設定します。

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

$ oc create -f quay-integration.yaml

この時点でQuayの統合リソースが作成され、OpenShiftクラスタとRed Hat Quayインスタンスがリンクされます。Quay 内の組織は、OpenShift 環境の関連の namespace 用に作成する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

設計されている機能

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

独立した異なるレジストレーション

レプリケーションやミラーリングがまだ完了していない場合はどうなりますか?

リモートコピーを使用する(遅くなります)

画像が表示されない

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

はい(すべてのRed Hat Quayノード)。

いいえ(個別のストレージ

ユーザーは両方のサイトの画像を同じリポジトリにプッシュできますか?

不可

すべてのレジストリの内容と構成がすべての地域で同一であるか(共有データベース

不可

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

デフォルトでは、いいえ。

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

不可

Yes

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

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

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

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

ブール値

リポジトリーミラーリングを有効化または無効化します

デフォルト: false

 

 

 

REPO_MIRROR_INTERVAL

数値

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

REPO_MIRROR_SERVER_HOSTNAME

文字列

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

デフォルト: None

:
openshift-quay-service

REPO_MIRROR_TLS_VERIFY

ブール値

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.6.5 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.6.5 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. パターン構文

パターン

説明

*

すべての文字にマッチする

?

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

[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ページからミラーリングしたリポジトリを選択し、以下のいずれかの操作を行います。

  • リポジトリの有効化/無効化: 左列のミラーリングボタンを選択し、「有効」のチェックボックスを切り替えて、リポジトリを一時的に有効または無効にします。
  • ミラーログの確認ミラーリングされたリポジトリが正常に動作していることを確認するために、ミラーログを確認することができます。そのためには、左カラムのUsage Logsボタンを選択します。以下に例を示します。

    View logs for your Red Hat Quay repo mirror

  • 今すぐミラーを同期リポジトリ内のイメージをすぐに同期するには、Sync Nowボタンを選択します。
  • クレデンシャルを変更する。ユーザー名とパスワードを変更するには、Credentialsの行からDELETEを選択します。その後、「なし」を選択し、プロンプトが表示されたら、外部レジストリにログインするために必要なユーザー名とパスワードを追加します。
  • ミラーリングをキャンセルする: ミラーリングを中止するには、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は、Quayがすでに稼働している他のノードを含め、どのノードでも実行できます。
  • リポジトリのミラーリングは、データベースでスケジュールされ、一括して実行されます。その結果、ワーカーが増えれば、より多くのバッチが処理されるため、ミラーリングが速くなる可能性があります。
  • ミラーリングPodの最適な数は、以下の要素により変わります。

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

第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 の設定

設定ツールで認証の項目を探し、ドロップダウンメニューから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は、提供されたSSL証明書を使用してTLSの設定を行います。
  • 以下は、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
  • すべてのユーザーのLDAPレコードを検索するための第二のベースパスとなる、上記で定義したベースDNに相対する識別名パスのリスト(オプション)。これらのパスは、プライマリの相対的なDNでユーザーを見つけられなかった場合に試行されます。
  • User Relative DNはBaseDNからの相対的なものです。例: ou=NYC であり、ou=NYC,dc=example,dc=orgではない。
  • ユーザーオブジェクトが配置されているOrganizational Unitが複数ある場合は、Secondary User Relative DNを複数入力することができます。複数のRDNを追加するには、Organizational Unitを入力してAddボタンをクリックします。例: ou=Users,ou=NYC および ou=Users,ou=SFO
  • User Relative DN はサブツリーのスコープで検索します。例えば、組織がUsers OUの下にNYCとSFOのOrganizational Unitを持っている場合ou=SFO,ou=Usersおよびou=NYC,ou=Users)、User Relative DNがUsers(ou=Users)に設定されていれば、Red Hat QuayはNYCSFOの両方のOrganizational Unitからユーザーを認証することができます。
  • 以下は、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

  • 管理者アカウントのDistinguished Name(識別名)とPassword(パスワード)。このアカウントは、ログインしてすべてのユーザーアカウントの記録を閲覧できる必要があります。例: 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属性は、ユーザー名として使用するLDAPユーザーレコードのプロパティフィールドの名前です。一般的には、uid です。
  • Mail属性は、LDAPユーザーレコードのプロパティフィールドの名前で、ユーザーの電子メールアドレスが格納されています。一般的には mailです。
  • いずれもログイン時に使用することができます。
  • ログインしたユーザー名がUser Relative 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

すべての検証が成功しないと先に進めません。また、編集を続けるボタンを選択して追加の設定を行うこともできます。

11.3. 共通の課題

無効な認証情報

Administrator DNまたはAdministrator DN Passwordの値が正しくない

スーパーユーザー %USERNAME% の検証に失敗しました。ユーザー名が見つかりません ユーザーがリモート認証システムに存在しないか、LDAP認証の設定が間違っています。

Red Hat Quay は Administrator DN フィールドで指定された Username/Password で LDAP サーバーに接続できますが、User Relative DN Path の UID Attribute または Mail Attribute フィールドで現在ログインしているユーザーを見つけることができません。現在ログインしているユーザーがUser Relative DN Pathに存在しないか、Administrator 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.6.5

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

$ 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 インスタンスにアクセスする方法が必要です。典型的なセットアップでは、すべての Red Hat Quay インスタンスを単一の名前付き DNS エントリにリストアップし、それを 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章 Geo レプリケーション

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

注記

OpenShift での geo-replication を使用した Red Hat Quay のデプロイは Operator ではサポートされません。

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

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

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

  • 1つのデータベース、つまりすべてのメタデータとQuayの設定がすべてのリージョンで共有されます。
  • 1つのRedisキャッシュはQuayのセットアップ全体で共有され、すべてのQuayPodからアクセスできる必要があります。
  • ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数を使用して明示的に設定できます。
  • Geo レプリケーションでは、各リージョンにオブジェクトストレージが必要です。ローカルストレージやNFSでは動作しません。
  • 各リージョンは、各リージョンのすべてのストレージエンジンにアクセスできる必要があります(ネットワークパスが必要)。
  • また、ストレージプロキシオプションを使用することもできます。
  • ストレージのバックエンド全体(すべてのblob)が複製されます。これは、組織やリポジトリ、イメージに限定することができるリポジトリミラーリングとは対照的です。
  • すべての Quay インスタンスは、ロードバランサーを介して同じエントリーポイントを共有する必要があります。
  • すべてのQuayインスタンスは、共通の設定ファイルで定義された同じスーパーユーザーのセットを持つ必要があります。

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

13.3. Geo レプリケーションのアーキテクチャ

Georeplication

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

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

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

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

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

13.4.1. ストレージの環境設定によるRed Hat Quayの実行

  1. config.yaml を Red Hat Quay を実行しているすべてのマシンにコピーします。
  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.6.5
    注記

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

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

第14章 Red Hat Quay のトラブルシューティング

一般的な故障モードと復旧のためのベストプラクティス

第15章 Red Hat Quay の設定用スキーマ

ほとんどの Red Hat Quay 構成情報は、Red Hat Quay が最初に展開されたときにブラウザベースの config ツールを使用して作成されるconfig.yamlファイルに保存されます。

設定オプションは『Red Hat Quay Configuration Guide』で説明されています。

関連情報