3.2. オブジェクトストレージの設定
ストレージを管理するのが Red Hat Quay Operator かユーザーかにかかわらず、Red Hat Quay をインストールする前にオブジェクトストレージを設定する必要があります。
Red Hat Quay Operator にストレージの管理を任せたい場合は、マネージドストレージ セクションで、NooBaa および Red Hat OpenShift Data Foundations Operator のインストールと設定の詳細を参照してください。
別のストレージソリューションを使用している場合は、Operator の設定時に objectstorage
を Unmanaged
(管理外) として設定します。以下のセクションを参照してください。既存のストレージの設定の詳細は、管理対象外ストレージ を参照してください。
3.2.1. 管理対象外ストレージの使用
このセクションでは、参考として管理対象外ストレージの設定例を示しています。オブジェクトストレージの設定方法の詳細は、Red Hat Quay 設定ガイドを参照してください。
3.2.1.1. AWS S3 ストレージ
Red Hat Quay デプロイメント用に AWS S3 ストレージを設定する場合は、次の例を使用します。
DISTRIBUTED_STORAGE_CONFIG: s3Storage: - S3Storage - host: s3.us-east-2.amazonaws.com s3_access_key: ABCDEFGHIJKLMN s3_secret_key: OL3ABCDEFGHIJKLMN s3_bucket: quay_bucket s3_region: <region> storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - s3Storage
3.2.1.2. AWS Cloudfront ストレージ
Red Hat Quay デプロイメント用に AWS Cloudfront を設定する場合は、次の例を使用します。
AWS Cloudfront ストレージを設定する場合、Red Hat Quay を適切に使用するには次の条件を満たす必要があります。
-
config.yaml
ファイルで定義されている Red Hat Quay のストレージパスと一致するように Origin パス を設定する必要があります。この要件を満たさない場合、イメージを取得するときに403
エラーが発生します。詳細は、Origin path を参照してください。 - Bucket policy と Cross-origin resource sharing (CORS) ポリシーを設定する必要があります。
-
Cloudfront S3 の YAML 例
DISTRIBUTED_STORAGE_CONFIG: default: - CloudFrontedS3Storage - cloudfront_distribution_domain: <CLOUDFRONT_DISTRIBUTION_DOMAIN> cloudfront_key_id: <CLOUDFRONT_KEY_ID> cloudfront_privatekey_filename: <CLOUDFRONT_PRIVATE_KEY_FILENAME> host: <S3_HOST> s3_access_key: <S3_ACCESS_KEY> s3_bucket: <S3_BUCKET_NAME> s3_secret_key: <S3_SECRET_KEY> storage_path: <STORAGE_PATH> s3_region: <S3_REGION> DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: - default DISTRIBUTED_STORAGE_PREFERENCE: - default
バケットポリシーの例
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>/*" }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/CloudFront Origin Access Identity <CLOUDFRONT_OAI_ID>" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::<S3_BUCKET_NAME>" } ] }
3.2.1.3. Google Cloud storage
Red Hat Quay デプロイメント用に Google Cloud ストレージを設定する場合は、次の例を使用します。
DISTRIBUTED_STORAGE_CONFIG:
googleCloudStorage:
- GoogleCloudStorage
- access_key: GOOGQIMFB3ABCDEFGHIJKLMN
bucket_name: quay-bucket
secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
storage_path: /datastorage/registry
boto_timeout: 120 1
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- googleCloudStorage
- 1
- オプション: 接続から読み取ろうとしたときにタイムアウト例外が出力されるまでの時間 (秒単位)。デフォルトは
60
秒です。また、接続を試行するときにタイムアウト例外が出力されるまでの時間 (秒単位) も含まれます。デフォルトは60
秒です。
3.2.1.4. Microsoft Azure ストレージ
Red Hat Quay デプロイメント用に Microsoft Azure ストレージを設定する場合は、次の例を使用します。
DISTRIBUTED_STORAGE_CONFIG:
azureStorage:
- AzureStorage
- azure_account_name: azure_account_name_here
azure_container: azure_container_here
storage_path: /datastorage/registry
azure_account_key: azure_account_key_here
sas_token: some/path/
endpoint_url: https://[account-name].blob.core.usgovcloudapi.net 1
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- azureStorage
- 1
- Microsoft Azure ストレージの
endpoint_url
パラメーターは任意であり、Microsoft Azure Government (MAG) エンドポイントで使用できます。空白のままにすると、endpoint_url
は通常の Microsoft リージョンに接続します。Red Hat Quay 3.7 以降では、MAG Blob サービスのプライマリーエンドポイントを使用する必要があります。MAG Blob サービスのセカンダリーエンドポイントを使用すると、
AuthenticationErrorDetail:Cannot find the claimed account when trying to GetProperties for the account whusc8-secondary
エラーが発生します。
3.2.1.5. Ceph/RadosGW ストレージ
Red Hat Quay デプロイメント用に Ceph/RadosGW ストレージを設定する場合は、次の例を使用します。
DISTRIBUTED_STORAGE_CONFIG: radosGWStorage: #storage config name - RadosGWStorage #actual driver - access_key: access_key_here #parameters secret_key: secret_key_here bucket_name: bucket_name_here hostname: hostname_here is_secure: 'true' port: '443' storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: #must contain name of the storage config - radosGWStorage
3.2.1.6. Swift ストレージ:
Red Hat Quay デプロイメント用に Swift ストレージを設定する場合は、次の例を使用します。
DISTRIBUTED_STORAGE_CONFIG: swiftStorage: - SwiftStorage - swift_user: swift_user_here swift_password: swift_password_here swift_container: swift_container_here auth_url: https://example.org/swift/v1/quay auth_version: 3 os_options: tenant_id: <osp_tenant_id_here> user_domain_name: <osp_domain_name_here> ca_cert_path: /conf/stack/swift.cert" storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - swiftStorage
3.2.1.7. NooBaa 管理対象外ストレージ
次の手順を使用して、NooBaa を管理対象外のストレージ設定としてデプロイします。
手順
-
Red Hat Quay コンソールで、Storage
Object Bucket Claims に移動して、NooBaa Object Bucket Claim を作成します。 - アクセスキー、バケット名、エンドポイント (ホスト名)、および秘密鍵を含む Object Bucket Claim データの詳細を取得します。
Object Bucket Claim (オブジェクトバケット要求) の情報を使用する
config.yaml
設定ファイルを作成します。DISTRIBUTED_STORAGE_CONFIG: default: - RHOCSStorage - access_key: WmrXtSGk8B3nABCDEFGH bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef hostname: s3.openshift-storage.svc.cluster.local is_secure: true port: "443" secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
Object Bucket Claim の設定の詳細は、オブジェクトバケットクレーム を参照してください。
3.2.2. 管理対象外 NooBaa インスタンスの使用
以下の手順を使用して、Red Hat Quay デプロイメントに管理対象外 NooBaa インスタンスを使用します。
手順
-
Storage
Object Bucket Claims のコンソールで NooBaa Object Bucket Claim を作成します。 -
Access Key
、Bucket Name
、Endpoint (hostname)
、およびSecret Key
を含む Object Bucket Claim データの詳細を取得します。 Object Bucket Claim (オブジェクトバケット要求) の情報を使用して
config.yaml
設定ファイルを作成します。以下に例を示します。DISTRIBUTED_STORAGE_CONFIG: default: - RHOCSStorage - access_key: WmrXtSGk8B3nABCDEFGH bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef hostname: s3.openshift-storage.svc.cluster.local is_secure: true port: "443" secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - default
3.2.3. マネージドストレージ
Red Hat Quay Operator に Red Hat Quay のオブジェクトストレージを管理させる場合、クラスターは ObjectBucketClaim
API を通じてオブジェクトストレージを提供できる必要があります。Red Hat OpenShift Data Foundations Operator を使用する場合は、サポートされている 2 つのオプションを使用できます。
ローカルの Kubernetes
PersistentVolume
ストレージでサポートされる Multi-Cloud Object Gateway のスタンドアロンインスタンス- 高可用性がない
- Red Hat Quay サブスクリプションに含まれている
- Red Hat OpenShift Data Foundation の別のサブスクリプションは不要
スケールアウト Object Service と Ceph を備えた Red Hat OpenShift Data Foundation の実稼働環境用デプロイメント
- 高可用性がある
- Red Hat OpenShift Data Foundation の別のサブスクリプションが必要
スタンドアロンのインスタンスオプションを使用するには、以下の読み取りを続行します。Red Hat OpenShift Data Foundation の実稼働環境用デプロイメントの詳細は、公式ドキュメント を参照してください。
オブジェクトストレージのディスク容量は、50 GiB が Red Hat Quay Operator によって自動的に割り当てられます。この数は、ほとんどの小規模/中規模の Red Hat Quay インストールで利用可能なストレージの量を表しますが、実際のユースケースには十分ではない可能性があります。現在、Red Hat OpenShift Data Foundation ボリュームのサイズ変更は、Red Hat Quay Operator によって処理されません。詳細は、マネージドストレージのサイズ変更に関するセクションを参照してください。
3.2.3.1. Red Hat Quay の Red Hat OpenShift Data Foundation Operator での Multicloud Object Gateway コンポーネントの使用
Red Hat Quay サブスクリプションの一環として、Red Hat OpenShift Data Foundations Operator (以前は OpenShift Container Storage Operator として知られる) の Multi-Cloud Object Gateway (MCG) コンポーネントを使用できます。このゲートウェイコンポーネントを使用すると、Kubernetes PersistentVolume
ベースのブロックストレージがサポートする Red Hat Quay への S3 互換のオブジェクトストレージインターフェイスを指定できます。この使用は、Operator で管理される Red Hat Quay デプロイメントや、以下に示す Multicloud Object Gateway インスタンスの正確な仕様に限定されます。
Red Hat Quay はローカルファイルシステムのストレージをサポートしないため、ユーザーは代わりに Kubernetes PersistentVolume
ストレージと組み合わせてゲートウェイを利用し、サポートされるデプロイメントを提供できます。PersistentVolume
はオブジェクトストレージのバッキングストアとしてゲートウェイインスタンスに直接マウントされ、ブロックベースの StorageClass
がサポートされます。
PersistentVolume
の性質上、これはスケールアウトできる高可用性ソリューションではなく、Red Hat OpenShift Data Foundation などのスケールアウトストレージシステムを置き換えることはできません。ゲートウェイの単一インスタンスのみが実行されています。再スケジュール、更新、または予定外のダウンタイムが原因でゲートウェイを実行している Pod が利用できなくなると、接続された Red Hat Quay インスタンスのパフォーマンスが一時的に低下します。
以下の手順を使用して、Local Storage Operator、Red Hat OpenShift Data Foundation をインストールし、スタンドアロンの Multicloud Object Gateway を作成して OpenShift Container Platform に Red Hat Quay をデプロイします。
以下のドキュメントは、Red Hat OpenShift Data Foundation の公式ドキュメント と共通性を共有します。
3.2.3.1.1. OpenShift Container Platform への Local Storage Operator のインストール
以下の手順を使用して、ローカルストレージデバイスに Red Hat OpenShift Data Foundation クラスターを作成する前に、OperatorHub から Local Storage Operator をインストールします。
- OpenShift Web コンソール にログインします。
-
Operators
OperatorHub をクリックします。 - 検索ボックスに local storage と入力して、Operators のリストから Local Storage Operator を見つけます。Local Storage をクリックします。
- Install をクリックします。
Install Operator ページで、次のオプションを設定します。
- 更新チャネルの場合は、stable を選択します。
- インストールモードの場合は、A specific namespace on the cluster を選択します。
- インストールされた namespace の場合は、Operator recommended namespace openshift-local-storage を選択します。
- 更新の承認の場合は、Automatic を選択します。
- Install をクリックします。
3.2.3.1.2. OpenShift Container Platform への Red Hat OpenShift Data Foundation のインストール
以下の手順を使用して、Red Hat OpenShift Data Foundation を OpenShift Container Platform にインストールします。
前提条件
-
cluster-admin
および Operator インストールのパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - OpenShift Container Platform クラスターにワーカーノードが少なくとも 3 つある。
- その他のリソース要件は、デプロイメントのプランニング ガイドを参照してください。
手順
- OpenShift Web コンソール にログインします。
-
Operators
OperatorHub をクリックします。 - 検索ボックスに OpenShift Data Foundation と入力します。OpenShift Data Foundation をクリックします。
- Install をクリックします。
Install Operator ページで、次のオプションを設定します。
- 更新チャネルの場合は、最新の安定したバージョンを選択します。
- インストールモードの場合は、A specific namespace on the cluster を選択します。
- インストールされた namespace の場合は、Operator recommended Namespace: openshift-storage を選択します。
更新の承認の場合は、Automatic または Manual を選択します。
Automatic (自動) 更新を選択すると、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
Manual 更新を選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。
- コンソールプラグインの場合は、Enable を選択します。
Install をクリックします。
Operator がインストールされると、
Web console update is available
メッセージを含むポップアップがユーザーインターフェイスに表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。- Red Hat Quay の Multicloud Object Gateway コンポーネントを活用するには、「スタンドアロンの Multicloud Object Gateway」の作成に進んでください。
3.2.3.1.3. OpenShift Container Platform UI を使用したスタンドアロン Multicloud Object Gateway の作成
スタンドアロン Multicloud Object Gateway を作成するには、次の手順を使用します。
前提条件
- Local Storage Operator がインストールされている。
- Red Hat OpenShift Data Foundation Operator がインストールされている。
手順
OpenShift Web コンソール で、Operators
Installed Operators をクリックし、インストールされた Operator をすべて表示します。 namespace が
openshift-storage
であることを確認します。- Create StorageSystem をクリックします。
Backing storage ページで、以下を選択します。
- Deployment type の Multicloud Object Gateway を選択します。
- Create a new StorageClass using the local storage devices オプションを選択します。
Next をクリックします。
注記Local Storage Operator がまだインストールされていない場合は、インストールするように求められます。Install をクリックし、「OpenShift Container Platform への Local Storage Operator のインストール」で説明されている手順に従います。
Create local volume set ページで、以下の情報を入力します。
- LocalVolumeSet および StorageClass の名前を入力します。デフォルトでは、ストレージクラス名としてローカルボリュームセット名が表示されます。名前を変更できます。
以下のいずれかを選択します。
すべてのノード上のディスク
すべてのノードにある選択したフィルターに一致する利用可能なディスクを使用します。
選択したノード上のディスク
選択したノードにある選択したフィルターにのみ一致する利用可能なディスクを使用します。
- Disk Type の利用可能なリストから、SSD/NVMe を選択します。
Advanced セクションを拡張し、以下のオプションを設定します。
ボリュームモード
デフォルトではファイルシステムが選択されています。Volume Mode で Filesystem が選択されていることを常に確認してください。
デバイスタイプ
ドロップダウンリストから 1 つ以上のデバイスタイプを選択します。
ディスクサイズ
デバイスの最小サイズ 100GB と、含める必要のあるデバイスの最大サイズを設定します。
ディスクの最大数の制限
これは、ノードで作成できる PV の最大数を示します。このフィールドが空のままの場合、PV は一致するノードで利用可能なすべてのディスクに作成されます。
Next をクリックします。
LocalVolumeSet
の作成を確認するポップアップが表示されます。- Yes をクリックして続行します。
Capacity and nodes ページで、以下を設定します。
- Available raw capacity には、ストレージクラスに関連付けられた割り当てられたすべてのディスクに基づいて容量の値が設定されます。これには少し時間がかかります。Selected nodes リストには、ストレージクラスに基づくノードが表示されます。
- Next をクリックして先に進みます。
オプション: Connect to an external key management service チェックボックスを選択します。これはクラスター全体の暗号化の場合はオプションになります。
- Key Management Service Provider ドロップダウンリストから、Vault または Thales CipherTrust Manager (using KMIP) を選択します。Vault を選択した場合は、次の手順に進みます。Thales CipherTrust Manager (using KMIP) を選択した場合は、手順 iii に進みます。
Authentication Method を選択します。
トークン認証方式の使用
- Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号および Token を入力します。
Advanced Settings をデプロイメントして、
Vault
設定に基づいて追加の設定および証明書の詳細を入力します。- OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
- オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
- それぞれの PEM でエンコードされた証明書ファイルをアップロードし、CA 証明書、クライアント証明書、および クライアントの秘密鍵 を提供します。
Save をクリックして、手順 iv に進みます。
Kubernetes 認証方式の使用
- Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号、および Role 名を入力します。
Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。
- Red Hat OpenShift Data Foundation 専用で一意の Backend Path にキーと値のシークレットパスを入力します。
- 該当する場合は、TLS Server Name および Authentication Path を入力します。
- PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA 証明書、クライアント証明書、および クライアントの秘密鍵 を提供します。
- Save をクリックして、手順 iv に進みます。
Thales CipherTrust Manager (using KMIP) を KMS プロバイダーとして使用するには、次の手順に従います。
- プロジェクト内のキー管理サービスの一意の Connection Name を入力します。
Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。以下に例を示します。
- Address: 123.34.3.2
- Port: 5696
- Client Certificate、CA certificate、および Client Private Key をアップロードします。
- StorageClass 暗号化が有効になっている場合は、上記で生成された暗号化および復号化に使用する一意の識別子を入力します。
-
TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、
kmip_all_<port>.ciphertrustmanager.local
などです。
- Network を選択します。
- Next をクリックします。
- Review and create ページで、設定の詳細を確認します。設定を変更するには、Back をクリックします。
- Create StorageSystem をクリックします。
3.2.3.1.4. CLI を使用して Multicloud Object Gateway を作成する
以下の手順に従って、Red Hat OpenShift Data Foundation (以前の OpenShift Container Storage) Operator をインストールし、単一インスタンスの Multi-Cloud Gateway サービスを設定します。
次の設定は、Red Hat OpenShift Data Foundation がインストールされているクラスターで並行して実行できないことに注意してください。
手順
-
OpenShift Web コンソール で、Operators
OperatorHub を選択します。 - Red Hat OpenShift Data Foundation を検索し、Install を選択します。
- すべてのデフォルトのオプションを受け入れて、Install を選択します。
Status 列を表示して Operator がインストールされたことを確認します。この列には Succeeded とマークが付けられています。
警告Red Hat OpenShift Data Foundation Operator のインストールが完了すると、ストレージシステムを作成するように求められます。この指示には従わないでください。代わりに、次の手順に従って NooBaa オブジェクトストレージを作成します。
マシン上で、次の情報を含む
noobaa.yaml
という名前のファイルを作成します。apiVersion: noobaa.io/v1alpha1 kind: NooBaa metadata: name: noobaa namespace: openshift-storage spec: dbResources: requests: cpu: '0.1' memory: 1Gi dbType: postgres coreResources: requests: cpu: '0.1' memory: 1Gi
これにより、Multi-cloud Object Gateway の単一インスタンスデプロイメントが作成されます。
以下のコマンドを使用して設定を適用します。
$ oc create -n openshift-storage -f noobaa.yaml
出力例
noobaa.noobaa.io/noobaa created
数分後に、Multi-cloud Object Gateway プロビジョニングが完了するはずです。次のコマンドを入力してステータスを確認できます。
$ oc get -n openshift-storage noobaas noobaa -w
出力例
NAME MGMT-ENDPOINTS S3-ENDPOINTS IMAGE PHASE AGE noobaa [https://10.0.32.3:30318] [https://10.0.32.3:31958] registry.redhat.io/ocs4/mcg-core-rhel8@sha256:56624aa7dd4ca178c1887343c7445a9425a841600b1309f6deace37ce6b8678d Ready 3d18h
次の YAML ファイルを
noobaa-pv-backing-store.yaml
で名前作成して、ゲートウェイのバッキングストアを設定します。apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: noobaa-pv-backing-store namespace: openshift-storage spec: pvPool: numVolumes: 1 resources: requests: storage: 50Gi 1 storageClass: STORAGE-CLASS-NAME 2 type: pv-pool
以下のコマンドを入力して設定を適用します。
$ oc create -f noobaa-pv-backing-store.yaml
出力例
backingstore.noobaa.io/noobaa-pv-backing-store created
これにより、ゲートウェイのバッキングストア設定が作成されます。Red Hat Quay のすべてのイメージは、上記の設定によって作成される
PersistentVolume
のゲートウェイを経由してオブジェクトとして保存されます。以下のコマンドを実行して、
PersistentVolume
バッキングストアを、Red Hat Quay Operator が発行するすべてのObjectBucketClaims
のデフォルトにします。$ oc patch bucketclass noobaa-default-bucket-class --patch '{"spec":{"placementPolicy":{"tiers":[{"backingStores":["noobaa-pv-backing-store"]}]}}}' --type merge -n openshift-storage