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 レプリケーションの設定
- Quay のトラブルシューティング
第1章 Red Hat Quay の高度な設定
以下のインターフェイスのいずれかを使用して、初期デプロイメント後に Red Hat Quay を設定できます。
-
Red Hat Quay 設定ツール。このツールにより、
Quay
コンテナーをconfig
モードで実行する際に、Red Hat Quay クラスターを設定するための Web ベースのインターフェイスが提供されます。この方法は、Red Hat Quay サービスを設定する場合に推奨されます。 -
config.yaml
の編集。config.yaml
ファイルには、Red Hat Quay クラスターのほとんどの設定情報が含まれています。config.yaml
ファイルを直接編集することは可能ですが、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
コンテナーを実行して利用できます。
以下のセクションを使用して、Red Hat Quay Operator から Config Tool を実行するか、コマンドラインインターフェイス (CLI) からホストシステムで Config Tool を実行します。
1.1.1. Red Hat Quay Operator からの Config Tool の実行
OpenShift Container Platform で Red Hat Quay Operator を実行すると、Config Tool をすぐに使用できます。以下の手順を使用して、Red Hat Quay Config Tool にアクセスします。
前提条件
- Red Hat Quay Operator を OpenShift Container Platform にデプロイしている。
手順
-
OpenShift コンソールで、
quay-enterprise
などの Red Hat Quay プロジェクトを選択します。 ナビゲーションペインで Networking → Routes を選択します。次のイメージに示すように、Red Hat Quay アプリケーションと Config Tool の両方へのルートが表示されます。
-
Config Tool へのルート (例:
example-quayecosystem-quay-config
) を選択します。ブラウザーに Config Tool UI が表示されます。 Modify configuration for this cluster を選択して、Config Tool のセットアップを表示します。次に例を示します。
- 必要な変更を行い、Save Configuration Changes を選択します。
- Continue Editing をクリックして必要な修正を行うか、Next を選択して続行します。
-
プロンプトが表示されたら、Download Configuration を選択します。これにより、新しい
config.yaml
の tarball と、Red Hat Quay のセットアップで使用された証明書や鍵がダウンロードされます。config.yaml
を使用して、設定に高度な変更を加えたり、将来の参照として使用したりできます。 - Go to deployment rollout → Populate the configuration to deployments を選択します。Red Hat Quay Pod が再起動し、変更が有効になるのを待ちます。
1.1.2. コマンドラインからの Config Tool の実行
ホストシステムから Red Hat Quay を実行している場合は、以下の手順を使用して、初期デプロイメント後に設定を変更できます。
前提条件
-
podman
またはdocker
がインストールされていること。
-
- 設定モードで Red Hat Quay を起動します。
最初の
Quay
ノードで、次のコマンドを入力します。$ podman run --rm -it --name quay_config -p 8080:8080 \ -v path/to/config-bundle:/conf/stack \ {productrepo}/{quayimage}:{productminv} config <my_secret_password>
注記既存の設定バンドルを変更するには、設定ディレクトリーを
Quay
コンテナーにマウントできます。-
Red Hat Quay 設定ツールが起動したら、ブラウザーを開き、設定ファイルで使用されている URL とポート (例:
quay-server.example.com:8080
) に移動します。 - ユーザー名およびパスワードを入力します。
- 必要に応じて Red Hat Quay クラスターを変更します。
1.1.3. TLS 証明書を使用した設定ツールのデプロイ
環境変数をランタイム変数に渡すことで、セキュアな TLS 証明書を使用して設定ツールをデプロイできます。これにより、データベースやストレージバックエンドの認証情報などの機密データが確実に保護されます。
公開鍵と秘密鍵には、設定ツールをデプロイするルートの有効なサブジェクト代替名 (SAN) が含まれている必要があります。
パスは CONFIG_TOOL_PRIVATE_KEY
および CONFIG_TOOL_PUBLIC_KEY
を使用して指定できます。
コンテナーからデプロイを実行している場合、CONFIG_TOOL_PRIVATE_KEY
値と CONFIG_TOOL_PUBLIC_KEY
値は、コンテナー内の証明書の場所になります。以下はその例です。
$ podman run --rm -it --name quay_config -p 7070:8080 \ -v ${PRIVATE_KEY_PATH}:/tls/localhost.key \ -v ${PUBLIC_KEY_PATH}:/tls/localhost.crt \ -e CONFIG_TOOL_PRIVATE_KEY=/tls/localhost.key \ -e CONFIG_TOOL_PUBLIC_KEY=/tls/localhost.crt \ -e DEBUGLOG=true \ -ti config-app:dev
1.2. API を使用した Red Hat Quay の変更
Red Hat Quay API へのアクセス方法については、Red Hat Quay API ガイド を参照してください。
1.3. config.yaml
ファイルを編集して Red Hat Quay の変更
Config Tool では使用できない一部の高度な設定機能は、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 回に制限します。FEATURE_RATE_LIMITS
が設定されていない場合、API 呼び出しは 1 秒あたり 300 回に制限され、実質的に無制限になります。
レート制限は、使用可能なリソースがトラフィックで圧倒されないようにする必要がある場合に重要です。
一部の名前空間は、CI/CD にとって重要であり、優先される場合など、無制限のアクセスが必要になる場合があります。このシナリオでは、これらの名前空間は、NON_RATE_LIMITED_NAMESPACES
を使用して config.yaml
ファイルのリストに配置される場合があります。
1.3.4. データベースのコネクションプールの調整
Red Hat Quay は、すべてが同じコンテナー内で実行する多くの異なるプロセスで設定されています。これらのプロセスの多くは、データベースと連動しています。
DB_CONNECTION_POOLING
パラメーターを使用すると、データベースと対話する各プロセスに接続プールが含まれます。これらのプロセスごとの接続プールは、最大 20 の接続を維持するように設定されます。高負荷時には、Red Hat Quay コンテナー内のすべてのプロセスの接続プールを満たすことが可能です。特定のデプロイメントや負荷の下では、Red Hat Quay がデータベースの設定された最大接続数を超えないようにするために分析が必要になる場合があります。
時間が経つと、接続プールはアイドル接続を解放します。すべての接続をすぐに解除するには、Red Hat Quay の再起動が必要です。
DB_CONNECTION_POOLING
を true
または false
に設定することで、データベース接続プールを切り替えることができます。以下はその例です。
--- DB_CONNECTION_POOLING: true ---
DB_CONNECTION_POOLING
が有効になっている場合、config.yaml
の DB_CONNECTION_ARGS
で接続プールの最大サイズを変更できます。以下はその例です。
--- 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 接続引数
次の YAML は、サンプルの PostgreSQL SSL 設定を示しています。
--- DB_CONNECTION_ARGS: sslmode: verify-ca sslrootcert: /path/to/cacert ---
sslmode
パラメーターは、安全な SSL TCP/IP 接続がサーバーにネゴシエートされるかどうか、その優先度を決定します。sslmode
パラメーターには 6 つのモードがあります。
- disabl: SSL 以外の接続のみを試行します。
- allow: 最初に SSL 以外の接続を試行します。失敗した場合は、SSL 接続を試みます。
- prefer: デフォルト。最初に SSL 接続を試してください。失敗した場合は、SSL 以外の接続を試してください。
-
require: SSL 接続のみを試行します。ルート CA ファイルが存在する場合は、
verify-ca
が指定された場合と同じ方法で接続を検証します。 - verify-ca: SSL 接続のみを試行し、信頼された認証局 (CA) によりサーバー証明書が発行されていることを確認します。
- verify-full: SSL 接続のみを試行します。信頼された CA によりサーバー証明書が発行され、要求されたサーバーのホスト名が証明書のホスト名と一致することを確認します。
PostgreSQL の有効な引数の詳細は、Database Connection Control Functions を参照してください。
1.3.4.2.2. MySQL SSL 接続引数
次の YAML は、サンプルの MySQL SSL 設定を示しています。
--- DB_CONNECTION_ARGS: ssl: ca: /path/to/cacert ---
MySQL の有効な接続引数の詳細については、Connecting to the Server Using URI-Like Strings or Key-Value Pairs を参照してください。
1.3.4.3. HTTP 接続回数
環境変数を使用して、HTTP の同時接続数を指定することができます。環境変数は、全体として、または特定のコンポーネントに対して指定できます。それぞれのデフォルトは、1 プロセスあたり 50 並列接続です。環境変数の例については、次の YAML を参照してください。
--- 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 では、環境変数を使用してデフォルトの動作をオーバーライドすることができます。以下の表では、各変数と、使用できる値を一覧にして説明しています。
変数 | 説明 | 値 |
---|---|---|
WORKER_COUNT_REGISTRY |
| 8 ~ 64 の整数 |
WORKER_COUNT_WEB | コンテナー内で UI/Web リクエストを処理するプロセスの数を指定します。 | 2 ~ 32 の整数 |
WORKER_COUNT_SECSCAN | コンテナー内でセキュリティースキャン (Clair など) の統合を処理するプロセス数を指定します。 | 2 ~ 4 の整数 |
DB_CONNECTION_POOLING | データベースのコネクションプーリングを切り替えます。 | 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.13 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.13 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 のニュースをお知らせする通知を受け取ることができます。
- Red Hat カスタマーアカウントの認証情報を使用して Red Hat カスタマーポータル にログインします。
- ユーザー名 (右上隅) を選択して、Red Hat アカウントとカスタマーポータルの選択を表示します。
- Notifications を選択します。あなたのプロフィール活動ページが表示されます。
- Notifications タブを選択します。
- Manage Notifications を選択します。
- Follow を選択し、ドロップダウンボックスから Product を選択します。
- 製品の横にあるドロップダウンボックスで、Red Hat Quay を検索して選択します。
- 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. 認証局の作成
ルート CA キーを生成します。
$ openssl genrsa -out rootCA.key 2048
ルート CA 証明書を生成します。
$ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem
サーバーのホスト名など、証明書の要求に組み込まれる情報を入力します。以下に例を示します。
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. 証明書に署名
サーバーキーを生成します。
$ openssl genrsa -out ssl.key 2048
署名要求を生成します。
$ openssl req -new -key ssl.key -out ssl.csr
サーバーのホスト名など、証明書の要求に組み込まれる情報を入力します。以下に例を示します。
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
以下のようにサーバーのホスト名を指定して、設定ファイルの
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
設定ファイルを使用して、証明書
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 の設定
別の方法として、コマンドラインインターフェイスを使用できます。
証明書ファイルとプライマリーキーファイルを設定ディレクトリーにコピーして、それぞれ
ssl.cert
とssl.key
という名前が付けられていることを確認します。$ cp ~/ssl.cert $QUAY/config $ cp ~/ssl.key $QUAY/config $ cd $QUAY/config
config.yaml
ファイルを編集し、Quay で TLS を処理できるように指定します。config.yaml
... SERVER_HOSTNAME: quay-server.example.com ... PREFERRED_URL_SCHEME: https ...
Quay
コンテナーを停止し、レジストリーを再起動します。$ 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.13
4.4. UI を使用した SSL の設定
このセクションでは、Quay UI を使用して SSL を設定します。コマンドラインインターフェイスを使用して SSL を設定するには、以下のセクションを参照してください。
Quay
コンテナーを設定モードで起動します。$ sudo podman run --rm -it --name quay_config -p 80:8080 -p 443:8443 registry.redhat.io/quay/quay-rhel8:v3.7.13 config secret
-
Server Configuration セクションで、TLS に
Red Hat Quay handle TLS
を選択します。先に作成した証明書ファイルとプライベートキーファイルをアップロードし、証明書の作成時に Server Hostname が使用された値と一致することを確認します。更新された設定を検証およびダウンロードします。 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.13
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
)、ブラウザーは潜在的なリスクについて警告します。
画面にログインすると、ブラウザーは接続が安全ではないことを通知します。
ルート認証局 (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. 認証局を信頼するようにシステムを設定
ルート CA ファイルを統合されたシステム全体のトラストストアにコピーします。
$ sudo cp rootCA.pem /etc/pki/ca-trust/source/anchors/
システム全体のトラストストア設定を更新します。
$ sudo update-ca-trust extract
trust list
コマンドを使用して、Quay サーバーが設定されていることを確認できます。$ trust list | grep quay label: quay-server.example.com
https://quay-server.example.com
でレジストリーを参照すると、接続が安全であることを示すロックアイコンが表示されます。システム全体の信頼からルート 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 に追加
コンテナーに追加される証明書を表示します。
$ cat storage.crt -----BEGIN CERTIFICATE----- MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV [...] -----END CERTIFICATE-----
certs ディレクトリーを作成し、そこに証明書をコピーします。
$ mkdir -p quay/config/extra_ca_certs $ cp storage.crt quay/config/extra_ca_certs/ $ tree quay/config/ ├── config.yaml ├── extra_ca_certs │ ├── storage.crt
Quay
コンテナーのCONTAINER ID
をpodman ps
で取得します。$ sudo podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS 5a3e82c4a75f <registry>/<repo>/quay:v3.7.13 "/sbin/my_init" 24 hours ago Up 18 hours 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 443/tcp grave_keller
その ID でコンテナーを再起動します。
$ sudo podman restart 5a3e82c4a75f
コンテナーの名前空間にコピーされた証明書を調べます。
$ sudo podman exec -it 5a3e82c4a75f cat /etc/ssl/certs/storage.pem -----BEGIN CERTIFICATE----- MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV
5.2. Kubernetes へのデプロイ時に証明書を追加
Kubernetes にデプロイすると、Red Hat Quay は config アセットを保存するボリュームとしてシークレットにマウントします。残念ながら、これは現在、スーパーユーザーパネルの証明書のアップロード機能に干渉します。
このエラーを回避するには、Red Hat Quay が展開された 後に base64 エンコードされた証明書をシークレットに追加します。以下に、実行する方法を説明します。
まず、証明書の内容を Base64 エンコードします。
$ cat ca.crt -----BEGIN CERTIFICATE----- MIIDljCCAn6gAwIBAgIBATANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5MQUIu TElCQ09SRS5TTzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2 MDExMjA2NTkxMFoXDTM2MDExMjA2NTkxMFowOTEXMBUGA1UECgwOTEFCLkxJQkNP UkUuU08xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZI [...] -----END CERTIFICATE----- $ cat ca.crt | base64 -w 0 [...] c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
kubectl
ツールを使用して、quay-enterprise-config-secret を編集します。$ kubectl --namespace quay-enterprise edit secret/quay-enterprise-config-secret
証明書のエントリーを追加し、エントリーの下に base64 エンコードされた文字列を完全に貼り付けます。
custom-cert.crt: c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
-
最後に、すべての Red Hat Quay Pod をリサイクルします。
kubectl delete
を使用して、すべての Red Hat Quay Pod を削除します。Red Hat Quay Deployment は、新しい証明書データを使用して交換用 Pod を自動的にスケジュールします。
第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 を使用するように変更するための設定方法を説明します。
- Elasticsearch のアカウントを取得します。
- Red Hat Quay Config Tool を開きます (Red Hat Quay のデプロイ中またはデプロイ後)。
Action Log Storage Configuration 設定までスクロールし、Database の代わりに Elasticsearch を選択します。次の図は、表示される Elasticsearch の設定です。
使用する 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 に必要な追加フィールドを示しています。
Logs Producer として Elasticsearch を選択した場合、これ以上の設定は必要ありません。Kinesis を選択した場合、以下を記入してください。
- ストリーム名: Kinesis のストリームの名前。
- AWS access key: Kinesis ストリームへのアクセスを得るために必要な AWS アクセスキーの名前 (必要な場合)。
- AWS secret key: Kinesis ストリームにアクセスするために必要な AWS シークレットキーの名前 (必要な場合)。
- AWS region: AWS のリージョン。
- 完了したら、設定を保存します。Config Tool が設定内容を検証します。Elasticsearch または Kinesis サービスへの接続に問題がある場合は、エラーが表示され、編集を続ける機会が与えられます。そうしないと、新しい設定に伴いでクラスターが再起動した後に、ロギングがあなたの Elasticsearch 設定に対して開始されます。
第7章 Clair セキュリティースキャン
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 V2 (image quay.io/redhat/clair-jwt) が新しい Clair V4 (image registry.redhat.io/quay/clair-rhel8) に完全に置き換わりました。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 と一緒に手動で設定します。
現在のプロジェクトを、Red Hat Quay が実行されているプロジェクトの名前に設定します。以下に例を示します。
$ oc project quay-enterprise
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
以下のように、postgres データベースをデプロイします。
$ oc create -f ./clairv4-postgres.yaml
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 ドキュメント に記載されています。
Clair の
config.yaml
からシークレットを作成します。$ oc create secret generic clairv4-config-secret --from-file=./config.yaml
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.13 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
以下のように Clair v4 の配置を作成します。
$ oc create -f ./clair-combo.yaml
Red Hat Quay 配置の
config.yaml
ファイルを変更して、最後に以下のエントリーを追加します。FEATURE_SECURITY_NOTIFICATIONS: true FEATURE_SECURITY_SCANNER: true SECURITY_SCANNER_V4_ENDPOINT: http://clairv4 1
- 1
- Clair v4 サービスのエンドポイントの特定
修正した
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
-
新しい
config.yaml
を有効にするには、Red Hat Quay の Pod を再起動する必要があります。quay-app
の Pod を削除するだけで、更新された設定の Pod がデプロイされます。
この時点で、名前空間のホワイトリストで特定された組織のイメージは、Clair v4 によってスキャンされます。
7.2. OpenShift ではない Red Hat Quay のデプロイメントに Clair をセットアップ
OpenShift 上で稼働していない Red Hat Quay のデプロイメントでは、Clair のセキュリティースキャンを手動で設定することが可能です。すでに Clair V2 を実行している Red Hat Quay のデプロイメントは、以下の手順で Clair V4 をデプロイメントに追加することができます。
(フォールトトレラントが望ましい) Postgres データベースサーバーを導入します。なお、Clair は Postgres データベースに
uuid-ossp
エクステンションを追加する必要があります。Clair のconfig.yaml
で指定されたユーザーが、拡張機能を作成するのに必要な権限を持っている場合は、Clair 自身によって自動的に追加されます。そうでない場合は、Clair を起動する前に拡張機能を追加する必要があります。この拡張子がない場合は、Clair を起動しようとすると以下のエラーが表示されます。ERROR: Please load the "uuid-ossp" extension. (SQLSTATE 42501)
特定のフォルダーで 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 ドキュメント に記載されています。
コンテナーイメージ経由で 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.13
- 新しい 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 設定を提供できます。
手順
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 にあります。
-
データベース証明書は、
clair-config.yaml
をconfigBundleSecret
という名前のバンドルシークレットに追加します。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.yaml
のairgap
パラメーターをtrue
に設定する必要があります。 - エアギャップ環境で Quay を実行している場合は、すべてのアップデーターを無効にする必要があります。
-
エアギャップ環境で Quay を実行している場合は、
clairpostgres
が managed
に設定されている場合は、カスタム Clair データベースの設定の手順を使用してデータベースを設定します。
エアギャップ環境での Clair の実行の詳細は、エアギャップ OpenShift クラスターでの Clair データベースへのアクセスの設定 を参照してください。
7.4. Clair CRDA 設定
7.4.1. Clair CRDA の有効化
Java スキャンは、Code Ready Dependency Analytics (CRDA) と呼ばれる Red Hat が提供する公開 API サービスに依存しています。CRDA はインターネットアクセスでのみ使用でき、デフォルトでは有効になっていません。CRDA サービスをカスタム API キーと統合し、CRDA for Java および Python スキャンを有効にするには、次の手順に従います。
前提条件
- Red Hat Quay 3.7 以降
手順
- API キーリクエストフォーム を送信して、Quay 固有の CRDA リモートマッチャーを取得します。
clair-config.yaml
ファイルで CRDA 設定を設定します。matchers: config: crda: url: https://gw.api.openshift.io/api/v2/ key: <CRDA_API_KEY> 1 source: <QUAY_SERVER_HOSTNAME> 2
- 1
- この API キーリクエストフォーム から Quay 固有の CRDA リモートマッチャーを挿入します。
- 2
- Quay サーバーのホスト名。
7.5. クレールの使用
- Red Hat Quay クラスターにログインし、Clair スキャンを設定した組織を選択します。
その組織からいくつかのイメージを保持するリポジトリーを選択し、左のナビゲーションからタグを選択します。次の図は、2 枚のイメージがスキャンされたリポジトリーの例です。
脆弱性が発見された場合は、イメージのセキュリティースキャン欄を選択すると、すべての脆弱性または修正可能な脆弱性が表示されます。次の図は、見つかったすべての脆弱性の情報を示しています。
7.6. 脆弱性情報データベース (NVD: National Vulnerability Database) の CVE 評価
Clair v4.2 では、エンリッチメントデータを Quay UI で表示できるようになりました。さらに、Clair v4.2 は、検出された脆弱性について National Vulnerability Database から CVSS スコアを追加します。
この変更により、脆弱性の CVSS スコアがディストリビューションのスコアの 2 レベル以内である場合は、デフォルトで Quay UI present が、ディストリビューションのスコアになります。以下に例を示します。
これは以前のインターフェイスとは異なり、以下の情報のみを表示します。
7.7. 切断された環境のための Clair の設定
Clair は、アップデータと呼ばれる一連のコンポーネントを利用して、様々な脆弱性データベースからのデータのフェッチとパースを処理します。これらのアップデータは、インターネットから直接脆弱性データを取得するようにデフォルトで設定されており、すぐに使用することができます。インターネットに直接アクセスできない切断された環境にいるお客様にとっては、これは問題となります。クレアは、ネットワークの分離を考慮した様々なタイプの更新ワークフローに対応することで、これらの環境をサポートします。clairctl
コマンドラインユーティリティーを使用すると、どのプロセスでも、オープンホスト経由でインターネットからアップデータを取得し、そのデータを隔離されたホストに安全に転送し、隔離されたホスト上のアップデータを Clair 本体にインポートすることが簡単にできます。
その手順は以下の通りです。
まず、Clair の設定で、自動化されたアップデータの実行が無効になっていることを確認してください。
config.yaml
matcher: disable_updaters: true
最新のアップデータをローカルのアーカイブに書き出します。このためには、バイナリーとして直接実行するか、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.13 --config /cfg/config.yaml export-updaters /updaters/updaters.gz
なお、Clair の設定を細かく参照する必要があります。これにより、
/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.13 --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 の内部に関する詳細なドキュメントは、Upstream Clair および ClairCore のドキュメントを参照してください。
第8章 コンテナーセキュリティー Operator での Pod イメージのスキャン
Container Security Operator (CSO) は、OpenShift Container Platform およびその他の Kubernetes プラットフォームで利用可能な Clair セキュリティースキャナーのアドオンです。CSO を使用すると、ユーザーはアクティブな Pod に関連付けられているコンテナーイメージをスキャンして、既知の脆弱性を見つけることができます。
CSO は、Red Hat Quay と Clair なしでは機能しません。
Container Security Operator (CSO) は、次の機能を実行します。
- 指定された namespace またはすべての namespace の Pod に関連付けられたコンテナーを監視します。
- コンテナーのソースであるコンテナーレジストリーにクエリーを実行して、脆弱性情報を取得します (イメージのレジストリーが、Clair スキャンを使用する Red Hat Quay レジストリーなどのイメージスキャンをサポートしている場合)。
-
Kubernetes API の
ImageManifestVuln
オブジェクトを使用して脆弱性を公開します。
CSO を Kubernetes にインストールする手順を見るには、Container Security OperatorHub.io のページから Install ボタンを選択します。
8.1. OpenShift Container Platform での Container Security Operator のダウンロードおよび実行
次の手順を使用して、Container Security Operator をダウンロードします。
次の手順では、CSO を marketplace-operators
namespace にインストールします。これにより、OpenShift Container Platform クラスターのすべての namespace で CSO を使用できるようになります。
-
Operators → OperatorHub (Security を選択) で、利用可能な
Container Security
Operator が表示されます。 -
Container Security
Operator を選択し、Install
を選択して Create Operator Subscription ページに移動します。 -
設定 (デフォルトでは、全ネームスペースと自動承認戦略) を確認し、
Subscribe
を選択します。しばらくすると、Installed Operators
画面にContainer Security
が表示されます。 必要に応じて、カスタム証明書を CSO に追加できます。以下の例では、現在のディレクトリーに quay.crt という名前の証明書を作成します。その後、次のコマンドを実行して、CSO に証明書を追加します (新しい証明書を有効にするために、Operator Pod を再起動します)。
$ oc create secret generic container-security-operator-extra-certs --from-file=quay.crt -n openshift-operators
OpenShift Dashboard を開きます (Home → Dashboards)。Image Security へのリンクが status セクションに表示され、これまでに見つかった脆弱性の数の一覧が表示されます。リンクを選択すると、次の図のようにセキュリティーの内訳が表示されます。
この時点で、検出された脆弱性をフォローするために以下の 2 つのいずれかの操作を実行できます。
脆弱性へのリンクを選択します。コンテナーのレジストリー、Red Hat Quay、またはコンテナーを取得したその他のレジストリーに移動し、脆弱性に関する情報が表示されます。以下の図は、Quay.io レジストリーから検出された脆弱性の例を示しています。
namespaces のリンクを選択すると、ImageManifestVuln 画面が表示され、選択したイメージの名前と、そのイメージが実行されているすべてのネームスペースが表示されます。以下の図は、特定の脆弱なイメージが 2 つの namespace で実行されていることを示しています。
この時点では、脆弱性のあるイメージや、イメージの脆弱性を解決するために必要なこと、およびイメージが実行されたすべての namespace を確認できます。以下を実行することができます。
- 脆弱性を修正する必要のあるイメージを実行しているユーザーに警告します。
- イメージが置かれている Pod を起動したデプロイメントまたは他のオブジェクトを削除して、イメージの実行を停止します。
なお、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章 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 トークンを生成します。
手順
- WebUI を介して Red Hat Quay にログインします。
- 外部アプリケーションを設定する組織を選択します。
- ナビゲーションペインで、Applications を選択します。
-
Create New Application を選択し、新規アプリケーションの名前を入力します (例:
openshift
)。 -
OAuth Applications ページで、アプリケーション (
openshift
など) を選択します。 - ナビゲーションペインで、Generate Token を選択します。
次のフィールドを選択します。
- Administer Organization
- Administer Repositories
- Create Repositories
- View all visible repositories
- Read/Write to any accessible repositories
- Administer User
- Read User Information
- 割り当てられた権限を確認します。
- Authorize Application を選択し、Authorize Application を選択して認証を確認します。
生成されたアクセストークンを保存します。
重要Red Hat Quay はトークン管理を提供しません。トークンを一覧表示したり、トークンを削除したり、トークンを変更したりすることはできません。生成されたアクセストークンは 1 回だけ表示され、ページを閉じた後に再取得することはできません。
9.2. OpenShift Container Platform への OpenShift Container Platform のインストール
この手順では、Quay Bridge Operator を OpenShift Container Platform にインストールします。
前提条件
- Red Hat Quay をセットアップし、アクセストークンを取得した。
- クラスター管理者権限を持っている OpenShift Container Platform 4.6 の環境。
手順
- Web コンソールの Administrator パースペクティブを開き、ナビゲーションペインで Operator → OperatorHub に移動します。
-
Quay Bridge Operator
を検索し、Quay Bridge Operator のタイトルをクリックして、Install をクリックします。 - インストールするバージョン (たとえば、stable-3.7) を選択し、Install をクリックします。
- インストールが完了したら、View Operator をクリックして、Quay Bridge Operator の Details ページに移動します。または、Installed Operators → Red 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
カスタムリソースを作成します。
手順
quay-integration.yaml
を作成します:$ touch quay-integration.yaml
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
すべての設定フィールドのリストについては、QuayIntegration configuration fields を参照してください。
QuayIntegration
カスタムリソースを作成します。$ oc create -f quay-integration.yaml
9.4.2. オプション:Web コンソールを使用して QuayIntegration カスタムリソースを作成する
この手順に従って、Web コンソールを使用して QuayIntegration
カスタムリソースを作成します。
手順
- Web コンソールの Administrator パースペクティブを開き、Operators → Installed Operators に移動します。
- Red Hat Quay Bridge Operator をクリックします。
- Quay Bridge Operator の Details ページで、Quay Integration API カードの Create Instance をクリックします。
Create QuayIntegration ページで、Form view または YAML view のいずれかに以下の必須情報を入力します。
-
Name:
QuayIntegration
カスタムリソースオブジェクトを参照する名前。 -
Cluster ID: このクラスターに関連付けられている ID。この値は、エコシステム全体で一意である必要があります。指定しない場合、デフォルトで
openshift
になります。 - Credentials secret: 以前に作成されたトークンを含むシークレットの名前空間と名前を参照します。
Quay hostname: Quay レジストリーのホスト名。
すべての設定フィールドのリストについては、QuayIntegration configuration fields を参照してください。
-
Name:
QuayIntegration
カスタムリソースが作成されると、OpenShift Container Platform クラスターが Red Hat Quay インスタンスにリンクされます。Red Hat Quay レジストリー内の組織は、OpenShift Container Platform 環境の関連する namespace 用に作成する必要があります。
9.5. QuayIntegration 設定フィールド
QuayIntegration カスタムリソースでは、次の設定フィールドを使用できます。
名前 | 説明 | スキーマ |
---|---|---|
allowlistNamespaces | 含める namespace のリスト。 | Array |
clusterID | このクラスターに関連付けられている ID。 | 文字列 |
credentialsSecret.key | Quay レジストリーと通信するための資格情報を含む秘密。 | オブジェクト |
denylistNamespaces | 除外する namespace のリスト。 | Array |
insecureRegistry | Quay レジストリーへの TLS 検証をスキップするかどうか | ブール値 |
quayHostname | Quay レジストリーのホスト名。 | 文字列 |
scheduledImageStreamImport | イメージストリームのインポートを有効にするかどうか。 | ブール値 |
第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 レプリケーションを同時に使用できます。
機能と性能 | Geo レプリケーション | リポジトリーのミラーリング |
---|---|---|
設計されている機能 | グローバルに共有されるレジストリー | 独立した異なるレジストレーション |
レプリケーションやミラーリングがまだ完了していない場合はどうなるか ? | リモートコピーを使用する (遅くなります) | イメージが表示されない |
両地域のすべてのストレージバックエンドへのアクセスが必要か ? | はい (すべての Red Hat Quay ノード)。 | いいえ (個別のストレージ) |
ユーザーは両方のサイトのイメージを同じリポジトリーにプッシュできるか ? | はい | いいえ |
すべてのレジストリーの内容と設定がすべての地域で同一であるか (共有データベース) | はい | いいえ |
ユーザーはミラーリングする個別の namespace またはリポジトリーを選択できるか ? | いいえ | はい |
ユーザーは同期ルールにフィルターを適用できるか ? | いいえ | はい |
各リージョンで許可されている個別/異なる RBAC 設定か ? | いいえ | はい |
10.3. リポジトリーミラーリングの使用
ここでは、Red Hat Quay リポジトリーミラーリングの機能と制限について説明します。
- リポジトリーのミラーリングでは、リポジトリー全体をミラーリングしたり、同期するイメージを選択的に制限したりできます。フィルターは、タグのコンマ区切りの一覧、タグの範囲、または正規表現でタグを特定する他の方法によります。
- ミラーリングされたリポジトリーとして設定されると、そのリポジトリーに他のイメージを手動で追加することはできません。
- ミラーリングされたリポジトリーは設定するリポジトリーとタグをベースとするため、そのリポジトリー/タグのペアで表されるコンテンツのみを保持します。つまり、リポジトリーの一部のイメージがこれ以上一致しないようにタグを変更すると、これらのイメージは削除されます。
- 指定されたロボットだけが、ミラーリングされたリポジトリーにイメージをプッシュすることができ、リポジトリーに設定されたロールベースのアクセスコントロール権限に優先します。
- ミラーリングされたリポジトリーを使用すると、ユーザーはリポジトリーからイメージをプルできますが (読み取りパーミッションが付与される)、イメージをリポジトリーにプッシュすることはできません。
- ミラーリングされたリポジトリーの設定の変更は、作成するミラーリングされたリポジトリーの Repositories → Mirrors タブを使用して Red Hat Quay UI で実行できます。
- イメージは一定の間隔で同期されますが、必要に応じて同期することもできます。
10.4. 設定のミラーリング UI
設定モードで
Quay
コンテナーを起動し、Enable Repository Mirroring チェックボックスを選択します。HTTPS 通信を必要とし、ミラーリング時に証明書を検証する必要がある場合は、HTTPS を選択し、証明書の検証のチェックボックスを選択します。-
configuration
を検証し、ダウンロードしてから、更新された設定ファイルを使用してレジストリーモードで Quay を再起動します。
10.5. 設定フィールドのミラーリング
フィールド | 型 | 説明 |
---|---|---|
FEATURE_REPO_MIRROR | Boolean |
リポジトリーミラーリングを有効化または無効化します |
REPO_MIRROR_INTERVAL | Number |
次にリポジトリーミラー候補をチェックするまでの秒数。 |
REPO_MIRROR_SERVER_HOSTNAME | 文字列 |
|
REPO_MIRROR_TLS_VERIFY | Boolean |
HTTPS を必要とし、ミラー時に Quay レジストリーの証明書を検証します。 |
REPO_MIRROR_ROLLBACK | ブール値 |
デフォルト: |
10.6. ミラーリングワーカー
次の手順を使用して、リポジトリーミラーリングワーカーを開始します。
手順
/root/ca.crt
証明書を使用して TLS 通信を設定していない場合は、次のコマンドを入力し、repomirror
オプションを指定して、Quay
Pod を開始します。$ sudo podman run -d --name mirroring-worker \ -v $QUAY/config:/conf/stack:Z \ {productrepo}/{quayimage}:{productminv} 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:Z \ {productrepo}/{quayimage}:{productminv} repomirror
10.7. ミラーリングされたリポジトリーの作成
以下のセクションで説明する手順は、Red Hat Quay クラスターの設定でリポジトリーのミラーリングが有効にされており、リポジトリーミラーリングワーカーをデプロイしていることを前提としています。
外部コンテナーレジストリーからリポジトリーをミラーリングする場合は、新しいプライベートリポジトリーを作成します。通常、ターゲットリポジトリーと同じ名前が使用されます (例: quay-rhel8
)。
10.7.1. リポジトリーのミラーリングの設定
Settings タブで、Repository State を
Mirror
に設定します。Mirror タブで、タグ、スケジューリング、およびアクセス情報と共に外部レジストリーに接続するための情報を入力します。
必要に応じて、以下のフィールドに詳細を入力します。
-
Registry Location: ミラーリングする外部リポジトリー (例:
registry.redhat.io/quay/quay-rhel8
)。 Tags: このフィールドは必須です。個別のタグまたはタグパターンのコンマ区切りの一覧を入力できます。(詳細は、タグパターン のセクションを参照してください。)
注記Quay がリモートリポジトリーのタグの一覧を取得するには、以下のいずれかの要件を満たす必要があります。
- latest タグのあるイメージがリモートリポジトリー OR に存在している必要があります
- パターンの一致のない少なくとも 1 つの明示的なタグが、指定するタグの一覧に存在する必要があります。
- Start Date: ミラーリングが開始する日付。現在の日時がデフォルトで使用されます。
- Sync Interval: デフォルトで 24 時間ごとの同期に設定されます。これは時間または日に基づいて変更できます。
- Robot User: 新しい robot アカウントを作成するか、既存の robot アカウントを選択してミラーリングを実行します。
- Username: ミラーリングするリポジトリーを保持する外部レジストリーにアクセスするためのユーザー名。
- Password: ユーザー名に関連付けられたパスワード。パスワードにはエスケープ文字 (\) を必要とする文字を含めることができないことに注意してください。
-
Registry Location: ミラーリングする外部リポジトリー (例:
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 タブで利用できます。
ミラーリングが完了すると、イメージは Tags タブに表示されます。
以下は、完了した Repository Mirroring 画面の例です。
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 ページからミラーリングされたリポジトリーを選択し、以下のいずれかを行います。
- リポジトリーの有効化/無効化: 左列の Mirroring ボタンを選択してから Enabled チェックボックスを切り替え、一時的にリポジトリーを有効または無効にします。
ミラーログの確認: ミラーリングされたリポジトリーが正常に動作していることを確認するために、ミラーログを確認することができます。そのためには、左カラムの Usage Logs ボタンを選択します。以下に例を示します。
- 今すぐミラーを同期: リポジトリー内のイメージをすぐに同期するには、Sync Now ボタンを選択します。
- クレデンシャルの変更: ユーザー名とパスワードを変更するには、Credentials の行から DELETE を選択します。その後、なしを選択し、プロンプトが表示されたら、外部レジストリーにログインするために必要なユーザー名とパスワードを追加します。
- ミラーリングのキャンセル: ミラーリングを中止するには、CANCEL ボタンを選択します。これにより、現在のイメージはそのまま利用できますが、新しいイメージは同期されなくなります。
ロボットのパーミッション設定: Red Hat Quay のロボットアカウントは、外部のリポジトリーにアクセスするための認証情報を保持する名前付きのトークンです。ロボットに認証情報を割り当てることで、そのロボットは、同じ外部レジストリーにアクセスする必要のある複数のミラーリングされたリポジトリーで使用することができます。
既存のロボットをリポジトリーに割り当てるには、Account Settings を開き、左カラムの Robot Accounts アイコンを選択します。ロボットアカウントの場合は、REPOSITORIES 欄のリンクを選択します。ポップアップウィンドウから、以下のことができます。
- そのロボットにどのリポジトリーが割り当てられているかを確認します。
- この図に示されている PERMISSION フィールドから対象のロボットに読み取り、書き込み、または管理者権限を割り当てます。
ロボット認証情報の変更: ロボットは、Kubernetes の秘密、Docker のログイン情報、Mesos のバンドルなどの認証情報を保持することができます。ロボットの認証情報を変更するには、Robot Accounts ウィンドウのロボットのアカウント行にある Options ギアを選択し、View Credentials を選択します。ロボットがアクセスする必要のある外部リポジトリーの適切な認証情報を追加します。
- 一般設定の確認と変更: ミラーリングされたリポジトリーのページの左カラムから設定ボタン (歯車のアイコン) を選択します。表示されるページでは、ミラーリングされたリポジトリーに関連する設定を変更できます。特に、ユーザーやロボットのパーミッションを変更して、どのユーザーやロボットがレポジトリーを読み書きできるかを正確に指定することができます。
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_CREATION
が true
に設定されている場合は、LDAP 認証ユーザーが最初のログイン時に Quay のデータベースに自動的に作成されます。このオプションを false
に設定すると、LDAP ユーザーの自動ユーザー作成に失敗し、ユーザーはログインできません。このシナリオでは、スーパーユーザーが最初に必要なユーザーアカウントを作成する必要があります。一方、FEATURE_USER_CREATION
が true
に設定されている場合は、LDAP に同等のユーザーがある場合でも、ユーザーは Quay ログイン画面からもアカウントを作成できます。
11.2. LDAP の設定
設定ツールで認証の項目を探し、ドロップダウンメニューから LDAP を選択します。必要に応じて LDAP 設定項目を更新してください。
- 以下は、config.yaml ファイルの結果としてのエントリーの例です。
AUTHENTICATION_TYPE: LDAP
11.2.1. 完全な LDAP URI
- ldap:// または ldaps:// の接頭辞を含む、完全な LDAP URI。
- ldaps:// で始まる URI は、提供された SSL 証明書を使用して TLS の設定を行います。
- 以下は、config.yaml ファイルの結果としてのエントリーの例です。
LDAP_URI: ldaps://ldap.example.org
11.2.2. チームシンクロナイゼーション
- この機能を有効にすると、スーパーユーザーである組織管理者は、チームのメンバーシップを LDAP の下位グループと同期させるように設定できます。
- 再同期期間とは、チームを再同期させる必要がある期間のことです。継続時間を文字列形式で表現する必要があります (30m、1h、1d)。
- オプションとして、管理者である組織の下で、スーパーユーザー以外の人がチームの同期を有効にして管理できるようにします。
- 以下は、config.yaml ファイルの結果としてのエントリーの例です。
FEATURE_TEAM_SYNCING: true TEAM_RESYNC_STALE_TIME: 60m FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP: true
11.2.3. ベースおよび相対的な区別された名前
- すべての LDAP レコードを検索するための基本パスとなる識別名のパス。たとえば、dc=my,dc=domain,dc=com です。
- すべてのユーザーの LDAP レコードを検索するための第二のベースパスとなる、上記で定義したベース DN に相対する識別名パスのリスト (オプション)。これらのパスは、プライマリーの相対的な DN でユーザーを見つけられなかった場合に試行されます。
- User Relative DN は BaseDN からの相対的なものです。たとえば、ou=NYC,dc=example,dc=org ではなく ou=NYC です。
- ユーザーオブジェクトが配置されている 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 がある場合 (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. ユーザーフィルターの追加
- 指定された場合は、すべてのユーザー検索クエリーで使用される追加フィルターとなります。なお、フィルターで使用する識別名はすべて 完全 パスでなければならず、ベース DN はここでは自動的に追加されません。括弧でくくる必要があります。たとえば、(&(someFirstField=someValue)(someOtherField=someOtherValue)) です。
- 以下は、config.yaml ファイルの結果としてのエントリーの例です。
LDAP_USER_FILTER: (memberof=cn=developers,ou=groups,dc=example,dc=com)
11.2.5. 管理者 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 属性は、ユーザー名 として使用する 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 ボタンをクリックして設定を有効にします。
すべての検証が成功しないと先に進めません。また、編集を続けるボタンを選択して追加の設定を行うこともできます。
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 に存在しないか、管理者 DN ユーザーにこの LDAP パスの検索/読み取り権限がありません。
11.4. LDAP ユーザーをスーパーユーザーとして設定
LDAP が設定されると、有効な LDAP ユーザー名とパスワードで Red Hat Quay インスタンスにログインできるようになります。次の図のように、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.13
これでメトリクスが利用可能になります。
$ 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 には、リポジトリーのガべージコレクションワーカーによって削除対象としてマークされたリポジトリーが含まれます。repositorygc の queue_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 設定フラグを使用します。
フィールド | 型 | 説明 |
---|---|---|
DEFAULT_SYSTEM_REJECT_QUOTA_BYTES | 文字列 |
すべての組織およびユーザーに適用するクォータサイズ |
組織またはユーザーに特定のクォータを設定してから、そのクォータを削除すると、システム全体のデフォルトのクォータが設定されている場合に適用されます。同様に、組織またはユーザーに特定のクォータを設定してから、システム全体のデフォルトクォータを変更した場合、更新されたシステム全体のデフォルトは特定の設定を上書きします。
13.2. クォータ管理アーキテクチャー
RepositorySize
データベーステーブルは、組織内の Red Hat Quay リポジトリーのストレージ消費量をバイト単位で保持します。組織のすべてのリポジトリーサイズの合計は、Red Hat Quay 組織の現在のストレージサイズを定義します。イメージプッシュが初期化されると、ユーザーの組織ストレージが検証され、設定されたクォータ制限を超えているかどうかがチェックされます。イメージプッシュが定義されたクォータ制限を超えると、ソフトチェックまたはハードチェックが発生します。
- ソフトチェックの場合は、ユーザーに通知されます。
- ハードチェックの場合は、プッシュが停止します。
ストレージ消費量が設定済みのクォータ制限内にある場合は、プッシュを続行できます。
イメージマニフェストの削除も同様のフローに従い、関連するイメージタグとマニフェストの間のリンクが削除されます。さらに、イメージマニフェストが削除された後、リポジトリーサイズが再計算され、RepositorySize
テーブルで更新されます。
13.3. Red Hat Quay UI でクォータの確立
次の手順では、ストレージ消費量をレポートし、ストレージクォータ制限を設定する方法を説明します。
前提条件
- Red Hat Quay レジストリー
- スーパーユーザーアカウント
- クォータ制限の要求を満たすのに十分なストレージ
手順
新しい組織を作成するか、既存の組織を選択します。Organization Settings タブに表示されているように、最初はクォータが設定されていません。
スーパーユーザーとしてレジストリーにログインし、Super User Admin Panel の Manage Organizations タブに移動します。ストレージクォータ制限を作成する組織の Options アイコンをクリックします。
Configure Quota をクリックして、初期クォータ (たとえば 10 MB) を入力します。次に、Apply をクリックしてから Close をクリックします。
スーパーユーザーパネルの Manage Organizations タブで、消費されたクォータが 10MB のうち 0 を示していることを確認します。
消費されたクォータ情報は、組織ページから直接入手することもできます。
最初に消費されたクォータ
クォータを 100MB に増やすには、スーパーユーザーパネルの Manage Organizations タブに移動します。Options アイコンをクリックし、Configure Quota を選択して、クォータを 100 MB に設定します。Apply をクリックしてから Close をクリックします。
コマンドラインからサンプルイメージを組織にプッシュします。
サンプルコマンド
$ 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
スーパーユーザーパネルには、組織ごとに消費されたクォータが表示されます。
組織ページには、イメージで使用されているクォータの合計比率が表示されます。
最初のイメージで消費された合計クォータ
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
組織ページには、その組織の各リポジトリーで使用されているクォータの合計比率が表示されます。
各リポジトリーで消費された合計クォータ
拒否 と 警告 の制限を作成します。
スーパーユーザーパネルから、Manage Organizations タブに移動します。組織の Options アイコンをクリックし、Configure Quota を選択します。Quota Policy セクションで、Action タイプを Reject に設定し、Quota Threshold を 80 に設定して、Add Limit をクリックします。
警告 制限を作成するには、Action タイプに Warning を選択し、Quota Threshold を 70 に設定して、Add Limit をクリックします。
クォータポップアップで Close をクリックします。制限は、Organization ページの Settings タブで表示できますが、編集することはできません。
拒否制限を超えたイメージをプッシュします。
拒否制限 (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
制限を超えると、UI に通知が表示されます。
クォータ通知
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"a=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. 別のイメージをプッシュ
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
組織内のリポジトリーのクォータレポートを表示するには、/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"a=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 } ] }
組織の詳細でクォータ情報を表示するには、/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. 制限を超えた場合の通知
制限を超えると、通知が表示されます。
クォータ通知
13.5. クォータ管理の制限
クォータ管理は、組織がリソース消費を維持するのに役立ちます。クォータ管理の制限の 1 つは、プッシュでリソース消費を計算すると、計算がプッシュのクリティカルパスの一部になることです。これがないと、使用状況データがドリフトする可能性があります。
最大ストレージクォータサイズは、選択したデータベースによって異なります。
変数 | 説明 |
---|---|
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 レプリケーションの要件と制約
- geo レプリケーション設定では、Red Hat Quay では、すべてのリージョンが他のすべてのリージョンのオブジェクトストレージに対して読み取り/書き込みできる必要があります。オブジェクトストレージは、他のすべてのリージョンから地理的にアクセスできる必要があります。
- 1 つの geo レプリケーションサイトでオブジェクトストレージシステムに障害が発生した場合に、そのサイトの Red Hat Quay デプロイメントをシャットダウンして、クライアントがグローバルロードバランサーにより、ストレージシステムで問題のない残りのサイトにリダイレクトされるようにする必要があります。そうしないと、クライアントでプルとプッシュの失敗が発生します。
- Red Hat Quay は、接続されたオブジェクトストレージシステムの内部の正常性または可用性に関する認識はありません。1 つのサイトのオブジェクトストレージシステムが利用できなくなった場合に、残りのサイトの残りのストレージシステム (複数可) に自動的にリダイレクトされません。
- geo レプリケーションは非同期です。サイトが完全に失われると、そのサイトのオブジェクトストレージシステムに保存されているが、障害発生時に残りのサイトにまだ複製されていないデータが失われます。
1 つのデータベース、つまりすべてのメタデータと Quay の設定がすべてのリージョンで共有されます。
geo レプリケーションはデータベースをレプリケートしません。障害が発生した場合、geo レプリケーションが有効になっている Red Hat 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 レプリケーション
上記の例では、Quay は共通のデータベースおよび共通の Redis インスタンスを持つ 2 つのリージョンでスタンドアロンを実行します。ローカライズされたイメージストレージは各リージョンで提供され、最も近くにある利用可能なストレージエンジンからイメージプルが提供されます。コンテナーイメージのプッシュは、Quay インスタンスの推奨ストレージエンジンに書き込まれ、次にバックグラウンドで他のストレージエンジンに複製されます。
たとえば米国のクラスターなど、1 つのクラスターで Clair に障害が発生した場合に、米国のユーザーに 2 番目のクラスター (EU) の脆弱性レポートを Quay を表示しません。これは、すべての Clair インスタンスの状態が同じであるためです。Clair に障害が発生した場合、通常はクラスター内の問題が原因です。
14.3.1. ストレージレプリケーションを有効にする - スタンドアロン Quay
-
スクロールダウンして、
Registry Storage
というセクションに進みます。 -
Enable Storage Replication
をクリックします。 - データを複製するストレージエンジンをそれぞれ追加します。使用するすべてのストレージエンジンをリストに載せる必要があります。
-
すべてのイメージをすべてのストレージエンジンに完全にレプリケートする必要がある場合は、各ストレージエンジンの設定の下で
Replicate to storage engine by default
をクリックします。これにより、すべてのイメージがそのストレージエンジンにレプリケートされます。代わりに名前空間ごとのレプリケーションを有効にするには、サポートにお問い合わせください。 -
完了したら、
Save Configuration Changes
をクリックします。設定変更は、Red Hat Quay が次回再起動したときに有効になります。 ストレージを追加し、Geo レプリケーションの Replicate to storage engine by default を有効にした後、既存のイメージデータをすべてのストレージで同期する必要があります。そのためには、コンテナーに
oc exec
(または docker/kubectl exec) して実行する必要があります。# scl enable python27 bash # python -m util.backfillreplication
この操作は、新しいストレージを追加した後にコンテンツを同期するための 1 回限りの操作です。
14.3.2. ストレージの環境設定による Red Hat Quay の実行
- config.yaml を Red Hat Quay を実行しているすべてのマシンにコピーします。
各リージョンの各マシンは、マシンが稼働しているリージョンの優先ストレージエンジンを持つ
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.13
注記指定された環境変数の値は、コンフィグパネルで定義されたロケーション ID の名前と一致する必要があります。
- すべての Red Hat Quay コンテナーを再起動します。
14.4. Red Hat Quay Operator を使用した Geo レプリケーション
上記の例では、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 レプリケーションの設定
手順
Quaypostgres インスタンスをデプロイします。
- データベースにログインします。
Quay のデータベースを作成します。
CREATE DATABASE quay;
データベース内で pg_trm 拡張機能を有効にします。
\c quay; CREATE EXTENSION IF NOT EXISTS pg_trgm;
Redis インスタンスをデプロイします。
注記- クラウドプロバイダーに独自のサービスがある場合は、Redis インスタンスをデプロイする必要がない場合があります。
- Builder を利用している場合は、Redis インスタンスをデプロイする必要があります。
- Redis 用の VM をデプロイします。
- Quay が実行されているクラスターからアクセスできることを確認してください。
- ポート 6379/TCP が開いている必要があります。
インスタンス内で Redis を実行します。
sudo dnf install -y podman podman run -d --name redis -p 6379:6379 redis
クラスターごとに 1 つずつ、2 つのオブジェクトストレージバックエンドを作成します。
理想的には、一方のオブジェクトストレージバケットは 1 番目のクラスター (プライマリー) の近くにあり、もう一方は 2 番目のクラスター (セカンダリー) の近くにあります。
- 環境変数のオーバーライドを使用して、同じ設定バンドルでクラスターをデプロイし、個々のクラスターに適切なストレージバックエンドを選択します。
- クラスターへの単一のエントリーポイントを提供するように、ロードバランサーを設定します。
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 - kind: mirror 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 - kind: mirror 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 がデプロイメントされている (状況条件
Available
がtrue
に設定されている)。 -
コンポーネント
quay
、postgres
、およびobjectstorage
はmanaged: true
に設定されている。 -
コンポーネント
clair
がmanaged: true
に合、コンポーネントclairpostgres
もmanaged: true
に設定されている (Red Hat Quay Operator v3.7 以降で開始)。
デプロイメントに部分的に管理されていないデータベースまたはストレージコンポーネントが含まれ、Postgres または S3 互換オブジェクトストレージの外部サービスを使用している場合、Red Hat Quay デプロイメントを実行するには、サービスプロバイダーまたはベンダーのドキュメントを参照してデータのバックアップを作成してください。このガイドで説明されているツールは、外部 Postgres データベースまたはオブジェクトストレージのバックアップの開始点として参照できます。
15.1.1. Red Hat Quay 設定のバックアップ
QuayRegistry
カスタムリソースをエクスポートしてバックアップします。$ oc get quayregistry <quay-registry-name> -n <quay-namespace> -o yaml > quay-registry.yaml
作成される
quayregistry.yaml
を編集し、ステータスセクションおよび以下のメタデータフィールドを削除します。metadata.creationTimestamp metadata.finalizers metadata.generation metadata.resourceVersion metadata.uid
管理対象キーシークレットをバックアップします。
注記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
作成された
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
プロパティーの情報はすべて同じままにする必要があります。現在の 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
Quay Pod 内にマウントされた
/conf/stack/config.yaml
ファイルをバックアップします。$ oc exec -it quay-pod-name -- cat /conf/stack/config.yaml > quay-config.yaml
15.1.2. Red Hat Quay デプロイメントのスケールダウン
この手順は、Red Hat Quay デプロイメントの状態の整合性のあるバックアップを作成するために必要になります。Postgres データベースや S3 互換オブジェクトストレージが外部サービスによって提供されるセットアップ (Operator の管理対象外) を含め、この手順を省略しないでください。
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 …
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>
registry-quay-app
、registry-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 データベースで設定されている場合は、これらのデータベースの一貫したバックアップを作成する方法についてベンダーのドキュメントを参照してください。
Quay PostgreSQL Pod 名を特定します。
$ oc get pod -l quay-component=postgres -n <quay-namespace> -o jsonpath='{.items[0].metadata.name}'
出力例:
quayregistry-quay-database-59f54bb7-58xs7
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
バックアップデータベースをダウンロードします。
$ 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 のストレージバケットのコンテンツのコピーを作成する方法についてベンダーのドキュメントを参照してください。
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)
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)
新しいディレクトリーを作成し、すべての 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
15.1.4. Red Hat Quay デプロイメントのバックアップのスケーリング
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 …
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>
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 レジストリーをバックアップした後に実行する必要があります。詳細については、Red Hat Quay のバックアップ を参照してください。
前提条件
- Red Hat Quay が、Red Hat Quay Operator を使用して OpenShift Container Platform にデプロイされている。
- Red Hat Quay Operator によって管理される Red Hat Quay 設定のバックアップが、Red Hat Quay のバックアップ セクションの手順に従って作成されている。
- Red Hat Quay データベースがバックアップされている。
- Red Hat Quay で使用されるオブジェクトストレージバケットがバックアップされている。
-
コンポーネント
quay
、postgres
、およびobjectstorage
はmanaged: true
に設定されている。 -
コンポーネント
clair
がmanaged: true
に設定されている場合、コンポーネントclairpostgres
もmanaged: 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 のバックアップ ガイドのプロセスに従い、同じ名前のバックアップファイルを作成していることを前提としています。
バックアップされた 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
で再作成する必要があります。QuayRegistry
カスタムリソースを復元します。$ oc create -f ./quay-registry.yaml
Red Hat Quay デプロイメントのステータスを確認し、これが利用可能になるまで待機します。
$ oc wait quayregistry registry --for=condition=Available=true -n <quay-namespace>
15.2.2. Red Hat Quay デプロイメントのスケールダウン
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 …
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>
registry-quay-app
、registry-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 データベースの復元
Quay データベース Pod を特定します。
$ oc get pod -l quay-component=postgres -n <quay-namespace> -o jsonpath='{.items[0].metadata.name}'
出力例:
quayregistry-quay-database-59f54bb7-58xs7
ローカル環境および Pod にコピーして、バックアップをアップロードします。
$ oc cp ./backup.sql -n <quay-namespace> registry-quay-database-66969cd859-n2ssm:/tmp/backup.sql
データベースに対してリモートターミナルを開きます。
$ oc rsh -n <quay-namespace> registry-quay-database-66969cd859-n2ssm
psql を入力します。
bash-4.4$ psql
以下のコマンドを実行してデータベースを一覧表示できます。
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 |
データベースを削除します。
postgres=# DROP DATABASE "quayregistry-quay-database";
出力例:
DROP DATABASE
postgres CLI を終了して bash-4.4 を再入力します。
\q
PostgreSQL データベースをバックアップデータベースにリダイレクトします。
sh-4.4$ psql < /tmp/backup.sql
bash を終了します。
sh-4.4$ exit
15.2.4. Red Hat Quay オブジェクトストレージデータの復元
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)
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)
以下のコマンドを実行して、すべての 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}')
15.2.5. Red Hat Quay デプロイメントのスケールアップ
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 …
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>
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 のスタンドアロンデプロイメントのバックアップ
手順
スタンドアロンデプロイメントの Quay
config.yaml
をバックアップします。$ mkdir /tmp/quay-backup $ cp /path/to/Quay/config/directory/config.yaml /tmp/quay-backup
スタンドアロン 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
- AWS CLI がない場合はインストールします。
~/.aws/
ディレクトリーを作成します。$ mkdir ~/.aws/
スタンドアロンデプロイメントの 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
Quay
config.yaml
ファイルからのaccess_key
およびsecret_key
を~/.aws
ディレクトリーに保存します。$ touch ~/.aws/credentials
オプション:
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
を実行して手動でクレデンシャルを入力することで、それを設定できます。quay-backup
ディレクトリーで、bucket_backup
ディレクトリーを作成します。$ mkdir /tmp/quay-backup/bucket-backup
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_CONFIG
のhostname
の下にある Quayconfig.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 を使用します。
Red Hat Quay Operator をスケールダウンします。
$ oc scale --replicas=0 deployment quay-operator.v3.6.2 -n openshift-operators
アプリケーションをスケールダウンし、デプロイメントをミラーリングします。
$ oc scale --replicas=0 deployment QUAY_MAIN_APP_DEPLOYMENT QUAY_MIRROR_DEPLOYMENT
データベース 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
オペレーターが作成した
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
データベース Pod 内でシェルを実行します。
# oc exec -it quay-postgresql-database-pod -- /bin/bash
psql を入力します。
bash-4.4$ psql
データベースを削除します。
postgres=# DROP DATABASE "example-restore-registry-quay-database";
出力例:
DROP DATABASE
新しいデータベースを作成し、所有者を同じ名前に設定します。
postgres=# CREATE DATABASE "example-restore-registry-quay-database" OWNER "example-restore-registry-quay-database";
出力例:
CREATE DATABASE
データベースに接続します。
postgres=# \c "example-restore-registry-quay-database";
出力例:
You are now connected to database "example-restore-registry-quay-database" as user "postgres".
Quay データベースの
pg_trmg
エクステンションを作成します。example-restore-registry-quay-database=# create extension pg_trgm ;
出力例:
CREATE EXTENSION
postgres CLI を終了して bash-4.4 を再入力します。
\q
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
bash モードを終了します。
bash-4.4$ exit
Red Hat Quay Operator の新規設定バンドルを作成します。
$ touch config-bundle.yaml
新規の
config-bundle.yaml
で、LDAP 設定、キー、古いレジストリーのその他の変更など、レジストリーに必要なすべての情報を含めます。以下のコマンドを実行してsecret_key
をconfig-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 ファイルに追加する必要があります。
OpenShift クラスター内に設定バンドルシークレットを作成します。
$ oc create secret generic new-custom-config-bundle --from-file=config.yaml=/tmp/quay-backup/config-bundle.yaml
Quay Pod をスケールアップします。
$ oc scale --replicas=1 deployment quayregistry-quay-app deployment.apps/quayregistry-quay-app scaled
ミラー Pod をスケールアップします。
$ oc scale --replicas=1 deployment quayregistry-quay-mirror deployment.apps/quayregistry-quay-mirror scaled
QuayRegistry
CRD にパッチを適用し、新規カスタム設定バンドルへの参照が含まれるようにします。$ oc patch quayregistry QUAY_REGISTRY_NAME --type=merge -p '{"spec":{"configBundleSecret":"new-custom-config-bundle"}}'
注記Quay が
500
の内部サーバーエラーを返した場合、DISTRIBUTED_STORAGE_CONFIG
のlocation
をdefault
に更新する必要がある場合があります。/.aws/
ディレクトリーに新しいAWScredentials.yaml
を作成し、Operator が作成したconfig.yaml
ファイルからaccess_key
とsecret_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
を実行して手動でクレデンシャルを入力することで、それを設定できます。NooBaa の公開されているエンドポイントを記録します。
$ oc get route s3 -n openshift-storage -o yaml -o jsonpath="{.spec.host}{'\n'}"
バックアップデータを NooBaa バックエンドストレージに同期します。
$ aws s3 sync --no-verify-ssl --endpoint-url https://NOOBAA_PUBLIC_S3_ROUTE /tmp/quay-backup/bucket-backup/* s3://QUAY_DATASTORE_BUCKET_NAME
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 のバックアップと復元
このセクションの内容を使用して、スタンドアロンデプロイメントの Red Hat Quay をバックアップおよび復元します。
17.1. スタンドアロンデプロイメントでの Red Hat Quay のバックアップ
この手順では、スタンドアロンデプロイメントで Red Hat Quay のバックアップを作成する方法について説明します。
手順
一時バックアップディレクトリーを作成します (例:
quay-backup
)。$ mkdir /tmp/quay-backup
以下のコマンド例は、Red Hat Quay が開始されたローカルディレクトリー (
/opt/quay-install
など) を示しています。$ podman run --name quay-app \ -v /opt/quay-install/config:/conf/stack:Z \ -v /opt/quay-install/storage:/datastorage:Z \ {productrepo}/{quayimage}:{productminv}
次のコマンドを実行して、コンテナー内の
/conf/stack
にバインドマウントするディレクトリー (/opt/quay-install
など) に移動します。$ cd /opt/quay-install
以下のコマンドを入力して、Red Hat Quay デプロイメントの内容を
quay-backup
ディレクトリーのアーカイブに圧縮します。$ tar cvf /tmp/quay-backup/quay-backup.tar.gz *
出力例:
config.yaml config.yaml.bak extra_ca_certs/ extra_ca_certs/ca.crt ssl.cert ssl.key
次のコマンドを入力して、Quay コンテナーサービスをバックアップします。
$ podman inspect quay-app | jq -r '.[0].Config.CreateCommand | .[]' | paste -s -d ' ' - /usr/bin/podman run --name quay-app \ -v /opt/quay-install/config:/conf/stack:Z \ -v /opt/quay-install/storage:/datastorage:Z \ {productrepo}/{quayimage}:{productminv}
次のコマンドを入力して、
conf/stack/config.yaml
ファイルの内容を一時的に作成したquay-config.yaml
ファイルにリダイレクトします。$ podman exec -it quay cat /conf/stack/config.yaml > /tmp/quay-backup/quay-config.yaml
以下のコマンドを入力して、一時的に作成した
quay-config.yaml
にあるDB_URI
を取得します。$ grep DB_URI /tmp/quay-backup/quay-config.yaml
出力例:
$ postgresql://<username>:test123@172.24.10.50/quay
次のコマンドを入力して、PostgreSQL の内容をバックアップ .sql ファイルの一時バックアップディレクトリーに抽出します。
$ pg_dump -h 172.24.10.50 -p 5432 -d quay -U <username> -W -O > /tmp/quay-backup/quay-backup.sql
次のコマンドを入力して、
DISTRIBUTED_STORAGE_CONFIG
の内容を出力します。DISTRIBUTED_STORAGE_CONFIG: default: - S3Storage - s3_bucket: <bucket_name> storage_path: /registry s3_access_key: <s3_access_key> s3_secret_key: <s3_secret_key> host: <host_name>
ステップ 7 で取得した
access_key
認証情報を使用して、AWS_ACCESS_KEY_ID
をエクスポートします。$ export AWS_ACCESS_KEY_ID=<access_key>
ステップ 7 で取得した
secret_key
を使用して、AWS_SECRET_ACCESS_KEY
をエクスポートします。$ export AWS_SECRET_ACCESS_KEY=<secret_key>
DISTRIBUTED_STORAGE_CONFIG
のhostname
からquay
バケットを/tmp/quay-backup/blob-backup/
ディレクトリーに同期します。$ aws s3 sync s3://<bucket_name> /tmp/quay-backup/blob-backup/ --source-region us-east-2
出力例:
download: s3://<user_name>/registry/sha256/9c/9c3181779a868e09698b567a3c42f3744584ddb1398efe2c4ba569a99b823f7a to registry/sha256/9c/9c3181779a868e09698b567a3c42f3744584ddb1398efe2c4ba569a99b823f7a download: s3://<user_name>/registry/sha256/e9/e9c5463f15f0fd62df3898b36ace8d15386a6813ffb470f332698ecb34af5b0d to registry/sha256/e9/e9c5463f15f0fd62df3898b36ace8d15386a6813ffb470f332698ecb34af5b0d
機密情報が含まれているため、quay
バケットを同期した後は quay-config.yaml
ファイルを削除することをお勧めします。quay-config.yaml
ファイルは quay-backup.tar.gz
ファイルにバックアップされるため、失われることはありません。
17.2. スタンドアロンデプロイメントでの Red Hat Quay の復元
この手順では、スタンドアロンデプロイメントで Red Hat Quay を復元する方法について説明します。
前提条件
- Red Hat Quay デプロイメントをバックアップしている。
手順
Red Hat Quay コンテナー内の
/conf/stack
にバインドマウントする新しいディレクトリーを作成します。$ mkdir /opt/new-quay-install
「スタンドアロンデプロイメントでの Red Hat Quay のバックアップ」 で作成した一時バックアップディレクトリーの内容を、ステップ 1 で作成した
new-quay-install1
ディレクトリーにコピーします。$ cp /tmp/quay-backup/quay-backup.tar.gz /opt/new-quay-install/
次のコマンドを入力して、
new-quay-install
ディレクトリーに移動します。$ cd /opt/new-quay-install/
Red Hat Quay ディレクトリーの内容を抽出します。
$ tar xvf /tmp/quay-backup/quay-backup.tar.gz *
出力例:
config.yaml config.yaml.bak extra_ca_certs/ extra_ca_certs/ca.crt ssl.cert ssl.key
次のコマンドを入力して、バックアップした
config.yaml
ファイルからDB_URI
を呼び出します。$ grep DB_URI config.yaml
出力例:
postgresql://<username>:test123@172.24.10.50/quay
次のコマンドを実行して、PostgreSQL データベースサーバーに入ります。
$ sudo postgres
次のコマンドを入力して、psql と入力し、172.24.10.50 に新しいデータベースを作成して、quay データベースを復元します (例:
example_restore_registry_quay_database
)。$ psql "host=172.24.10.50 port=5432 dbname=postgres user=<username> password=test123" postgres=> CREATE DATABASE example_restore_registry_quay_database;
出力例:
CREATE DATABASE
次のコマンドを実行して、データベースに接続します。
postgres=# \c "example-restore-registry-quay-database";
出力例:
You are now connected to database "example-restore-registry-quay-database" as user "postgres".
次のコマンドを実行して、Quay データベースの
pg_trmg
エクステンションを作成します。example_restore_registry_quay_database=> CREATE EXTENSION IF NOT EXISTS pg_trgm;
出力例:
CREATE EXTENSION
次のコマンドを入力して、postgres CLI を終了します。
\q
次のコマンドを実行して、データベースのバックアップを新しいデータベースにインポートします。
$ psql "host=172.24.10.50 port=5432 dbname=example_restore_registry_quay_database user=<username> password=test123" -W < /tmp/quay-backup/quay-backup.sql
出力例:
SET SET SET SET SET
Red Hat Quay のデプロイメントを再起動する前に
config.yaml
のDB_URI
の値をpostgresql://<username>:test123@172.24.10.50/quay
からpostgresql://<username>:test123@172.24.10.50/example-restore-registry-quay-database
に更新してください。注記DB_URI の形式は
DB_URI postgresql://<login_user_name>:<login_user_password>@<postgresql_host>/<quay_database>
です。ある PostgreSQL サーバーから別の PostgreSQL サーバーに移動する場合は、<login_user_name>
、<login_user_password>
、および<postgresql_host>
の値を同時に更新します。/opt/new-quay-install
ディレクトリーで、DISTRIBUTED_STORAGE_CONFIG
バンドルの内容を出力します。$ cat config.yaml | grep DISTRIBUTED_STORAGE_CONFIG -A10
出力例:
DISTRIBUTED_STORAGE_CONFIG: default: DISTRIBUTED_STORAGE_CONFIG: default: - S3Storage - s3_bucket: <bucket_name> storage_path: /registry s3_access_key: <s3_access_key> s3_secret_key: <s3_secret_key> host: <host_name>
注記Red Hat Quay のデプロイメントを再起動する前に
/opt/new-quay-install
にあるDISTRIBUTED_STORAGE_CONFIG
を更新する必要があります。ステップ 13 で取得した
access_key
認証情報を使用して、AWS_ACCESS_KEY_ID
をエクスポートします。$ export AWS_ACCESS_KEY_ID=<access_key>
ステップ 13 で取得した
secret_key
を使用して、AWS_SECRET_ACCESS_KEY
をエクスポートします。$ export AWS_SECRET_ACCESS_KEY=<secret_key>
次のコマンドを入力して、新しい s3 バケットを作成します。
$ aws s3 mb s3://<new_bucket_name> --region us-east-2
出力例:
$ make_bucket: quay
次のコマンドを入力して、すべての Blob を新しい s3 バケットにアップロードします。
$ aws s3 sync --no-verify-ssl \ --endpoint-url <example_endpoint_url> 1 /tmp/quay-backup/blob-backup/. s3://quay/
- 1
- Red Hat Quay レジストリーのエンドポイントは、バックアップ前と復元後に同じである必要があります。
出力例:
upload: ../../tmp/quay-backup/blob-backup/datastorage/registry/sha256/50/505edb46ea5d32b5cbe275eb766d960842a52ee77ac225e4dc8abb12f409a30d to s3://quay/datastorage/registry/sha256/50/505edb46ea5d32b5cbe275eb766d960842a52ee77ac225e4dc8abb12f409a30d upload: ../../tmp/quay-backup/blob-backup/datastorage/registry/sha256/27/27930dc06c2ee27ac6f543ba0e93640dd21eea458eac47355e8e5989dea087d0 to s3://quay/datastorage/registry/sha256/27/27930dc06c2ee27ac6f543ba0e93640dd21eea458eac47355e8e5989dea087d0 upload: ../../tmp/quay-backup/blob-backup/datastorage/registry/sha256/8c/8c7daf5e20eee45ffe4b36761c4bb6729fb3ee60d4f588f712989939323110ec to s3://quay/datastorage/registry/sha256/8c/8c7daf5e20eee45ffe4b36761c4bb6729fb3ee60d4f588f712989939323110ec ...
Red Hat Quay デプロイメントを再起動する前に、config.yaml でストレージ設定を更新します。
DISTRIBUTED_STORAGE_CONFIG: default: DISTRIBUTED_STORAGE_CONFIG: default: - S3Storage - s3_bucket: <new_bucket_name> storage_path: /registry s3_access_key: <s3_access_key> s3_secret_key: <s3_secret_key> host: <host_name>
第18章 Red Hat Quay ガベージコレクション
18.1. Red Hat Quay ガベージコレクションについて
Red Hat Quay には、自動で継続的なイメージガベージコレクションが含まれています。ガベージコレクションは、関連付けられていないイメージやタグなしのイメージ、リポジトリー、レイヤーやマニフェストなどのブロブなど、かなりの量のディスクスペースを占めるオブジェクトを削除することで、アクティブオブジェクトのリソースを効率的に使用できるようにします。Red Hat Quay によって実行されるガベージコレクションは、組織の環境でのダウンタイムを減らすことができます。
18.2. 実際の Red Hat Quay ガベージコレクション
現在、すべてのガベージコレクションは慎重に行われます。ガベージコレクションを手動で実行するコマンドはありません。Red Hat Quay は、さまざまなガベージコレクションワーカーのステータスを追跡するメトリックを提供します。
namespace とリポジトリーのガベージコレクションの場合、進行状況はそれぞれのキューのサイズに基づいて追跡されます。namespace とリポジトリーのガベージコレクションワーカーが機能するには、グローバルロックが必要です。その結果、パフォーマンス上の理由から、一度に 1 人のワーカーのみが実行されます。
Red Hat Quay は、ディスク容量を節約するために、名前空間とリポジトリーの間で BLOB を共有します。たとえば、同じイメージが 10 回プッシュされた場合、そのイメージのコピーは 1 つだけ保存されます。
タグは、Red Hat Quay にすでに保存されているさまざまなイメージと、タグのレイヤーを共有できます。その場合、共有 BLOB を削除すると他のイメージが使用できなくなるため、BLOB はストレージに残ります。
BLOB の有効期限は、タイムマシンとは無関係です。Red Hat Quay にタグをプッシュして、タイムマシンに 0 秒を設定し、すぐにタグを削除した場合に、ガベージコレクションはそのタグと、そのタグに関連するものすべてを削除しますが、Blog の有効期限に到達するまで Blob のストレージは削除しません。
タグ付きイメージのガベージコレクションは、namespace またはリポジトリーでのガベージコレクションとは動作が異なります。タグ付けされたイメージのガベージコレクションワーカーは、処理するアイテムのキューを用意するのではなく、非アクティブまたは期限切れのタグを持つリポジトリーをアクティブに検索してクリーンアップします。ガベージコレクションワーカーの各インスタンスはリポジトリーロックを取得します。これにより、リポジトリーごとに 1 つのワーカーが生成されます。
- Red Hat Quay では、最後のタグが削除されたか期限切れになったため、非アクティブまたは期限切れのタグはタグのないマニフェストです。マニフェストには、イメージがどのように設定され、個々のタグのデータベースに保存されるかに関する情報が保存されます。タグが削除され、タイムマシン から割り当てられた時間に到達すると、Red Hat Quay ガベージは、レジストリー内の他のマニフェストに接続されていない BLOB を収集します。特定の BLOB がマニフェストに接続されている場合に、Blob はストレージに保持され、削除されるマニフェストへの接続のみが削除されます。
- 期限切れのイメージは割り当てられた時間が経過すると消えますが、Red Hat Quay には引き続き保存されます。イメージが完全に削除されるタイミング、またはコレクションされるタイミングは、組織の Time Machine の設定によって異なります。特に指定がない限り、ガベージコレクションのデフォルトの時間は 14 日です。それまでは、期限切れまたは削除されたイメージをタグで参照できます。
ガベージコレクションのタイプごとに、Red Hat Quay は、各ガベージコレクションワーカーによって削除されたテーブルごとの行数のメトリックを提供します。次のイメージは、Red Hat Quay が同じメトリックを使用してガベージコレクションをモニターする方法の例を示しています。
18.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 が削除されます。
18.3. ガベージコレクション設定フィールド
次の設定フィールドを使用して、ガベージコレクションの内容、およびガベージコレクションが発生する頻度をカスタマイズできます。
名前 | 説明 | スキーマ |
---|---|---|
FEATURE_GARBAGE_COLLECTION |
イメージタグに対してガベージコレクションが有効になっているかどうか。デフォルトは | ブール値 |
FEATURE_NAMESPACE_GARBAGE_COLLECTION |
namespace に対してガベージコレクションが有効になっているかどうか。デフォルトは | ブール値 |
FEATURE_REPOSITORY_GARBAGE_COLLECTION |
リポジトリーでガベージコレクションが有効になっているかどうか。デフォルトは | ブール値 |
GARBAGE_COLLECTION_FREQUENCY | ガベージコレクションワーカーが実行される頻度 (秒単位)。ガベージコレクションワーカーにのみ影響します。デフォルトは 30 秒です。 | 文字列 |
PUSH_TEMP_TAG_EXPIRATION_SEC | アップロード後にブロブがガベージコレクションされない秒数。この機能は、ガベージコレクションがまだ参照されていないが進行中のプッシュの一部として使用されている blob をクリーンアップするのを防ぎます。 | 文字列 |
タグの有効期限オプション | 有効なタグの有効期限の値のリスト。 | 文字列 |
DEFAULT_TAG_EXPIRATION | タイムマシンの有効期限にタグを付けます。 | 文字列 |
CLEAN_BLOB_UPLOAD_FOLDER | S3 マルチパートアップロードから残った古い BLOB を自動的に消去します。既定では、2 日以上経過した BLOB ファイルは 1 時間ごとにクリーンアップされます。 | Boolean
+ デフォルト: |
18.4. ガベージコレクションの無効化
イメージタグ、namespace、およびリポジトリーのガベージコレクション機能は、config.yaml
ファイルに保存されます。これらの機能のデフォルトは true
です。
まれに、ガベージコレクションを無効にして、ガベージコレクションを実行するタイミングを制御したい場合があります。GARBAGE_COLLECTION
機能を false
に設定すると、ガベージコレクションを無効にできます。無効にすると、関連付けれていない、またはタグが付いていないイメージ、リポジトリー、名前空間、レイヤー、マニフェストは削除されません。これにより、環境のダウンタイムが増加する可能性があります。
ガベージコレクションを手動で実行するコマンドはありません。代わりに、ガベージコレクション機能を無効にしてから再度有効にします。
18.5. ガベージコレクションとクォータ管理
Red Hat Quay は、3.7 でクォータ管理を導入しました。クォータ管理により、ユーザーは、設定されたストレージクォータ制限を確立することにより、ストレージ消費を報告し、レジストリーの増加を抑えることができます。
Red Hat Quay 3.7 以降、ガベージコレクションは、削除後にイメージ、リポジトリー、および BLOB に割り当てられたメモリーを再利用します。ガベージコレクション機能は削除後にメモリーを再利用するため、環境のディスクスペースに格納されているものと、クォータ管理が総消費量としてレポートしているものとの間に不一致があります。現在、この問題に対する回避策はありません。
18.6. 実際のガベージコレクション
以下の手順を使用して Red Hat Quay ログをチェックし、ガベージコレクションが機能していることを確認します。
手順
次のコマンドを入力して、ガベージコレクションが正しく機能していることを確認します。
$ sudo podman logs <container_id>
出力例:
gcworker stdout | 2022-11-14 18:46:52,458 [63] [INFO] [apscheduler.executors.default] Job "GarbageCollectionWorker._garbage_collection_repos (trigger: interval[0:00:30], next run at: 2022-11-14 18:47:22 UTC)" executed successfully
- イメージタグを削除します。
次のコマンドを入力して、タグが削除されたことを確認します。
$ podman logs quay-app
出力例:
gunicorn-web stdout | 2022-11-14 19:23:44,574 [233] [INFO] [gunicorn.access] 192.168.0.38 - - [14/Nov/2022:19:23:44 +0000] "DELETE /api/v1/repository/quayadmin/busybox/tag/test HTTP/1.0" 204 0 "http://quay-server.example.com/repository/quayadmin/busybox?tab=tags" "Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0"
18.7. 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 ...
第19章 Red Hat Quay のトラブルシューティング
一般的な故障モードと復旧のためのベストプラクティス
- HTTP Status Code 429 を受信している
- 認証されているが、403 が表示される
- Dockerfile でベースイメージのプルが 403 で失敗する
- ビルドトリガーを追加できない
- ビルドログが読み込まれない
- Cannot locate specified Dockerfile と表示される * Could not reach any registry endpoint と表示される
- EC2 Container Service でプライベートリポジトリーにアクセスできない
- Docker が i/o タイムアウトを返す
- Docker のログインが奇異なエラーで失敗する
- プルが異常なエラーで失敗する
- 今プッシュしましたが、タイムスタンプが間違っている
- Marathon/Mesos を使用した Private Quay.io イメージの取り込みに失敗する
第20章 Red Hat Quay の設定用スキーマ
ほとんどの Red Hat Quay 設定情報は、Red Hat Quay が最初に展開されたときにブラウザーベースの config ツールを使用して作成される config.yaml
ファイルに保存されます。
設定オプションは、Red Hat Quay 設定ガイドで説明しています。