Red Hat Quay Operator の機能
Red Hat Quay Operator の高度な機能
概要
第1章 連邦情報処理標準 (FIPS) の準備と準拠
米国国立標準技術研究所 (NIST) によって開発された連邦情報処理標準 (FIPS) は、特に銀行、医療、公共部門などの高度に規制された分野で、機密データを保護および暗号化するために高く評価されていると見なされています。Red Hat Enterprise Linux (RHEL) および OpenShift Container Platform は FIPS モード を提供することで FIPS をサポートします。このモードでは、システムは openssl などの特定の FIPS 検証済み暗号モジュールの使用のみを許可します。これにより、FIPS への準拠が保証されます。
1.1. FIPS コンプライアンスの有効化
以下の手順を使用して、Red Hat Quay デプロイメントで FIPS コンプライアンスを有効にします。
前提条件
- Red Hat Quay のスタンドアロンデプロイメントを実行している場合、Red Hat Enterprise Linux (RHEL) デプロイメントはバージョン 8 以降であり、FIPS が有効である。
- Red Hat Quay Operator を使用している場合、OpenShift Container Platform はバージョン 4.10 以降を使用する。
- Red Hat Quay のバージョンが 3.5.0 以降である。
- Red Hat Quay デプロイメントの管理者権限がある。
手順
Red Hat Quay の
config.yamlファイルで、FEATURE_FIPS設定フィールドをtrueに設定します。以下に例を示します。--- FEATURE_FIPS = true ---
FEATURE_FIPSをtrueに設定すると、Red Hat Quay は FIPS 準拠のハッシュ関数を使用して実行されます。
第2章 コンソールでのモニタリングおよびアラート
Red Hat Quay では、OpenShift Container Platform コンソール内から Red Hat Quay Operator を使用してデプロイされたインスタンスのモニタリングがサポートされています。新規のモニタリング機能には、Grafana ダッシュボード、個別のメトリクスへのアクセス、Quay Pod を頻繁に再起動するために通知するアラートなどが含まれます。
モニタリング機能を有効にするには、Red Hat Quay Operator が すべての名前空間 モードでインストールされている必要があります。
2.1. ダッシュボード
OpenShift Container Platform コンソールで、Monitoring → Dashboards をクリックし、目的の Red Hat Quay レジストリーインスタンスのダッシュボードを検索します。
ダッシュボードには、次を含む統計情報が表示されます。
- Organizations、Repositories、Users、Robot accounts の数
- CPU の使用率
- 最大メモリー使用量
- プル、プッシュ、認証要求のレート
- API 要求のレート
- 待機時間
2.2. メトリクス
UI で Monitoring → Metrics にアクセスすると、Red Hat Quay ダッシュボードの背後にある基礎となるメトリクスを表示できます。Expression フィールドに quay_ を入力し、利用可能なメトリクスのリストを表示します。
quay_org_rows など、サンプルメトリクスを選択します。
このメトリクスは、レジストリー内の組織の数を示します。ダッシュボードにも直接表示されます。
2.3. アラート
Quay Pod が頻繁に再起動する場合はアラートが発生します。アラートを設定するには、コンソール UI の Monitoring → Alerting で Alerting ルールタブにアクセスし、Quay 固有のアラートを検索します。
QuayPodFrequentlyRestarting ルールの詳細を選択し、アラートを設定します。
第3章 OpenShift Container Platform での Red Hat Quay の設定
デプロイメント後に、Red Hat Quay 設定バンドルシークレット spec.configBundleSecret を編集して Red Hat Quay アプリケーションを設定できます。QuayRegistry リソースの spec.components オブジェクトで、コンポーネントの管理ステータスも変更できます。
設定エディター UI を使用して Red Hat Quay アプリケーションを設定することもできます。詳細は、OpenShift Container Platform で設定ツールを使用して Red Hat Quay を再設定する を参照してください。
3.1. OpenShift Container Platform コンソールでの設定バンドルシークレットの編集
OpenShift Container Platform コンソールで設定バンドルシークレットを編集するには、次の手順を実行します。
手順
Red Hat Quay Registry の概要画面で、Config Bundle Secret のリンクをクリックします。
シークレットを編集するには、Actions → Edit Secret をクリックします。
設定を変更して保存します
- デプロイメントを監視して、正常に完了したこと、および設定の変更が反映されていることを確認します。
3.2. QuayRegistry エンドポイントおよびシークレットの決定
次の手順を実行して、QuayRegistry エンドポイントとシークレットを見つけます。
手順
現在のエンドポイントとシークレットを見つけるには、次のコマンドを入力し、
oc description quayregistryまたはoc get quayregistry -o yamlを使用してQuayRegistryリソースを調べます。$ oc get quayregistry example-registry -n quay-enterprise -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 1 status: configEditorCredentialsSecret: example-registry-quay-config-editor-credentials-fg2gdgtm24 2 configEditorEndpoint: https://example-registry-quay-config-editor-quay-enterprise.apps.docs.gcp.quaydev.org 3 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 4
3.2.1. 設定エディターツールのユーザー名とパスワードを見つける
設定エディターツールのユーザー名とパスワードを見つけるには、次の手順を実行します。
手順
次のコマンドを入力し、シークレットを取得します。
$ oc get secret -n quay-enterprise example-registry-quay-config-editor-credentials-fg2gdgtm24 -o yaml
出力例
apiVersion: v1 data: password: SkZwQkVKTUN0a1BUZmp4dA== username: cXVheWNvbmZpZw== kind: Secret
次のコマンドを入力し、ユーザー名をデコードします。
$ echo 'cXVheWNvbmZpZw==' | base64 --decode
出力例
quayconfig
次のコマンドを入力し、パスワードをデコードします。
$ echo 'SkZwQkVKTUN0a1BUZmp4dA==' | base64 --decode
出力例
JFpBEJMCtkPTfjxt
3.3. 既存設定のダウンロード
以下は、各種ストラテジーを使用して既存の設定をダウンロードするための手順です。
3.3.1. 設定エディターのエンドポイントを使用して既存の設定をダウンロード
次の手順を使用して、設定エディターのエンドポイントを介して既存の設定をダウンロードします。
手順
設定エディターのユーザー名とパスワードを指定して次のコマンドを入力し、既存の設定をダウンロードします。
$ curl -k -u quayconfig:JFpBEJMCtkPTfjxt https://example-registry-quay-config-editor-quay-enterprise.apps.docs.quayteam.org/api/v1/config
出力例
{ "config.yaml": { "ALLOW_PULLS_WITHOUT_STRICT_LOGGING": false, "AUTHENTICATION_TYPE": "Database", ... "USER_RECOVERY_TOKEN_LIFETIME": "30m" }, "certs": { "extra_ca_certs/service-ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURVVENDQWptZ0F3SUJBZ0lJRE9kWFhuUXFjMUF3RFFZSktvWklodmNOQVFFTEJRQXdOakUwTURJR0ExVUUKQXd3cmIzQmxibk5vYVdaMExYTmxjblpwWTJVdGMyVnlkbWx1WnkxemFXZHVaWEpBTVRZek1UYzNPREV3TXpBZQpGdzB5TVRBNU1UWXdOelF4TkRKYUZ..." } }
3.3.2. 設定バンドルのシークレットを使用して既存の設定をダウンロード
設定バンドルのシークレットを使用して、既存の設定をダウンロードできます。
手順
次のコマンドを入力してシークレットデータを取得します。
$ oc get secret -n quay-enterprise init-config-bundle-secret -o jsonpath='{.data}'出力例
{ "config.yaml": "RkVBVFVSRV9VU0 ... MDAwMAo=" }次のコマンドを入力してデータをデコードします。
$ echo 'RkVBVFVSRV9VU0 ... MDAwMAo=' | base64 --decode
出力例
FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false FEATURE_QUOTA_MANAGEMENT: true FEATURE_PROXY_CACHE: true FEATURE_BUILD_SUPPORT: true DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: 102400000
3.4. 設定バンドルを使用したカスタム SSL/TLS 証明書の設定
カスタム SSL/TLS 証明書は、初期デプロイメントの前、または Red Hat Quay を OpenShift Container Platform にデプロイした後に設定できます。これは、設定バンドルのシークレットを作成または更新することで実行できます。
既存のデプロイメントに証明書を追加する場合は、設定を変更しない場合でも、新規の設定バンドルシークレットに既存の config.yaml を含める必要があります。
カスタム SSL/TLS 証明書を追加するには、次の手順を実行します。
手順
QuayRegistryYAML ファイルで、kind: tlsをmanage:falseに設定します。以下はその例です。- kind: tls managed: falseEvents ページには、適切な設定が行われるまで変更がブロックされていることが表示されます。以下に例を示します。
- lastTransitionTime: '2022-03-28T12:56:49Z' lastUpdateTime: '2022-03-28T12:56:49Z' message: >- required component `tls` marked as unmanaged, but `configBundleSecret` is missing necessary fields reason: ConfigInvalid status: 'True'埋め込みデータまたはファイルを使用してシークレットを作成します。
設定の詳細を
Secretリソース YAML ファイルに直接組み込みます。以下に例を示します。custom-ssl-config-bundle.yaml
apiVersion: v1 kind: Secret metadata: name: custom-ssl-config-bundle-secret namespace: quay-enterprise data: config.yaml: | FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false FEATURE_QUOTA_MANAGEMENT: true FEATURE_PROXY_CACHE: true FEATURE_BUILD_SUPPORT: true DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: 102400000 extra_ca_cert_my-custom-ssl.crt: | -----BEGIN CERTIFICATE----- MIIDsDCCApigAwIBAgIUCqlzkHjF5i5TXLFy+sepFrZr/UswDQYJKoZIhvcNAQEL BQAwbzELMAkGA1UEBhMCSUUxDzANBgNVBAgMBkdBTFdBWTEPMA0GA1UEBwwGR0FM .... -----END CERTIFICATE-----YAML ファイルからシークレットを作成します。
$ oc create -f custom-ssl-config-bundle.yaml
..
または、必要な情報が含まれるファイルを作成し、そのファイルからシークレットを作成できます。
次のコマンドを入力して、
config.yamlファイルとcustom-ssl.crtファイルを含む汎用Secretオブジェクトを作成します。$ oc create secret generic custom-ssl-config-bundle-secret \ --from-file=config.yaml \ --from-file=extra_ca_cert_my-custom-ssl.crt=my-custom-ssl.crt
作成された
Secretを参照するQuayRegistryYAML ファイルを作成または更新します。以下はその例です。QuayRegistryYAML ファイルの例apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: custom-ssl-config-bundle-secret
次のコマンドを入力し、YAML ファイルを使用してレジストリーをデプロイまたは更新します。
oc apply -f quayregistry.yaml
第4章 設定ツールを使用して OpenShift Container Platform で Red Hat Quay を再設定する
4.1. 設定エディターへのアクセス
QuayRegistry オブジェクトの Details セクションでは、設定エディターのエンドポイントと、設定エディターにログインするための認証情報を含む Secret オブジェクトへのリンクが利用可能です。以下に例を示します。
4.1.1. 設定エディターの認証情報の取得
次の手順を使用して、設定エディターの認証情報を取得します。
手順
設定エディターシークレットのリンクをクリックします。
Secret の詳細 ページの Data セクションで、Reveal values をクリックして、設定エディターにログインするための認証情報を表示します。以下に例を示します。
4.1.2. 設定エディターへのログイン
設定エディターにログインするには、次の手順を使用します。
手順
設定エディターのエンドポイントに移動します。プロンプトが表示されたら、ユーザー名 (例:
quayconfig) とパスワードを入力します。以下に例を示します。
4.1.3. 設定の変更
次の例では、削除されたタグのデフォルトの有効期限を変更して、設定ファイルを更新します。
手順
- 設定エディターで、Time Machine セクションを見つけます。
許可された有効期限 ボックスに有効期限を追加します (例:
4w)。
- Validate Configuration Changes を選択して、変更が有効であることを確認します。
Reconfigure Quay を押して変更を適用します。
変更を適用した後、設定ツールは、加えられた変更が Red Hat Quay デプロイメントに送信されたことを通知します。
設定ツール UI を使用して Red Hat Quay を再設定すると、更新された設定が適用されるまでの間、レジストリーが短時間使用できなくなる可能性があります。
4.2. Red Hat Quay UI での再設定のモニタリング
Red Hat Quay の再設定をリアルタイムで監視できます。
4.2.1. QuayRegistry リソース
Red Hat Quay Operator を再設定した後、QuayRegistry の特定のインスタンス (この場合は example-registry) の YAML タブで再デプロイメントの進行状況を追跡できます。
ステータスが変わるたびに、データをリロードして更新されたバージョンを表示するように求められます。最終的に、Red Hat Quay Operator が変更を調整し、異常なコンポーネントは報告されなくなりました。
4.2.2. イベント
QuayRegistry の Events タブには、再デプロイメントに関連するいくつかのイベントが表示されます。以下に例を示します。
再設定の影響を受ける名前空間内のすべてのリソースのストリーミングイベントは、OpenShift Container Platform コンソールの Home → Events で利用できます。以下に例を示します。
4.3. 再設定後に更新された情報へのアクセス
以下の手順を使用して、Red Hat Quay UI および config バンドルを使用して、更新された config.yaml ファイルにアクセスします。
手順
-
QuayRegistryの Details 画面で、Config Bundle Secret をクリックします。 -
Secretの詳細 画面の Data セクションで、Reveal values をクリックしてconfig.yamlファイルを表示します。 変更が適用されていることを確認します。この場合、
4wはTAG_EXPIRATION_OPTIONSの一覧に存在するはずです。以下に例を示します。--- SERVER_HOSTNAME: example-quay-openshift-operators.apps.docs.quayteam.org SETUP_COMPLETE: true SUPER_USERS: - quayadmin TAG_EXPIRATION_OPTIONS: - 2w - 4w ---
4.4. カスタム SSL/TLS 証明書 UI
設定ツールを使用してカスタム証明書をロードすると、外部データベースなどのリソースへのアクセスが容易になります。アップロードするカスタム証明書を選択し、拡張子 .crt を使用して PEM 形式のものであることを確認します。
設定ツールには、アップロードされた証明書の一覧が表示されます。アップロードしたカスタム SSL/TLS 証明書はリストに表示されます。以下に例を示します。
4.5. レジストリーへの外部アクセス
OpenShift Container Platform で実行している場合は、Routes API が利用可能になり、マネージドコンポーネントとして自動的に使用されます。QuayRegistry オブジェクトを作成すると、外部アクセスポイントは QuayRegistry オブジェクトのステータスブロックに表示されます。以下に例を示します。
status: registryEndpoint: some-quay.my-namespace.apps.mycluster.com
4.6. QuayRegistry API
Red Hat Quay Operator は、クラスターで Quay コンテナーレジストリーを宣言的に管理するために、QuayRegistry カスタムリソース API を提供します。この API と対話するには、OpenShift Container Platform UI またはコマンドラインツールのいずれかを使用します。
-
QuayRegistryを作成すると、Red Hat Quay Operator がクラスター上で Red Hat Quay を実行するために必要なすべてのリソースをデプロイおよび設定します。 -
QuayRegistryを編集すると、Red Hat Quay Operator が変更を調整し、目的の設定に併せてオブジェクトを作成、更新、削除します。 -
QuayRegistry を削除すると、これまで作成したすべてのリソースがガベージコレクションになります。削除した後は、Quayコンテナーレジストリーが使用できなくなります。
QuayRegistry API フィールドは、次のセクションで概要を説明します。
第5章 Red Hat Quay の Clair
Clair v4 (Clair) は、静的コード分析を活用してイメージコンテンツを解析し、コンテンツに影響を与える脆弱性を報告するオープンソースアプリケーションです。Clair は Red Hat Quay にパッケージ化されており、スタンドアロンと Operator デプロイメントの両方で使用できます。エンタープライズ環境に合わせてコンポーネントを個別にスケーリングできる、非常にスケーラブルな設定で実行できます。
5.1. Clair 脆弱性データベース
Clair は、次の脆弱性データベースを使用して、イメージの問題を報告します。
- Ubuntu Oval データベース
- Debian Oval データベース
- Red Hat Enterprise Linux (RHEL) Oval データベース
- SUSE Oval データベース
- Oracle Oval データベース
- アルパイン SecDB データベース
- VMWare Photon OS データベース
- Amazon Web Services (AWS) UpdateInfo
- Pyup.io (Python) データベース
Clair がさまざまなデータベースでセキュリティーマッピングを行う方法は、ClairCore Severity Mapping を参照してください。
5.2. OpenShift Container Platform の Clair
OpenShift Container Platform 上の Red Hat Quay デプロイメントで Clair v4 (Clair) をセットアップするには、Red Hat Quay Operator を使用することが推奨されます。デフォルトでは、Red Hat Quay Operator は、Clair デプロイメントを Red Hat Quay デプロイメントとともにインストールまたはアップグレードし、Clair を自動的に設定します。
5.3. Clair のテスト
以下の手順を使用して、スタンドアロンの Red Hat Quay デプロイメントまたは OpenShift Container Platform Operator ベースのデプロイメントで Clair をテストします。
前提条件
- Clair コンテナーイメージをデプロイしている。
手順
次のコマンドを入力して、サンプルイメージをプルします。
$ podman pull ubuntu:20.04
次のコマンドを入力して、レジストリーにイメージをタグ付けします。
$ sudo podman tag docker.io/library/ubuntu:20.04 <quay-server.example.com>/<user-name>/ubuntu:20.04
以下のコマンドを入力して、イメージを Red Hat Quay レジストリーにプッシュします。
$ sudo podman push --tls-verify=false quay-server.example.com/quayadmin/ubuntu:20.04
- UI から Red Hat Quay デプロイメントにログインします。
- リポジトリー名 (quayadmin/ubuntu など) をクリックします。
ナビゲーションウィンドウで、Tags をクリックします。
レポートの概要
イメージレポート (例: 45 medium) をクリックして、より詳細なレポートを表示します。
レポートの詳細
注記場合によっては、Clair はイメージに関する重複レポートを表示します (例:
ubi8/nodejs-12またはubi8/nodejs-16)。これは、同じ名前の脆弱性が異なるパッケージに存在するために発生します。この動作は Clair 脆弱性レポートで予期されており、バグとしては扱われません。
5.4. 高度な Clair 設定
次のセクションの手順を使用して、Clair の詳細設定を行います。
5.4.1. アンマネージド Clair 設定
Red Hat Quay ユーザーは、Red Hat Quay OpenShift Container Platform Operator を使用してアンマネージド Clair 設定を実行できます。この機能により、ユーザーはアンマネージド Clair データベースを作成したり、アンマネージドデータベースなしでカスタム Clair 設定を実行したりできます。
アンマネージド Clair データベースにより、Red Hat Quay オペレーターは、Operator の複数のインスタンスが同じデータベースと通信する必要がある地理的に複製された環境で作業できます。アンマネージド Clair データベースは、ユーザーがクラスターの外部に存在する高可用性 (HA) Clair データベースを必要とする場合にも使用できます。
5.4.1.1. アンマネージド Clair データベースを使用したカスタム Clair 設定の実行
次の手順を使用して、Clair データベースをアンマネージドに設定します。
手順
Quay Operator で、
QuayRegistryカスタムリソースのclairpostgresコンポーネントをmanaged: falseに設定します。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
5.4.1.2. アンマネージド Clair データベースを使用したカスタム Clair データベースの設定
Red Hat Quay Operator for OpenShift Container Platform を使用すると、ユーザーは独自の Clair データベースを提供できます。
次の手順を使用して、カスタム Clair データベースを作成します。
次の手順では、SSL/TLS 証明書を使用して Clair をセットアップします。SSL/TSL 証明書を使用して Clair をセットアップしない同様の手順を表示するには、マネージド Clair 設定を使用したカスタム 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ファイルをバンドルシークレットに追加します。次に例を示します。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> ssl.crt: <base64 encoded SSL certificate> ssl.key: <base64 encoded SSL private key>
注記更新すると、提供された
clair-config.yamlファイルが Clair Pod にマウントされます。提供されていないフィールドには、Clair 設定モジュールを使用してデフォルトが自動的に入力されます。Build History ページでコミットをクリックするか、
oc get pods -n <namespace>を実行して、Clair Pod のステータスを確認できます。以下に例を示します。$ oc get pods -n <namespace>
出力例
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Running 0 7s
5.4.2. マネージド Clair データベースを使用したカスタム Clair 設定の実行
場合によっては、マネージド Clair データベースを使用してカスタム Clair 設定を実行します。これは、以下のシナリオで役に立ちます。
- ユーザーが特定のアップデーターリソースを無効にする場合。
ユーザーが切断された環境で Red Hat Quay を実行している場合。切断された環境での Clair の実行の詳細は、エアギャップ OpenShift クラスターでの Clair データベースへのアクセスの設定 を参照してください。
注記-
切断された環境で Red Hat Quay を実行している場合は、
clair-config.yamlのairgapパラメーターをtrueに設定する必要があります。 - 切断された環境で Red Hat Quay を実行している場合は、すべてのアップデーターコンポーネントを無効にする必要があります。
-
切断された環境で Red Hat Quay を実行している場合は、
5.4.2.1. Clair データベースをマネージドに設定する
次の手順を使用して、Clair データベースをマネージドに設定します。
手順
Quay Operator で、
QuayRegistryカスタムリソースのclairpostgresコンポーネントをmanaged: trueに設定します。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: true
5.4.2.2. マネージド Clair 設定を使用したカスタム Clair データベースの設定
Red Hat Quay Operator for OpenShift Container Platform を使用すると、ユーザーは独自の Clair データベースを提供できます。
次の手順を使用して、カスタム 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 config-bundle-secret
Clair
config.yamlファイルの例indexer: connstring: host=quay-server.example.com port=5432 dbname=quay user=quayrdsdb password=quayrdsdb sslmode=disable 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 sslmode=disable migrations: true metrics: name: prometheus notifier: connstring: host=quay-server.example.com port=5432 dbname=quay user=quayrdsdb password=quayrdsdb sslmode=disable 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ファイルをバンドルシークレットに追加します。次に例を示します。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>
注記-
更新すると、提供された
clair-config.yamlファイルが Clair Pod にマウントされます。提供されていないフィールドには、Clair 設定モジュールを使用してデフォルトが自動的に入力されます。
-
更新すると、提供された
Build History ページでコミットをクリックするか、
oc get pods -n <namespace>を実行して、Clair Pod のステータスを確認できます。以下に例を示します。$ oc get pods -n <namespace>
出力例
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Running 0 7s
5.4.3. 切断された環境での Clair
Clair は、updater と呼ばれる一連のコンポーネントを使用して、さまざまな脆弱性データベースからのデータのフェッチと解析を処理します。updater はデフォルトで、脆弱性データをインターネットから直接プルし、すぐに使用できるように設定されています。ただし、一部のユーザーは、切断された環境またはインターネットに直接アクセスできない環境で Red Hat Quay を実行する必要がある場合があります。Clair は、ネットワーク分離を考慮したさまざまな種類の更新ワークフローを使用することで、切断された環境をサポートします。これは clairctl コマンドラインインターフェイスツールを使用して機能します。このツールは、オープンホストを使用してインターネットから updater データを取得し、そのデータを隔離されたホストにセキュアに転送してから、隔離されたホスト上の updater データを Clair にインポートします。
このガイドを使用して、切断された環境で Clair をデプロイします。
現在、Clair エンリッチメントデータは CVSS データです。エンリッチメントデータは現在、オフライン環境ではサポートされていません。
Clair アップデーターの詳細は、Clair アップデーターを参照してください。
5.4.3.1. 切断された OpenShift Container Platform クラスターでの Clair のセットアップ
以下の手順を使用して、切断された OpenShift Container Platform クラスターに OpenShift Container Platform でプロビジョニングされた Clair Pod をセットアップします。
5.4.3.1.1. OpenShift Container Platform デプロイメント用の clairctl コマンドラインユーティリティーツールのインストール
以下の手順を使用して、OpenShift Container Platform デプロイメント用の clairctl CLI ツールをインストールします。
手順
以下のコマンドを入力して、Clair デプロイメント用の
clairctlプログラムを OpenShift Container Platform クラスターにインストールします。$ oc -n quay-enterprise exec example-registry-clair-app-64dd48f866-6ptgw -- cat /usr/bin/clairctl > clairctl
注記非公式ですが、
clairctlツールをダウンロードできます。clairctlファイルの権限を設定して、ユーザーが実行できるようにします。次に例を示します。$ chmod u+x ./clairctl
5.4.3.1.2. OpenShift Container Platform での Clair デプロイメントの Clair 設定シークレットの取得とデコード
以下の手順を使用して、OpenShift Container Platform 上の OpenShift Container Platform でプロビジョニングされた Clair インスタンスの設定シークレットを取得してデコードします。
前提条件
-
clairctlコマンドラインユーティリティーツールをインストールしている。
手順
次のコマンドを入力して、設定シークレットを取得してデコードし、それを Clair 設定 YAML に保存します。
$ oc get secret -n quay-enterprise example-registry-clair-config-secret -o "jsonpath={$.data['config\.yaml']}" | base64 -d > clair-config.yamldisable_updatersおよびairgapパラメーターがtrueに設定されるように、clair-config.yamlファイルを更新します。次に例を示します。--- indexer: airgap: true --- matcher: disable_updaters: true ---
5.4.3.1.3. 接続された Clair インスタンスからアップデータバンドルをエクスポートする
次の手順を使用して、インターネットにアクセスできる Clair インスタンスから更新プログラムバンドルをエクスポートします。
前提条件
-
clairctlコマンドラインユーティリティーツールをインストールしている。 -
Clair 設定シークレットを取得してデコードし、Clair の
config.yamlファイルに保存している。 -
Clair の
config.yamlファイルで、disable_updatersおよびairgapパラメーターがtrueに設定されている。
手順
インターネットにアクセスできる Clair インスタンスから、設定ファイルで
clairctlCLI ツールを使用して、アップデーターバンドルをエクスポートします。以下に例を示します。$ ./clairctl --config ./config.yaml export-updaters updates.gz
5.4.3.1.4. 切断された OpenShift Container Platform クラスターでの Clair データベースへのアクセスの設定
以下の手順を使用して、切断された OpenShift Container Platform クラスター内の Clair データベースへのアクセスを設定します。
前提条件
-
clairctlコマンドラインユーティリティーツールをインストールしている。 -
Clair 設定シークレットを取得してデコードし、Clair の
config.yamlファイルに保存している。 -
Clair の
config.yamlファイルで、disable_updatersおよびairgapパラメーターがtrueに設定されている。 - インターネットにアクセスできる Clair インスタンスからアップデーターバンドルをエクスポートしている。
手順
CLI ツール
ocを使用して、Clair データベースサービスを特定します。次に例を示します。$ oc get svc -n quay-enterprise
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE example-registry-clair-app ClusterIP 172.30.224.93 <none> 80/TCP,8089/TCP 4d21h example-registry-clair-postgres ClusterIP 172.30.246.88 <none> 5432/TCP 4d21h ...
Clair データベースポートを転送して、ローカルマシンからアクセスできるようにします。以下に例を示します。
$ oc port-forward -n quay-enterprise service/example-registry-clair-postgres 5432:5432
Clair の
config.yamlファイルを更新します。次に例を示します。indexer: connstring: host=localhost port=5432 dbname=postgres user=postgres password=postgres sslmode=disable 1 scanlock_retry: 10 layer_scan_concurrency: 5 migrations: true scanner: repo: rhel-repository-scanner: 2 repo2cpe_mapping_file: /data/cpe-map.json package: rhel_containerscanner: 3 name2repos_mapping_file: /data/repo-map.json
5.4.3.1.5. 切断された OpenShift Container Platform クラスターへのアップデーターバンドルのインポート
以下の手順を使用して、アップデーターバンドルを切断された OpenShift Container Platform クラスターにインポートします。
前提条件
-
clairctlコマンドラインユーティリティーツールをインストールしている。 -
Clair 設定シークレットを取得してデコードし、Clair の
config.yamlファイルに保存している。 -
Clair の
config.yamlファイルで、disable_updatersおよびairgapパラメーターがtrueに設定されている。 - インターネットにアクセスできる Clair インスタンスからアップデーターバンドルをエクスポートしている。
- アップデーターバンドルを切断された環境に転送している。
手順
CLI ツール
clairctlを使用して、アップデーターバンドルを OpenShift Container Platform によってデプロイされた Clair データベースにインポートします。以下に例を示します。$ ./clairctl --config ./clair-config.yaml import-updaters updates.gz
5.4.3.2. 切断された OpenShift Container Platform クラスター用の Clair の自己管理デプロイメントのセットアップ
以下の手順を使用して、切断された OpenShift Container Platform クラスター用に Clair の自己管理デプロイメントをセットアップします。
5.4.3.2.1. OpenShift Container Platform で自己管理 Clair デプロイメント用の clairctl コマンドラインユーティリティーツールをインストールする
以下の手順を使用して、OpenShift Container Platform に自己管理 Clair デプロイメント用の clairctl CLI ツールをインストールします。
手順
podman cpコマンドを使用して、自己管理の Clair デプロイメント用のclairctlプログラムをインストールします。以下に例を示します。$ sudo podman cp clairv4:/usr/bin/clairctl ./clairctl
clairctlファイルの権限を設定して、ユーザーが実行できるようにします。次に例を示します。$ chmod u+x ./clairctl
5.4.3.2.2. 切断された OpenShift Container Platform クラスター用の自己管理 Clair コンテナーのデプロイ
以下の手順を使用して、切断された OpenShift Container Platform クラスター用の自己管理 Clair コンテナーをデプロイします。
前提条件
-
clairctlコマンドラインユーティリティーツールをインストールしている。
手順
Clair 設定ファイル用のフォルダーを作成します。次に例を示します。
$ mkdir /etc/clairv4/config/
disable_updatersパラメーターをtrueに設定して Clair 設定ファイルを作成します。次に例を示します。--- indexer: airgap: true --- matcher: disable_updaters: true ---
コンテナーイメージを使用して Clair を起動し、作成したファイルから設定にマウントします。
$ sudo podman run -it --rm --name clairv4 \ -p 8081:8081 -p 8088:8088 \ -e CLAIR_CONF=/clair/config.yaml \ -e CLAIR_MODE=combo \ -v /etc/clairv4/config:/clair:Z \ registry.redhat.io/quay/clair-rhel8:v3.9.0
5.4.3.2.3. 接続された Clair インスタンスからアップデータバンドルをエクスポートする
次の手順を使用して、インターネットにアクセスできる Clair インスタンスから更新プログラムバンドルをエクスポートします。
前提条件
-
clairctlコマンドラインユーティリティーツールをインストールしている。 - Clair をデプロイしている。
-
Clair の
config.yamlファイルで、disable_updatersおよびairgapパラメーターがtrueに設定されている。
手順
インターネットにアクセスできる Clair インスタンスから、設定ファイルで
clairctlCLI ツールを使用して、アップデーターバンドルをエクスポートします。以下に例を示します。$ ./clairctl --config ./config.yaml export-updaters updates.gz
5.4.3.2.4. 切断された OpenShift Container Platform クラスターでの Clair データベースへのアクセスの設定
以下の手順を使用して、切断された OpenShift Container Platform クラスター内の Clair データベースへのアクセスを設定します。
前提条件
-
clairctlコマンドラインユーティリティーツールをインストールしている。 - Clair をデプロイしている。
-
Clair の
config.yamlファイルで、disable_updatersおよびairgapパラメーターがtrueに設定されている。 - インターネットにアクセスできる Clair インスタンスからアップデーターバンドルをエクスポートしている。
手順
CLI ツール
ocを使用して、Clair データベースサービスを特定します。次に例を示します。$ oc get svc -n quay-enterprise
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE example-registry-clair-app ClusterIP 172.30.224.93 <none> 80/TCP,8089/TCP 4d21h example-registry-clair-postgres ClusterIP 172.30.246.88 <none> 5432/TCP 4d21h ...
Clair データベースポートを転送して、ローカルマシンからアクセスできるようにします。以下に例を示します。
$ oc port-forward -n quay-enterprise service/example-registry-clair-postgres 5432:5432
Clair の
config.yamlファイルを更新します。次に例を示します。indexer: connstring: host=localhost port=5432 dbname=postgres user=postgres password=postgres sslmode=disable 1 scanlock_retry: 10 layer_scan_concurrency: 5 migrations: true scanner: repo: rhel-repository-scanner: 2 repo2cpe_mapping_file: /data/cpe-map.json package: rhel_containerscanner: 3 name2repos_mapping_file: /data/repo-map.json
5.4.3.2.5. 切断された OpenShift Container Platform クラスターへのアップデーターバンドルのインポート
以下の手順を使用して、アップデーターバンドルを切断された OpenShift Container Platform クラスターにインポートします。
前提条件
-
clairctlコマンドラインユーティリティーツールをインストールしている。 - Clair をデプロイしている。
-
Clair の
config.yamlファイルで、disable_updatersおよびairgapパラメーターがtrueに設定されている。 - インターネットにアクセスできる Clair インスタンスからアップデーターバンドルをエクスポートしている。
- アップデーターバンドルを切断された環境に転送している。
手順
CLI ツール
clairctlを使用して、アップデーターバンドルを OpenShift Container Platform によってデプロイされた Clair データベースにインポートします。$ ./clairctl --config ./clair-config.yaml import-updaters updates.gz
5.4.4. 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 サーバーのホスト名。
5.4.5. 共通製品列挙情報へのリポジトリーのマッピング
Clair の Red Hat Enterprise Linux (RHEL) スキャナーは、Common Product Enumeration (CPE) ファイルに依存して、RPM パッケージを対応するセキュリティーデータにマッピングし、マッチングする結果を生成します。これらのファイルは製品セキュリティーによって所有され、毎日更新されます。
スキャナーが RPM を適切に処理するには、CPE ファイルが存在するか、ファイルへのアクセスが許可されている必要があります。ファイルが存在しないと、コンテナーイメージにインストールされている RPM パッケージはスキャンされません。
表5.1 Clair CPE マッピングファイル
| CPE | JSON マッピングファイルへのリンク |
|---|---|
|
| |
|
|
切断された Clair インストール用のデータベースに CVE 情報をアップロードするだけでなく、マッピングファイルをローカルで使用できるようにする必要もあります。
- スタンドアロン Red Hat Quay および Clair デプロイメントの場合は、マッピングファイルを Clair Pod に読み込む必要があります。
-
OpenShift Container Platform および Clair デプロイメントでの Red Hat Quay Operator デプロイメントの場合は、Clair コンポーネントを
unmanagedに設定する必要があります。次に、Clair を手動でデプロイメントし、マッピングファイルのローカルコピーを読み込むように設定する必要があります。
5.4.5.1. Common Product Enumeration サンプル設定へのリポジトリーのマッピング
Clair 設定の repo2cpe_mapping_file フィールドと name2repos_mapping_file フィールドを使用して、CPE JSON マッピングファイルを含めます。以下に例を示します。
indexer:
scanner:
repo:
rhel-repository-scanner:
repo2cpe_mapping_file: /data/cpe-map.json
package:
rhel_containerscanner:
name2repos_mapping_file: /data/repo-map.json詳細は、OVAL セキュリティーデータをインストール済みの RPM と正確にマッチングする方法 を参照してください。
5.5. インフラストラクチャーノードへの Red Hat Quay のデプロイ
デフォルトでは、Red Hat Quay Operator を使用してレジストリーをデプロイする際に Quay 関連の Pod は任意のワーカーノードに配置されます。マシンセットを使用してインフラストラクチャーコンポーネントのみをホストするようにノードを設定する方法の詳細は、インフラストラクチャーマシンセットの作成 を参照してください。
OpenShift Container Platform マシンセットリソースを使用してインフラノードをデプロイしていない場合、このドキュメントのセクションでは、インフラストラクチャー目的でノードに手動でラベルを付けてテイントする方法を示します。手動またはマシンセットを使用してインフラストラクチャーノードを設定したら、ノードセレクターおよび容認を使用してこれらのノードに対する Quay Pod の配置を制御できます。
5.5.1. インフラストラクチャー用ノードへのラベルとテインとの追加
次の手順を実行して、インフラストラクチャー用のノードにラベルとテインとを追加します。
次のコマンドを入力して、マスターノードとワーカーノードを表示します。この例では、3 つのマスターノードと 6 つのワーカーノードがあります。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION user1-jcnp6-master-0.c.quay-devel.internal Ready master 3h30m v1.20.0+ba45583 user1-jcnp6-master-1.c.quay-devel.internal Ready master 3h30m v1.20.0+ba45583 user1-jcnp6-master-2.c.quay-devel.internal Ready master 3h30m v1.20.0+ba45583 user1-jcnp6-worker-b-65plj.c.quay-devel.internal Ready worker 3h21m v1.20.0+ba45583 user1-jcnp6-worker-b-jr7hc.c.quay-devel.internal Ready worker 3h21m v1.20.0+ba45583 user1-jcnp6-worker-c-jrq4v.c.quay-devel.internal Ready worker 3h21m v1.20.0+ba45583 user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal Ready worker 3h21m v1.20.0+ba45583 user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal Ready worker 3h22m v1.20.0+ba45583 user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal Ready worker 3h21m v1.20.0+ba45583
次のコマンドを入力して、インフラストラクチャーで使用する 3 つのワーカーノードにラベルを付けます。
$ oc label node --overwrite user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal node-role.kubernetes.io/infra=
$ oc label node --overwrite user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal node-role.kubernetes.io/infra=
$ oc label node --overwrite user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal node-role.kubernetes.io/infra=
ここで、クラスター内のノードをリストすると、最後の 3 つのワーカーノードには
infraロールが与えられます。以下に例を示します。$ oc get nodes
例
NAME STATUS ROLES AGE VERSION user1-jcnp6-master-0.c.quay-devel.internal Ready master 4h14m v1.20.0+ba45583 user1-jcnp6-master-1.c.quay-devel.internal Ready master 4h15m v1.20.0+ba45583 user1-jcnp6-master-2.c.quay-devel.internal Ready master 4h14m v1.20.0+ba45583 user1-jcnp6-worker-b-65plj.c.quay-devel.internal Ready worker 4h6m v1.20.0+ba45583 user1-jcnp6-worker-b-jr7hc.c.quay-devel.internal Ready worker 4h5m v1.20.0+ba45583 user1-jcnp6-worker-c-jrq4v.c.quay-devel.internal Ready worker 4h5m v1.20.0+ba45583 user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal Ready infra,worker 4h6m v1.20.0+ba45583 user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal Ready infra,worker 4h6m v1.20.0+ba45583 user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal Ready infra,worker 4h6m v1.20.0+ba4558
ワーカーノードに
infraロールが割り当てられている場合、ユーザーのワークロードが誤ってインフラノードに割り当てられる可能性があります。これを回避するには、infra ノードにテイントを適用し、制御する Pod に容認を追加します。以下に例を示します。$ oc adm taint nodes user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule
$ oc adm taint nodes user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule
$ oc adm taint nodes user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal node-role.kubernetes.io/infra:NoSchedule
5.5.2. ノードセレクターと容認を使用したプロジェクト作成
ノードセレクターと容認を持つプロジェクトを作成するには、次の手順を実行します。
すでに Operator を使用して Red Hat Quay をデプロイしている場合は、インストールした Operator と、デプロイメントのために作成した特定の namespace を削除します。
手順
ノードセレクターと許容範囲を指定して、プロジェクトリソースを作成します。以下に例を示します。
quay-registry.yaml
kind: Project apiVersion: project.openshift.io/v1 metadata: name: quay-registry annotations: openshift.io/node-selector: 'node-role.kubernetes.io/infra=' scheduler.alpha.kubernetes.io/defaultTolerations: >- [{"operator": "Exists", "effect": "NoSchedule", "key": "node-role.kubernetes.io/infra"}]以下のコマンドを入力してプロジェクトを作成します。
$ oc apply -f quay-registry.yaml
出力例
project.project.openshift.io/quay-registry created
quay-registry namespace で作成された後続のリソースは、専用のインフラストラクチャーノードでスケジュールされます。
5.5.3. namespace への Red Hat Quay Operator のインストール
以下の手順を実行して、Red Hat Quay Operator を namespace にインストールします。
Red Hat Quay Operator を特定の namespace にインストールするには、次のコマンドのように、適切なプロジェクト名前空間を明示的に指定する必要があります。この例では、
quay-registryを使用しています。これにより、Operator Pod が 3 つのインフラストラクチャーノードの 1 つに着陸します。以下に例を示します。$ oc get pods -n quay-registry -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE quay-operator.v3.4.1-6f6597d8d8-bd4dp 1/1 Running 0 30s 10.131.0.16 user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal
5.5.4. Red Hat Quay レジストリーの作成
Red Hat Quay レジストリーを作成するには、次の手順を実行します。
次のコマンドを入力して、Red Hat Quay レジストリーを作成します。次に、デプロイメントが
readyとしてマークされるまで待ちます。次の例では、インフラストラクチャー目的でラベルを付けた 3 つのノード上でのみスケジュールされていることがわかります。$ oc get pods -n quay-registry -o wide
出力例
NAME READY STATUS RESTARTS AGE IP NODE example-registry-clair-app-789d6d984d-gpbwd 1/1 Running 1 5m57s 10.130.2.80 user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal example-registry-clair-postgres-7c8697f5-zkzht 1/1 Running 0 4m53s 10.129.2.19 user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal example-registry-quay-app-56dd755b6d-glbf7 1/1 Running 1 5m57s 10.129.2.17 user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal example-registry-quay-config-editor-7bf9bccc7b-dpc6d 1/1 Running 0 5m57s 10.131.0.23 user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal example-registry-quay-database-8dc7cfd69-dr2cc 1/1 Running 0 5m43s 10.129.2.18 user1-jcnp6-worker-c-pwxfp.c.quay-devel.internal example-registry-quay-mirror-78df886bcc-v75p9 1/1 Running 0 5m16s 10.131.0.24 user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal example-registry-quay-postgres-init-8s8g9 0/1 Completed 0 5m54s 10.130.2.79 user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal example-registry-quay-redis-5688ddcdb6-ndp4t 1/1 Running 0 5m56s 10.130.2.78 user1-jcnp6-worker-d-m9gg4.c.quay-devel.internal quay-operator.v3.4.1-6f6597d8d8-bd4dp 1/1 Running 0 22m 10.131.0.16 user1-jcnp6-worker-d-h5tv2.c.quay-devel.internal
5.6. Red Hat Quay Operator が単一の namespace にインストールされている場合のモニタリングの有効化
Red Hat Quay Operator が単一の namespace にインストールされている場合、モニタリングコンポーネントは unmanaged に設定されます。モニタリングを設定するには、OpenShift Container Platform でユーザー定義の namespace に対してモニタリングを有効にする必要があります。
詳細は、OpenShift Container Platform ドキュメントの モニタリングスタックの設定 および ユーザー定義プロジェクトのモニタリングの有効化 を参照してください。
以下のセクションでは、OpenShift Container Platform ドキュメントに基づいて Red Hat Quay のモニタリングを有効にする方法を示します。
5.6.1. クラスターモニタリング設定マップの作成
次の手順を使用して、cluster-monitoring-config ConfigMap オブジェクトが存在するかどうかを確認します。
手順
次のコマンドを入力して、
cluster-monitoring-configConfigMap オブジェクトが存在するかどうかを確認します。$ oc -n openshift-monitoring get configmap cluster-monitoring-config
出力例
Error from server (NotFound): configmaps "cluster-monitoring-config" not found
オプション:
ConfigMapオブジェクトが存在しない場合は、YAML マニフェストを作成します。次の例では、ファイルの名前はcluster-monitoring-config.yamlです。apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: |
オプション:
ConfigMapオブジェクトが存在しない場合は、ConfigMapオブジェクトを作成します。$ oc apply -f cluster-monitoring-config.yaml configmap/cluster-monitoring-config created
次のコマンドを実行して、
ConfigMapオブジェクトが存在することを確認します。$ oc -n openshift-monitoring get configmap cluster-monitoring-config
出力例
NAME DATA AGE cluster-monitoring-config 1 12s
5.6.2. ユーザー定義のワークロード監視 ConfigMap オブジェクトの作成
次の手順を使用して、user-workload-monitoring-config ConfigMap オブジェクトが存在するかどうかを確認します。
手順
次のコマンドを入力して、
user-workload-monitoring-configConfigMapオブジェクトが存在するかどうかを確認します。$ oc -n openshift-user-workload-monitoring get configmap user-workload-monitoring-config
出力例
Error from server (NotFound): configmaps "user-workload-monitoring-config" not found
ConfigMapオブジェクトが存在しない場合は、YAML マニフェストを作成します。次の例では、ファイルの名前はuser-workload-monitoring-config.yamlです。apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: |
オプション: 次のコマンドを入力して、
ConfigMapオブジェクトを作成します。$ oc apply -f user-workload-monitoring-config.yaml
出力例
configmap/user-workload-monitoring-config created
5.6.3. ユーザー定義プロジェクトのモニタリングの有効化
ユーザー定義プロジェクトの監視を有効にするには、次の手順を実行します。
手順
次のコマンドを入力して、ユーザー定義プロジェクトの監視が実行されているかどうかを確認します。
$ oc get pods -n openshift-user-workload-monitoring
出力例
No resources found in openshift-user-workload-monitoring namespace.
次のコマンドを入力して、
cluster-monitoring-configConfigMapを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
config.yamlファイルでenableUserWorkload: trueを設定して、クラスター上のユーザー定義プロジェクトの監視を有効にします。apiVersion: v1 data: config.yaml: | enableUserWorkload: true kind: ConfigMap metadata: annotations:次のコマンドを入力してファイルを保存し、変更を適用して、適切な Pod が実行されていることを確認します。
$ oc get pods -n openshift-user-workload-monitoring
出力例
NAME READY STATUS RESTARTS AGE prometheus-operator-6f96b4b8f8-gq6rl 2/2 Running 0 15s prometheus-user-workload-0 5/5 Running 1 12s prometheus-user-workload-1 5/5 Running 1 12s thanos-ruler-user-workload-0 3/3 Running 0 8s thanos-ruler-user-workload-1 3/3 Running 0 8s
5.6.4. Red Hat Quay メトリックを公開するための Service オブジェクトの作成
以下の手順を使用して Service オブジェクトを作成し、Red Hat Quay メトリクスを公開します。
手順
Service オブジェクトの YAML ファイルを作成します。
$ cat <<EOF > quay-service.yaml apiVersion: v1 kind: Service metadata: annotations: labels: quay-component: monitoring quay-operator/quayregistry: example-registry name: example-registry-quay-metrics namespace: quay-enterprise spec: ports: - name: quay-metrics port: 9091 protocol: TCP targetPort: 9091 selector: quay-component: quay-app quay-operator/quayregistry: example-registry type: ClusterIP EOF次のコマンドを入力して、
Serviceオブジェクトを作成します。$ oc apply -f quay-service.yaml
出力例
service/example-registry-quay-metrics created
5.6.5. ServiceMonitor オブジェクトの作成
ServiceMonitor リソースを作成してメトリックを取得するように OpenShift Monitoring を設定するには、次の手順を使用します。
手順
ServiceMonitorリソースの YAML ファイルを作成します。$ cat <<EOF > quay-service-monitor.yaml apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: quay-operator/quayregistry: example-registry name: example-registry-quay-metrics-monitor namespace: quay-enterprise spec: endpoints: - port: quay-metrics namespaceSelector: any: true selector: matchLabels: quay-component: monitoring EOF次のコマンドを入力して、
ServiceMonitorリソースを作成します。$ oc apply -f quay-service-monitor.yaml
出力例
servicemonitor.monitoring.coreos.com/example-registry-quay-metrics-monitor created
5.6.6. OpenShift Container Platform でのメトリックの表示
OpenShift Container Platform コンソールの Monitoring → Metrics からメトリックにアクセスできます。式フィールドに quay_ と入力すると、使用可能なメトリックのリストが表示されます。
たとえば、レジストリーにユーザーを追加した場合は、quay-users_rows メトリックを選択します。
5.7. 管理ストレージのサイズ変更
Red Hat Quay Operator は、NooBaa オブジェクト (50 Gib) の作成時に Red Hat OpenShift Data Foundation によって提供されるデフォルトを使用してデフォルトのオブジェクトストレージを作成します。
NooBaa オブジェクトストレージを拡張するには 2 つの方法があります。
- 既存の Persistent Volume Claim (PVC) のサイズを変更できます。
- 新しいストレージプールにさらに PVC を追加できます。
5.7.1. NooBaa PVC のサイズ変更
NooBaa PVC のサイズを変更するには、次の手順を使用します。
手順
- OpenShift Container Platform コンソールにログインし、Storage → Persistent Volume Claims を選択します。
-
名前が
noobaa-default-backing-store-noobaa-pvc-*などのPersistentVolumeClaimを選択します。 - Action メニューから Expand PVC を選択します。
- 永続ボリューム要求 (PVC) の新しいサイズを入力し、Expand を選択します。
数分後に (PVC のサイズによって異なる)、拡張されたサイズは PVC の Capacity フィールドに反映される必要があります。
5.8. デフォルトの Operator イメージのカスタマイズ
特定の状況では、Red Hat Quay Operator が使用するデフォルトのイメージをオーバーライドすると便利な場合があります。これを行うには、Red Hat Quay Operator ClusterServiceVersion で 1 つ以上の環境変数を設定します。
このメカニズムの使用は、実稼働 Red Hat Quay 環境ではサポートされておらず、開発またはテストの目的でのみ使用することが強く推奨されます。Red Hat Quay Operator でデフォルト以外のイメージを使用する場合は、デプロイメントが正しく機能するという保証はありません。
5.8.1. 環境変数
以下の環境変数は、Red Hat Quay Operator でコンポーネントイメージをオーバーライドするために使用されます。
| 環境変数 | コンポーネント |
|
|
|
|
|
|
|
|
|
|
|
|
オーバーライドされたイメージは、タグ (:latest) ではなく、マニフェスト (@sha256:) によって参照する 必要があります。
5.8.2. 実行中のオペレータへのオーバーライドの適用
Red Hat Quay Operator が Operator Lifecycle Manager (OLM) を通じてクラスターにインストールされている場合、マネージドコンポーネントのコンテナーイメージは、ClusterServiceVersion オブジェクトを変更すると簡単にオーバーライドできます。
以下の手順を使用して、実行中の Red Hat Quay Operator にオーバーライドを適用します。
手順
ClusterServiceVersionオブジェクトは、クラスター内で実行中の Operator を Operator Lifecycle Manager が表現したものです。Kubernetes UI またはkubectl/ocCLI ツールを使用して、Red Hat Quay Operator のClusterServiceVersionを見つけます。以下に例を示します。$ oc get clusterserviceversions -n <your-namespace>
UI、
oc edit、または別の方法を使用して、Red Hat QuayClusterServiceVersionを変更して、オーバーライドイメージを指す上記の環境変数を含めます。JSONPath:
spec.install.spec.deployments[0].spec.template.spec.containers[0].env- name: RELATED_IMAGE_COMPONENT_QUAY value: quay.io/projectquay/quay@sha256:c35f5af964431673f4ff5c9e90bdf45f19e38b8742b5903d41c10cc7f6339a6d - name: RELATED_IMAGE_COMPONENT_CLAIR value: quay.io/projectquay/clair@sha256:70c99feceb4c0973540d22e740659cd8d616775d3ad1c1698ddf71d0221f3ce6 - name: RELATED_IMAGE_COMPONENT_POSTGRES value: centos/postgresql-10-centos7@sha256:de1560cb35e5ec643e7b3a772ebaac8e3a7a2a8e8271d9e91ff023539b4dfb33 - name: RELATED_IMAGE_COMPONENT_REDIS value: centos/redis-32-centos7@sha256:06dbb609484330ec6be6090109f1fa16e936afcf975d1cbc5fff3e6c7cae7542
これは Operator レベルで実行されるため、すべての QuayRegistry はこれらの同じオーバーライドを使用してデプロイされています。
5.9. AWS S3 CloudFront
バックエンドレジストリーストレージに AWS S3 Cloudfront を使用している場合は、次の手順を使用します。
手順
次のコマンドを入力してレジストリーキーを指定します。
$ oc create secret generic --from-file config.yaml=./config_awss3cloudfront.yaml --from-file default-cloudfront-signing-key.pem=./default-cloudfront-signing-key.pem test-config-bundle
第6章 Red Hat Quay ビルドの機能強化
Red Hat Quay ビルドは仮想化プラットフォーム上で実行できます。以前のビルド設定を実行するための下位互換性も利用できます。
6.1. Red Hat Quay ビルドの制限
特権のないコンテキストで Red Hat Quay でビルドを実行すると、以前のビルド戦略で機能していた一部のコマンドが失敗する可能性があります。ビルド戦略を変更しようとすると、ビルドのパフォーマンスの問題と信頼性の問題が発生する可能性があります。
コンテナーでビルドを直接実行しても、仮想マシンを使用する場合と同じように分離されることはありません。ビルド環境を変更すると、以前は機能していたビルドが失敗する可能性もあります。
6.2. OpenShift Container Platform を使用した Red Hat Quay ビルダー環境の作成
このセクションの手順では、OpenShift Container Platform で Red Hat Quay 仮想ビルダー環境を作成する方法を説明します。
6.2.1. OpenShift Container Platform TLS コンポーネント
tls コンポーネントを使用すると、TLS 設定を制御できます。
TLS コンポーネントが Operator によって管理されている場合、Red Hat Quay 3 はビルダーをサポートしません。
tls を unmanaged に設定する場合は、独自の ssl.cert ファイルと ssl.key ファイルを提供します。このとき、クラスターでビルダーをサポートする場合は、Quay ルートとビルダールート名の両方を証明書の SAN リストに追加するか、ワイルドカードを使用する必要があります。
ビルダールートを追加するには、次の形式を使用します。
[quayregistry-cr-name]-quay-builder-[ocp-namespace].[ocp-domain-name]:443
6.2.2. OpenShift Container Platform ビルダー向けの Red Hat Quay の使用
ビルダーには SSL/TLS 証明書が必要です。SSL/TLS 証明書の詳細は Red Hat Quay コンテナーへの TLS 証明書の追加 を参照してください。
Amazon Webservice (AWS) S3 ストレージを使用している場合は、ビルダーを実行する前に、AWS コンソールでストレージバケットを変更する必要があります。必要なパラメーターは、次のセクションの AWS S3 ストレージバケットの変更を参照してください。
6.2.2.1. 仮想ビルダー向けの OpenShift Container Platform の準備
以下の手順を使用して、Red Hat Quay 仮想ビルダー用に OpenShift Container Platform を準備します。
- この手順は、クラスターが既にプロビジョニングされており、Quay Operator が実行されていることを前提とします。
- この手順は、OpenShift Container Platform で仮想 namespace を設定するためのものです。
手順
- クラスター管理者アカウントを使用して Red Hat Quay クラスターにログインします。
次のコマンドを実行して、仮想ビルダーが実行される新しいプロジェクト (
virtual-buildersなど) を作成します。$ oc new-project virtual-builders
次のコマンドを入力して、ビルドの実行に使用されるプロジェクトに
ServiceAccountを作成します。$ oc create sa -n virtual-builders quay-builder
作成したサービスアカウントに編集権限を付与して、ビルドを実行できるようにします。
$ oc adm policy -n virtual-builders add-role-to-user edit system:serviceaccount:virtual-builders:quay-builder
次のコマンドを入力して、Quay ビルダーに
anyuid scc権限を付与します。$ oc adm policy -n virtual-builders add-scc-to-user anyuid -z quay-builder
注記このアクションには、クラスター管理者特権が必要です。非特権ビルドまたはルートレスビルドを機能させるには、ビルダーを Podman ユーザーとして実行する必要があるため、これが必要です。
Quay ビルダーサービスアカウントのトークンを取得します。
OpenShift Container Platform 4.10 以前のバージョンを使用している場合は、以下のコマンドを入力します。
oc sa get-token -n virtual-builders quay-builder
OpenShift Container Platform 4.11 以降を使用している場合は、以下のコマンドを入力します。
$ oc create token quay-builder -n virtual-builders
出力例
eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ...
次のコマンドを入力してビルダールートを決定します。
$ oc get route -n quay-enterprise
出力例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD ... example-registry-quay-builder example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org example-registry-quay-app grpc edge/Redirect None ...
次のコマンドを入力して、拡張子が .crt の自己署名 SSL/TlS 証明書を生成します。
$ oc extract cm/kube-root-ca.crt -n openshift-apiserver
出力例
ca.crt
次のコマンドを入力して、
ca.crtファイルの名前をextra_ca_cert_build_cluster.crtに変更します。$ mv ca.crt extra_ca_cert_build_cluster.crt
Console で設定バンドルのシークレットを見つけ、Actions → Edit Secret を選択して、適切なビルダー設定を追加します。
FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - <superusername> FEATURE_USER_CREATION: false FEATURE_QUOTA_MANAGEMENT: true FEATURE_BUILD_SUPPORT: True BUILDMAN_HOSTNAME: <sample_build_route> 1 BUILD_MANAGER: - ephemeral - ALLOWED_WORKER_COUNT: 1 ORCHESTRATOR_PREFIX: buildman/production/ JOB_REGISTRATION_TIMEOUT: 3600 2 ORCHESTRATOR: REDIS_HOST: <sample_redis_hostname> 3 REDIS_PASSWORD: "" REDIS_SSL: false REDIS_SKIP_KEYSPACE_EVENT_SETUP: false EXECUTORS: - EXECUTOR: kubernetesPodman NAME: openshift BUILDER_NAMESPACE: <sample_builder_namespace> 4 SETUP_TIME: 180 MINIMUM_RETRY_THRESHOLD: 0 BUILDER_CONTAINER_IMAGE: <sample_builder_container_image> 5 # Kubernetes resource options K8S_API_SERVER: <sample_k8s_api_server> 6 K8S_API_TLS_CA: <sample_crt_file> 7 VOLUME_SIZE: 8G KUBERNETES_DISTRIBUTION: openshift CONTAINER_MEMORY_LIMITS: 300m 8 CONTAINER_CPU_LIMITS: 1G 9 CONTAINER_MEMORY_REQUEST: 300m 10 CONTAINER_CPU_REQUEST: 1G 11 NODE_SELECTOR_LABEL_KEY: "" NODE_SELECTOR_LABEL_VALUE: "" SERVICE_ACCOUNT_NAME: <sample_service_account_name> SERVICE_ACCOUNT_TOKEN: <sample_account_token> 12
- 1
- ビルドルートは、Open Shift Operators namespace の名前で
oc get route -nを実行することにより取得されます。ルートの最後にポートを指定する必要があり、quayregistry-cr-name-quay-builder-ocp-namespace.ocp-domain-name:443の形式を使用する必要があります。 - 2
JOB_REGISTRATION_TIMEOUTパラメーターの設定が低すぎると、failed to register job to build manager: rpc error: code = Unauthenticated desc = Invalid build token: Signature has expiredエラーが発生する可能性があります。このパラメーターは少なくとも 240 に設定することをお勧めします。- 3
- Redis ホストにパスワードまたは SSL/TLS 証明書がある場合は、それに応じて更新する必要があります。
- 4
- 仮想ビルダーの namespace の名前と一致するように設定します (例:
virtual-builders)。 - 5
- 早期アクセスの場合、
BUILDER_CONTAINER_IMAGEは現在quay.io/projectquay/quay-builder:3.7.0-rc.2です。ただし、早期アクセス期間中に変更される可能性があります。これが発生した場合は、顧客に警告が表示されます。 - 6
K8S_API_SERVERは、oc cluster-infoを実行して取得します。- 7
- カスタム CA 証明書を手動で作成して追加する必要があります (例
K8S_API_TLS_CA: /conf/stack/extra_ca_certs/build_cluster.crt)。 - 8
- 指定しないと、デフォルトは
5120Miです。 - 9
- 仮想ビルドの場合は、クラスターに十分なリソースがあることを確認する必要があります。指定しないと、デフォルトは
1000mです。 - 10
- 指定しないと、デフォルトは
3968Miです。 - 11
- 指定しないと、デフォルトは
500mです。 - 12
oc create saの実行時に取得します。
設定サンプル
FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false FEATURE_QUOTA_MANAGEMENT: true FEATURE_BUILD_SUPPORT: True BUILDMAN_HOSTNAME: example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org:443 BUILD_MANAGER: - ephemeral - ALLOWED_WORKER_COUNT: 1 ORCHESTRATOR_PREFIX: buildman/production/ JOB_REGISTRATION_TIMEOUT: 3600 ORCHESTRATOR: REDIS_HOST: example-registry-quay-redis REDIS_PASSWORD: "" REDIS_SSL: false REDIS_SKIP_KEYSPACE_EVENT_SETUP: false EXECUTORS: - EXECUTOR: kubernetesPodman NAME: openshift BUILDER_NAMESPACE: virtual-builders SETUP_TIME: 180 MINIMUM_RETRY_THRESHOLD: 0 BUILDER_CONTAINER_IMAGE: quay.io/projectquay/quay-builder:3.7.0-rc.2 # Kubernetes resource options K8S_API_SERVER: api.docs.quayteam.org:6443 K8S_API_TLS_CA: /conf/stack/extra_ca_certs/build_cluster.crt VOLUME_SIZE: 8G KUBERNETES_DISTRIBUTION: openshift CONTAINER_MEMORY_LIMITS: 1G CONTAINER_CPU_LIMITS: 1080m CONTAINER_MEMORY_REQUEST: 1G CONTAINER_CPU_REQUEST: 580m NODE_SELECTOR_LABEL_KEY: "" NODE_SELECTOR_LABEL_VALUE: "" SERVICE_ACCOUNT_NAME: quay-builder SERVICE_ACCOUNT_TOKEN: "eyJhbGciOiJSUzI1NiIsImtpZCI6IldfQUJkaDVmb3ltTHZ0dGZMYjhIWnYxZTQzN2dJVEJxcDJscldSdEUtYWsifQ"
6.2.2.2. SSL/TLS 証明書の手動追加
設定ツールの既知の問題のため、ビルダーを適切に実行するには、カスタム SSL/TLS 証明書を手動で追加する必要があります。次の手順を使用して、カスタム SSL/TLS 証明書を手動で追加します。
SSL/TLS 証明書の作成の詳細は、Red Hat Quay コンテナーへの TLS 証明書の追加 を参照してください。
6.2.2.2.1. 証明書の作成と署名
SSL/TLS 証明書を作成して署名するには、次の手順を使用します。
手順
認証局を作成し、証明書に署名します。詳細は、認証局の作成と証明書への署名 を参照してください。
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 = example-registry-quay-quay-enterprise.apps.docs.quayteam.org 1 DNS.2 = example-registry-quay-builder-quay-enterprise.apps.docs.quayteam.org 2
サンプルコマンド
$ openssl genrsa -out rootCA.key 2048 $ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem $ openssl genrsa -out ssl.key 2048 $ openssl req -new -key ssl.key -out ssl.csr $ openssl x509 -req -in ssl.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out ssl.cert -days 356 -extensions v3_req -extfile openssl.cnf
6.2.2.2.2. TLS の管理対象外への設定
次の手順を使用して、king:tls を管理対象外に設定します。
手順
Red Hat Quay Registry YAML で、
kind: tlsをmanaged: falseに設定します。- kind: tls managed: falseEvents ページでは、適切な
config.yamlファイルを設定するまで変更がブロックされます。以下に例を示します。- lastTransitionTime: '2022-03-28T12:56:49Z' lastUpdateTime: '2022-03-28T12:56:49Z' message: >- required component `tls` marked as unmanaged, but `configBundleSecret` is missing necessary fields reason: ConfigInvalid status: 'True'
6.2.2.2.3. 一時的なシークレットの作成
次の手順を使用して、CA 証明書の一時的なシークレットを作成します。
手順
CA 証明書のデフォルトの namespace にシークレットを作成します。
$ oc create secret generic -n quay-enterprise temp-crt --from-file extra_ca_cert_build_cluster.crt
ssl.keyファイルおよびssl.certファイルのデフォルトの namespace にシークレットを作成します。$ oc create secret generic -n quay-enterprise quay-config-ssl --from-file ssl.cert --from-file ssl.key
6.2.2.2.4. シークレットデータの設定 YAML へのコピー
次の手順を使用して、シークレットデータを config.yaml ファイルにコピーします。
手順
- コンソール UI の Workloads → Secrets で新しいシークレットを見つけます。
シークレットごとに、YAML ビューを見つけます。
kind: Secret apiVersion: v1 metadata: name: temp-crt namespace: quay-enterprise uid: a4818adb-8e21-443a-a8db-f334ace9f6d0 resourceVersion: '9087855' creationTimestamp: '2022-03-28T13:05:30Z' ... data: extra_ca_cert_build_cluster.crt: >- LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURNakNDQWhxZ0F3SUJBZ0l.... type: Opaquekind: Secret apiVersion: v1 metadata: name: quay-config-ssl namespace: quay-enterprise uid: 4f5ae352-17d8-4e2d-89a2-143a3280783c resourceVersion: '9090567' creationTimestamp: '2022-03-28T13:10:34Z' ... data: ssl.cert: >- LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVaakNDQTA2Z0F3SUJBZ0lVT... ssl.key: >- LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcFFJQkFBS0NBUUVBc... type: OpaqueUI で Red Hat Quay レジストリー設定バンドルのシークレットを見つけるか、以下のようなコマンドを実行してコマンドラインから見つけます。
$ oc get quayregistries.quay.redhat.com -o jsonpath="{.items[0].spec.configBundleSecret}{'\n'}" -n quay-enterpriseOpenShift Container Platform コンソールで、設定バンドルのシークレットの YAML タブを選択し、作成した 2 つのシークレットからデータを追加します。
kind: Secret apiVersion: v1 metadata: name: init-config-bundle-secret namespace: quay-enterprise uid: 4724aca5-bff0-406a-9162-ccb1972a27c1 resourceVersion: '4383160' creationTimestamp: '2022-03-22T12:35:59Z' ... data: config.yaml: >- RkVBVFVSRV9VU0VSX0lOSVRJQUxJWkU6IHRydWUKQlJ... extra_ca_cert_build_cluster.crt: >- LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURNakNDQWhxZ0F3SUJBZ0ldw.... ssl.cert: >- LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVaakNDQTA2Z0F3SUJBZ0lVT... ssl.key: >- LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcFFJQkFBS0NBUUVBc... type: Opaque- Save をクリックします。
次のコマンドを入力して、Pod が再起動しているかどうかを確認します。
$ oc get pods -n quay-enterprise
出力例
NAME READY STATUS RESTARTS AGE ... example-registry-quay-app-6786987b99-vgg2v 0/1 ContainerCreating 0 2s example-registry-quay-app-7975d4889f-q7tvl 1/1 Running 0 5d21h example-registry-quay-app-7975d4889f-zn8bb 1/1 Running 0 5d21h example-registry-quay-app-upgrade-lswsn 0/1 Completed 0 6d1h example-registry-quay-config-editor-77847fc4f5-nsbbv 0/1 ContainerCreating 0 2s example-registry-quay-config-editor-c6c4d9ccd-2mwg2 1/1 Running 0 5d21h example-registry-quay-database-66969cd859-n2ssm 1/1 Running 0 6d1h example-registry-quay-mirror-764d7b68d9-jmlkk 1/1 Terminating 0 5d21h example-registry-quay-mirror-764d7b68d9-jqzwg 1/1 Terminating 0 5d21h example-registry-quay-redis-7cc5f6c977-956g8 1/1 Running 0 5d21h
Red Hat Quay レジストリーが再設定されたら、次のコマンドを入力して、Red Hat Quay アプリの Pod が実行されているかどうかを確認します。
$ oc get pods -n quay-enterprise
出力例
example-registry-quay-app-6786987b99-sz6kb 1/1 Running 0 7m45s example-registry-quay-app-6786987b99-vgg2v 1/1 Running 0 9m1s example-registry-quay-app-upgrade-lswsn 0/1 Completed 0 6d1h example-registry-quay-config-editor-77847fc4f5-nsbbv 1/1 Running 0 9m1s example-registry-quay-database-66969cd859-n2ssm 1/1 Running 0 6d1h example-registry-quay-mirror-758fc68ff7-5wxlp 1/1 Running 0 8m29s example-registry-quay-mirror-758fc68ff7-lbl82 1/1 Running 0 8m29s example-registry-quay-redis-7cc5f6c977-956g8 1/1 Running 0 5d21h
ブラウザーで、レジストリーエンドポイントにアクセスし、証明書が適切に更新されていることを確認します。以下に例を示します。
Common Name (CN) example-registry-quay-quay-enterprise.apps.docs.quayteam.org Organisation (O) DOCS Organisational Unit (OU) QUAY
6.2.2.3. UI を使用してビルドトリガーを作成
UI を使用してビルドトリガーを作成するには、次の手順に従います。
手順
- Red Hat Quay リポジトリーにログインします。
-
Create New Repository をクリックして、
testrepoなどの新しいレジストリーを作成します。 Repositories ページで、ナビゲーションペインの Builds タブをクリックします。または、対応する URL を直接使用します。
https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/repository/quayadmin/testrepo?tab=builds
重要場合によっては、ビルダーでホスト名の解決に問題が発生することがあります。この問題は、ジョブオブジェクトで
defaultに設定されているdnsPolicyに関連している可能性があります。現在、この問題に対する回避策はありません。これは、Red Hat Quay の将来のバージョンで解決される予定です。- Create Build Trigger → Custom Git Repository Push をクリックします。
Git リポジトリーのクローン作成に使用する HTTPS または SSH スタイルの URL を入力し、Continue をクリックします。以下に例を示します。
https://github.com/gabriel-rh/actions_test.git
- Tag manifest with the branch or tag name を確認し、Continue をクリックします。
-
トリガーが呼び出されたときにビルドする Dockerfile の場所 (たとえば
/Dockerfile) を入力し、Continue をクリックします。 -
Docker ビルドのコンテキストの場所 (たとえば
/) を入力し、Continue をクリックします。 - 必要に応じて、ロボットアカウントを作成します。それ以外の場合は、Continue をクリックします。
- Continue をクリックして、パラメーターを確認します。
- Builds ページで、トリガー名の Options アイコンをクリックし、Run Trigger Now をクリックします。
- Git リポジトリーからコミット SHA を入力し、Start Build をクリックします。
ビルドのステータスを確認するには、Build History ページで commit をクリックするか、
oc get pods -n virtual-buildersを実行します。以下に例を示します。$ oc get pods -n virtual-builders
出力例
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Running 0 7s
$ oc get pods -n virtual-builders
出力例
NAME READY STATUS RESTARTS AGE f192fe4a-c802-4275-bcce-d2031e635126-9l2b5-25lg2 1/1 Terminating 0 9s
$ oc get pods -n virtual-builders
出力例
No resources found in virtual-builders namespace.
ビルドが完了したら、ナビゲーションペインのタグで Tags のステータスを確認できます。
注記早期アクセスにより、完全なビルドログとビルドのタイムスタンプは現在利用できません。
6.2.2.4. AWS S3 ストレージバケットの変更
AWS S3 ストレージを使用している場合は、ビルダーを実行する前に、AWS コンソールでストレージバケットを変更する必要があります。
手順
- s3.console.aws.com で AWS コンソールにログインします。
-
検索バーで
S3を検索し、S3 をクリックします。 -
バケットの名前 (
myawsbucketなど) をクリックします。 - Permissions タブをクリックします。
Cross-origin resource sharing (CORS) の下に、次のパラメーターを含めます。
[ { "AllowedHeaders": [ "Authorization" ], "AllowedMethods": [ "GET" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [], "MaxAgeSeconds": 3000 }, { "AllowedHeaders": [ "Content-Type", "x-amz-acl", "origin" ], "AllowedMethods": [ "PUT" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [], "MaxAgeSeconds": 3000 } ]
6.2.2.5. Google Cloud Platform オブジェクトバケットの変更
仮想ビルダーの Cross Origin Resource Sharing (CORS) を設定するには、次の手順を使用します。
CORS 設定がないと、ビルド Dockerfile のアップロードは失敗します。
手順
次のリファレンスを使用して、特定の CORS ニーズに合わせた JSON ファイルを作成します。以下に例を示します。
$ cat gcp_cors.json
出力例
[ { "origin": ["*"], "method": ["GET"], "responseHeader": ["Authorization"], "maxAgeSeconds": 3600 }, { "origin": ["*"], "method": ["PUT"], "responseHeader": [ "Content-Type", "x-goog-acl", "origin"], "maxAgeSeconds": 3600 } ]次のコマンドを入力して、GCP ストレージバケットを更新します。
$ gcloud storage buckets update gs://<bucket_name> --cors-file=./gcp_cors.json
出力例
Updating Completed 1
次のコマンドを実行すると、GCP バケットの更新された CORS 設定を表示できます。
$ gcloud storage buckets describe gs://<bucket_name> --format="default(cors)"
出力例
cors: - maxAgeSeconds: 3600 method: - GET origin: - '*' responseHeader: - Authorization - maxAgeSeconds: 3600 method: - PUT origin: - '*' responseHeader: - Content-Type - x-goog-acl - origin
第7章 Geo レプリケーション
Geo レプリケーションでは、地理的に分散した複数の Red Hat Quay デプロイメントを、クライアントやユーザーの視点から、単一のレジストリーとして動作させることができます。グローバルに分散された Red Hat Quay のセットアップにおいて、プッシュとプルのパフォーマンスが大幅に向上します。イメージデータはバックグラウンドで非同期的に複製され、クライアントには透過的なフェイルオーバー/リダイレクトが行われます。
Geo レプリケーションを使用した Red Hat Quay のデプロイメントは、スタンドアロンおよび Operator デプロイメントでサポートされます。
7.1. Geo レプリケーション機能
- Geo レプリケーションが設定されると、コンテナーイメージのプッシュはその Red Hat Quay インスタンスの優先ストレージエンジンに書き込まれます。これは通常、リージョン内で最も近いストレージバックエンドです。
- 最初のプッシュの後、イメージデータはバックグランドで他のストレージエンジンに複製されます。
- レプリケーションロケーションのリストは設定可能で、それらは異なるストレージバックエンドにできます。
- イメージプルでは、プルのパフォーマンスを最大化するために、常に利用可能な最も近いストレージエンジンを使用します。
- レプリケーションがまだ完了していない場合、プルでは代わりにソースストレージバックエンドが使用されます。
7.2. Geo レプリケーションの要件と制約
- geo レプリケーション設定では、Red Hat Quay で、すべてのリージョンが他の全リージョンのオブジェクトストレージに対して読み取りと書き込みができるようにする必要があります。オブジェクトストレージは、他のすべてのリージョンから地理的にアクセスできる必要があります。
- 1 つの geo レプリケーションサイトでオブジェクトストレージシステムに障害が発生した場合に、そのサイトの Red Hat Quay デプロイメントをシャットダウンして、クライアントがグローバルロードバランサーにより、ストレージシステムで問題のない残りのサイトにリダイレクトされるようにする必要があります。そうしないと、クライアントでプルとプッシュの失敗が発生します。
- Red Hat Quay は、接続されたオブジェクトストレージシステムの内部の正常性または可用性に関する認識はありません。1 つのサイトのオブジェクトストレージシステムが利用できなくなった場合に、残りのサイトの残りのストレージシステム (複数可) に自動的にリダイレクトされません。
- Geo レプリケーションは非同期です。サイトが完全に失われると、そのサイトのオブジェクトストレージシステムに保存されていても、障害発生時に残りのサイトに複製されていないデータが失われます。
単一のデータベース、つまりすべてのメタデータと Red Hat Quay 設定がすべてのリージョンで共有されます。
Geo レプリケーションはデータベースをレプリケートしません。障害が発生すると、Geo レプリケーションが有効になっている Red Hat Quay は別のデータベースにフェイルオーバーしません。
- 1 つの Redis キャッシュは Red Hat Quay のセットアップ全体で共有され、すべての Red Hat Quay Pod からアクセスできる必要があります。
-
ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、
QUAY_DISTRIBUTED_STORAGE_PREFERENCE環境変数を使用して明示的に設定できます。 - Geo レプリケーションでは、各リージョンにオブジェクトストレージが必要です。ローカルストレージでは機能しません。
- 各リージョンは、ネットワークパスを必要とする各リージョン内のすべてのストレージエンジンにアクセスできる必要があります。
- また、ストレージプロキシーオプションを使用することもできます。
- ストレージバックエンド全体 (たとえば、すべての BLOB) がレプリケートされます。対照的に、リポジトリーミラーリングはリポジトリーまたはイメージに限定できます。
- すべての Red Hat Quay インスタンスは、通常はロードバランサーを介して同じエントリーポイントを共有する必要があります。
- すべての Red Hat Quay インスタンスは、共通の設定ファイル内で定義されているため、スーパーユーザーの同じセットが含まれる必要があります。
-
Geo レプリケーションでは、Clair 設定を
unmanagedに設定する必要があります。アンマネージド Clair データベースにより、Red Hat Quay は geo-replicated environment で作業できます。この環境では、Red Hat Quay Operator の複数のインスタンスが同じデータベースと通信する必要があります。詳細は、Clair の詳細設定 を参照してください。 - Geo レプリケーションには SSL/TLS 証明書とキーが必要です。詳細は、Red Hat Quay への接続を保護するための SSL/TSL の使用 を参照してください。
上記の要件を満たすことができない場合は、代わりに 2 つ以上の異なる Red Hat Quay のデプロイメントを使用し、リポジトリーミラーリング機能を利用する必要があります。
7.2.1. OpenShift Container Platform での Geo レプリケーションのセットアップ
OpenShift Container Platform で Geo レプリケーションを設定するには、次の手順を実行します。
手順
- Red Hat Quay の postgres インスタンスをデプロイします。
次のコマンドを入力してデータベースにログインします。
psql -U <username> -h <hostname> -p <port> -d <database_name>
quayという名前で Red Hat Quay のデータベースを作成します。以下に例を示します。CREATE DATABASE quay;
データベース内で pg_trm 拡張機能を有効にします。
\c quay; CREATE EXTENSION IF NOT EXISTS pg_trgm;
Redis インスタンスをデプロイします。
注記- クラウドプロバイダーに独自のサービスが含まれている場合は、Redis インスタンスをデプロイする必要がない可能性があります。
- Builder を利用している場合は、Redis インスタンスをデプロイする必要があります。
- Redis 用の VM をデプロイします。
- Red Hat Quay が実行されているクラスターからアクセスできることを確認します。
- ポート 6379/TCP が開いている必要があります。
インスタンス内で Redis を実行します。
sudo dnf install -y podman podman run -d --name redis -p 6379:6379 redis
- クラスターごとに 1 つずつ、2 つのオブジェクトストレージバックエンドを作成します。1 つのオブジェクトストレージバケットが最初のクラスター (プライマリークラスター) の近くにあり、もう 1 つが 2 番目のクラスター (セカンダリークラスター) の近くにあると理想的です。
- 環境変数のオーバーライドを使用して、同じ設定バンドルでクラスターをデプロイし、個々のクラスターに適切なストレージバックエンドを選択します。
- クラスターへの単一のエントリーポイントを提供するように、ロードバランサーを設定します。
7.2.1.1. OpenShift Container Platform 上の Red Hat Quay Operator での Geo レプリケーションの設定
Red Hat Quay Operator の Geo レプリケーションを設定するには、次の手順を実行します。
手順
クラスター間で共有される
config.yamlファイルを作成します。このconfig.yamlファイルには、一般的な PostgreSQL、Redis、ストレージバックエンドの詳細が含まれています。Geo レプリケーションの
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 Container Platform Operator を使用してデプロイされた Clair インスタンスの設定ファイルを取得するには、Clair 設定の取得 を参照してください。
次のコマンドを入力して、
configBundleSecretを作成します。$ oc create secret generic --from-file config.yaml=./config.yaml georep-config-bundle
各クラスターで、
configBundleSecretを設定し、QUAY_DISTRIBUTED_STORAGE_PREFERENCE環境変数のオーバーライドを使用して、そのクラスターに適切なストレージを設定します。以下に例を示します。注記両方のデプロイメント間の
config.yamlファイルは一致する必要があります。一方のクラスターに変更を加える場合は、もう一方のクラスターでも変更する必要があります。US クラスター
QuayRegistryの例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注記SSL/TLS は管理されておらず、ルートは管理されているため、設定ツールを使用するか、設定バンドルで直接、証明書を提供する必要があります。詳細は、TLS およびルートの設定 を参照してください。
ヨーロッパのクラスター
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注記SSL/TLS は管理されておらず、ルートは管理されているため、設定ツールを使用するか、設定バンドルで直接、証明書を提供する必要があります。詳細は、TLS およびルートの設定 を参照してください。
7.2.2. Geo レプリケーションのための複合ストレージ
Red Hat Quay の Geo レプリケーションは、異なる複数のレプリケーションターゲットの使用をサポートしています。たとえば、パブリッククラウドの AWS S3 ストレージとオンプレミスの Ceph ストレージを使用します。これは、すべての Red Hat Quay Pod とクラスターノードからすべてのストレージバックエンドへのアクセスを許可するという重要な要件を複雑にします。そのため、以下を使用することを推奨します。
- 内部ストレージの可視性を防ぐための VPN、または
- Red Hat Quay が使用する特定のバケットへのアクセスのみを許可するトークンペア
これにより、Red Hat Quay のパブリッククラウドインスタンスがオンプレミスのストレージにアクセスできるようになりますが、ネットワークは暗号化され、保護され、ACL を使用するため、セキュリティー要件が満たされます。
これらのセキュリティー対策を実施できない場合は、2 つの異なる Red Hat Quay レジストリーをデプロイし、Geo レプリケーションの代わりにリポジトリーミラーリングを使用することが推奨されます。
7.3. Red Hat Quay Operator の geo レプリケーションデプロイメントのアップグレード
geo レプリケーションされた Red Hat Quay Operator をアップグレードするには、次の手順を使用します。
- geo レプリケーションされた Red Hat Quay Operator デプロイメントを次の y-stream リリース (例: Red Hat Quay 3.7 → Red Hat Quay 3.8) にアップグレードする場合は、アップグレードを行う前に操作を停止する必要があります。
- y-stream リリースを次のリリースにアップグレードする場合は、アップグレード中にダウンタイムが断続的に発生します。
- アップグレードを行う前に、Red Hat Quay Operator デプロイメントをバックアップすることが強く推奨されます。
この手順では、Red Hat Quay Operator を 3 つ (以上) のシステムで実行していることを前提とします。この手順では、System A、System B、および System C という名前の 3 つのシステムを想定します。System A は、Red Hat Quay Operator がデプロイされるプライマリーシステムとして機能します。
System B および System C で、Red Hat Quay Operator デプロイメントをスケールダウンします。これを行うには、自動スケーリングを無効にし、Red Hat Quay、ミラーワーカー、および Clair (マネージドの場合) のレプリカ数をオーバーライドします。次の
quayregistry.yamlファイルを参照として使用します。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 …注記Red Hat Quay Operator がシステム A で実行されている状態を維持する必要があります。システム A の
quayregistry.yamlファイルは更新しないでください。registry-quay-app、registry-quay-mirror、およびregistry-clair-appPod が消えるまで待機します。以下のコマンドを入力してステータスを確認します。oc get pods -n <quay-namespace>
出力例
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-redis-84f888776f-hhgms 1/1 Running 0 12m
- システム A で、Red Hat Quay Operator を最新の y-stream バージョンにアップグレードします。これは手動プロセスです。インストールされた Operator のアップグレードの詳細は、インストールされた Operator のアップグレード を参照してください。Red Hat Quay アップグレードパスの詳細は、Red Hat Quay Operator のアップグレード を参照してください。
-
新規の Red Hat Quay Operator のインストール後に、クラスターに必要なアップグレードは自動的に完了します。その後、新しい Red Hat Quay Pod は、最新の y-stream バージョンで起動します。さらに、新しい
QuayPod がスケジュールされ、起動します。 Red Hat Quay UI に移動して、更新が適切に機能していることを確認します。
OpenShift コンソールで Operators → Installed Operators に移動し、Registry Endpoint リンクをクリックします。
重要Red Hat Quay UI が利用可能になるまで、次の手順を実行しないでください。システム A で UI が利用可能になるまで、システム B およびシステム C で Red Hat Quay Operator をアップグレードしないでください。
更新が System A で適切に機能していることを確認した後に、System B および System C で Red Hat Quay Operator を開始します。Operator のアップグレードにより、Red Hat Quay インストールがアップグレードされ、Pod が再起動されます。
注記データベーススキーマは新しい y-stream インストールに適しているため、System B および System C の新しい Pod がすぐに起動します。
7.3.1. Red Hat Quay Operator デプロイメントから geo レプリケートされたサイトを削除する
以下の手順を使用すると、Red Hat Quay 管理者は geo レプリケートされたセットアップ内のサイトを削除できます。
前提条件
- OpenShift Container Platform にログインしている。
-
少なくとも 2 つのサイト (例:
usstorageとeustorage) を使用して Red Hat Quay geo レプリケーションを設定している。 - 各サイトに、独自の組織、リポジトリー、およびイメージタグがある。
手順
次のコマンドを実行して、定義されたすべてのサイト間で BLOB を同期します。
$ python -m util.backfillreplication
警告Red Hat Quay
config.yamlファイルからストレージエンジンを削除する前に、定義されているすべてのサイト間ですべての BLOB が同期されていることを確認する 必要があります。続行する前に、この手順を完了してください。-
サイト
usstorageの Red Hat Quayconfig.yamlファイルで、eustorageサイトのDISTRIBUTED_STORAGE_CONFIGエントリーを削除します。 次のコマンドを入力して、
Quayアプリケーション Pod を識別します。$ oc get pod -n <quay_namespace>
出力例
quay390usstorage-quay-app-5779ddc886-2drh2 quay390eustorage-quay-app-66969cd859-n2ssm
以下のコマンドを入力して、
usstoragePod でインタラクティブシェルセッションを開きます。$ oc rsh quay390usstorage-quay-app-5779ddc886-2drh2
次のコマンドを入力して、
eustorageサイトを完全に削除します。重要次の操作は元に戻すことができません。注意して使用してください。
sh-4.4$ python -m util.removelocation eustorage
出力例
WARNING: This is a destructive operation. Are you sure you want to remove eustorage from your storage locations? [y/n] y Deleted placement 30 Deleted placement 31 Deleted placement 32 Deleted placement 33 Deleted location eustorage
第8章 Red Hat Quay Operator によって管理される Red Hat Quay のバックアップおよび復元
OpenShift Container Platform で Red Hat Quay Operator によって管理される場合、このセクション内のコンテンツを使用して Red Hat Quay をバックアップおよび復元します。
8.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 以降で開始)。
デプロイメントに部分的に管理されていないデータベースまたはストレージコンポーネントが含まれ、PostgreSQL または S3 互換オブジェクトストレージの外部サービスを使用している場合、Red Hat Quay デプロイメントを実行するには、サービスプロバイダーまたはベンダーのドキュメントを参照してデータのバックアップを作成してください。このガイドで説明されているツールは、外部 PostgreSQL データベースまたはオブジェクトストレージのバックアップの開始点として参照できます。
8.1.1. Red Hat Quay 設定のバックアップ
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 より前のバージョンを実行している場合は、この手順を省略できます。一部のシークレットは Red Hat 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.yamlQuayPod 内にマウントされた/conf/stack/config.yamlファイルをバックアップします。$ oc exec -it quay_pod_name -- cat /conf/stack/config.yaml > quay_config.yaml
8.1.2. Red Hat Quay デプロイメントのスケールダウン
Red Hat Quay デプロイメントをスケールダウンするには、次の手順を実行します。
この手順は、Red Hat Quay デプロイメントの状態の整合性のあるバックアップを作成するために必要になります。PostgreSQL データベースや S3 互換オブジェクトストレージが外部サービスによって提供されるセットアップ (Red Hat Quay Operator で管理されない) を含め、この手順を省略しないでください。
手順
Red Hat Quay デプロイメントのバージョンに応じて、次のいずれかのオプションを使用してデプロイメントをスケールダウンします。
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-appPod (どのコンポーネントを 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
8.1.3. Red Hat Quay マネージドデータベースのバックアップ
Red Hat Quay マネージドデータベースをバックアップするには、次の手順を実行します。
Red Hat Quay デプロイメントが外部のアンマネージド PostgreSQL データベースで設定されている場合は、これらのデータベースの一貫したバックアップを作成する方法についてベンダーのドキュメントを参照してください。
手順
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
8.1.3.1. Red Hat Quay マネージドオブジェクトストレージのバックアップ
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)新しいディレクトリーを作成します。
$ mkdir blobs
次のコマンドを入力して、すべての Blob をディレクトリーにコピーします。
$ 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
8.1.4. Red Hat Quay デプロイメントのバックアップのスケーリング
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
8.2. Red Hat Quay の復元
Red Hat Quay オペレーターがデータベースを管理している場合は、次の手順を使用して 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 デプロイメントを実行していない。
デプロイメントに部分的に管理されていないデータベースまたはストレージコンポーネントが含まれ、PostgreSQL または S3 互換オブジェクトストレージの外部サービスを使用している場合、Red Hat Quay デプロイメントを実行するには、サービスプロバイダーまたはベンダーのドキュメントを参照して、Red Hat Quay を復元する前にバックアップからデータを復元してください。
8.2.1. バックアップからの Red Hat Quay およびその設定の復元
Red Hat Quay とその設定ファイルをバックアップから復元するには、次の手順を実行します。
これらの手順では、Red Hat Quay のバックアップ ガイドのプロセスに従い、同じ名前のバックアップファイルを作成していることを前提としています。
手順
次のコマンドを入力して、バックアップされた Red Hat Quay 設定を復元します。
$ oc create -f ./config-bundle.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で再作成する必要があります。次のコマンドを入力して、生成されたキーをバックアップから復元します。
$ oc create -f ./managed-secret-keys.yaml
QuayRegistryカスタムリソースを復元します。$ oc create -f ./quay-registry.yaml
Red Hat Quay デプロイメントのステータスを確認し、これが利用可能になるまで待機します。
$ oc wait quayregistry registry --for=condition=Available=true -n <quay-namespace>
8.2.2. Red Hat Quay デプロイメントのスケールダウン
Red Hat Quay デプロイメントをスケールダウンするには、次の手順を実行します。
手順
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-appPod (どのコンポーネントを Red Hat Quay 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
8.2.3. Red Hat Quay データベースの復元
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
8.2.4. Red Hat Quay オブジェクトストレージデータの復元
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}')
8.2.5. Red Hat Quay デプロイメントのスケールアップ
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
第9章 Red Hat Quay Operator による OCI サポートの有効化
Red Hat Quay の Open Container Initiative (OCI) サポートを設定するには、次の手順を実行します。
手順
次の情報を含む
quay-config-bundleYAML ファイルを作成します。apiVersion: v1 stringData: config.yaml: | FEATURE_GENERAL_OCI_SUPPORT: true kind: Secret metadata: name: quay-config-bundle namespace: quay-enterprise type: Opaque次のコマンドを入力して、適切な名前空間に
quay-config-bundleオブジェクトを作成し、OCI サポートを有効にするために必要なプロパティーを渡します。以下に例を示します。$ oc create -n quay-enterprise -f quay-config-bundle.yaml
quay-registry.yamlファイルで、spec.configBundleSecretフィールドのシークレットを参照します。以下に例を示します。apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: quay-config-bundle
関連情報
詳細は、OCI サポートと Red Hat Quay を参照してください。
第10章 ボリュームサイズのオーバーライド
マネージドコンポーネントにプロビジョニングされるストレージリソースの希望のサイズを指定できます。Clair および PostgreSQL データベースのデフォルトサイズは 50Gi です。パフォーマンス上の理由がある場合や、ストレージバックエンドにサイズ変更機能がない場合など、十分な容量を事前に選択できるようになりました。
以下の例では、Clair および Quay PostgreSQL データベースのボリュームサイズは 70Gi に設定されています。
apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
name: quay-example
namespace: quay-enterprise
spec:
configBundleSecret: config-bundle-secret
components:
- kind: objectstorage
managed: false
- kind: route
managed: true
- kind: tls
managed: false
- kind: clair
managed: true
overrides:
volumeSize: 70Gi
- kind: postgres
managed: true
overrides:
volumeSize: 70Gi
- kind: clairpostgres
managed: true
clairpostgres コンポーネントのボリュームサイズはオーバーライドできません。これは既知の問題であり、Red Hat Quay の将来のバージョンで修正される予定です。(PROJQUAY-4301)
第11章 コンテナーセキュリティー 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 ボタンを選択します。
11.1. OpenShift Container Platform での Container Security Operator のダウンロードおよび実行
Container Security Operator (CSO) をダウンロードするには、次の手順を使用します。
次の手順では、CSO を marketplace-operators namespace にインストールします。これにより、OpenShift Container Platform クラスターのすべての namespace で CSO を使用できるようになります。
手順
- OpenShift Container Platform コンソールページで、Operators → OperatorHub を選択し、Container Security Operator を検索します。
- Container Security Operator を選択し、Install を選択して Create Operator Subscription ページに移動します。
- 設定 (デフォルトでは、すべての名前空間と自動承認戦略) を確認し、Subcription を選択します。しばらくすると、Installed Operators 画面に Container Security が表示されます。
オプション: カスタム証明書を CSO に追加できます。以下の例では、現在のディレクトリーに
quay.crtという名前の証明書を作成します。次に、次のコマンドを実行して証明書を CSO に追加します。$ oc create secret generic container-security-operator-extra-certs --from-file=quay.crt -n openshift-operators
注記新しい証明書を有効にするには、Operator Pod を再起動する必要があります。
Home → Dashboard に移動します。Image Security へのリンクが status セクションに表示され、これまでに見つかった脆弱性の数の一覧が表示されます。次の図に示すように、リンクを選択するとセキュリティーの内訳が表示されます。
重要Container Security Operator は現在、Red Hat セキュリティーアドバイザリーの壊れたリンクを提供しています。たとえば、リンク
https://access.redhat.com/errata/RHSA-2023:1842%20https://access.redhat.com/security/cve/CVE-2023-23916が提供される場合があります。URL 内の%20はスペース文字を表しますが、現時点では 2 つの URL が 1 つの不完全な URL に結合されます (例:https://access.redhat.com/errata/RHSA-2023:1842とhttps://access.redhat.com/security/cve/CVE-2023-23916。一時的な回避策として、各 URL をブラウザーにコピーして、適切なページに移動できます。これは既知の問題であり、Red Hat Quay の今後のバージョンで修正される予定です。この時点で、検出された脆弱性をフォローするために以下の 2 つのいずれかの操作を実行できます。
脆弱性へのリンクを選択します。コンテナーのレジストリー、Red Hat Quay、またはコンテナーを取得したその他のレジストリーに移動し、脆弱性に関する情報が表示されます。以下の図は、Quay.io レジストリーから検出された脆弱性の例を示しています。
namespaces リンクを選択し、ImageManifestVuln 画面に移動します。ここでは、選択されたイメージの名前、およびイメージが実行されているすべての namespace を確認できます。以下の図は、特定の脆弱なイメージが 2 つの namespace で実行されていることを示しています。
この手順を実行すると、どのイメージに脆弱性があるか、それらの脆弱性を修正するために何をしなければならないか、およびイメージが実行されたすべての名前空間がわかります。これを知っていると、次のアクションを実行できます。
- イメージを実行しているユーザーに、脆弱性を修正する必要があることを警告します。
デプロイメント、またはイメージが含まれる Pod を開始したオブジェクトを削除して、イメージの実行を停止します。
注記Pod を削除した場合、ダッシュボードで脆弱性がリセットされるまでに数分かかる場合があります。
11.2. CLI からイメージの脆弱性を問い合わせ
コマンドラインインターフェイス (CLI) からイメージの脆弱性をクエリーするには、次の手順を使用します。
手順
次のコマンドを入力して、検出された脆弱性をクエリーします。
$ oc get vuln --all-namespaces
出力例
NAMESPACE NAME AGE default sha256.ca90... 6m56s skynet sha256.ca90... 9m37s
オプション。特定の脆弱性の詳細を表示するには、特定の脆弱性とその名前空間を特定し、
oc descriptionコマンドを使用します。以下の例は、イメージに脆弱性のある 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...
第12章 Red Hat Quay Operator への IPv6 のデプロイ
Red Hat Quay Operator デプロイメントは、Telco や Edge 環境など、IPv6 のみをサポートする場所で提供できるようになりました。
既知の制限のリストは、IPv6 の制限 を参照してください。
12.1. IPv6 プロトコルファミリーの有効化
以下の手順を使用して、スタンドアロンの Red Hat Quay デプロイメントで IPv6 サポートを有効にします。
前提条件
- Red Hat Quay を 3.8 に更新している。
- ホストとコンテナーソフトウェアプラットフォーム (Docker、Podman) を、IPv6 をサポートするように設定している。
手順
デプロイメントの
config.yamlファイルにFEATURE_LISTEN_IP_VERSIONパラメーターを追加し、IPv6に設定します。次に例を示します。--- FEATURE_GOOGLE_LOGIN: false FEATURE_INVITE_ONLY_USER_CREATION: false FEATURE_LISTEN_IP_VERSION: IPv6 FEATURE_MAILING: false FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP: false ---
- Red Hat Quay デプロイメントを起動または再起動します。
次のコマンドを入力して、デプロイが IPv6 をリッスンしていることを確認します。
$ curl <quay_endpoint>/health/instance {"data":{"services":{"auth":true,"database":true,"disk_space":true,"registry_gunicorn":true,"service_key":true,"web_gunicorn":true}},"status_code":200}
デプロイメントの config.yaml で IPv6 を有効にすると、環境が IPv6 を使用するように設定され、IPv6 およびデュアルスタックの制限 によって妨げられない限り、Red Hat Quay のすべての機能を通常どおり使用できます。
環境が IPv4 に設定されていても、FEATURE_LISTEN_IP_VERSION 設定フィールドが IPv6 に設定されていると、Red Hat Quay はデプロイに失敗します。
12.2. IPv6 の制限
現在、一般的な Microsoft Azure Blob Storage 設定を使用して Red Hat Quay デプロイメントを設定しようとしても、IPv6 シングルスタック環境では機能しません。Microsoft Azure Blob Storage のエンドポイントは IPv6 をサポートしていないため、この問題に対する回避策はありません。
詳細は、PROJQUAY-4433 を参照してください。
現在、Amazon S3 CloudFront を使用して Red Hat Quay デプロイメントを設定しようとしても、IPv6 シングルスタック環境では機能しません。Amazon S3 CloudFront のエンドポイントは IPv6 をサポートしていないため、この問題に対する回避策はありません。
詳細は、PROJQUAY-4470 を参照してください。
- 現在、Red Hat Quay が IPv6 シングルスタック環境にデプロイされている場合、Red Hat OpenShift Data Foundations はサポートされません。そのため、Red Hat OpenShift Data Foundation は IPv6 環境で使用できません。この制限は、OpenShift Data Foundations の今後のバージョンで修正される予定です。
- 現在、デュアルスタック (IPv4 および IPv6) のサポートは、Red Hat Quay OpenShift Container Platform デプロイメントでは機能しません。Red Hat Quay 3.8 が OpenShift Container Platform にデプロイされ、デュアルスタックサポートが有効になっている場合は、Red Hat Quay Operator によって生成される Quay Route が IPv4 アドレスのみを生成し、IPv6 アドレスは生成されません。その結果、IPv6 アドレスを持つクライアントは、OpenShift Container Platform 上の Red Hat Quay アプリケーションにアクセスできません。この制限は、OpenShift Container Platform の今後のバージョンで修正される予定です。
第13章 Red Hat Quay が Kubernetes にデプロイされている場合のカスタム SSL/TLS 証明書の追加
Kubernetes にデプロイすると、Red Hat Quay は config アセットを保存するボリュームとしてシークレットにマウントします。現在、これによりスーパーユーザーパネルの証明書のアップロード機能が中断されます。
一時的な回避策として、Red Hat Quay の デプロイ後 に、base64 でエンコードされた証明書をシークレットに追加できます。
Red Hat Quay が Kubernetes にデプロイされている場合は、次の手順を使用してカスタム SSL/TLS 証明書を追加します。
前提条件
- Red Hat Quay がデプロイされている。
-
カスタムの
ca.crtファイルがある。
手順
次のコマンドを入力して、SSL/TLS 証明書の内容を Base64 でエンコードします。
$ 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=
kubectl deleteコマンドを使用して、すべての Red Hat Quay Pod を削除します。以下に例を示します。$ kubectl delete pod quay-operator.v3.7.1-6f9d859bd-p5ftc quayregistry-clair-postgres-7487f5bd86-xnxpr quayregistry-quay-app-upgrade-xq2v6 quayregistry-quay-config-editor-6dfdcfc44f-hlvwm quayregistry-quay-database-859d5445ff-cqthr quayregistry-quay-redis-84f888776f-hhgms
その後、Red Hat Quay デプロイメントにより、Pod を新しい証明書データに置き換えるスケジュールが自動的に設定されます。
第14章 Red Hat Quay Operator のアップグレードの概要
Red Hat Quay Operator は、シンクロナイズドバージョニング スキームに従います。つまり、Red Hat Operator の各バージョンは Quay とその管理するコンポーネントに関連付けられます。QuayRegistry カスタムリソースには、Red Hat Quay が deploy するバージョンを設定するフィールドはありません。Operator は、すべてのコンポーネントを 1 つのバージョンのみデプロイできます。このスキームは、すべてのコンポーネントが適切に連携し、Kubernetes で Red Hat Quay の多数に渡るバージョンのライフサイクルを管理する方法を把握する必要がある Operator の複雑性を軽減するために、選択されました。
14.1. Operator Lifecycle Manager
Red Hat Quay Operator は 、Operator Lifecycle Manager (OLM) を使用してインストールおよびアップグレードする必要があります。デフォルトの approvalStrategy: Automatic で Subscription を作成する場合、OLM は新規バージョンが利用可能になると常に Red Hat Quay Operator を自動的にアップグレードします。
Red Hat Quay Operator が Operator Lifecycle Manager によってインストールされている場合、自動または手動のアップグレードをサポートするように設定されていることがあります。このオプションは、インストール時に Red Hat Quay Operator の Operator Hub ページに表示されます。これは、Red Hat Quay Operator Subscription オブジェクトの ApprovalStrategy フィールドでも確認できます。Automatic を選択すると、新規 Operator バージョンがリリースされるたびに Red Hat Quay Operator が自動的にアップグレードされます。これが望ましくない場合は、Manual 承認ストラテジーを選択する必要があります。
14.2. Quay Operator のアップグレード
インストールされた Operator を OpenShift Container Platform にアップグレードする一般的な方法については、インストールされた Operator のアップグレード を参照してください。
一般的に、Red Hat Quay は以前の (N-1) マイナーバージョンからのアップグレードのみをサポートしています。たとえば、Red Hat Quay 3.0.5 から最新バージョンの 3.5 への直接アップグレードはサポートされていません。代わりに、次のようにアップグレードする必要があります。
- 3.0.5 → 3.1.3
- 3.1.3 → 3.2.2
- 3.2.2 → 3.3.4
- 3.3.4 → 3.4.z
- 3.4.z → 3.5.z
この作業は、必要なデータベースの移行が正しく実行され、適切な順序でアップグレードが行われるようにするために必要です。
場合によっては、Red Hat Quay は、以前の (N-2、N-3) マイナーバージョンからの直接のシングルステップアップグレードをサポートします。これにより、古いリリースを使用している顧客のアップグレード手順が簡素化されます。次のアップグレードパスがサポートされています。
- 3.3.z → 3.6.z
- 3.4.z → 3.6.z
- 3.4.z → 3.7.z
- 3.5.z → 3.7.z
- 3.7.z → 3.8.z
- 3.6.z → 3.9.z
- 3.7.z → 3.9.z
- 3.8.z → 3.9.z
Red Hat Quay のスタンドアロンデプロイメントを使用しているユーザーが 3.9 にアップグレードしたい場合は、スタンドアロンアップグレード ガイドを参照してください。
14.2.1. Quay のアップグレード
Red Hat Quay をあるマイナーバージョンから次のマイナーバージョン (たとえば、3.4 → 3.5) に更新するには、Red Hat Quay Operator の更新チャネルを変更する必要があります。
3.4.2 → 3.4.3 などの z ストリームのアップグレードの場合、更新は、ユーザーが最初にインストール時に選択した major-minor チャネルでリリースされます。z ストリームのアップグレードを実行する手順は、上記のように approvalStrategy によって異なります。承認ストラテジーが Automatic に設定されている場合、Quay Operator は自動的に最新の z ストリームにアップグレードします。これにより、ダウンタイムがほとんどない (またはまったくない) 新しい z ストリームへの Quay の自動更新が行われます。それ以外の場合は、インストールを開始する前に更新を手動で承認する必要があります。
14.2.2. Red Hat Quay を 3.8 → 3.9 に更新する
Red Hat Quay デプロイメントを 1 つの y ストリームから次の y ストリームにアップグレードする場合 (たとえば、3.8.10 → 3.8.11 に)、アップグレードチャネルを stable-3.8 から stable-3.9 に切り替えないでください。y-stream アップグレードの途中でアップグレードチャネルを変更すると、Red Hat Quay を 3.9 にアップグレードできなくなります。これは既知の問題であり、Red Hat Quay の今後のバージョンで修正される予定です。
Red Hat Quay 3.8 → 3.9 に更新すると、Operator は Clair および Red Hat Quay の既存の PostgreSQL データベースをバージョン 10 からバージョン 13 に自動的にアップグレードします。
- このアップグレードは元に戻すことができません。PostgreSQL 13 にアップグレードすることが強く推奨されます。PostgreSQL 10 は 2022 年 11 月 10 日に最終リリースとなり、サポートされなくなりました。詳細は、PostgreSQL のバージョン管理ポリシー を参照してください。
-
デフォルトでは、Red Hat Quay は PostgreSQL 10 から古い Persistent Volume Claim (PVC) を削除するように設定されています。この設定を無効にして古い PVC をバックアップするには、
quay-operatorサSubscriptionオブジェクトでPOSTGRES_UPGRADE_RETAIN_BACKUPをTrueに設定する必要があります。
前提条件
- OpenShift Container Platform に Red Hat Quay 3.8 がインストールされている。
100 GB の空き容量、追加のストレージ。
アップグレードプロセス中に、移行されたデータを保存するために追加の永続ボリュームクレーム (PVC) がプロビジョニングされる。これにより、ユーザーデータに対する破壊的な操作を防ぐことが可能。アップグレードプロセスでは、Red Hat Quay データベースのアップグレードと Clair データベースのアップグレードの両方で、50 GB の PVC をロールアウト。
手順
オプション:
quay-operatorSubscriptionオブジェクトのPOSTGRES_UPGRADE_RETAIN_BACKUPをTrueに設定して、PostgreSQL 10 から古い PVC をバックアップします。以下に例を示します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: quay-operator namespace: quay-enterprise spec: channel: stable-3.8 name: quay-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: POSTGRES_UPGRADE_RETAIN_BACKUP value: "true"- OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
- Red Hat Quay Operator をクリックします。
- Subscription タブに移動します。
- Subscription details で Update channel をクリックします。
- stable-3.9 を選択して変更を保存します。
- Upgrade status で新規インストールの進行状況を確認します。アップグレードのステータスが 1 installed に変わるまで待ってから続行してください。
- OpenShift Container Platform クラスターで、Workloads → Pod に移動します。既存の Pod は終了するか、または終了中である必要があります。
-
データベースのアップグレードと既存データのアレンビック移行を担当する Pod
clair-postgres-upgrade、quay-postgres-upgrade、およびquay-app-upgradeが起動するまで待ちます。 -
clair-postgres-upgrade、quay-postgres-upgrade、およびquay-app-upgradePod が Completed としてマークされると、Red Hat Quay デプロイメントの残りの Pod が起動します。これには約 10 分かかります。 -
quay-databaseおよびclair-postgresPod がpostgresql-13イメージを使用していることを確認します。 -
quay-appPod が Running としてマークされると、Red Hat Quay レジストリーにアクセスできるようになります。
14.2.3. 3.3.z または 3.4.z から 3.6 への直接アップグレード
次のセクションでは、Red Hat Quay 3.3.z または 3.4.z から 3.6 にアップグレードする際の重要な情報を説明しています。
14.2.3.1. エッジルーティングを有効にした状態でのアップグレード
- 以前は、エッジルーティングを有効にして 3.3.z バージョンの Red Hat Quay を実行している場合、ユーザーは 3.4.z バージョンの Red Hat Quay にアップグレードできませんでした。これは、Red Hat Quay 3.6 のリリースで解決されました。
3.3.z から 3.6 にアップグレードするときに、Red Hat Quay 3.3.z デプロイメントで
tls.terminationがnoneに設定されている場合は、TLS エッジ終端を使用して HTTPS に変更され、デフォルトのクラスターワイルドカード証明書が使用されます。以下に例を示します。apiVersion: redhatcop.redhat.io/v1alpha1 kind: QuayEcosystem metadata: name: quay33 spec: quay: imagePullSecretName: redhat-pull-secret enableRepoMirroring: true image: quay.io/quay/quay:v3.3.4-2 ... externalAccess: hostname: quayv33.apps.devcluster.openshift.com tls: termination: none database: ...
14.2.3.2. サブジェクト別名のないカスタム SSL/TLS 証明書/キーペアを使用したアップグレード
Red Hat Quay 3.3.4 から Red Hat Quay 3.6 に直接アップグレードするときに、サブジェクト代替名 (SAN) なしで独自の SSL/TLS 証明書/キーペアを使用しているお客様には問題があります。Red Hat Quay 3.6 へのアップグレード中に、デプロイメントがブロックされ、Red Hat Quay Operator Pod ログから Red Hat Quay SSL/TLS 証明書に SAN が必要であることを示すエラーメッセージが表示されます。
可能であれば、SAN 内の正しいホスト名を使用して SSL/TLS 証明書を再生成する必要があります。考えられる回避策には、アップグレード後に quay-app、quay-upgrade、quay-config-editor Pod で環境変数を定義して、CommonName のマッチングを有効にすることが含まれます。
GODEBUG=x509ignoreCN=0
GODEBUG=x509ignoreCN=0 フラグは、SAN が存在しない場合に、X.509 証明書の CommonName フィールドをホスト名として扱うという従来の動作を有効にします。ただし、この回避策は再デプロイメント後も持続しないため、お勧めしません。
14.2.3.3. Red Hat Quay Operator を使用して 3.3.z または 3.4.z から 3.6 にアップグレードする場合の Clair v4 の設定
OpenShift Container Platform 上の新しい Red Hat Quay デプロイメントに Clair v4 をセットアップする場合は、Red Hat Quay Operator を使用することが強く推奨されます。デフォルトでは、Red Hat Quay Operator は、Clair デプロイメントを Red Hat Quay デプロイメントとともにインストールまたはアップグレードし、Clair を自動的に設定します。
切断された OpenShift Container Platform クラスターで Clair v4 をセットアップする手順については、Red Hat Quay OpenShift デプロイメントでの Clair のセットアップを 参照してください。
14.2.4. 3.3.z から 3.6 にアップグレードする際の Swift 設定
Red Hat Quay 3.3.z から 3.6.z にアップグレードすると、ユーザーが Switch auth v3 requires tenant_id (string) in os_options エラーを受け取る場合があります。回避策として、DISTRIBUTED_STORAGE_CONFIG を手動で更新して、os_options パラメーターおよび tenant_id パラメーターを追加できます。
DISTRIBUTED_STORAGE_CONFIG:
brscale:
- SwiftStorage
- auth_url: http://****/v3
auth_version: "3"
os_options:
tenant_id: ****
project_name: ocp-base
user_domain_name: Default
storage_path: /datastorage/registry
swift_container: ocp-svc-quay-ha
swift_password: *****
swift_user: *****14.2.5. Red Hat Quay Operator の更新チャネルの変更
インストールされた Operator のサブスクリプションは、Operator の更新を追跡して受け取るために使用される更新チャネルを指定します。Red Hat Quay Operator をアップグレードして新規チャネルからの更新の追跡および受信を開始するには、インストールされた Red Hat Quay Operator の Subscription タブで更新チャネルを変更します。Automatic 承認ストラテジーのあるサブスクリプションの場合、アップグレードは自動的に開始し、インストールされた Operator を一覧表示したページでモニターできます。
14.2.6. 保留中の Operator アップグレードの手動による承認
インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合は、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。Red Hat Quay Operator に保留中のアップグレードがある場合、このステータスはインストールされたOperator のリストに表示されます。Red Hat Quay Operator の Subscription タブで、インストール計画をプレビューし、アップグレードに利用可能なリソースとして一覧表示されるリソースを確認できます。問題がなければ、Approve をクリックし、Installed Operators を一覧表示したページに戻り、アップグレードの進捗を監視します。
以下のイメージには、更新 Channel、Approval ストラテジー、Upgrade status および InstallPlan などの UI の Subscription タブが表示されています。
Installed Operator の一覧は、現在の Quay インストールの概要を提供します。
14.3. QuayRegistry のアップグレード
Red Hat Quay Operator を起動すると、監視するように設定されている namespace にある QuayRegistries をすぐに検索します。見つかった場合は、次のロジックが使用されます。
-
status.currentVersionが設定されていない場合は、通常通り調整を行います。 -
status.currentVersionが Operator のバージョンと等しい場合は、通常通り調整を行います。 -
status.currentVersionが Operator のバージョンと一致しない場合は、アップグレードできるかどうかを確認します。可能な場合は、アップグレードタスクを実行し、完了後にstatus.currentVersionを Operator のバージョンに設定します。アップグレードできない場合は、エラーを返し、QuayRegistryとそのデプロイされた Kubernetes オブジェクトのみを残します。
14.4. QuayEcosystem のアップグレード
アップグレードは、QuayEcosystem API を使用して限られた設定を行っていた旧バージョンの Operator からサポートされています。移行が予期せず行われるようにするには、移行を行うために特別なラベルを QuayEcosystem に適用する必要があります。Operator が管理するための新しい QuayRegistry が作成されますが、古い QuayEcosystem は手動で削除されるまで残り、何か問題が発生した場合にロールバックして Quay にアクセスできるようになります。既存の QuayEcosystem を新しい QuayRegistry に移行するには、次の手順を実行します。
手順
"quay-operator/migrate": "true"をQuayEcosystemのmetadata.labelsに追加します。$ oc edit quayecosystem <quayecosystemname>
metadata: labels: quay-operator/migrate: "true"-
QuayRegistryがQuayEcosystemと同じmetadata.nameで作成されるまで待機します。QuayEcosystemにはラベル"quay-operator/migration-complete": "true"のマークが付けられます。 -
新しい
QuayRegistryのstatus.registryEndpointが設定されたら、Red Hat Quay にアクセスし、すべてのデータと設定が正常に移行されたことを確認します。 -
すべてが正常に動作する場合は
QuayEcosystemを削除でき、Kubernetes ガベージコレクションによって古いリソースがすべてクリーンアップされます。
14.4.1. QuayEcosystem アップグレードを元に戻す
QuayEcosystem から QuayRegistry への自動アップグレード時に問題が発生した場合は、以下の手順を実行して QuayEcosystem の使用に戻します。
手順
UI または
kubectlのいずれかを使用してQuayRegistryを削除します。$ kubectl delete -n <namespace> quayregistry <quayecosystem-name>
-
Routeを使用して外部アクセスを提供していた場合は、UI やkubectlを使用して元のServiceを指すようにRouteを変更します。
QuayEcosystem が PostgreSQL データベースを管理している場合、アップグレードプロセスにより、アップグレードされた Operator が管理する新しい Postgres データベースにデータが以降されます。古いデータベースは変更または削除されませんが、移行が完了すると Quay はこのデータベースを使用しなくなります。データの移行中に問題が発生した場合は、アップグレードプロセスを終了し、データベースを管理対象外コンポーネントとして継続して使用することが推奨されます。
14.4.2. アップグレードでサポートされる QuayEcosystem 設定
QuayEcosystem コンポーネントの移行が失敗するかサポートされていない場合、Red Hat Quay Operator はログと status.conditions でエラーを報告します。アンマネージドコンポーネントを移行する場合、Kubernetes リソースを導入する必要がなく、必要な値はすべて Red Hat Quay の config.yaml で指定されているため、正常に移行できるはずです。
データベース
一時データベースはサポートされません (volumeSize フィールドを設定する必要があります)。
Redis
特別な設定は必要ありません。
External Access
パススルー Route アクセスのみが自動移行でサポートされます。他の方法には手動移行が必要です。
-
ホスト名のない
LoadBalancer:QuayEcosystemにラベル"quay-operator/migration-complete": "true"が付けられた後、Kubernetes がServiceをガベージコレクションしてロードバランサーを削除するのを防ぐため、QuayEcosystemを削除する 前 に、既存のServiceからmetadata.ownerReferencesフィールドを削除します。新規Serviceはmetadata.name形式の<QuayEcosystem-name>-quay-appで作成されます。既存のServiceのspec.selectorを新しいServiceのspec.selectorに合わせて編集することで、古いロードバランサーのエンドポイントへのトラフィックが新しい Pod に誘導されるようになります。これで古いServiceを管理します。Quay Operator はこれを管理しません。 -
カスタムホスト名を持つ
LoadBalancer/NodePort/Ingress: タイプLoadBalancerの新規Serviceはmetadata.name形式の<QuayEcosystem-name>-quay-appで作成されます。新しいServiceが提供するstatus.loadBalancerエンドポイントを指すように、DNS 設定を変更します。
Clair
特別な設定は必要ありません。
オブジェクトストレージ
QuayEcosystem には管理オブジェクトストレージコンポーネントがないため、オブジェクトストレージには常に管理外のマークが付けられます。ローカルストレージはサポートされません。
リポジトリーのミラーリング
特別な設定は必要ありません。
関連情報
- Red Hat Quay Operator の詳細は、アップストリームの quay-operator プロジェクトを参照してください。