IBM Cloud Docs
サービス・ブローカーの開発、ホスティング、およびテスト

サービス・ブローカーの開発、ホスティング、およびテスト

IBM Cloud® プラットフォームはサービス・ブローカーと相互作用して、サービス・インスタンスとサービス・バインディングを作成・管理する。 公開されている IBM Cloud サービス・ブローカー・サンプル、Open Service Broker リファレンス・アプリケーション、Open Service Broker API ドキュメントを組み合わせて、ブローカーを構築することができます。

サービスを IBM Cloudにオンボードする場合、サービスのライフサイクルと計量統合を管理するために、1 つ以上のサービス・ブローカーを作成する必要があります。 詳しくは、 計量の統合 を参照してください。

サービス・ブローカーとは何か?

サービス・ブローカーは、サービスのライフサイクルを管理します。 プラットフォームは、サービス・ブローカーと対話して、サービス・ブローカーが提供するサービスを作成、アクセス、および管理します。 Open Service Broker API は、これらの対話を定義して、ソフトウェア・プロバイダーが選択するテクノロジーやインフラストラクチャーに関係なく、ソフトウェア・プロバイダーがサービスを誰にでも提供できるようにします。 サービス・ブローカーは、製品のサービス・インスタンスの自動プロビジョニングを処理するミドルウェア・コンポーネントとして機能し、サービス・インスタンスの使用状況の追跡に役立ちます。

ブローカーは、複数のベンダーにまたがる Software as a Service、Platform as a Service、または Infrastructure as a Service を開発して提供する場合に役立ちます。 お客様のプロビジョニングとバインディングを自動化するサービス・ブローカーを導入することで、ビジネス価値を高めることができます。 また、このようなクロスカットの問題に対処するミドルウェア・コンポーネントにより、お客様の管理と使用状況の追跡が容易になります。 ただし、任意の仮想マシンまたはプラットフォームにデプロイできるカスタム・ソフトウェアがある場合は、サービス・ブローカーは適していません。

ユーザーが IBM Cloud カタログからサービスとその価格プランを選択してインスタンスを作成すると、価格プランとメトリックを含むサービスのデータがサービス・ブローカーに送信されます。 ブローカーは、サービス・インスタンスのプロビジョニングと、選択した価格プランのメトリックを管理するバックエンド・システムと統合されます。 お客様が製品のインスタンスを削除すると、サービス・ブローカーに要求が送信され、インスタンスのプロビジョン解除が管理されます。

図 1. ユーザーが IBM Cloud カタログから製品を選択する際のサービス・ブローカーの役割について説明します。
ユーザーがカタログから製品を選択したときにサービス・ブローカーが実行する役割をサード・パーティー・プロバイダーが示す図。

ブローカー・アーキテクチャーは、開発チームと運用チームの両方に大きな利点を提供します。

  • 開発者は、必要なバッキング・サービスにアプリケーションとコンテナーを接続できます。 バッキング・サービスに関係なく、操作は同じです。
  • オペレーターは、サービスへのアクセス権限を手動で作成して委任する必要がなくなりました。 代わりに、サービスおよびサービス・プランのマーケットプレイスを構成します。 そこから開発者はセルフサービスができ、多くの企業が今日直面している管理コストを削減できます。

Open Service Broker API 仕様に組み込まれている各サービス・ブローカーには、同じ直観的なライフサイクル・コマンド・セットがあります。 これらのコマンドは、サービス・ブローカーにとって便利な利点を提供します。

サービス・ブローカーが提供するバッキング・サービスのカタログの取り出し
カタログには、サービス・ブローカーを介して作成できるすべてのサービスが記述されており、各サービスはプランで構成されています。 プランは通常、サービスの特定のバリアントのコストとメリットを表します。 多くのサービスは、製品のサイズ (小規模、中規模、大規模など) に関連したプランを使用します。
新規サービス・インスタンスのプロビジョニング
サービス・インスタンスは、サービス・ブローカーのカタログに記述されているサービスおよびプランの作成済みインスタンスです。
それらのサービス・インスタンスからのアプリケーションおよびコンテナーの接続および切断
サービス・インスタンスの作成時に、アプリケーションまたはコンテナーがそのインスタンスとの通信を開始するようにします。 サービス・ブローカーの観点からは、これはサービス・バインディングと呼ばれます。
サービス・インスタンスのプロビジョン解除
このアクションにより、サービス・インスタンスの初回作成時に作成されたすべてのリソースが削除されます。

開始前に

ブローカーのビルド

以下のドキュメントとサンプル・アプリケーションを使用して、必要な仕様のブローカーを設定し、デプロイします:

次のサンプル・アプリケーションを確認してください:

必要なエンドポイントの組み込み

