第6章 サービスカタログコンポーネント


6.1. サービスカタログ

6.1.1. 概要

マイクロサービスベースのアプリケーションを開発して、クラウドネイティブのプラットフォームで実行する場合には、サービスプロバイダーやプラットフォームに合わせて、異なるリソースをプロビジョンして、その従属、認証情報、設定を共有する方法は多数あります。

開発者がよりシームレスに作業できるように、OpenShift Container Platform には Kubernetes 向けの Open Service Broker API (OSB API) の実装である サービスカタログ が含まれています。これにより、OpenShift Container Platform にデプロイされているアプリケーションをさまざまな種類のサービスブローカーに接続できます。

サービスカタログでは、クラスター管理者が 1 つの API 仕様を使用して、複数のプラットフォームを統合できます。OpenShift Container Platform Web コンソールは、サービスカタログにサービスブローカーによって提供されるクラスターサービスカタログを表示するので、ユーザーはこれらのサービスをそれぞれのアプリケーションで使用できるようにサービスの検出やインスタンス化を実行できます。

このように、サービスユーザーは異なるプロバイダーが提供する異なるタイプのサービスを簡単かつ一貫性を保ちながら使用できるという利点が得られます。また、サービスプロバイダーは、複数のプラットフォームにアクセスできる統合ポイントから利点を得られます。

6.1.2. 設計

サービスカタログの設計は基本的なワークフローに基づいています。

注記

以下の新規の用語は「概念および用語」でさらに定義されています。

Service Catalog Architecture
クラスター管理者は、1 つまたは複数の クラスターサービスブローカー を OpenShift Container Platform クラスターに登録します。これは、デフォルトで提供されているサービスブローカーでインストール時に自動的に行うことも、手動で行うことも可能です。
各サービスブローカーは、ユーザーに提供すべき クラスターサービスクラス セットと、これらのサービスのバリエーション (サービスプラン) を、OpenShift Container Platform に指定します。
OpenShift Container Platform web コンソールまたは CLI を使用して、ユーザーは利用可能なサービスを検出します。たとえば、クラスターサービスクラスは、BestDataBase と呼ばれる database-as-a-service などの、サービスクラスが利用できる可能性があります。
ユーザーは、クラスターサービスクラスを選択して、自身の新しい インスタンス を要求します。たとえば、サービスは my_dbという名前の BestDataBase インスタンスなどです。
ユーザーは、サービスを pod セット (アプリケーション) にリンクまたは バインド します。たとえば、my_db サービスインスタンスは、my_app と呼ばれるユーザーアプリケーションにバインドできます。

ユーザーがリソースのプロビジョニングおよびプロビジョニング解除を要求すると、この要求はサービスカタログに送信され、次に適切なクラスターサービスブローカーに要求が送信されます。サービスによっては、provisiondeprovision および update などの操作に時間がかかる可能性があります。クラスターサービスブローカーが利用できない場合には、サービスカタログはこの操作の再試行を続けます。

このインフラストラクチャーでは、OpenShift Container Platform で実行中のアプリケーションと、それが使用するサービスの間で疎結合することができます。こうすることで、これらのサービスを使用するアプリケーションが独自のビジネスロジックにフォーカスし、サービスの管理をプロバイダーに任せることができます。

6.1.2.1. リソースの定義

ユーザーがサービスを使用し終えた場合 (または、請求しなくてもいい場合) には、このサービスインスタンスは削除できます。サービスインスタンスを削除するには、サービスのバインドを先に削除する必要があります。サービスのバインドの削除は、バインド解除 と呼ばれます。削除のプロセスで、削除予定のサービスバインディングを参照するシークレットも削除します。

サービスバインディングが削除されると、サービスインスタンスを削除できあす。サービスインスタンスの削除は プロビジョニング解除 として知られています。

サービスバインディングやサービスインスタンスが含まれるプロジェクトや namespace を削除する場合は、サービスカタログは先にクラスターサービスブローカーに、関連のインスタンスとバインディングを削除するように要求する必要があります。これにより、サービスカタログは、クラスターのサービスブローカーと通信して、プロビジョニング解除を行うまで待つ必要があるので、実際のプロジェクトや namespace の削除が遅延してしまうことが予想されます。通常の状況では、サービスにより異なりますが、数分以上かかる場合があります。

注記

デプロイメントで使用されるサービスバインディングを削除する場合、デプロイメントからバインディングの参照を削除する必要もあります。そうしないと、次のロールアウトは失敗します。

6.1.3. 概念および用語

クラスターサービスブローカー

A cluster service broker is a server that conforms to the OSB API specification and manages a set of one or more services. The software could be hosted within| your own OpenShift Container Platform cluster or elsewhere.

クラスター管理者は、クラスターサービスブローカーを表す ClusterServiceBroker API リソースを作成して、OpenShift Container Platform クラスターに登録できます。これにより、クラスター管理者はクラスター内で利用可能なクラスターサービスブローカーを使用して新しい種類の管理済みサービスを作成できるようになります。

ClusterServiceBroker リソースは、クラスターサービスブローカーの接続詳細と、サービスセット (およびこれらのサービスのバリエーション) を OpenShift Container Platform に指定すると、ユーザーに提供できるはずです。authInfo セクションには、クラスターサービスブローカーの認証に使用するデータが含まれている点に特に注意してください。

ClusterServiceBroker リソースの例

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ClusterServiceBroker
metadata:
  name: BestCompanySaaS
spec:
  url: http://bestdatabase.example.com
  authInfo:
    basic:
      secretRef:
        namespace: test-ns
        name: secret-name

クラスターサービスクラス

