8.8. capabilities に関連するバックエンドカスタムリソース
新しく作成したテナントで Openshift Container Platform を使用し、バックエンド、それらに対応するメトリクス、メソッド、およびマッピングルールを設定します。バックエンドのカスタムリソースのステータスや、バックエンドがどのようにテナントアカウントにリンクされているかについても説明します。
前提条件
一般的な前提条件 に記載の条件と同じインストール要件が適用されます。ただし、以下の考慮事項に注意してください。
- 3scale アカウントから最低限必要なパラメーターは、管理ポータルの URL アドレスとアクセストークンです。
8.8.1. capabilities に関連するバックエンドカスタムリソースのデプロイ
新しく作成したテナントで Openshift Container Platform を使用し、新規バックエンドを設定します。
手順
- OpenShift アカウントで、Installed operators に移動します。
- 3scale operator をクリックします。
- 3scale Backend で、Create Instance をクリックします。
- YAML View を選択します。
特定の 3scale 管理 URL アドレスをポイントする 3scale バックエンドを作成します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: <your_backend_OpenShift_name> spec: name: "<your_backend_name>" privateBaseURL: "<your_admin_portal_URL>"
以下に例を示します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend-1 spec: name: "My Backend Name" privateBaseURL: "https://api.example.com"
- 変更を保存するには、Create をクリックします。
OpenShift と 3scale アカウントの両方でバックエンドが作成されるまで数秒待機します。その後、以下の検証を実行できます。
-
3scale Backend Overview ページで、Synced 状態が
True
とマークされていることを確認して、バックエンドが OpenShift で作成されたことを確認します。 -
3scale アカウントに移動し、バックエンドが作成されたことを確認します。上記の例では、
My Backend Name
という新しいバックエンドが表示されます。
-
3scale Backend Overview ページで、Synced 状態が
8.8.2. バックエンドメトリクスの定義
新しく作成した 3scale テナントで Openshift Container Platform を使用し、バックエンドのカスタムリソースに必要なバックエンドメトリクスを定義します。
以下の点について考慮してください。
-
metrics
マップキー名はsystem_name
として使用されます。下の例ではmetric01
、metric02
、およびhits
です。 -
metrics
マップキー名は、すべてのメトリクスおよびメソッド間で一意である必要があります。 -
unit
およびfriendlyName
は必須フィールドです。 -
Hits メトリクスを追加しない場合
、このメトリクスは operator によって作成されます。
手順
以下の例に示すように、新しい 3scale バックエンドにバックエンドメトリクスを追加します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend-1 spec: name: "My Backend Name" privateBaseURL: "https://api.example.com" metrics: metric01: friendlyName: Metric01 unit: "1" metric02: friendlyName: Metric02 unit: "1" hits: description: Number of API hits friendlyName: Hits unit: "hit
8.8.3. バックエンドメソッドの定義
新しく作成した 3scale テナントで Openshift Container Platform を使用し、バックエンドのカスタムリソースに必要なバックエンドメソッドを定義します。
以下の点について考慮してください。
-
methods
マップキー名はsystem_name
として使用されます。以下の例では、Method01
とMethod02
です。 -
methods
マップキー名は、すべてのメトリクスおよびメソッド間で一意である必要があります。 -
friendlyName
は必須フィールドです。
手順
以下の例に示すように、新しい 3scale バックエンドにバックエンドメソッドを追加します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend-1 spec: name: "My Backend Name" privateBaseURL: "https://api.example.com" methods: method01: friendlyName: Method01 method02: friendlyName: Method02
8.8.4. バックエンドマッピングルールの定義
新しく作成した 3scale テナントで Openshift Container Platform を使用し、バックエンドのカスタムリソースに必要なバックエンドマッピングルールを定義します。
以下の点について考慮してください。
-
httpMethod
、pattern
、increment
、およびmetricMethodRef
は必須フィールドです。 -
metricMethodRef
は、既存のメトリクスまたはメソッドマップキー名system_name
への参照を保持します。以下の例では、hits
です。
手順
以下の例に示すように、新しい 3scale バックエンドにバックエンドマッピングルールを追加します。
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend-1 spec: name: "My Backend Name" privateBaseURL: "https://api.example.com" mappingRules: - httpMethod: GET pattern: "/pets" increment: 1 metricMethodRef: hits - httpMethod: GET pattern: "/pets/id" increment: 1 metricMethodRef: hits metrics: hits: description: Number of API hits friendlyName: Hits unit: "hit"
8.8.5. バックエンドカスタムリソースのステータス
status フィールドには、エンドユーザーに役立つリソース情報が表示されます。手動で更新することは意図されず、リソースの変更ごとに同期されます。
status フィールドの属性は以下のとおりです。
-
backendId
: 3scale バックエンドの内部 ID。 conditions
:status.Conditions
Kubernetes 共通パターンを表します。これには、以下のタイプまたは状態があります。-
Invalid:
BackendSpec
の設定の組み合わせはサポート対象外です。これは一時的なエラーではなく、進捗するには修正する必要がある状態を示します。 - Synced: バックエンドは正常に同期されています。
- Failed: 同期中にエラーが発生しています。
-
Invalid:
-
observedGeneration
: ステータス情報が最新のリソース仕様で更新されていることを確認するヘルパーフィールドです。
同期されたリソースの例:
status: backendId: 59978 conditions: - lastTransitionTime: "2020-06-22T10:50:33Z" status: "False" type: Failed - lastTransitionTime: "2020-06-22T10:50:33Z" status: "False" type: Invalid - lastTransitionTime: "2020-06-22T10:50:33Z" status: "True" type: Synced observedGeneration: 2
8.8.6. テナントアカウントにリンクされたバックエンドカスタムリソース
3scale operator が新しい 3scale リソースを見つけると、LookupProviderAccount プロセスは、リソースを所有するテナントを識別するために開始されます。
プロセスは、テナントのクレデンシャルソースを確認します。何も見つからない場合は、エラーが発生します。
以下の手順では、プロセスがテナントのクレデンシャルソースを検証する方法を説明します。
providerAccountRef リソース属性からのクレデンシャルを確認します。これはシークレットのローカル参照です (例: mytenant)。
apiVersion: capabilities.3scale.net/v1beta1 kind: Backend metadata: name: backend-1 spec: name: "My Backend Name" privateBaseURL: "https://api.example.com" 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 テナント (プロバイダーアカウント) に必要なクレデンシャルを自動的に収集します。