すべてのサービス・ブローカーは、特定の必須エンドポイントを設定する必要があります。 バインド可能サービスおよびサービス・インスタンスの無効化と再有効化には、追加のエンドポイント・ロジックが必要です。

すべてのサービス・ブローカーに必要なエンドポイント・ロジック

サービス・ブローカーは、REST API が取り込むメタデータ値の標準セットを提供する必要があります。また、IBM Cloud ブローカーには、以下の REST API エンドポイントまたはパスのロジックが含まれている必要があります。

カタログ (GET)
ブローカーに含まれるカタログ・メタデータを戻します。
リソース・インスタンス (PUT)
サービス・インスタンスを作成します。
リソース・インスタンス (DELETE)
サービス・インスタンスを削除します。
リソース・インスタンス (PATCH)
サービス・インスタンスを更新します。

カタログ (GET) に関する注: このエンドポイントは、ブローカーがサポートするサービスとプランについて、ブローカーと IBM Cloud プラットフォーム間の契約を定義します。 このエンドポイントは、ブローカー内に保存されているカタログ・メタデータを返します。 これらの値は、あなたのサービスと IBM Cloud プラットフォーム間の最小限の契約を定義します。 必要でない追加のカタログ・メタデータはすべて、 IBM Cloud カタログ内に保存される。 リンクやアイコンなどのカタログ表示値に対する更新は、 IBM Cloud コンソールで更新する必要があり、ブローカーには含まれていません。 ブローカーに保管されたメタデータは、IBM Cloud コンソールでも IBM Cloud CLI でも表示されません。 コンソールと CLI は、Partner Center Sell 内で設定され、 IBM Cloud カタログに保存された内容を返します。 次のセクションでは、catalog(GET)が返す最低限必要な値を示す:

{
       "services": [{
           "id": "0bc9d744-6f8c-4821-9648-2278bf6925bb",
           "name": "ibmcloud-link",
           "description": "An IBM provided service that enables aliasing to service instances in the IBM Cloud.",
           "bindable": true,
           "plan_updateable": false,
           "plans": [
               {
                   "id": "da40662d-2f72-4a19-8c79-8c77cf285e1",
                   "name": "ibmcloud-alias",
                   "free": true,
                   "description": "The IBM Cloud alias plan used for linking."
               }
               ]
       }]
}

バインド可能なサービスに必要なエンドポイント・ロジック

サービスが IBM Cloud のアプリケーションにバインドできる場合、サービス・コンシューマーにAPIエンドポイントとクレデンシャルを返す必要がある。 バインド可能なサービスは、Open Service Broker 仕様のバインド可能な操作を使用して、以下のエンドポイントまたはパスを実装する必要があります。

バインディングと資格情報 (PUT)
サービス・インスタンスをアプリケーションにバインドします。
バインディングと資格情報 (DEL)
サービス・インスタンスをアプリケーションからアンバインドします。

必要な IBM Cloud 拡張エンドポイント

OSB 仕様では、使用不可のインスタンス状態はサポートされていません。 無効状態には、支払いの欠落や、アカウントのサスペンド (ただし、まだ取り消されていない) につながるその他の状況が含まれます。これは、削除されたインスタンス状態とは異なります。 IBM Cloud で、無効な状態が発生する可能性があるお客様をサポートするために、 IBM Cloud は、サービス・インスタンスを無効化および再有効化できる拡張 API エンドポイントを定義しました。 以下のエンドポイント拡張が必要です:

インスタンスの有効化と無効化 (GET)
状況 - サービス・インスタンスの状態を戻します。
インスタンスの有効化と無効化 (PUT)
サービス・インスタンスを有効または無効にします。

無効化エンドポイントが開始されたときにサービス・インスタンスへのアクセスを無効化すること、および有効化エンドポイントが開始されたときにそのアクセスを再有効化することは、サービス・プロバイダーの責任で行います。

IBM Cloud プラットフォームで提供されるブローカー情報

サービス・ブローカーは、IBM Cloud プラットフォームから以下の情報を受け取ります。

X-Broker-API-Originating-Identity

ユーザーIDヘッダーは、API発信IDヘッダーを通して提供される。 この要求ヘッダーには、ユーザーの IBM Cloud IAM ID が含まれます。 IAM ID は base64 エンコードされます。IBM Cloud は、単一の認証レルム IBMid をサポートします。 IBMid レルムは、IBMid Unique ID (IUI) を使用して、IBM Cloud でユーザーの ID を識別します。 この IUI は、サービス・プロバイダーに内部が見えないストリングです。

例:

X-Broker-API-Originating-Identity: ibmcloud eyJpYW1faWQiOiJJQk1pZC01MEdOUjcxN1lFIn0=
Decoded:
{"iam_id":"IBMid-50GNR717YE"}

API ヘッダー・バージョン

API バージョン・ヘッダー2.12です。 例えば、X-Broker-Api-Version: 2.12 などです。

リソース・インスタンス (PUT) の body.context とリソース・インスタンス (PATCH) の body.context

PUT /v2/service_instances/:resource_instance_idPATCH /v2/service_instances/:resource_instance_id は、body.context 内の次の値を受け取ります。{ "platform": "ibmcloud", "account_id": "tracys-account-id", "crn": "resource-instance-crn" }

ブローカーに関するその他の推奨

同期操作ではなく、非同期を使用することに関する推奨

OSB API は、操作の同期モードと非同期モードの両方をサポートします。 操作にかかる時間が 10 秒未満の場合は、同期応答を使用する必要があります。 それ以外の場合は、非同期モードの操作を使用してください。 非同期モードには、 last_operation エンドポイントが必要です。 詳しくは、 サービス・インスタンスの進行中のプロビジョンの状況の取得 を参照してください。

ロケーションをまたがるブローカーの管理に関する推奨

ユーザーが、待ち時間、可用性、データ常駐のためにクラウド・サービスのロケーションを理解することは重要です。

IBM Cloud でサービス・インスタンスを作成する場合、ユーザーが提供する必須パラメーターの1つは、サービス・インスタンスを作成する場所である。 サービスによっては、複数の場所での作成に対応できるものもある。 例えば、データベースサービスは、 IBM Cloud のすべてのリージョンでの作成をサポートすることも、サブセットをサポートすることもできる。

サード・パーティーの API ベースのサービスが別のクラウドで実装されていて IBM Cloud に公開される場合、ロケーションは、そのもう一方のクラウドにおけるサービスのロケーションを示します。

IBM Cloud にオンボードする場合、少なくとも 1 つの OSB ブローカーを実装する必要があります。 デプロイメント戦略およびサービスでサポートするロケーションに応じて、複数のブローカーを持つことができます。 Partner Center Sell では、価格設定プランとブローカーの間のマッピングを確立します。 典型的な選択肢は、サービスの全ロケーションにサービスを提供する単一のブローカーを定義するか、ロケーションごとにブローカーを定義するかである。

使用可能なロケーションのリストについては、 IBM グローバル・カタログのロケーションを確認してください。 サービスで追加のロケーションを定義する必要がある場合は、IBM Cloud オンボーディング・チームに相談してください。

ブローカーのホスティング

ブローカーは、REST API 呼び出しに応答できるアプリケーションの一部としてホストされる必要があり、ホストされる場所は IBM Cloud セキュリティガイドラインを満たす必要があります。 ブローカーを IBM Cloud 内でホストすることもできるし、 IBM Cloud 自体から一般にアクセスできるのであれば、外部でホストすることもできる。

IBM の外部でブローカーをホストするには、以下のセキュリティー・ガイドラインを満たしている必要があります。

  • トランスポート・レイヤー・セキュリティ(TLS)プロトコルのバージョン 1.2 に従うこと。 詳しくは、 TLS プロトコルの概要を参照してください。
  • パブリック・インターネットでアクセスできる有効な HTTPS エンドポイントでホストされる必要があります。

サービスのブローカーのテスト

有効にしたさまざまなエンドポイントに対して curl コマンドを実行して、ブローカーを検証する必要があります。 サービス・ブローカーがホストされている場所と、アプリケーションに関連付けられた URL と認証情報が必要です。 ブローカーをテストするには、以下の方法を使うことができる:

サービスブローカーをテストしている間、リソースコントローラーは設定された認証スキームを使用してブローカーにリクエストを行います。 ブローカーが、サポートされている認証方法のいずれかを実装していることを確認し、適切な検証と認可を行うようにしましょう。 詳細については、「 ブローカーの認証スキーム 」を参照のこと。

curl 要求の例

ブローカーの curl 応答をテストするには、以下の例を使用してください。

curl -X PUT  https://<sample-service-broker>/v2/service_instances/<encoded-resource-crn> \
     -u '<your broker user>:<your broker password>' \
     -H 'content-type: application/json' \
      -d '{ "context": {"platform": "ibmcloud", \
                        "account_id": "34ff5928-c3c7-4d46-bbf6-1a5628c325d1", \
                        "resource_group_crn": "crn:v1:bluemix:public:resource-controller::a/003e9bc3993aec710d30a5a719e57a80::resource-group:b4570a825f7f4d57aa54e8e1d9507926", \
                        "crn": "<resource-crn>", \
                        "target_crn": "<target_crn>"}, \
            "service_id": "a07f025c-90db-4652-afd1-cf4adfac93c8", \
            "plan_id": "fe442cec-2eef-41fe-9f92-58d6c094584f"}'