また、サービスカタログのコンテキストで「サービス」と類義の クラスターサービスクラス は、特定のクラスターサービスブローカーが提供する管理サービスの 1 種です。新しいクラスターサービスブローカーのリソースがクラスターに追加されるたびに、サービスカタログコントローラーは、適切なクラスターサービスブローカーに接続し、サービスオファリングの一覧を取得します。新しい ClusterServiceClass リソースは自動的に、クラスターサービスブローカーごとに作成されます。

注記

さらに、OpenShift Container Platform には、サービスと呼ばれるコアとなるコンセプトがあります。サービスとは、内部の負荷分散に関連する別個の Kubernetes リソースです。これらのリソースは、サービスカタログや OSB API のコンテキストで使用する用語と混同しないようにしてください。

ClusterServiceClass リソースの例

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ClusterServiceClass
metadata:
  name: smallDB
  brokerName: BestDataBase
  plans: [...]

クラスターサービス計画
A cluster service plan is represents tiers of a cluster service class. For example, a cluster service class may expose a set of plans that offer varying degrees of quality-of-service (QoS), each with a different cost associated with it.
サービスインスタンス

サービスインスタンス は、プロビジョニングされたクラスターサービスクラスのインスタンスです。サービスクラスが提供する機能を使用する場合には、新しいサービスインスタンスを作成してください。

新規の ServiceInstance リソースを作成した場合には、サービスカタログコントローラーは、適切なクラスターサービスブローカーと接続して、サービスインスタンスをプロビジョニングするように指示を出します。

ServiceInstance リソースの例

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
  name: my_db
  namespace: test-ns
spec:
  externalClusterServiceClassName: smallDB
  externalClusterServicePlanName: default

アプリケーション
アプリケーション という用語は、サービスインスタンス を使用する ユーザーのプロジェクトで実行中の pod など、OpenShift Container Platform デプロイメントのアーティファクトを指します。
認証情報
認証情報 とは、サービスインスタンスと通信するアプリケーションで必要な情報です。
サービスバインディング

サービスバインディング は、サービスインスタンスとアプリケーションの間のリンクを指します。サービスバインディングは、アプリケーションからサービスインスタンスを参照して使用できるように希望するクラスターユーザーが作成します。

Upon creation, the service catalog controller creates a Kubernetes secret containing connection details and credentials for the service instance. Such secrets can be mounted into pods as usual. There is also integration with PodPresets, which allow you to express how the secret should be consumed, and in which pods.

ServiceBinding リソースの例

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
  name: myBinding
  namespace: test-ns
spec:
  instanceRef:
    name: my_db
  parameters:
    securityLevel: confidential
  secretName: mySecret

パラメーター

パラメーター は、サービスバインディングまたはサービスインスタンスの使用時に、追加のデータをクラスターサービスブローカーに渡すために提供されている特別なフィールドです。唯一のフォーマット要件は、パラメーターを有効な YAML (または JSON) で指定することです。上記の例では、セキュリティーレベルのパラメーターをサービスバインディング要求でクラスターサービスブローカーに渡します。より高度なセキュリティーが必要なパラメーターの場合は、パラメーターをシークレットに配置し、parametersFrom を使用して参照します。

シークレットを参照するサービスバインディングリソースの例

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
  name: myBinding
  namespace: test-ns
spec:
  instanceRef:
    name: my_db
  parametersFrom:
    - secretKeyRef:
        name: securityLevel
        key: myKey
  secretName: mySecret

6.1.4. 提供されるクラスターサービスブローカー

OpenShift Container Platform は、サービスカタログで使用する以下のクラスターサービスブローカーを提供します。

6.2. テンプレートサービスブローカー

 

The template service broker (TSB) gives the service catalog visibility into the default Instant App and Quickstart templates that have shipped with OpenShift Container Platform since its initial release. The TSB can also make available as a service anything for which an OpenShift Container Platform template has been written, whether provided by Red Hat, a cluster administrator or user, or a third party vendor.

デフォルトでは、TSB は openshift プロジェクトからグローバルで入手可能なオブジェクトを表示します。また、クラスター管理者が選択する他のプロジェクトを監視するように設定することも可能です。

6.3. OpenShift Ansible Broker

6.3.1. 概要

OpenShift Ansible Broker (OAB) は、Ansible playbook bundle (APB) で定義されるアプリケーションを管理する Open Service Broker (OSB) API の実装です。 APB は、Ansible ランタイムと、コンテナイメージに同梱されている Ansible playbook のバンドルで構成されており、OpenShift Container Platform のコンテナーアプリケーションを定義、配信する新しい方法を提供します。APB は Ansible を活用して、複雑なデプロイするを自動化する標準メカニズムを構築します。

OAB の設計はこの基本的なワークフローに従います。

  1. ユーザーは、OpenShift Container Platform Web コンソールを使用してサービスカタログから利用可能なアプリケーションの一覧を要求します。
  2. サービスカタログは利用可能なアプリケーションについて OAB に要求します。
  3. The OAB communicates with a defined container registry to learn which APBs are available.
  4. ユーザーは特定の APB をプロビジョニングする要求を実行します。
  5. プロビジョニング要求は OAB に移動し、APB でプロビジョニングメソッドを呼び出して、ユーザー要求に対応します。

6.3.2. Ansible Playbook Bundle

Ansible Playbook Bundle (APB) は、Ansible ロールおよび Playbook の既存の投資を利用できる軽量のアプリケーション定義です。

APB は、名前の付いた playbook が含まれる単純なディレクトリーを使用し、プロビジョニングやバインドなどの OSB API アクションを実行します。apb.yml の仕様ファイルで定義するメタデータには、デプロイメント中に使用する必須/任意のパラメーターの一覧が含まれています。

See the APB Development Guide for details on the overall design and how APBs are written.

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.