Red Hat Quay の管理
Red Hat Quay の管理
概要
はじめに
Red Hat Quay レジストリーを展開した後、その展開をさらに設定、管理する方法は数多くあります。ここでは、以下のようなトピックを取り上げています。
- Red Hat Quay の高度な設定
- Red Hat Quay の新リリースを知らせる通知の設定
- SSL および TLS 証明書による接続の保護
- アクションログのストレージの Elasticsearch へのダイレクト
- Clair によるイメージセキュリティースキャンの設定
- コンテナーセキュリティー Operator での Pod イメージのスキャン
- Quay Bridge Operator を使用した Red Hat Quay の OpenShift への統合
- リポジトリーミラーリングによるイメージの反映
- BitTorrent サービスによる Quay イメージの共有
- LDAP によるユーザーの認証
- Prometheus および Grafana メトリクスの Quay の有効化
- Geo レプリケーションの設定
- Quay のトラブルシューティング
第1章 Red Hat Quay の高度な設定
初期導入後の Red Hat Quay は、いくつかの異なるインターフェイスを使用して設定できます。
-
Red Hat Quay Config Tool:
config
モードでQuay
コンテナーを実行すると、Red Hat Quay クラスターを設定するための Web ベースのインターフェイスが表示されます。この方法は、Red Hat Quay サービス自体のほとんどの設定に推奨される方法です。 -
config.yaml
の編集:config.yaml
ファイルには、Red Hat Quay クラスターの設定情報のほとんどが格納されています。このファイルを直接編集することは可能ですが、Config Tool では利用できない高度なチューニングやパフォーマンス機能を利用する場合にのみお勧めします。 - Red Hat Quay の API: 一部の Red Hat Quay の設定は API を通じて行うことができます。
特定の機能のための設定は別のセクションで説明しますが、このセクションでは、それぞれのインターフェイスを使用して、より高度な設定を行う方法を説明します。
1.1. Red Hat Quay Config Tool を使用した Red Hat Quay の変更
Red Hat Quay Config Tool は、通常の Red Hat Quay サービスと共に config
モードで Quay
コンテナーを実行して利用できます。Config Tool の実行は、OpenShift 上で動作する Red Hat Quay クラスターの場合は、ホストシステム上で直接動作する場合とは異なります。
1.1.1. Red Hat Quay Operator からの Config Tool の実行
OpenShift から Red Hat Quay Operator を実行している場合は、おそらく Config Tool がすでに利用可能になっています。Config Tool にアクセスするには、次のようにします。
- OpenShift コンソールから、Red Hat Quay が実行されているプロジェクトを選択します。たとえば、quay-enterprise です。
左の列からネットワーク→ルートを選択します。次のイメージに示すように、Red Hat Quay アプリケーションと Config Tool の両方へのルートが表示されます。
- Config Tool へのルート (例: example-quayecosystem-quay-config) を選択し、選択します。ブラウザーに Config tool Web UI が表示されます。
Modify configuration for this cluster
を選択します。次のイメージに示すように、Config Tool が表示され、Red Hat Quay クラスターの機能を変更する準備ができています。-
必要な変更を行った後、
Save Configuration Changes
を選択します。Config Tool が変更内容を検証します。 -
必要に応じて、
Continue Editing
を選択して修正するか、Next
を選択して次に進みます。 -
プロンプトが表示されたら、
Download Configuration
を選択することをお勧めします。これにより、新しいconfig.yaml
と、Red Hat Quay のセットアップで使用された証明書や鍵を含む tarball がダウンロードされます。 -
Go to deployment rollout
を選択し、Populate the configuration to deployments
を選択します。Red Hat Quay の Pd が再起動となり、変更が有効になります。
保存された config.yaml
ファイルは、設定の高度な変更を行うために使用することも、今後の参考のために保存しておくこともできます。
1.1.2. コマンドラインからの Config Tool の実行
podman
コマンドや docker
コマンドなどのツールを使用してホストシステムから直接 Red Hat Quay を実行している場合は、最初の Red Hat Quay の展開後に Config Tool を再起動して Red Hat Quay クラスターを変更することができます。以下に、実行する方法を説明します。
quay をコンフィグモードで起動: 最初の
quay
ノードで以下を実行し、my-secret-password
をあなたのパスワードに置き換えます。既存の設定バンドルを変更する場合は、レジストリーモードの場合と同様に、設定ディレクトリーをQuay
コンテナーに簡単にマウントすることができます。# podman run --rm -it --name quay_config -p 8080:8080 \ -v path/to/config-bundle:/conf/stack \ registry.redhat.io/quay/quay-rhel8:v3.5.7 config my-secret-password
- ブラウザーを開く: Quay のコンフィグレーションツールが起動したら、コンフィグレーションツールを実行しているシステムの URL およびポート 8080 に向けてブラウザーを開きます (例: https://myquay.example.com:8080)。ユーザー名とパスワードの入力を求められます。
この時点で、前述のように Red Hat Quay クラスターの変更を開始することができます。
1.2. API を使用した Red Hat Quay の変更
Red Hat Quay API へのアクセス方法については、Red Hat Quay API ガイド を参照してください。
1.3. config.yaml
ファイルを編集して Red Hat Quay の変更
Config Tool では利用できない高度な Red Hat Quay の設定は、config.yaml
ファイルを直接編集することで実現できます。利用可能な設定は、Red Hat Quay 設定のスキーマ に記載されています。以下は、config.yaml
ファイルで直接変更できる設定の例です。
1.3.1. Red Hat Quay のサインインに名前と会社を追加
以下のように設定すると、ユーザーが最初にサインインしたときに、名前と会社名を入力するプロンプトが表示されます。任意ですが、Red Hat Quay のユーザーに関する追加データを提供することができます。
+ FEATURE_USER_METADATA: true
1.3.2. TLS プロトコルの無効化
SSL_PROTOCOLS 設定を変更して、Red Hat Quay インスタンスでサポートしたくない SSL プロトコルを削除することができます。たとえば、デフォルトの SSL_PROTOCOLS : ['TLSv1','TLSv1.1','TLSv1.2'] から TLS v1 のサポートを削除するには、以下のように変更します。
+ SSL_PROTOCOLS : ['TLSv1.1','TLSv1.2']
1.3.3. API コールのレート制限
config.yaml
に FEATURE_RATE_LIMITS パラメーターを追加すると、nginx
は特定の API コールを 1 秒あたり 30 回に制限します。この機能が設定されていない場合、API コールは 1 秒間に 300 回に制限されます (事実上無制限)。利用可能なリソースがトラフィックで圧迫されないようにする必要がある場合、レート制限は重要な機能となります。
名前空間の中には、無制限のアクセスを必要とするものもあります (たとえば、CI/CD にとって重要であり、優先順位が高いなど)。この場合、それらの名前空間は、config.yaml
の NON_RATE_LIMITED_NAMESPACES のリストに配置することができます。
1.3.4. データベースのコネクションプールの調整
Red Hat Quay は、すべてが同じコンテナー内で実行する多くの異なるプロセスで設定されています。これらのプロセスの多くは、データベースと連動しています。
有効にすると、データベースと対話する各プロセスには、コネクションプールが含まれます。これらのプロセスごとのコネクションプールは、最大 20 個の接続を維持するように設定されています。高負荷時には、Red Hat Quay コンテナー内のすべてのプロセスの接続プールを満たすことが可能です。特定の展開や負荷の下では、Red Hat Quay がデータベースの設定された最大接続数を超えないようにするための分析が必要になる場合があります。
時間が経つと、接続プールはアイドル接続を解放します。すべての接続をすぐに解除するには、Red Hat Quay の再起動が必要です。
データベース接続プールは、環境変数 DB_CONNECTION_POOLING={true|false}
を設定して切り替えることができます。
データベース接続プーリングが有効な場合は、接続プールの最大サイズを変更することができます。これは、以下の config.yaml
オプションを使用して実行できます。
DB_CONNECTION_ARGS: max_connections: 10
1.3.4.1. データベース接続引数
Red Hat Quay のデータベース接続設定は config.yaml
ファイル内でカスタマイズすることができます。これらは、Postgres 用の psycopg2
や MySQL 用の pymysql
のように、基礎となるデータベースドライバーに完全に依存しています。また、以下のように、Peewee のコネクションプーリング機構が使用する引数を渡すことも可能です。
DB_CONNECTION_ARGS: max_connections: n # Max Connection Pool size. (Connection Pooling only) timeout: n # Time to hold on to connections. (Connection Pooling only) stale_timeout: n # Number of seconds to block when the pool is full. (Connection Pooling only)
1.3.4.2. データベース SSL 設定
DB_CONNECTION_ARGS で定義されたキーと値のペアは汎用的なものも、データベース固有のものもあります。特に、SSL 設定は、デプロイするデータベースによって異なります。
1.3.4.2.1. PostgreSQL SSL 接続引数
PostgreSQL SSL の設定例は以下のようになります。
DB_CONNECTION_ARGS: sslmode: verify-ca sslrootcert: /path/to/cacert
sslmode
オプションは、セキュアな SSL/IP 接続がサーバーにネゴシエートされるかどうか、またはその優先度を決定します。モードは 6 つあります。
- Disable: SSL 以外の接続のみを試行する。
- allow: 初回は SSL 以外の接続を試行して、それに失敗すると SSL 接続を試行する。
- preferred: (デフォルト) 初回は SSL を試行して、それに失敗すると SSL 以外の接続を試行する。
- require: SSL 接続のみを試行する。ルート CA ファイルが存在する場合は、verify-ca が指定されているときと同じように、証明書を確認します。
- verify-ca: SSL 接続のみを試行し、信頼された認証局 (CA) によりサーバー証明書が発行されていることを確認します。
- verify-full: SSL 接続のみを試行します。信頼された CA によりサーバー証明書が発行され、要求されたサーバーのホスト名が証明書と一致することを確認します。
PostgreSQL の有効な引数び詳細は、https://www.postgresql.org/docs/current/libpq-connect.html を参照してください。
1.3.4.2.2. MySQL SSL 接続引数
MySQL SSL の設定例:
DB_CONNECTION_ARGS: ssl: ca: /path/to/cacert
MySQL の有効な接続引数の詳細は、https://dev.mysql.com/doc/refman/8.0/en/connecting-using-uri-or-key-value-pairs.html を参照してください。
1.3.4.3. HTTP 接続回数
環境変数を使用して、HTTP の同時接続数を指定することができます。これらは、全体として、または特定のコンポーネントに対して指定することができます。それぞれのデフォルトは、1 プロセスあたり 50 並列接続です。
環境変数:
WORKER_CONNECTION_COUNT_REGISTRY=n WORKER_CONNECTION_COUNT_WEB=n WORKER_CONNECTION_COUNT_SECSCAN=n WORKER_CONNECTION_COUNT=n
特定のコンポーネントのカウントを指定すると、WORKER_CONNECTION_COUNT で設定された値が上書きされます。
1.3.4.4. ダイナミックなプロセスカウント
ダイナミックサイズのプロセスの量を推定するために、デフォルトでは以下の計算が行われます。
Red Hat Quay は、マシン全体から利用可能な CPU 数を照会します。kubernetes やその他の非仮想化メカニズムを使用して適用された制限は、この動作に影響しません。Red Hat Quay はノード上のプロセッサーの合計数に基づいて計算します。記載されているデフォルト値は単なる目標値であり、最大値を超えてはならず、最小値を下回ってはならない。
以下の各プロセス量は、以下の環境変数を使ってオーバーライドすることができます。
registry - レジストリーアクションを処理するための HTTP エンドポイントを提供します。
- 最小値: 8
- 最大値: 64
- デフォルト: $CPU_COUNT x 4
- 環境変数: WORKER_COUNT_REGISTRY
web - ウェブベースのインターフェイス用の HTTP エンドポイントを提供します
- 最小値: 2
- 最大値: 32
- デフォルト: $CPU_COUNT x 2
- 環境変数: WORKER_COUNT_WEB
secscan - Clair と相互作用します。
- 最小値: 2
- 最大値: 4
- デフォルト: $CPU_COUNT x 2
- 環境変数: WORKER_COUNT_SECSCAN
1.3.4.5. 環境変数
Red Hat Quay では、環境変数を使用してデフォルトの動作をオーバーライドすることができます。この表では、各変数と、使用できる値を一覧にして説明しています。
変数 | 説明 | 値 |
---|---|---|
WORKER_COUNT_REGISTRY |
| 8 ~ 64 の整数 |
WORKER_COUNT_WEB | コンテナー内で UI/Web リクエストを処理するプロセスの数を指定します。 | 2 ~ 32 の整数 |
WORKER_COUNT_SECSCAN | コンテナー内でセキュリティースキャン (Clair など) の統合を処理するプロセス数を指定します。 | 2 ~ 4 の整数 |
DB_CONNECTION_POOLING | データベースのコネクションプーリングを切り替えます。3.4 では、デフォルトで無効になっています。 | true または false |
1.3.4.6. コネクションプーリングの停止
大量のユーザーアクティビティーを伴う Red Hat Quay の展開では、定期的に最大 2k のデータベース接続制限に達することがあります。このような場合、Red Hat Quay でデフォルトで有効になっているコネクションプーリングは、データベース接続数が指数関数的に増加する原因となるため、コネクションプーリングをオフにする必要があります。
コネクションプーリングをオフにしてもデータベース接続数が 2k に制限されるのを防ぐのに十分でない場合は、追加の対策を講じる必要があります。この場合、ワークロードに合わせてデータベースの最大接続数を増やす必要があるかもしれません。
第2章 コンフィグレーション API の利用
コンフィグレーションツールは、設定の構築、検証、バンドル、およびデプロイに使用できる 4 つのエンドポイントを示します。config-tool の API は、https://github.com/quay/config-tool/blob/master/pkg/lib/editor/API.md に記載されています。ここでは、API を使用して現在の設定を取得する方法と、変更した内容を検証する方法について説明します。
2.1. 初期設定値の取得
初めてコンフィグレーションツールを実行するときに、既存のコンフィグレーションがない場合は、デフォルトのコンフィグレーションを取得することができます。コンテナーをコンフィグモードで起動します。
$ sudo podman run --rm -it --name quay_config \ -p 8080:8080 \ registry.redhat.io/quay/quay-rhel8:v3.5.7 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.5.7 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 Account とカスタマーポータルの選択項目が表示されます。
- 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
を作成します。opensssl.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.5.7
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.5.7 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.5.7
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.5.7 "/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.5.7 1 imagePullPolicy: IfNotPresent name: clair-combo env: - name: CLAIR_CONF value: /clair/config.yaml - name: CLAIR_MODE value: combo ports: - containerPort: 8080 name: clair-http protocol: TCP - containerPort: 8089 name: clair-intro protocol: TCP volumeMounts: - mountPath: /clair/ name: config imagePullSecrets: - name: redhat-pull-secret restartPolicy: Always volumes: - name: config secret: secretName: clairv4-config-secret --- apiVersion: v1 kind: Service metadata: name: clairv4 2 labels: quay-component: clair-combo spec: ports: - name: clair-http port: 80 protocol: TCP targetPort: 8080 - name: clair-introspection port: 8089 protocol: TCP targetPort: 8089 selector: quay-component: clair-combo type: ClusterIP
- 1
- イメージを最新のクレアのイメージ名とバージョンに変更します。
- 2
- サービスを clairv4 に設定すると、Clair v4 のスキャナーエンドポイントは、Red Hat Quay の config.yaml の
SECURITY_SCANNER_V4_ENDPOINT
に以下のように入力します。http://clairv4
.
以下のように Clair v4 の配置を作成します。
$ oc create -f ./clair-combo.yaml
Red Hat Quay 配置の
config.yaml
ファイルを変更して、最後に以下のエントリーを追加します。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.5.7
- 新しい Clair V4 エンドポイントを使用するために Red Hat Quay を設定するには、前のセクションの残りの指示に従ってください。
この形で複数の Clair コンテナーを実行することも可能ですが、1 つのコンテナーを超えるデプロイメントシナリオでは、Kubernetes や OpenShift などのコンテナーオーケストレーターの使用を強く推奨します。
7.3. クレールの使用
- Red Hat Quay クラスターにログインし、Clair スキャンを設定した組織を選択します。
その組織からいくつかのイメージを保持するリポジトリーを選択し、左のナビゲーションからタグを選択します。次の図は、2 枚のイメージがスキャンされたリポジトリーの例です。
脆弱性が発見された場合は、イメージのセキュリティースキャン欄を選択すると、すべての脆弱性または修正可能な脆弱性が表示されます。次の図は、見つかったすべての脆弱性の情報を示しています。
7.4. 切断された環境のための 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.5.7 --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.5.7 --config /cfg/config.yaml import-updaters /updaters/updaters.gz
7.5. 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.6. 追加情報
マイクロサービスがどのように設定されているかなど、Clair の内部に関する詳細なドキュメントは、Upstream Clair および ClairCore のドキュメントを参照してください。
第8章 コンテナーセキュリティー Operator での Pod イメージのスキャン
Container Security Operator (CSO) を使用すると、OpenShift (4.2 以降) やその他の Kubernetes プラットフォーム上で動作するアクティブな Pod に関連するコンテナーイメージをスキャンし、既知の脆弱性を確認することができます。CSO は、以下を行います。
- すべての namespace または指定された namespace の Pod に関連付けられたコンテナーを監視します。
- イメージのレジストリーがイメージスキャンをサポートしている場合 (Clair スキャンを備えた Quay レジストリーなど) は、コンテナーの元となったコンテナーレジストリーに脆弱性情報を問い合わせます。
- Kubernetes API の ImageManifestVuln オブジェクトを使用して脆弱性を公開します。
この手順を使用すると、CSO は marketplace-operators
namespace にインストールされ、OpenShift クラスターのすべての namespace で利用可能になります。
CSO を Kubernetes にインストールする手順を見るには、Container Security OperatorHub.io のページから Install ボタンを選択します。
8.1. OpenShift での CSO の実行
OpenShift で CSO の使用を開始するには、次のようにします。
-
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章 Bridge Operator で Red Hat Quay を OpenShift に統合
Quay Bridge Operator を使用すると、OpenShift の統合コンテナーレジストリーを Red Hat Quay レジストリーで置き換えることができます。これにより、統合された OpenShift レジストリーは、ロールベースのアクセスコントロール (RBAC) 機能が強化された、可用性の高いエンタープライズグレードの Red Hat Quay レジストリーになります。
Bridge Operator の主な目的は、統合された OpenShift レジストリーの機能を、新しい Red Hat Quay レジストリーに複製することです。この Operator で可能な機能は以下の通りです。
Red Hat Quay の組織として OpenShift の名前空間を同期させます。
- デフォルトネームスペースのサービスアカウントごとのロボットアカウントの作成
- 作成されたロボットアカウントごとにシークレットを作成 (各ロボットシークレットをサービスアカウントに Mountable と Image Pull Secret として関連付ける)。
- OpenShift の ImageStream を Quay のリポジトリーとして同期させる
- Red Hat Quay に出力するために ImageStream を使用して新しいビルドを自動的に書き換えます。
- ビルドが完了すると自動的に ImageStream タグをインポートします。
この手順を Quay Bridge Operator で使用すると、Red Hat Quay と OpenShift クラスター間の双方向通信が可能になります。
Quay Bridge Operator から同じ Red Hat Quay インスタンスを指している OpenShift Container Platform クラスターを複数にすることはできません。そうすると、2 つのクラスターに同じ名前の名前空間を作ることができなくなります。
9.1. Quay Bridge Operator の実行
9.1.1. 前提条件
Bridge Operator をセットアップする前に、以下のものを用意してください。
- スーパーユーザー権限を持つ既存の Red Hat Quay 環境
- クラスター管理者権限を持つ Red Hat OpenShift Container Platform 環境 (4.2 以降を推奨)
-
OpenShift のコマンドラインツール (
oc
コマンド)
9.1.2. OpenShift および Red Hat Quay のセットアップおよび設定
Red Hat Quay と OpenShift の両方の設定が必要です。
9.1.2.1. Red Hat Quay のセットアップ
Red Hat Quay の専用組織を作成し、その組織内で作成した新規アプリケーションから、OpenShift の Quay Bridge Operator で使用する OAuth トークンを生成します。
- スーパーユーザー権限を持つユーザーとして Red Hat Quay にログインし、外部アプリケーションを設定する組織を選択します。
- 左のナビゲーションで Applications を選択します。
-
Create New Application
を選択し、新しいアプリケーションの名前を入力します (例:openshift
)。 - 新しいアプリケーションが表示された状態で、それを選択します。
-
左側のナビゲーションで
Generate Token
を選択し、新しい OAuth2 トークンを作成します。 - すべてのチェックボックスを選択して、統合に必要なアクセスを許可します。
-
割り当てられた権限を確認し、
Authorize Application
を選択して確認します。 - 生成された Access Token は、次のセクションで使用するためにコピーして保存します。
9.1.2.2. OpenShift のセットアップ
Quay Bridge Operator に OpenShift をセットアップするには、以下のようないくつかのステップが必要です。
- OpenShift シークレットの作成: Quay で先に作成した OAuth トークンを使って、OpenShift シークレットを作成します。
- MutatingWebhookConfiguration のサポートを追加: OpenShift と Red Hat Quay の統合をサポートするために、新しい Build リクエストをインターセプトして、OpenShift の統合レジストリーではなく Red Hat Quay をターゲットにするように出力を変更できるようにします。
OpenShift の典型的なビルドプロセスの一部として実行される API リクエストの動的な傍受のサポートは、MutatingWebhookConfiguration によって促進されます。MutatingWebhookConfiguration は、特定の API リクエストを受信したときに、OpenShift 上のプロジェクト内で実行されている API を起動することができます。
Kubernetes では、Webhook エンドポイントがクラスターの証明機関を利用した証明書を用いて SSL で保護されている必要があります。幸いなことに、OpenShift はクラスターで署名された証明書の生成をサポートしています。
-
OpenShift
oc
コマンドラインツールを使用して、クラスター管理者として OpenShift にログインします。 -
openshift-operators
など、使用する OpenShift ネームスペースを選択するか、新しいネームスペースを作成します。 OpenShift のシークレットを作成し、<access_token>を先ほど Red Hat Quay から取得した Access Token に置き換えます。例えば、これはあなたの<access_token>を使って
quay-integration
というシークレットをtoken
というキーで作成します。$ oc create secret generic quay-integration --from-literal=token=<access_token>
その結果、新たに作成された秘密鍵と証明書が、指定された秘密の中に配置されます。シークレットは、Operator のデプロイメントでの宣言の通りに、オペレーター内の適切な場所にマウントされます。
Operator の Webhook エンドポイントの Service を作成します。
quay-webhook.yaml
apiVersion: v1 kind: Service metadata: labels: name: quay-bridge-operator name: quay-bridge-operator namespace: openshift-operators spec: ports: - name: https port: 443 protocol: TCP targetPort: 8443 selector: name: quay-bridge-operator sessionAffinity: None type: ClusterIP
次のように Webhook サービスを作成します。
$ oc create -f quay-webhook.yaml
- webhook-create-signed-cert.sh スクリプトをダウンロードして、Kubernetes 認証局で署名された証明書を生成するために使用できるようにします。
以下のコマンドを実行して、証明書を要求します。
$ ./webhook-create-signed-cert.sh --namespace openshift-operators \ --secret quay-bridge-operator-webhook-certs \ --service quay-bridge-operator
以下のコマンドを実行して CA を取得し、その結果を 1 行にまとめて MutatingWebhookConfiguration リソースに入力できるようにします。
$ oc get configmap -n kube-system \ extension-apiserver-authentication \ -o=jsonpath='{.data.client-ca-file}' | base64 | tr -d '\n'
以下の MutatingWebhookConfiguration の YAML で、${CA_BUNDLE}変数を置き換えてください。
quay-mutating-webhook.yaml
apiVersion: admissionregistration.k8s.io/v1 kind: MutatingWebhookConfiguration metadata: name: quay-bridge-operator webhooks: - name: quayintegration.redhatcop.redhat.io clientConfig: service: namespace: openshift-operators name: quay-bridge-operator path: "/admissionwebhook" caBundle: "${CA_BUNDLE}" 1 rules: - operations: [ "CREATE" ] apiGroups: [ "build.openshift.io" ] apiVersions: ["v1" ] resources: [ "builds" ] failurePolicy: Fail matchPolicy: Exact timeoutSeconds: 30 sideEffects: None admissionReviewVersions: [v1beta1]
- 1
- ${CA_BUNDLE}を前のステップの出力で置き換えます。これは、${CA_BUNDLE}を置き換えるためにコピー&ペーストする 1 つの長い行として表示されます。
以下のように MutatingWebhookConfiguration を作成します。
$ oc create -f quay-mutating-webhook.yaml
オペレータが動作するまでは、MutatingWebhookConfiguration が呼び出す Web サーバーが利用できず、オブジェクトを etcd に永続化するために適切な is レスポンスが必要となるため、ビルドに対する新しいリクエストは失敗します。
OpenShift のコンソールに移動し、以下のように Quay Bridge Operator をインストールします。
- OperatorHub を選択し、Quay Bridge Operator を検索します。
- インストールを選択します。
- インストールモード (全ネームスペース)、更新チャンネル、承認方法 (自動または手動) を選択します。
- Subscribe を選択します。
QuayIntegration
というカスタムリソース (CR) を作成します。例:quay-integration.yaml
apiVersion: redhatcop.redhat.io/v1alpha1 kind: QuayIntegration metadata: name: example-quayintegration spec: clusterID: openshift 1 credentialsSecretName: openshift-operators/quay-integration 2 quayHostname: https://<QUAY_URL> 3 whitelistNamespaces: 4 - default insecureRegistry: false 5
- 1
- clusterID の値は、エコシステム全体で一意でなければなりません。この値はオプションで、デフォルトでは openshift が使用されます。
- 2
- credentialsSecretName には、
openshift-operators/quay-integration
を名前空間の名前と、先に作成したトークンを含むシークレットに置き換えます。 - 3
- QUAY_URL を Red Hat Quay インスタンスのホスト名に置き換えてください。
- 4
- whitelistNamespaces はオプションです。使用しない場合、Bridge Operator は openshift の接頭辞を持つプロジェクトを除くすべての名前空間を Red Hat Quay に同期します。この例では、ホワイトリストのネームスペース (デフォルト) に、Red Hat Quay の組織が関連付けられています。ここでは、好きな名前空間を使用してください。
- 5
- Quay が自己署名証明書を使用している場合、プロパティー
insecureRegistry: true
を設定します。
その結果、Red Hat Quay 内の組織は、OpenShift の関連する名前空間のために作成する必要があります。
以下のように
QuayIntegration
を作成します。$ oc create -f quay-integration.yaml
この時点で Quay の統合リソースが作成され、OpenShift クラスターと Red Hat Quay インスタンスがリンクされます。
作成したホワイトリストの名前空間には、Red Hat Quay の組織があるはずです。oc new-app
などのコマンドを使用して、その namespace で新規アプリケーションを作成する場合、内部レジストリーを使用する代わりに、作成された新しい Red Hat Quay リポジトリーが表示されます。
第10章 リポジトリーのミラーリング
10.1. リポジトリーのミラーリング
Red Hat Quay リポジトリーミラーリングを使用すると、外部コンテナーレジストリー (または別のローカルレジストリー) から Red Hat Quay クラスターにイメージをミラーリングできます。リポジトリーミラーリングを使用すると、リポジトリー名とタグに基づいてイメージを Red Hat Quay に同期できます。
リポジトリーミラーリングが有効にされた Red Hat Quay クラスターから、以下を実行できます。
- 外部のレジストリーからミラーリングするリポジトリーを選択する。
- 外部レジストリーにアクセスするための認証情報を追加する。
- 同期する特定のコンテナーイメージリポジトリー名とタグを特定する。
- リポジトリーが同期される間隔を設定する。
- 同期の現在の状態を確認する。
ミラーリング機能を使用するには、以下を行う必要があります。
- Red Hat Quay 設定で Repository Mirroring を有効にする。
- リポジトリーミラーリングワーカーを実行する。
- ミラーリングされたリポジトリーを作成する。
すべてのリポジトリーミラーリングの設定は、コンフィグレーションツールの UI または Quay API を使用して行うことができます。
10.2. リポジトリーのミラーリングと geo レプリケーションの比較
Quay の geo レプリケーションは、データベースが共有されている間に、2 つ以上の異なるストレージバックエンド間でイメージストレージのバックエンドデータ全体をミラーリングします (2 つの異なる blob ストレージエンドポイントを持つ 1 つの Quay レジストリー)。geo レプリケーションの主なユースケースは以下のとおりです。
- 地理的に分散する設定向けのバイナリー Blob へのアクセス速度を上げる
- イメージのコンテンツがリージョン全体で同じであることを保証する
リポジトリーのミラーリングは、選択されたリポジトリー (またはリポジトリーのサブセット) をあるレジストリーから別のレジストリーに同期します。レジストリーは固有であり、別個のデータベースおよびイメージストレージです。ミラーリングの主なユースケースは、以下のとおりです。
- 異なるデータセンターまたはリージョンでの独立したレジストリーのデプロイメント。ここでは、すべてのコンテンツの特定のサブセットがデータセンター/リージョン間で共有されることになっています。
- 外部レジストリーからローカル Quay デプロイメントへの選択された (ホワイトリスト化された) アップストリームリポジトリーの自動同期またはミラーリング
リポジトリーのミラーリングと Geo レプリケーションを同時に使用できます。
機能と性能 | Geo レプリケーション | リポジトリーのミラーリング |
---|---|---|
設計されている機能 | グローバルに共有されるレジストリー | 独立した異なるレジストレーション |
レプリケーションやミラーリングがまだ完了していない場合はどうなるか ? | リモートコピーを使用する (遅くなります) | イメージが表示されない |
両地域のすべてのストレージバックエンドへのアクセスが必要か ? | はい (すべての Red Hat Quay ノード)。 | いいえ (個別のストレージ) |
ユーザーは両方のサイトのイメージを同じリポジトリーにプッシュできるか ? | はい | いいえ |
すべてのレジストリーの内容と設定がすべての地域で同一であるか (共有データベース) | はい | いいえ |
ユーザーはミラーリングする個別の namespace またはリポジトリーを選択できるか ? | デフォルトでは、いいえ。 | はい |
ユーザーは同期ルールにフィルターを適用できるか ? | いいえ | はい |
10.3. リポジトリーミラーリングの使用
ここでは、Red Hat Quay リポジトリーミラーリングの機能と制限について説明します。
- リポジトリーのミラーリングでは、リポジトリー全体をミラーリングしたり、同期するイメージを選択的に制限したりできます。フィルターは、タグのコンマ区切りの一覧、タグの範囲、または正規表現でタグを特定する他の方法によります。
- ミラーリングされたリポジトリーとして設定されると、そのリポジトリーに他のイメージを手動で追加することはできません。
- ミラーリングされたリポジトリーは、設定されたリポジトリーとタグに基づいているため、レポ/タグのペアで表されるコンテンツのみを保持します。つまり、リポジトリーの一部のイメージがこれ以上一致しないようにタグを変更すると、これらのイメージは削除されます。
- 指定されたロボットだけが、ミラーリングされたリポジトリーにイメージをプッシュすることができ、リポジトリーに設定されたロールベースのアクセスコントロール権限に優先します。
- ミラーリングされたリポジトリーでは、ユーザーは (読み取り権限を与えられて) リポジトリーからイメージを引き出すことはできますが、リポジトリーにイメージをプッシュすることはできません。
- ミラーリングされたリポジトリーの設定の変更は、作成するミラーリングされたリポジトリーについての Repositories ページの Mirrors タブから行われます。
- イメージは一定の間隔で同期されますが、必要に応じて同期することもできます。
10.4. 設定のミラーリング UI
設定モードで
Quay
コンテナーを起動し、Enable Repository Mirroring チェックボックスを選択します。HTTPS 通信を必要とし、ミラーリング時に証明書を検証する必要がある場合は、HTTPS を選択し、証明書の検証のチェックボックスを選択します。-
configuration
を検証し、ダウンロードしてから、更新された設定ファイルを使用してレジストリーモードで Quay を再起動します。
10.5. 設定フィールドのミラーリング
フィールド | タイプ | 説明 |
---|---|---|
FEATURE_REPO_MIRROR | ブール値 |
リポジトリーミラーリングの有効化または無効化を行います。 |
|
|
|
REPO_MIRROR_INTERVAL | 数値 |
次にリポジトリーミラー候補をチェックするまでの秒数 |
REPO_MIRROR_SERVER_HOSTNAME | 文字列 |
|
REPO_MIRROR_TLS_VERIFY | ブール値 |
HTTPS を必要とし、ミラー時に Quay レジストリーの証明書を検証します。 |
10.6. ミラーリングワーカー
リポジトリーのミラーリングワーカーを実行するには、
repomirror
オプションを指定してQuay
Pod を起動します。$ sudo podman run -d --name mirroring-worker \ -v $QUAY/config:/conf/stack:Z \ registry.redhat.io/quay/quay-rhel8:v3.5.7 repomirror
証明書
/root/ca.crt
を使用して TLS 通信を設定している場合、以下の例ではミラーリングワーカーの起動方法を示します。$ sudo podman run -d --name mirroring-worker \ -v $QUAY/config:/conf/stack:Z \ -v /root/ca.crt:/etc/pki/ca-trust/source/anchors/ca.crt \ registry.redhat.io/quay/quay-rhel8:v3.5.7 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 は、Quay がすでに稼働している他のノードを含め、どのノードでも実行できます。
- リポジトリーのミラーリングは、データベースでスケジュールされ、一括して実行されます。その結果、ワーカーが増えれば、より多くのバッチが処理されるため、ミラーリングが速くなる可能性があります。
ミラーリング Pod の最適な数は、以下の要素により変わります。
- ミラーリングされるリポジトリーの合計数
- リポジトリー内のイメージやタグの数と変更の頻度
- 並列バッチ
- すべてのミラーリングされたリポジトリーが同時に起動しないように、ミラーリングのスケジュールをバランスよく設定する必要があります。
- ユーザー数が約 1000 人、リポジトリー数が約 1000 個、ミラーリングされたリポジトリー数が約 100 個の中規模のデプロイメントでは、3 ~ 5 個のミラーリング Pod を使用し、必要に応じて 10 個にスケールアップすることを想定しています。
第11章 OpenShift Container Platform デプロイメントでの Red Hat Quay のバックアップおよび復元
このセクションの内容を使用して、OpenShift Container Platform デプロイメントで Red Hat Quay をバックアップおよび復元します。
11.1. Red Hat Quay のバックアップ
この手順は、OpenShift Container Platform および NooBaa デプロイメント専用です。
前提条件
- OpenShift Container Platform での 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 namespace の
<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
ファイルを編集し、すべての所有者の参照を削除します。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
Quay、Quay Operator をスケールダウンします。
$ oc scale --replicas=0 deployment $(oc get deployment -n <quay-operator-namespace> |awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
Quay namespace をスケールダウンします。
$ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace> -l quay-component=quay -o jsonpath='{.items[0].metadata.name}') -n <quay-namespace>
registry-quay-app
Pod が消えるのを待ちます。以下のコマンドを実行してステータスを確認できます。$ 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-mirror-758fc68ff7-5wxlp 1/1 Running 0 8m29s registry-quay-mirror-758fc68ff7-lbl82 1/1 Running 0 8m29s registry-quay-redis-7cc5f6c977-956g8 1/1 Running 0 5d21h
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
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
Quay、Quay Operator をスケールアップします。
$ oc scale --replicas=1 deployment $(oc get deployment -n <quay-operator-namespace> |awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
Quay namespace をスケールアップします。
$ oc scale --replicas=1 deployment $(oc get deployment -n <quay-namespace> -l quay-component=quay -o jsonpath='{.items[0].metadata.name}') -n <quay-namespace>
Operator のステータスを確認します。
$ oc get quayregistry <quay-registry-name> -n <quay-namespace> -o yaml
出力例:
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: ... name: example-registry namespace: <quay-namespace> ... spec: components: - kind: quay managed: true ... - kind: clairpostgres managed: true configBundleSecret: init-config-bundle-secret status: configEditorCredentialsSecret: example-registry-quay-config-editor-credentials-fg2gdgtm24 configEditorEndpoint: https://example-registry-quay-config-editor-quay-enterprise.apps.docs.gcp.quaydev.org currentVersion: 3.7.0 lastUpdated: 2022-05-11 13:28:38.199476938 +0000 UTC registryEndpoint: https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org 0 5d21h
11.2. Red Hat Quay の復元
この手順は、Red Hat Quay Operator がデータベースを管理する際に Red Hat Quay を復元するために使用されます。これは、Quay レジストリーのバックアップが実行された後に実行する必要があります。
前提条件
- Red Hat Quay は、Quay Operator を使用して OpenShift Container Platform にデプロイされている。
- Red Hat Quay データベースがバックアップされている。
手順
バックアップされた 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
Quay、Quay Operator をスケールダウンします。
$ oc scale --replicas=0 deployment $(oc get deployment -n <quay-operator-namespace> |awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
Quay namespace をスケールダウンします。
$ oc scale --replicas=0 deployment $(oc get deployment -n <quay-namespace> -l quay-component=quay -o jsonpath='{.items[0].metadata.name}') -n <quay-namespace>
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
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}')
Quay、Quay Operator をスケールアップします。
$ oc scale --replicas=1 deployment $(oc get deployment -n <quay-operator-namespace> |awk '/^quay-operator/ {print $1}') -n <quay-operator-namespace>
Quay namespace をスケールアップします。
$ oc scale --replicas=1 deployment $(oc get deployment -n <quay-namespace> -l quay-component=quay -o jsonpath='{.items[0].metadata.name}') -n <quay-namespace>
Operator のステータスをチェックして、オンラインに戻ることを確認します。
$ oc get quayregistry -n <quay-namespace> <registry-name> -o yaml
出力例:
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: ... name: example-registry namespace: quay-enterprise ... spec: components: - kind: quay managed: true ... - kind: clairpostgres managed: true configBundleSecret: init-config-bundle-secret status: configEditorCredentialsSecret: example-registry-quay-config-editor-credentials-fg2gdgtm24 configEditorEndpoint: https://example-registry-quay-config-editor-quay-enterprise.apps.docs.gcp.quaydev.org currentVersion: 3.7.0 lastUpdated: 2022-05-11 13:28:38.199476938 +0000 UTC registryEndpoint: https://example-registry-quay-quay-enterprise.apps.docs.gcp.quaydev.org 0 5d21h
第12章 Red Hat Quay の LDAP 認証設定
LDAP (Lightweight Directory Access Protocol) は、IP ネットワークで分散ディレクトリー情報サービスにアクセスし、これを維持するために使用するオープンな、ベンダーに依存しない業界標準のアプリケーションプロトコルです。Red Hat Quay は ID プロバイダーとして LDAP の使用をサポートしています。
12.1. LDAP を有効にする前の考慮事項
12.1.1. 既存の Quay デプロイメント
ユーザーがすでに設定されている既存の Quay デプロイメントで LDAP を有効にすると、ユーザー名との競合が発生する可能性があります。LDAP を有効にする前に、Quay で特定のユーザー alice
を手動作成したシナリオを考慮してください。ユーザー名 alice
が LDAP ディレクトリーにも存在する場合に、alice
が LDAP を使用して初回ログインしたときに、Quay は新規ユーザー alice-1
を作成し、LDAP 認証情報をこのアカウントにマップします。これは、整合性の理由から望ましくない可能性があり、LDAP を有効にする前に、Quay からローカルのアカウント名で競合する可能性のある名前を削除することを推奨します。
12.1.2. 手動ユーザーの作成と LDAP 認証
Quay が LDAP 用に設定されていて、設定オプション FEATURE_USER_CREATION
が true
に設定されている場合は、LDAP 認証ユーザーが最初のログイン時に Quay のデータベースに自動的に作成されます。このオプションを false
に設定すると、LDAP ユーザーの自動ユーザー作成に失敗し、ユーザーはログインできません。このシナリオでは、スーパーユーザーが最初に必要なユーザーアカウントを作成する必要があります。一方、FEATURE_USER_CREATION
が true
に設定されている場合は、LDAP に同等のユーザーがある場合でも、ユーザーは Quay ログイン画面からもアカウントを作成できます。
12.2. LDAP の設定
設定ツールで認証の項目を探し、ドロップダウンメニューから LDAP を選択します。必要に応じて LDAP 設定項目を更新してください。
- 以下は、config.yaml ファイルの結果としてのエントリーの例です。
AUTHENTICATION_TYPE: LDAP
12.2.1. 完全な LDAP URI
- ldap:// または ldaps:// の接頭辞を含む、完全な LDAP URI。
- ldaps:// で始まる URI は、提供された SSL 証明書を使用して TLS の設定を行います。
- 以下は、config.yaml ファイルの結果としてのエントリーの例です。
LDAP_URI: ldaps://ldap.example.org
12.2.2. チームシンクロナイゼーション
- この機能を有効にすると、スーパーユーザーである組織管理者は、チームのメンバーシップを LDAP の下位グループと同期させるように設定できます。
- 再同期期間とは、チームを再同期させる必要がある期間のことです。継続時間を文字列形式で表現する必要があります (30m、1h、1d)。
- オプションとして、管理者である組織の下で、スーパーユーザー以外の人がチームの同期を有効にして管理できるようにします。
- 以下は、config.yaml ファイルの結果としてのエントリーの例です。
FEATURE_TEAM_SYNCING: true TEAM_RESYNC_STALE_TIME: 60m FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP: true
12.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
12.2.4. ユーザーフィルターの追加
- 指定された場合は、すべてのユーザー検索クエリーで使用される追加フィルターとなります。なお、フィルターで使用する識別名はすべて 完全 パスでなければならず、ベース DN はここでは自動的に追加されません。括弧でくくる必要があります。たとえば、(&(someFirstField=someValue)(someOtherField=someOtherValue)) です。
- 以下は、config.yaml ファイルの結果としてのエントリーの例です。
LDAP_USER_FILTER: (memberof=cn=developers,ou=groups,dc=example,dc=com)
12.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
12.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
12.2.7. 検証
設定が完了したら、Save Configuration Changes ボタンをクリックして設定を有効にします。
すべての検証が成功しないと先に進めません。また、編集を続けるボタンを選択して追加の設定を行うこともできます。
12.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 パスの検索/読み取り権限がありません。
12.4. LDAP ユーザーをスーパーユーザーとして設定
LDAP が設定されると、有効な LDAP ユーザー名とパスワードで Red Hat Quay インスタンスにログインできるようになります。次の図のように、Red Hat Quay のユーザー名を確認するプロンプトが表示されます。
LDAP ユーザーにスーパーユーザー権限を付与するには、config.yaml ファイルのユーザー名を変更します。以下に例を示します。
SUPER_USERS: - testadmin
更新された config.yaml ファイルを使用して Red Hat Quay
コンテナーを再起動します。次回のログイン時には、そのユーザーはスーパーユーザーの権限を持つことになります。
第13章 Red Hat Quay の下での Prometheus および Grafana のメトリクス
Red Hat Quay は、各インスタンスに Prometheus と Grafana に対応したエンドポイントをエクスポートし、簡単にモニターリングとアラートを行うことができます。
13.1. Prometheus エンドポイントの公開
Red Hat Quay インスタンス上の Prometheus と Grafana に対応したエンドポイントは、ポート 9091
にあります。Quay のリポジトリーカウントを監視するための Prometheus と Grafana の設定については、Monitoring Quay with Prometheus and Grafana を参照してください。
13.1.1. Prometheus がメトリクスを消費するための設定
Prometheus は、クラスター内で実行されているすべての Red Hat Quay インスタンスにアクセスする方法が必要です。典型的なセットアップでは、すべての Red Hat Quay インスタンスを単一の名前付き DNS エントリーにリストアップし、それを Prometheus に渡すことで行われます。
13.1.2. Kubernetes での DNS 設定
シンプルな Kubernetes service を設定して、Prometheus の DNS エントリーを提供することができます。Prometheus を Kubernetes 上で動作させるための詳細は、Prometheus and Kubernetes と Monitoring Kubernetes with Prometheus を参照してください。
13.1.3. 手動クラスターの DNS 設定
SkyDNS は、Kubernetes を使用していない場合に、この DNS レコードを管理するためのシンプルなソリューションです。SkyDNS は、etcd クラスター上で動作させることができます。クラスター内の各 Red Hat Quay インスタンスのエントリーを etcd ストアに追加、削除することができます。SkyDNS はそこから定期的に読み込んで、それに応じて DNS レコードの Quay インスタンスのリストを更新します。
第14章 Geo レプリケーション
Geo レプリケーションでは、地理的に分散した複数の Quay デプロイメントを、クライアントやユーザーの視点から、単一のレジストリーとして動作させることができます。グローバルに分散された Quay のセットアップにおいて、プッシュとプルのパフォーマンスが大幅に向上します。イメージデータはバックグラウンドで非同期的に複製され、クライアントには透過的なフェイルオーバー/リダイレクトが行われます。
OpenShift での geo-replication を使用した Red Hat Quay のデプロイは Operator ではサポートされません。
14.1. Geo レプリケーション機能
- Geo レプリケーションが設定されていると、コンテナーイメージのプッシュはその Red Hat Quay インスタンスの推奨ストレージエンジンに書き込まれます (通常はリージョン内の最も近いストレージバックエンド)。
- 最初のプッシュの後、イメージデータはバックグランドで他のストレージエンジンに複製されます。
- レプリケーションロケーションのリストは設定可能で、それらは異なるストレージバックエンドにすることができます。
- イメージプルでは、プルのパフォーマンスを最大化するために、常に利用可能な最も近いストレージエンジンを使用します。
- レプリケーションがまだ完了していない場合、プルは代わりにソースストレージのバックエンドを使用します。
14.2. Geo レプリケーションの要件と制約
- 1 つのデータベース、つまりすべてのメタデータと Quay の設定がすべてのリージョンで共有されます。
- 1 つの Redis キャッシュは Quay のセットアップ全体で共有され、すべての Quay Pod からアクセスできる必要があります。
-
ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、
QUAY_DISTRIBUTED_STORAGE_PREFERENCE
環境変数を使用して明示的に設定できます。 - Geo レプリケーションでは、各リージョンにオブジェクトストレージが必要です。ローカルストレージや NFS では動作しません。
- 各リージョンは、各リージョンのすべてのストレージエンジンにアクセスできる必要があります (ネットワークパスが必要)。
- また、ストレージプロキシーオプションを使用することもできます。
- ストレージのバックエンド全体 (すべての blob) が複製されます。これは、組織、リポジトリー、イメージに限定することができるリポジトリーミラーリングとは対照的です。
- すべての Quay インスタンスは、ロードバランサーを介して同じエントリーポイントを共有する必要があります。
- すべての Quay インスタンスは、共通の設定ファイルで定義された同じスーパーユーザーのセットを持つ必要があります。
上記の要件を満たすことができない場合は、代わりに 2 つ以上の異なる Quay のデプロイメントを使用し、リポジトリーミラーリング機能を利用する必要があります。
14.3. Geo レプリケーションのアーキテクチャー
上記の例では、Quay は共通のデータベースおよび共通の Redis インスタンスを持つ 2 つのリージョンで実行されます。ローカライズされたイメージストレージは各リージョンで提供され、最も近くにある利用可能なストレージエンジンからイメージプルが提供されます。コンテナーイメージのプッシュは、Quay インスタンスの推奨ストレージエンジンに書き込まれ、次にバックグラウンドで他のストレージエンジンに複製されます。
14.4. ストレージレプリケーションの有効化
-
スクロールダウンして、
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.4.1. ストレージの環境設定による 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.5.7
注記指定された環境変数の値は、コンフィグパネルで定義されたロケーション ID の名前と一致する必要があります。
- すべての Red Hat Quay コンテナーを再起動します。
第15章 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 イメージの取り込みに失敗する
第16章 Red Hat Quay の設定用スキーマ
ほとんどの Red Hat Quay 設定情報は、Red Hat Quay が最初に展開されたときにブラウザーベースの config ツールを使用して作成される config.yaml
ファイルに保存されます。この章では、config.yaml ファイルで使用可能なそれらの設定のスキーマについて説明します。
以下の項目は必須です (その他はすべて任意)。
AUTHENTICATION_TYPE BUILDLOGS_REDIS DATABASE_SECRET_KEY DB_URI DEFAULT_TAG_EXPIRATION DISTRIBUTED_STORAGE_CONFIG DISTRIBUTED_STORAGE_PREFERENCE PREFERRED_URL_SCHEME SECRET_KEY SERVER_HOSTNAME TAG_EXPIRATION_OPTIONS USER_EVENTS_REDIS
ACTION_LOG_ARCHIVE_LOCATION[文字列]: アクションログのアーカイブが有効な場合、アーカイブされたデータを配置するストレージエンジンです。
-
例:
s3_us_east
-
例:
ACTION_LOG_ARCHIVE_PATH[文字列]: アクションログのアーカイブが有効な場合、アーカイブされたデータを配置するストレージ内のパスです。
-
例:
archives/actionlogs
-
例:
ACTION_LOG_ROTATION_THRESHOLD[文字列]:ACTION_LOG_ROTATION_THRESHOLD [文字列] アクションログのアーカイブが有効な場合、ログを回転させる時間間隔を指定します。
-
例
30d
-
例
ALLOW_PULLS_WITHOUT_STRICT_LOGGING[ブール]:true の場合、pull 監査ログのエントリーが書き込めないプルも成功します。データベースが読み取り専用の状態にフォールバックすることができ、その間もプルを継続したい場合に有効です。デフォルトは false です。
-
例:
True
-
例:
APP_SPECIFIC_TOKEN_EXPIRATION[文字列,
null
]: 外部アプリのトークンの有効期限です。デフォルトは None です。-
パターン:
^[0-9]+(w|m|d|h|s)$
-
パターン:
AUTHENTICATION_TYPE[文字列] 必須。クレデンシャル認証に使用する認証エンジンを指定します。
- enum: Database, LDAP, JWT, Keystone, OIDC.
-
例
Database
AVATAR_KIND[文字列]: 表示するアバターの種類。インラインで生成されたもの (local) か、Gravatar(gravatar) か。
- enum: local, gravatar
BITBUCKET_TRIGGER_CONFIG['object', 'null']: ビルドトリガーに BitBucket を使用するための設定です。
consumer_key[文字列] 必須。この Red Hat Quay インスタンスに登録されているコンシューマーキー (クライアント ID) です。
-
例:
0e8dbe15c4c7630b6780
-
例:
BLACKLISTED_EMAIL_DOMAINS[array]:FEATURE_BLACKLISTED_EMAILS が true に設定されている場合に使用される電子メールアドレスドメインの配列です。
-
例:
"example.com", "example.org"
-
例:
BLACKLIST_V2_SPEC[文字列]:Red Hat Quay が V2 はunsupportedと応答する Docker CLI のバージョンです。デフォルトは
<1.6.0
.です。BRANDING[オブジェクト]。Red Hat Quay UI でのロゴや URL のカスタムブランディング。
- Required: ロゴ
properties:
logo [文字列] : メインのロゴイメージ URL
-
例:
/static/img/quay-horizontal-color.svg
-
例:
footer_img[文字列] :UI フッター用のロゴ。
-
例:
/static/img/RedHat.svg
-
例:
footer_url[文字列] : フッターイメージのリンク。
BROWSER_API_CALLS_XHR_ONLY[ブール値]。有効にすると、XHR によって行われるとマークされた API コールのみがブラウザーから許可されます。デフォルトは True です。
- 例: False
BUILDLOGS_REDIS[オブジェクト] 必須。ビルドログをキャッシュするための Redis の接続情報です。
HOST[文字列] 必須。Redis にアクセスするためのホスト名。
-
例:
my.redis.cluster
-
例:
PASSWORD[文字列]: Redis インスタンスに接続するためのパスワードです。
-
例:
mypassword
-
例:
PORT[番号]。Redis にアクセスするためのポートです。
-
例:
1234
-
例:
CONTACT_INFO[配列]: 指定された場合は、連絡先ページに表示する連絡先情報。連絡先が 1 つしか指定されていない場合は、連絡先のフッターが直接リンクされます。
- Min Items: 1
Unique Items: True
- array item 0[文字列] : メールを送信するためのリンクを追加する
-
パターン:
^mailto:(.)+$
-
例:
mailto:support@quay.io
array item 1[文字列] :IRC チャットルームを訪問するためのリンクを追加する
-
パターン:
^irc://(.)+$
-
例:
irc://chat.freenode.net:6665/quay
-
パターン:
array item 2 [文字列] : Adds a link to call a phone number
-
パターン:
^tel:(.)+$
-
例:
tel:+1-888-930-3475
-
パターン:
array item 3[文字列] : 定義された URL へのリンクを追加する
-
パターン:
^http(s)?://(.)+$
-
例:
https://twitter.com/quayio
-
パターン:
DB_CONNECTION_ARGS[オブジェクト]: 指定された場合、タイムアウトや SSL などのデータベースの接続引数。
-
threadlocals[ブール] 必須。スレッドローカルな接続を使用するかどうか。常に
true
である必要があります。 -
autorollback[ブール] 必須。自動ロールバック接続を使用するかどうか。常に
true
である必要があります。 ssl[オブジェクト]: SSL 接続の設定
- ca[文字列] 必須。SSL 接続に使用する CA 証明書の絶対コンテナーパス。
-
例:
conf/stack/ssl-ca-cert.pem
-
threadlocals[ブール] 必須。スレッドローカルな接続を使用するかどうか。常に
DATABASE_SECRET_KEY[文字列] 必須。データベース内の機密フィールドを暗号化するために使用するキー。一度設定した値は絶対に変更してはいけません。これを変更すると、関連するすべてのフィールド (例えば、リポジトリーミラーのユーザー名とパスワードの設定など) が無効になります。
-
例:
40157269433064266822674401740626984898972632465622168464725100311621640999470
-
例:
DB_URI[文字列] 必須。データベースにアクセスするための URI(認証情報を含む)。
- 参考: https://www.postgresql.org/docs/9.3/static/libpq-connect.html#AEN39495
-
例:
mysql+pymysql://username:password@dns.of.database/quay
DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT: [数値、
null
]: None でない場合、ネームスペースでキューに入れることができるビルドのデフォルトの最大数です。-
例:
20
-
例:
DEFAULT_TAG_EXPIRATION[文字列] 必須。タイムマシンのデフォルトの、設定可能なタグの有効期限です。デフォルトは
2w
です。-
パターン:
^[0-9]+(w|m|d|h|s)$
-
パターン:
DIRECT_OAUTH_CLIENTID_WHITELIST[配列]。ユーザーの承認なしに直接 OAuth 承認を実行することが許可されているRed Hat Quay 管理アプリケーションのクライアント ID のリスト。
- Min Items: None
- Unique Items: True
参考: https://coreos.com/quay-enterprise/docs/latest/direct-oauth.html
- array item[文字列] .
DISTRIBUTED_STORAGE_CONFIG [object] 必須: Red Hat Quay で使用するストレージエンジンの設定。各キーは、ストレージエンジンの一意の ID を表します。この値は、ストレージエンジンパラメーターを記述するオブジェクトのタプル (キー、値) で設定されます。
OCS / Noobaa:
rhocsStorage: - RHOCSStorage - access_key: access_key_here secret_key: secret_key_here bucket_name: quay-datastore-9b2108a3-29f5-43f2-a9d5-2872174f9a56 hostname: s3.openshift-storage.svc.cluster.local is_secure: 'true' port: '443' storage_path: /datastorage/registry
Ceph / RadosGW Storage / Hitachi HCP:
radosGWStorage: - RadosGWStorage - access_key: access_key_here secret_key: secret_key_here bucket_name: bucket_name_here hostname: hostname_here is_secure: 'true' port: '443' storage_path: /datastorage/registry
AWS S3 Storage:
s3Storage: - S3Storage - host: s3.ap-southeast-2.amazonaws.com s3_access_key: s3_access_key_here s3_secret_key: s3_secret_key_here s3_bucket: s3_bucket_here storage_path: /datastorage/registry
Azure Storage:
azureStorage: - AzureStorage - azure_account_name: azure_account_name_here azure_account_key: azure_account_key_here azure_container: azure_container_here sas_token: some/path/ storage_path: /datastorage/registry
Google Cloud Storage:
googleCloudStorage: - GoogleCloudStorage - access_key: access_key_here secret_key: secret_key_here bucket_name: bucket_name_here storage_path: /datastorage/registry
Swift Storage:
swiftStorage: - SwiftStorage - swift_user: swift_user_here swift_password: swift_password_here swift_container: swift_container_here auth_url: https://example.org/swift/v1/quay auth_version: 1 ca_cert_path: /conf/stack/swift.cert" storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS[配列]:DISTRIBUTED_STORAGE_CONFIG の ID で指定されたストレージエンジンのリストで、そのイメージはデフォルトで他のすべてのストレージエンジンに完全に複製されます。
- Min Items: None
例:
s3_us_east, s3_us_west
- array item[文字列] .
DISTRIBUTED_STORAGE_PREFERENCE[配列] 必須。使用する優先的なストレージエンジン (DISTRIBUTED_STORAGE_CONFIG の ID による)。優先されるエンジンとは、プルのチェックが行われ、イメージがプッシュされることを意味します。
Min Items: None
-
例:
[u's3_us_east', u's3_us_west']
- array item[文字列] .
-
例:
preferred_url_scheme[文字列] 必須。Red Hat Quay にアクセスする際に使用する URL スキームです。Red Hat Quay が SSL を一部的にでも使用している場合、これは
https
でなければなりません。-
enum:
http, https
-
例:
https
-
enum:
- DOCUMENTATION_ROOT[文字列]: ドキュメントへのリンクのルート URL。
ENABLE_HEALTH_DEBUG_SECRET[string,
null
]: 指定された場合、スーパーユーザーとして認証されていないときに、完全なデバッグ情報を見るためにヘルスエンドポイントに与えることができるシークレットです。-
例:
somesecrethere
-
例:
EXPIRED_APP_SPECIFIC_TOKEN_GC[string,
null
]: 期限切れの外部アプリのトークンがガベージコレクションされるまでの期間です。デフォルトは 1d です。-
パターン:
^[0-9]+(w|m|d|h|s)$
-
パターン:
EXTERNAL_TLS_TERMINATION[ブール]。TLS がサポートされているが、Red Hat Quay より前のレイヤーで終了している場合、true にする必要があります。
-
例:
True
-
例:
FEATURE_ACI_CONVERSION[ブール]:ACI への変換を有効にするかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_ACTION_LOG_ROTATION[ブール]: 古いアクションログをストレージに回転させるかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_ADVERTISE_V2[ブール]:v2/のエンドポイントを表示するかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL[ブール]: 集約されたログカウントの検索を許可するかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_ANONYMOUS_ACCESS[ブール]: 匿名ユーザーによるパブリックリポジトリーの閲覧やプルを許可するかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_APP_REGISTRY[ブール]:App のリポジトリーへの対応を有効にするかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_APP_SPECIFIC_TOKENS[ブール値]。有効にすると、ユーザーは Docker CLI で使用するトークンを作成できます。デフォルトは True です。
- 例: False
FEATURE_BITBUCKET_BUILD[ブール]:Bitbucket のビルドトリガーをサポートするかどうか。デフォルトは false です。
-
例:
False
-
例:
- FEATURE_BLACKLISTED_EMAIL
FEATURE_BUILD_SUPPORT[ブール]:Dockerfile のビルドをサポートするかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_CHANGE_TAG_EXPIRATION [ブール]: ユーザーや組織が、自分の名前空間にあるタグの有効期限を変更できるかどうか。デフォルトは True です。
-
例:
False
-
例:
FEATURE_DIRECT_LOGIN[ブール]: ユーザーが UI に直接ログインできるかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_GARBAGE_COLLECTION[ブール]: リポジトリーのガベージコレクションを有効にするかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_GITHUB_BUILD[ブール]:GitHub のビルドトリガーをサポートするかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_GITHUB_LOGIN[ブール]:GitHub のログインに対応しているかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_GITLAB_BUILD[ブール]:GitLab のビルドトリガーをサポートするかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_GOOGLE_LOGIN[ブール]:Google ログインがサポートされているかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_INVITE_ONLY_USER_CREATION[ブール]: 作成されるユーザーが他のユーザーによって招待されなければならないかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_LIBRARY_SUPPORT[ブール]:Docker からのプルプッシュ時に名前空間のないリポジトリーを許可するかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_LOG_EXPORT[ブール]: アクションログのエクスポートを許可するかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_MAILING[ブール]: メールが有効であるかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP[ブール値]。有効にすると、スーパーユーザーではない人でも、LDAP や Keystone をバックにチームの同期を設定できます。デフォルトは False です。
-
例:
True
-
例:
FEATURE_PARTIAL_USER_AUTOCOMPLETE[ブール値]。true に設定すると、オートコンプリートは部分的なユーザー名にも適用されます。デフォルトは True です。
-
例:
True
-
例:
FEATURE_PERMANENT_SESSIONS[ブール]: セッションが永続的であるかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_PROXY_STORAGE[ブール]: ストレージ内のすべての直接ダウンロード URL をレジストリーの nginx 経由でプロキシーするかどうかを指定します。デフォルトは false です。
-
例:
False
-
例:
FEATURE_PUBLIC_CATALOG[ブール値]。true に設定すると、
_catalog
エンドポイントは公開リポジトリーを返します。それ以外では、プライベートリポジトリーのみが返されます。デフォルトは false です。-
例:
False
-
例:
FEATURE_RATE_LIMITS[ブール]:API とレジストリーのエンドポイントでレート制限を有効にするかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_READER_BUILD_LOGS[ブール]:true に設定すると、ビルドログは書き込みアクセスや管理者アクセスだけではなく、レポへの読み取りアクセスを持つ人が読むことができます。デフォルトは false です。
- 例: False
FEATURE_READONLY_APP_REGISTRY[ブール]:App のリポジトリーを読み取り専用にするかどうか。デフォルトは false です。
-
例:
True
-
例:
FEATURE_RECAPTCHA[ブール]: ユーザーのログインとリカバリーに Recaptcha が必要かどうか。デフォルトは false です。
-
例:
False
- 参考: https://www.google.com/recaptcha/intro/
-
例:
FEATURE_REPO_MIRROR [boolean]: true に設定されている場合、リポジトリーのミラーリングを有効にします。デフォルトは false です。
-
例:
False
-
例:
FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH[ブール]: 基本認証に暗号化されていないパスワード (暗号化されたトークンではなく) を使用できるかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_REQUIRE_TEAM_INVITE[ブール]: ユーザーをチームに追加する際に招待状を要求するかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_RESTRICTED_V1_PUSH[ブール]:true に設定すると、V1_PUSH_WHITELIST に記載されている名前空間のみが V1 プッシュをサポートします。デフォルトは True です。
-
例:
True
-
例:
FEATURE_SECURITY_NOTIFICATIONS[ブール]: セキュリティースキャナが有効な場合、セキュリティー通知をオン/オフするかどうかを指定します。デフォルトは false です。
-
例:
False
-
例:
FEATURE_SECURITY_SCANNER[ブール]: セキュリティースキャナをオン/オフするかどうか。デフォルトは False に設定されます。
FEATURE_STORAGE_REPLICATION[ブール]: ストレージエンジン間で自動的にレプリケーションを行うかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_SUPER_USERS[ブール]: スーパーユーザーをサポートするかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_TEAM_SYNCING[ブール]: 認証エンジン (LDAP または Keystone) のバッキンググループからチームメンバーを同期させることを許可するかどうか。
-
例:
True
-
例:
FEATURE_USER_CREATION[ブール]: スーパーユーザーではない人が) ユーザーを作成できるかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_USER_LAST_ACCESSED[ブール]: ユーザーが最後にアクセスした時間を記録するかどうか。デフォルトは True です。
-
例:
True
-
例:
FEATURE_USER_LOG_ACCESS[ブール値]。true に設定すると、ユーザーは自分のネームスペースの監査ログにアクセスできます。デフォルトは false です。
-
例:
True
-
例:
FEATURE_USER_METADATA[ブール]: ユーザーのメタデータを収集してサポートするかどうか。デフォルトは false です。
-
例:
False
-
例:
FEATURE_USERNAME_CONFIRMATION[ブール値]。true に設定すると、ユーザーは生成されたユーザー名を確認できます。デフォルトは True です。
-
例:
False
-
例:
FEATURE_USER_RENAME[ブール値]。true に設定すると、ユーザーは自分のネームスペースの名前を変更できます。デフォルトは false です。
-
例:
True
-
例:
FRESH_LOGIN_TIMEOUT[文字列]: フレッシュログインでユーザーがパスワードの再入力を要求される時間
-
例
5m
-
例
GITHUB_LOGIN_CONFIG[オブジェクト, 'null']:GitHub (Enterprise) を外部ログインプロバイダーとして使用するための設定です。
- 参考: https://coreos.com/quay-enterprise/docs/latest/github-auth.html
allowed_organizations[配列]:ORG_RESTRICT オプションで動作するようにホワイトリストされた GitHub (Enterprise) の組織の名前。
- Min Items: None
Unique Items: True
- array item[文字列] .
API_ENDPOINT[文字列]: 使用する GitHub (Enterprise) API のエンドポイントです。github.com にオーバーライドされる必要があります。
CLIENT_ID[文字列] 必須。GITHUB_TRIGGER_CONFIG とは共有できません。
- Reference: https://coreos.com/quay-enterprise/docs/latest/github-app.html
-
例:
0e8dbe15c4c7630b6780
CLIENT_SECRET[文字列] 必須。この Red Hat Quay インスタンスに登録されているクライアントシークレットです。
- Reference: https://coreos.com/quay-enterprise/docs/latest/github-app.html
-
例:
e4a58ddd3d7408b7aec109e85564a0d153d3e846
GITHUB_ENDPOINT[文字列] 必須。ヒットしている GitHub(Enterprise) のエンドポイントです。
- ORG_RESTRICT[ブール]。true の場合、組織のホワイトリスト内のユーザーのみがこのプロバイダーを使用してログインできます。
-
例:
True
GITHUB_TRIGGER_CONFIGオブジェクト、
null
: ビルドトリガーに GitHub (Enterprise) を使用するための設定です。- Reference: https://coreos.com/quay-enterprise/docs/latest/github-build.html
API_ENDPOINT[文字列]: 使用する GitHub (Enterprise) API のエンドポイントです。github.com にオーバーライドされる必要があります。
CLIENT_ID[文字列] 必須。GITHUB_LOGIN_CONFIG とは共有できません。
- Reference: https://coreos.com/quay-enterprise/docs/latest/github-app.html
-
例:
0e8dbe15c4c7630b6780
CLIENT_SECRET[文字列] 必須。この Red Hat Quay インスタンスに登録されているクライアントシークレットです。
- Reference: https://coreos.com/quay-enterprise/docs/latest/github-app.html
-
例:
e4a58ddd3d7408b7aec109e85564a0d153d3e846
GITHUB_ENDPOINT[文字列] 必須。ヒットしている GitHub(Enterprise) のエンドポイントです。
GITLAB_TRIGGER_CONFIG[オブジェクト]:Gitlab (Enterprise) を外部認証で使用するための設定。
CLIENT_ID[文字列] 必須。この Red Hat Quay インスタンスの登録済みクライアント ID です。
-
例:
0e8dbe15c4c7630b6780
-
例:
CLIENT_SECRET[文字列] 必須。この Red Hat Quay インスタンスに登録されているクライアントシークレットです。
-
例:
e4a58ddd3d7408b7aec109e85564a0d153d3e846
gitlab_endpoint[文字列] 必須。Gitlab(Enterprise) が動作しているエンドポイントです。
-
例:
GOOGLE_LOGIN_CONFIGオブジェクト,
null
: 外部認証に Google を利用するための設定CLIENT_ID[文字列] 必須。この Red Hat Quay インスタンスの登録済みクライアント ID です。
-
例:
0e8dbe15c4c7630b6780
-
例:
CLIENT_SECRET[文字列] 必須。この Red Hat Quay インスタンスに登録されているクライアントシークレットです。
- 例: e4a58ddd3d7408b7aec109e85564a0d153d3e846
GPG2_PRIVATE_KEY_FILENAME[文字列]。ACI の解読に使用する秘密鍵のファイル名です。
-
例:
/path/to/file
-
例:
GPG2_PRIVATE_KEY_NAME[文字列]。ACI の署名に使用する秘密鍵の名前です。
-
例:
gpg2key
-
例:
GPG2_PUBLIC_KEY_FILENAME[文字列]。ACI の暗号化に使用する公開鍵のファイル名です。
-
例:
/path/to/file
-
例:
HEALTH_CHECKER[文字列]: 設定されたヘルスチェック。
-
例:
('RDSAwareHealthCheck', {'access_key': 'foo', 'secret_key': 'bar'})
-
例:
JWT_AUTH_ISSUER[文字列] :JWT ユーザーのエンドポイント。
-
例:
http://192.168.99.101:6060
-
パターン:
^http(s)?://(.)+$
-
例:
JWT_GETUSER_ENDPOINT [文字列] : The endpoint for JWT users.
-
例:
http://192.168.99.101:6060
-
パターン:
^http(s)?://(.)+$
-
例:
JWT_QUERY_ENDPOINT[文字列] :JWT クエリーのエンドポイントです。
-
例:
http://192.168.99.101:6060
-
パターン:
^http(s)?://(.)+$
-
例:
JWT_VERIFY_ENDPOINT[文字列] :JWT の検証を行うエンドポイント。
-
例:
http://192.168.99.101:6060
-
パターン:
^http(s)?://(.)+$
-
例:
- LDAP_ADMIN_DN[文字列]:LDAP 認証のアドミン DN です。
- LDAP_ADMIN_PASSWD[文字列]:LDAP 認証の管理者パスワードです。
- LDAP_ALLOW_INSECURE_FALLBACK[ブール]:LDAP 認証において、SSL insecure fallback を許可するかどうかを指定します。
- LDAP_BASE_DN[文字列]:LDAP 認証のベース DN です。
- LDAP_EMAIL_ATTR[文字列]:LDAP 認証のメール属性です。
- LDAP_UID_ATTR[文字列]:LDAP 認証の uid 属性です。
- LDAP_URI[文字列]:LDAP URI です。
- LDAP_USER_FILTER[文字列]:LDAP 認証のためのユーザーフィルターです。
- LDAP_USER_RDN[配列]:LDAP 認証のユーザー RDN です。
LOGS_MODEL[文字列]: アクションログのログモデル。
- enum: database, transition_reads_both_writes_es, elasticsearch
-
例:
database
LOGS_MODEL_CONFIG[オブジェクト]: アクションログ用のログモデル設定
elasticsearch_config [オブジェクト]: Elasticsearch クラスターの設定
access_key [文字列] :Elasticsearch のユーザー (AWS ES の場合は IAM キー)
-
例:
some_string
-
例:
ホスト [文字列]: Elasticsearch クラスターのエンドポイント
-
例:
host.elasticsearch.example
-
例:
index_prefix [文字列]。Elasticsearch のインデックスの接頭辞
-
例:
logentry_
-
例:
- index_settings [オブジェクト]: Elasticsearch のインデックス設定
use_ssl [ブール値]。Elasticsearch に ssl を使用します。デフォルトは true です。
-
例:
True
-
例:
secret_key [文字列] :Elasticsearch のパスワード (AWS ES の場合は IAM シークレット)
-
例:
some_secret_string
-
例:
aws_region [文字列]: Amazon Web サービスの地域
-
例:
us-east-1
-
例:
port [番号]: Elasticsearch クラスターのエンドポイントポート
-
例:
1234
-
例:
kinesis_stream_config [オブジェクト]: AWS Kinesis ストリームの設定
aws_secret_key [文字列]: AWS の秘密鍵
-
例:
some_secret_key
-
例:
stream_name [文字列]: アクションログの送信先となる Kinesis ストリーム
-
例:
logentry-kinesis-stream
-
例:
aws_access_key [文字列]: AWS アクセスキー
-
例:
some_access_key
-
例:
retries [番号]: 一回のリクエストに対する最大試行回数
-
例:
5
-
例:
read_timeout [番号]: 接続の読み込み時にタイムアウトするまでの秒数
-
例:
5
-
例:
max_pool_connections [番号]: コネクションプールに保持するコネクションの最大数
-
例:
10
-
例:
aws_region [文字列]: AWS のリージョン
-
例:
us-east-1
-
例:
connect_timeout [番号]: 接続を試みる際のタイムアウトまでの秒数
-
例:
5
-
例:
producer [文字列]: Elasticsearch にロギングする場合は、producer を記録します。
- enum: kafka、elasticsearch、kinesis_stream
-
例:
kafka
kafka_config [オブジェクト]: Kafka クラスターの設定
topic [文字列]: ログエントリーを公開する Kafka トピック
-
例:
logentry
-
例:
- bootstrap_servers [配列]: クライアントをブートストラップさせる Kafka ブローカーのリスト
max_block_seconds [番号]:
send()
の実行中に、バッファーがいっぱいになったり、メタデータが利用できないなどの理由でブロックする最大秒数-
例:
10
-
例:
LOG_ARCHIVE_LOCATION[文字列]。ビルドが有効な場合、アーカイブされたビルドログを配置するストレージエンジンです。
-
例:
s3_us_east
-
例:
LOG_ARCHIVE_PATH[文字列]: ビルドが有効な場合、アーカイブされたビルドログを保存するストレージ内のパス。
-
例:
archives/buildlogs
-
例:
- LOGS_MODEL[文字列]: アクションログのログモデル。
-
enum:
database
,transition_reads_both_writes_es
,elasticsearch
-
例:
database
MAIL_DEFAULT_SENDER[文字列、
null
]。指定された場合、Red Hat Quay が電子メールを送信する際にfrom
として使用される電子メールアドレスです。何もない場合、デフォルトはsupport@quay.io
です。-
例:
support@myco.com
-
例:
MAIL_PASSWORD[文字列,
null
]: 電子メールの送信時に使用する SMTP パスワード。-
例:
mypassword
-
例:
MAIL_PORT[番号]。使用する SMTP ポートを指定します。指定されていない場合、デフォルトでは 587 になります。
-
例:
588
-
例:
MAIL_SERVER[文字列]: 電子メールの送信に使用する SMTP サーバーです。FEATURE_MAILING が true に設定されている場合のみ必要です。
-
例:
smtp.somedomain.com
-
例:
MAIL_USERNAME[文字列, 'null']: 電子メールの送信時に使用する SMTP ユーザー名。
-
例:
myuser
-
例:
MAIL_USE_TLS[ブール値]。指定された場合、電子メールの送信に TLS を使用するかどうか。
-
例:
True
-
例:
MAXIMUM_LAYER_SIZE[文字列]: イメージレイヤーの最大許容サイズ。デフォルトは 20G です。
-
パターン:
^[0-9]+(G|M)$
-
例:
100G
-
パターン:
PREFERRED_URL_SCHEME[文字列]。Red Hat Quay にアクセスする際に使用する URL スキームです。Red Hat Quay が SSL を一部的にでも使用している場合、これは
https
でなければなりません。-
enum:
http
またはhttps
-
例:
https
-
enum:
PROMETHEUS_NAMESPACE[文字列]。公開されているすべての Prometheus メトリクスに適用される接頭辞です。デフォルトは
quay
です。-
例:
myregistry
-
例:
PUBLIC_NAMESPACES[配列]: 名前空間が公共の名前空間リストで定義されている場合、そのユーザーが名前空間のメンバーであるかどうかにかかわらず、すべてのユーザーのリポジトリーリストページに表示されます。一般的には、企業のお客様がよく知られた名前空間のセットを設定する際に使用されます。
- Min Items: None
Unique Items: True
- array item[文字列] .
- RECAPTCHA_SECRET_KEY[文字列]:recaptcha が有効な場合、Recaptcha サービスの秘密鍵。
- RECAPTCHA_SITE_KEY[文字列]:recaptcha が有効な場合、Recaptcha サービスのサイトキー。
REGISTRY_STATE[文字列]: レジストリーの状態です。
-
enum:
ノーマル
またはリードオンリー
-
例:
read-only
-
enum:
REGISTRY_TITLE[文字列]: 指定された場合は、レジストリーの長い形式のタイトルです。デフォルトは
Quay Enterprise
です。-
例:
Corp Container Service
-
例:
REGISTRY_TITLE_SHORT[文字列]: 指定された場合、レジストリーの短い形式のタイトル。デフォルトは
Quay Enterprise
です。-
例:
CCS
-
例:
REPO_MIRROR_INTERVAL[数値]。リポジトリーのミラー候補をチェックする間隔を秒単位で指定します。デフォルトは 30 です。
-
例:
30
-
例:
REPO_MIRROR_SERVER_HOSTNAME[文字列]を指定します。ミラーリング先の SERVER_HOSTNAME を置き換えます。デフォルトは unset です。
-
例:
openshift-quay-service
-
例:
REPO_MIRROR_TLS_VERIFY[ブール]: ミラーリング中に HTTPS を要求し、Quay レジストリーの証明書を検証します。デフォルトは True です。
-
例:
True
-
例:
SEARCH_MAX_RESULT_PAGE_COUNT[番号]: ユーザーが検索でページングする際に、制限されるまでの最大ページ数。デフォルトは 10 です。
-
例:
10
-
例:
SEARCH_RESULTS_PER_PAGE[番号]: 検索ページごとに返される結果の数。デフォルトは 10 です。
-
例:
10
-
例:
SECRET_KEY[文字列] 必須。データベースやランタイムで機密性の高いフィールドを暗号化するために使用されるキー。一度設定した値は絶対に変更してはいけません。これを変更すると、依存するすべてのフィールド (たとえば、暗号化されたパスワードの認証情報) が無効になります。
-
例:
40157269433064266822674401740626984898972632465622168464725100311621640999470
-
例:
SECURITY_SCANNER_ENDPOINT[文字列] : セキュリティースキャナのエンドポイントです。
-
パターン:
^http(s)?://(.)+$
-
例:
http://192.168.99.101:6060
-
パターン:
SECURITY_SCANNER_INDEXING_INTERVAL[番号]。セキュリティースキャナのインデキシング間隔の秒数です。デフォルトは 30 です。
-
例:
30
-
例:
SECURITY_SCANNER_NOTIFICATIONS[ブール]: セキュリティースキャナの通知機能を行うかどうか
-
例:
false
-
例:
SECURITY_SCANNER_V4_ENDPOINT[文字列]:V4 セキュリティースキャナーのエンドポイントです。
-
パターン:
^http(s)?://(.)+$
-
例:
http://192.168.99.101:6060
-
パターン:
- SECURITY_SCANNER_V4_PSK [string]: Clair に生成された PSK (pre-shared key)
SERVER_HOSTNAME[文字列] 必須。Red Hat Quay にアクセスするための URL で、スキームは含まれません。
-
例:
quay.io
-
例:
SESSION_COOKIE_SECURE[ブール]: セッションクッキーに
secure
プロパティーを設定するかどうか。デフォルトは false です。SSL を使用するすべてのインストールで True にすることを推奨します。- 例: True
- Reference: https://en.wikipedia.org/wiki/Secure_cookies
SSL_CIPHERS[配列]: 指定された場合、有効または無効にする SSL 暗号の nginx 定義のリストです。
-
例:
CAMELLIA
,!3DES
-
例:
SSL_PROTOCOLS[配列]: 指定された場合、nginx はリストで定義された SSL プロトコルを有効にするように設定されます。リストから SSL プロトコルを削除すると、Red Hat Quay の起動時にそのプロトコルが無効になります。
- SSL_PROTOCOLS: ['TLSv1','TLSv1.1','TLSv1.2']
SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD[番号]:None ではない場合、ビルドトリガーが自動的に無効になるまでに発生する連続した失敗の回数を指定します。デフォルトは 100 です。
-
例:
50
-
例:
- SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD[番号]:None でない場合、ビルドトリガーが自動的に無効になるまでに発生する連続した内部エラーの数を指定します。デフォルトは 5 です。
SUPER_USERS[配列]: スーパーユーザー権限を付与されるユーザーの Red Hat Quay ユーザー名。
- Min Items: None
Unique Items: True
- array item[文字列] .
TAG_EXPIRATION_OPTIONS[配列] 必須。ネームスペースのタグの有効期限について、ユーザーが選択できるオプション (有効な場合)。
- Min Items: None
- array item[文字列] .
-
パターン:
^[0-9]+(w|m|d|h|s)$
TEAM_RESYNC_STALE_TIME[文字列]: チームの同期が有効な場合、そのチームのメンバーシップをチェックし、必要に応じて再同期する頻度を指定します (デフォルト: 30m)。
-
パターン:
^[0-9]+(w|m|d|h|s)$
-
例:
2h
-
パターン:
USERFILES_LOCATION[文字列]: ユーザーがアップロードしたファイルを配置するストレージエンジンの ID。
-
例:
s3_us_east
-
例:
USERFILES_PATH[文字列]: ユーザーがアップロードしたファイルを配置するストレージ下のパス
-
例:
userfiles
-
例:
USER_EVENTS_REDIS[オブジェクト] 必須。ユーザーイベント処理用の Redis への接続情報です。
HOST[文字列] 必須。Redis にアクセスするためのホスト名。
-
例:
my.redis.cluster
-
例:
PASSWORD[文字列]: Redis インスタンスに接続するためのパスワードです。
-
例:
mypassword
-
例:
PORT[番号]。Redis にアクセスするためのポートです。
-
例:
1234
-
例:
CONSUMER_SECRET[文字列] 必須。この Red Hat Quay インスタンスに登録されているコンシューマーシークレット (クライアントシークレット) です。
- 例: e4a58ddd3d7408b7aec109e85564a0d153d3e846
USERFILES_LOCATION[文字列]: ユーザーがアップロードしたファイルを配置するストレージ エンジンの ID。
-
例:
s3_us_east
-
例:
USERFILES_PATH[文字列]: ユーザーがアップロードしたファイルを配置するストレージ下のパス。
-
例:
userfiles
-
例:
USER_RECOVERY_TOKEN_LIFETIME[文字列]: ユーザーアカウントを回復するためのトークンが有効な期間です。デフォルトでは 30m です。
-
例:
10m
-
パターン:
^[0-9]+(w|m|d|h|s)$
-
例:
V1_PUSH_WHITELIST[配列]:FEATURE_RESTRICTED_V1_PUSH が true に設定されている場合、V1 プッシュをサポートする名前空間名の配列です。
-
例:
some
,namespaces
-
例:
V2_PAGINATION_SIZE[数値]。V2 レジストリー API で 1 ページあたりに返される結果の数を指定します。
-
例:
100
-
例:
WEBHOOK_HOSTNAME_BLACKLIST[配列]: ウェブフックの検証時に許可しないホスト名のセット (localhost 以外)。
-
例:
someexternaldomain.com
-
例: