8.9. capabilities に関連するプロダクトカスタムリソース
新しく作成したテナントで Openshift Container Platform を使用し、プロダクト、それらに対応するメトリクス、メソッド、アプリケーションプラン、およびマッピングルールを設定し、プロダクトバックエンドの使用状況を定義すると共にプロダクトをテナントアカウントにリンクします。
前提条件
一般的な前提条件 に記載の条件と同じインストール要件が適用されます。ただし、以下の考慮事項に注意してください。
- 3scale アカウントから最低限必要なパラメーターは、プロダクト名です。
8.9.1. capabilities に関連するプロダクトカスタムリソースのデプロイ
新しく作成したテナントで Openshift Container Platform を使用し、新規プロダクトを設定します。
8.9.1.1. 基本的なプロダクトカスタムリソースのデプロイ
手順
- OpenShift アカウントで、Installed operators に移動します。
- 3scale operator をクリックします。
- 3scale Product セクションで、Create Instance をクリックします。
- YAML View を選択します。
3scale プロダクトを作成します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: <your_product_OpenShift_name> spec: name: "<your_product_name>"
以下に例を示します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1"
- 変更を保存するには、Create をクリックします。
OpenShift と 3scale アカウントの両方でプロダクトが作成されるまで数秒待機します。その後、以下の検証を実行できます。
-
3scale Product Overview ページで、Synced 状態が
True
とマークされていることを確認して、プロダクトが OpenShift で作成されたことを確認します。 -
3scale アカウントに移動し、プロダクトが作成されたことを確認します。上記の例では、
OperatedProduct 1
という新しいプロダクトが表示されます。
-
3scale Product Overview ページで、Synced 状態が
また、作成する各プロダクトに APIcast のデプロイメントモードを指定することもできます。以下の 2 つの方法があります。
8.9.1.2. Hosted APIcast を使用するプロダクトのデプロイ
Hosted APIcast と共にプロダクトを設定します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" deployment: apicastHosted: {}
8.9.1.3. Self-managed APIcast を使用するプロダクトのデプロイ
Self-managed APIcast と共にプロダクトを設定します。この場合、stagingPublicBaseURL
および productionPublicBaseURL
を指定します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" deployment: apicastSelfManaged: stagingPublicBaseURL: "https://staging.api.example.com" productionPublicBaseURL: "https://production.api.example.com"
8.9.2. プロダクトのアプリケーションプランの定義
新しく作成した 3scale テナントで Openshift Container Platform を使用し、applicationPlans
オブジェクトを使用してプロダクトカスタムリソースに必要なアプリケーションプランを定義します。
以下の点について考慮してください。
-
applicationPlans
マップキー名はsystem_name
として使用されます。以下の例では、plan01
およびplan02
です。
setupFee
および costMonth
は、一般的な 3scale の概念です。3scale ユーザーインターフェイスでアプリケーションプランを作成する際に、これらの詳細情報を入力する必要があります。アプリケーションプランへの課金ルールの設定 を参照してください。
手順
以下の例に示すように、新しい 3scale プロダクトにアプリケーションプランを追加します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" applicationPlans: plan01: name: "My Plan 01" setupFee: "14.56" plan02: name: "My Plan 02" trialPeriod: 3 costMonth: 3
8.9.3. プロダクトアプリケーションプランの制限の定義
新しく作成した 3scale テナントで Openshift Container Platform を使用し、applicationPlans.limits
リストを使用してプロダクトアプリケーションプランに必要な制限を定義します。
以下の点について考慮してください。
-
period
、value
、およびmetricMethodRef
は必須フィールドです。 -
metricMethodRef
参照は、プロダクトまたはバックエンド参照のいずれかです。オプションのbackend
フィールドを使用して、バックエンドメトリクスの所有者を参照します。
手順
以下の例に示すように、3scale プロダクトのアプリケーションプランに制限を定義します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" metrics: hits: description: Number of API hits friendlyName: Hits unit: "hit" applicationPlans: plan01: name: "My Plan 01" limits: - period: month value: 300 metricMethodRef: systemName: hits backend: backendA - period: week value: 100 metricMethodRef: systemName: hits
8.9.4. プロダクトアプリケーションプランの課金ルールの定義
新しく作成した 3scale テナントで Openshift Container Platform を使用し、applicationPlans.pricingRules
リストを使用してプロダクトアプリケーションプランに必要な課金ルールを定義します。
以下の点について考慮してください。
-
from
、to
、pricePerUnit
、およびmetricMethodRef
は必須フィールドです。 -
from
およびto
は検証されます。すべてのルールで、from
の値がto
より小さい設定、および同じメトリクスで範囲が重複する設定は許されません。 -
metricMethodRef
参照は、プロダクトまたはバックエンド参照のいずれかです。オプションのbackend
フィールドを使用して、バックエンドメトリクスの所有者を参照します。
手順
以下の例に示すように、3scale プロダクトのアプリケーションプランに課金ルールを定義します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" metrics: hits: description: Number of API hits friendlyName: Hits unit: "hit" applicationPlans: plan01: name: "My Plan 01" pricingRules: - from: 1 to: 100 pricePerUnit: "15.45" metricMethodRef: systemName: hits - from: 1 to: 300 pricePerUnit: "15.45" metricMethodRef: systemName: hits backend: backendA
8.9.5. OpenID Connect を使用したプロダクト認証の定義
任意の OAuth 2.0 フローの認証に OpenID Connect (OIDC) を使用する 3scale プロダクトの Product
カスタムリソースをデプロイできます。3scale は、OpenID Connect などのサードパーティーアイデンティティープロバイダー (IdP) と統合して、API リクエストの認証を行います。OpenID Connect についての詳しい情報は、OpenID Connect integration を参照してください。サードパーティーの IdP との統合後、プロダクトカスタムリソースに 2 種類のデータを含めます。
-
issuerType
: Red Hat Single Sign-On (RH-SSO) 使用時のkeycloak
の値およびサードパーティー IdP との統合時のrest
の値。 -
issuerEndpoint
: 必要なクレデンシャルを持つ URL。
前提条件
- RH-SSO を設定しておく。Red Hat Single Sign-On の設定 を参照してください。
- サードパーティーアイデンティティープロバイダーとの HTTP インテグレーションを設定している。
issuerEndpoint
で提供されるクレデンシャル CLIENT_ID および CLIENT_CREDENTIALS には、レルムで他のクライアントを管理するために十分なパーミッションが必要です。
手順
OpenID プロバイダーの場所を定義するエンドポイント
issuerEndpoint
を決定し、プロダクトカスタムリソースでこの形式を使用します。https://<client_id>:<client_secret>@<host>:<port_number>/auth/realms/<realm_name>`
OAuth 2.0 フローの OpenID Connect (OIDC) 認証を指定する 3scale
Product
CR を定義または更新します。以下に例を示します。apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" deployment: <any>: authentication: oidc: issuerType: "keycloak" issuerEndpoint: "https://myclientid:myclientsecret@mykeycloack.example.com/auth/realms/myrealm" authenticationFlow: standardFlowEnabled: false implicitFlowEnabled: true serviceAccountsEnabled: true directAccessGrantsEnabled: true jwtClaimWithClientID: "azp" jwtClaimWithClientIDType: "plain"
定義したばかりのリソースを作成します。以下に例を示します。
oc create -f product1.yaml
この例では、出力は以下のようになります。
product.capabilities.3scale.net/product1 created
8.9.6. プロダクトメトリクスの定義
新しく作成した 3scale テナントで Openshift Container Platform を使用し、metrics
オブジェクトを使用してプロダクトカスタムリソースに必要なメトリクスを定義します。
以下の点について考慮してください。
-
metrics
マップキー名はsystem_name
として使用されます。以下の例では、metric01
およびhits
です。 -
metrics
マップキー名は、すべてのメトリクスおよびメソッド間で一意である必要があります。 -
unit
およびfriendlyName
は必須フィールドです。 -
hits
メトリクスを追加しない場合は、operator によって作成されます。
手順
以下の例に示すように、新しい 3scale バックエンドにプロダクトメトリクスを追加します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" metrics: metric01: friendlyName: Metric01 unit: "1" hits: description: Number of API hits friendlyName: Hits unit: "hit"
8.9.7. プロダクトメソッドの定義
新しく作成した 3scale テナントで Openshift Container Platform を使用し、methods
オブジェクトを使用してプロダクトカスタムリソースに必要なメソッドを定義します。
以下の点について考慮してください。
-
methods
マップキー名はsystem_name
として使用されます。以下の例では、Method01
とMethod02
です。 -
methods
マップキー名は、すべてのメトリクスおよびメソッド間で一意である必要があります。 -
friendlyName
は必須フィールドです。
手順
以下の例のように、新しい 3scale プロダクトにメソッドを追加します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" methods: method01: friendlyName: Method01 method02: friendlyName: Method02
8.9.8. プロダクトマッピングルールの定義
新しく作成した 3scale テナントで Openshift Container Platform を使用し、mappingRules
オブジェクトを使用してプロダクトカスタムリソースに必要なマッピングルールを定義します。
以下の点について考慮してください。
-
httpMethod
、pattern
、increment
、およびmetricMethodRef
は必須フィールドです。 -
metricMethodRef
は、既存のメトリクスまたはメソッドマップキー名system_name
への参照を保持します。以下の例では、hits
です。
手順
以下の例に示すように、新しい 3scale バックエンドにプロダクトマッピングルールを追加します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" metrics: hits: description: Number of API hits friendlyName: Hits unit: "hit" methods: method01: friendlyName: Method01 mappingRules: - httpMethod: GET pattern: "/pets" increment: 1 metricMethodRef: hits - httpMethod: GET pattern: "/cars" increment: 1 metricMethodRef: method01
8.9.9. プロダクトバックエンドの使用状況の定義
新しく作成した 3scale テナントで Openshift Container Platform を使用し、backendUsages
オブジェクトを適用して宣言的にプロダクトに追加される必要なバックエンドを定義します。
以下の点について考慮してください。
-
path
は必須フィールドです。 -
backendUsages
マップキー名は、バックエンドのsystem_name
への参照です。以下の例では、backendA
およびbackendB
です。
手順
以下の例に示すように、プロダクトにバックエンドを追加して、その使用状況を宣言的に定義します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" backendUsages: backendA: path: /A backendB: path: /B
8.9.10. 3scale プロダクトカスタムリソースでのゲートウェイ応答の設定
3scale 管理者は、Product
カスタムリソースを設定して、その API プロダクトの公開された API へのリクエストに対するゲートウェイレスポンスを指定できます。CR のデプロイ後に、3scale は指定した応答およびエラーメッセージをゲートウェイが返すようにします。
Product
CR の gatewayResponse
オブジェクトには、ゲートウェイが返すレスポンスが含まれます。
手順
新規またはデプロイされた
Product
CR で、gatewayResponse
オブジェクトに 1 つ以上の応答を設定します。次の例は、userKey
と呼ばれる認証モードの Apacast ホスト型デプロイメントのレスポンス設定を示しています。apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" deployment: apicastHosted: authentication: userkey: gatewayResponse: errorStatusAuthFailed: 500 errorHeadersAuthFailed: "text/plain; charset=mycharset" errorAuthFailed: "My custom reponse body" errorStatusAuthMissing: 500 errorHeadersAuthMissing: "text/plain; charset=mycharset" errorAuthMissing: "My custom reponse body" errorStatusNoMatch: 501 errorHeadersNoMatch: "text/plain; charset=mycharset" errorNoMatch: "My custom reponse body" errorStatusLimitsExceeded: 502 errorHeadersLimitsExceeded: "text/plain; charset=mycharset" errorLimitsExceeded: "My custom reponse body"
ゲートウェイのレスポンスが含まれる
Product
CR をデプロイします。たとえば、product1.yaml
ファイルを更新した場合は、以下のコマンドを実行します。oc create -f product1.yaml
この例では、出力は以下のようになります。
product.capabilities.3scale.net/product1 created
8.9.11. 3scale プロダクトカスタムリソースでのポリシーチェーンの設定
3scale の管理者は、Product
カスタムリソースを設定して、その API プロダクトに適用するポリシーチェーンを指定できます。CR のデプロイ後に、3scale は設定済みのポリシーをプロダクトのアップストリームの公開された API へのリクエストに適用します。
手順
新規またはデプロイされた
Product
CR で、policies
オブジェクトに 1 つ以上のポリシーを設定します。以下に例を示します。apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" policies: - configuration: http_proxy: http://example.com https_proxy: https://example.com enabled: true name: camel version: builtin - configuration: {} enabled: true name: apicast version: builtin
それぞれのポリシーについて、以下のフィールドを指定します。
-
ポリシーにパラメーターがない場合、
configuration
は空白の中かっこを指定します。ポリシーにパラメーターがある場合は、ここで指定します。指定する必要のあるパラメーターの名前については、API ゲートウェイ、APIcast 標準ポリシーの管理 の関連するポリシーのドキュメントを参照してください。 -
enabled
は、ポリシーをオンまたはオフにするブール値のスイッチです。 -
name
はポリシーを識別します。これは、Product
カスタムリソースがリンクするテナントの範囲にある一意の名前です。ポリシー名を特定するには、API ゲートウェイ、APIcast 標準ポリシーの管理 の関連するポリシーのドキュメントを参照してください。 version
は、標準ポリシーの場合はbuiltin
で、カスタムポリシーの場合はユーザー定義の文字列です。たとえば、カスタムポリシーのバージョンを1.0
に設定できます。Product
CR にapicast
ポリシーを指定しないと、operator がこれを追加します。ポリシーチェーンがすでに管理ポータルに定義されている場合は、3scale toolbox の
export
コマンドを実行してポリシーチェーンを.yaml
形式でエクスポートできます。export
出力をProduct
CR に貼り付けできます。たとえば、api-provider-account-one
は 3scale プロバイダーアカウントの名前で、my-api-product-one
はポリシーチェーンをエクスポートするプロダクトの名前である場合、以下のコマンドを実行します。
3scale policies export api-provider-account-one my-api-product-one
-
ポリシーにパラメーターがない場合、
ポリシーチェーンが含まれる
Product
CR をデプロイします。たとえば、product1.yaml
ファイルを更新した場合は、以下のコマンドを実行します。oc create -f product1.yaml
この例では、出力は以下のようになります。
product.capabilities.3scale.net/product1 created
8.9.12. プロダクトカスタムリソースのステータス
status フィールドには、エンドユーザーに役立つリソース情報が表示されます。手動で更新することは意図されず、リソースの変更ごとに同期されます。
status フィールドの属性は以下のとおりです。
-
productid
: 3scale プロダクトの内部 ID conditions
:status.Conditions
Kubernetes 共通パターンを表します。これには、以下のタイプまたは状態があります。- Failed: 同期中にエラーが発生しています。操作はリトライされます。
- Synced: プロダクトは正常に同期されています。
- Invalid: オブジェクトが無効です。これは一時的なエラーではなく、無効な使用が報告され、それを変更する必要があります。操作はリトライされません。
- Orphan: 仕様は存在しないリソースを参照しています。operator はリトライします。
-
observedGeneration
: ステータス情報が最新のリソース仕様で更新されていることを確認します。 -
state
: 3scale API から読み取られた 3scale プロダクトの内部状態。 -
providerAccountHost
: バックエンドが同期される 3scale プロバイダーアカウントの URL。
同期されたリソースの例:
status: conditions: - lastTransitionTime: "2020-10-21T18:07:01Z" status: "False" type: Failed - lastTransitionTime: "2020-10-21T18:06:54Z" status: "False" type: Invalid - lastTransitionTime: "2020-10-21T18:07:01Z" status: "False" type: Orphan - lastTransitionTime: "2020-10-21T18:07:01Z" status: "True" type: Synced observedGeneration: 1 productId: 2555417872138 providerAccountHost: https://3scale-admin.example.com state: incomplete
8.9.13. テナントアカウントにリンクされたプロダクトカスタムリソース
3scale operator が新しい 3scale リソースを見つけると、LookupProviderAccount プロセスは、リソースを所有するテナントを識別するために開始されます。
プロセスは、テナントのクレデンシャルソースを確認します。何も見つからない場合は、エラーが発生します。
以下の手順では、プロセスがテナントのクレデンシャルソースを検証する方法を説明します。
providerAccountRef リソース属性からのクレデンシャルを確認します。これはシークレットのローカル参照です (例: mytenant)。
apiVersion: capabilities.3scale.net/v1beta1 kind: Product metadata: name: product1 spec: name: "OperatedProduct 1" providerAccountRef: name: mytenant
mytenant シークレットの adminURL および tokenフィールドには、テナントクレデンシャルが設定されている必要があります。以下に例を示します。
apiVersion: v1 kind: Secret metadata: name: mytenant type: Opaque stringData: adminURL: https://my3scale-admin.example.com:443 token: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
デフォルトの threescale-provider-account シークレットを確認します。例:
adminURL=https://3scale-admin.example.com
およびtoken=123456
:oc create secret generic threescale-provider-account --from-literal=adminURL=https://3scale-admin.example.com --from-literal=token=123456
- 3scale デプロイメントの同じ namespace にあるデフォルトのプロバイダーアカウントを確認します。3scale インストール環境がカスタムリソースと同じ namespace にある場合、operator はデフォルトの 3scale テナント (プロバイダーアカウント) に必要なクレデンシャルを自動的に収集します。