Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第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. 概念および用語

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

クラスターサービスブルーカー は、OSB API 仕様に準拠し、1 つ以上のサービスのセットを管理するサーバーです。ソフトウェアが独自の OpenShift Container Platform クラスター内またはその他の場所でホストされる可能性があります。

クラスター管理者は、クラスターサービスブローカーを表す 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: [...]

クラスターサービス計画
クラスターサービスプラン は、クラスターサービスクラスの階層を指します。たとえば、クラスターサービスクラスは、さまざまなレベルの quality-of-service (QoS) を提供するプランを公開し、それそれに異なるコストが関連付けられています。
サービスインスタンス

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

新規の 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 デプロイメントのアーティファクトを指します。
認証情報
認証情報 とは、サービスインスタンスと通信するアプリケーションで必要な情報です。
サービスバインディング

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

サービスバインディングの作成時に、サービスカタログコントローラーはサービスインスタンスの接続情報と認証情報を含む Kubernetes のシークレットを作成します。これらのシークレットは通常どおり Pod にマウントできます。また、PodPresets とも統合され、これでシークレットの使用方法や使用する pod などを表現できます。

ServiceBinding リソースの例

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

parameters

パラメーター は、サービスバインディングまたはサービスインスタンスの使用時に、追加のデータをクラスターサービスブローカーに渡すために提供されている特別なフィールドです。唯一のフォーマット要件は、パラメーターを有効な 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. サービスカタログのコマンドラインインターフェース (CLI)

6.2.1. 概要

サービスカタログと対話する 「基本的なワークフロー」は以下のとおりです。

  • クラスター管理者は、ブローカーサーバーをインストールして登録し、ブローカーサーバーのサービスを利用できるようにします。
  • ユーザーは、OpenShift プロジェクトでこれらをインスタンス化して、サービスインスタンスとその Pod をリンクすることで、このようなサービスを使用します。

svcat というサービスカタログコマンドラインインターフェース (CLI) ユーティリティーは、このようなユーザー関連のタスクに対応するために提供されています。oc コマンドは同様のタスクを実行できますが、svcat を使用して、サービスカタログのリソースとの対話を簡素化することができます。svcat は、OpenShift クラスター上に集約された API エンドポイントを使用してサービス API と通信します。

6.2.2. svcat のインストール

お使いの Red Hat アカウントに有効な OpenShift Enterprise サブスクリプションがある場合には、Red Hat Subscription Management (RHSM) を使用して RPM として svcat をインストールできます。

# yum install atomic-enterprise-service-catalog-svcat

6.2.2.1. クラウドプロバイダーの留意点

Google Compute Engine: Google Cloud Platform では、以下のコマンドを使用して、受信トラフィックを許可するファイアウォールルーツを設定します。

$ gcloud compute firewall-rules create allow-service-catalog-secure --allow tcp:30443 --description "Allow incoming traffic on 30443 port."

6.2.3. svcat の使用

以下のセクションでは、「サービスカタログのワークフロー」に記載のユーザー関連タスクを処理するための一般的なコマンドについて紹介します。svcat --help コマンドを使用して詳細情報を取得し、他に利用可能なコマンドオプションを表示できます。このセクションでの出力例は、Ansible Service Broker がすでにクラスターにインストールされていることが前提です。

6.2.3.1. ブローカーの詳細取得

利用可能なブローカー一覧の表示、ブローカーカタログの動機、サービスカタログにデプロイされたブローカーの詳細の取得が可能です。

6.2.3.1.1. ブローカーの検索

クラスターにインストールされた全ブローカーを表示します。

$ svcat get brokers
           NAME                                                        URL                                              STATUS
+-------------------------+-------------------------------------------------------------------------------------------+--------+
  ansible-service-broker    https://asb.openshift-ansible-service-broker.svc:1338/ansible-service-broker                Ready
  template-service-broker   https://apiserver.openshift-template-service-broker.svc:443/brokers/template.openshift.io   Ready
6.2.3.1.2. ブローカーカタログの同期

ブローカーからのカタログメタデータを更新します。

$ svcat sync broker ansible-service-broker
Synchronization requested for broker: ansible-service-broker
6.2.3.1.3. ブローカーの詳細表示

ブローカーの詳細を表示します。

$ svcat describe broker ansible-service-broker
  Name:     ansible-service-broker
  URL:      https://openshift-automation-service-broker.openshift-automation-service-broker.svc:1338/openshift-automation-service-broker/
  Status:   Ready - Successfully fetched catalog entries from broker @ 2018-06-07 00:32:59 +0000 UTC

6.2.3.2. サービスクラスおよびサービスプランの表示

ClusterServiceBroker リソースの作成時に、サービスカタログコントローラーはブローカーサーバーに対してクエリーを実行して提供する全サービスを検索して、それらのサービスごとにサービスクラス (ClusterServiceClass) を作成します。さらに、ブローカーのサービスごとにサービスプラン (ClusterServicePlan) も作成します。

6.2.3.2.1. サービスクラスの表示

利用可能な ClusterServiceClass リソースを表示します。

$ svcat get classes
        NAME                   DESCRIPTION
+-------------------+--------------------------------+
  rh-mediawiki-apb    Mediawiki apb implementation

  ...

  rh-mariadb-apb      Mariadb apb implementation
  rh-mysql-apb        Software Collections MySQL APB
  rh-postgresql-apb   SCL PostgreSQL apb
                      implementation

サービスクラスの詳細を表示します。

$ svcat describe class rh-postgresql-apb
  Name:          rh-postgresql-apb
  Description:   SCL PostgreSQL apb implementation
  UUID:          d5915e05b253df421efe6e41fb6a66ba
  Status:        Active
  Tags:          database, postgresql
  Broker:        ansible-service-broker

Plans:
  NAME            DESCRIPTION
+------+--------------------------------+
  prod   A single DB server with
         persistent storage
  dev    A single DB server with no
         storage
6.2.3.2.2. サービスプランの表示

クラスターで利用可能な ClusterServicePlan リソースを表示します。

$ svcat get plans
   NAME           CLASS                  DESCRIPTION
+---------+-------------------+--------------------------------+
  default   rh-mediawiki-apb    An APB that deploys MediaWiki

  ...

  prod      rh-mariadb-apb      This plan deploys a single
                                MariaDB instance with 10 GiB
                                of persistent storage
  dev       rh-mariadb-apb      This plan deploys a single
                                MariaDB instance with
                                ephemeral storage
  prod      rh-mysql-apb        A MySQL server with persistent
                                storage
  dev       rh-mysql-apb        A MySQL server with ephemeral
                                storage
  prod      rh-postgresql-apb   A single DB server with
                                persistent storage
  dev       rh-postgresql-apb   A single DB server with no
                                storage

プランの詳細を表示します。

$ svcat describe plan rh-postgresql-apb/dev
  Name:          dev
  Description:   A single DB server with no storage
  UUID:          9783fc2e859f9179833a7dd003baa841
  Status:        Active
  Free:          true
  Class:         rh-postgresql-apb

Instances:
No instances defined

Instance Create Parameter Schema:
  $schema: http://json-schema.org/draft-04/schema
  additionalProperties: false
  properties:
    postgresql_database:
      default: admin
      pattern: ^[a-zA-Z_][a-zA-Z0-9_]*$
      title: PostgreSQL Database Name
      type: string
    postgresql_password:
      pattern: ^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:|]+$
      title: PostgreSQL Password
      type: string
    postgresql_user:
      default: admin
      maxLength: 63
      pattern: ^[a-zA-Z_][a-zA-Z0-9_]*$
      title: PostgreSQL User
      type: string
    postgresql_version:
      default: "9.6"
      enum:
      - "9.6"
      - "9.5"
      - "9.4"
      title: PostgreSQL Version
      type: string
  required:
  - postgresql_database
  - postgresql_user
  - postgresql_password
  - postgresql_version
  type: object

Instance Update Parameter Schema:
  $schema: http://json-schema.org/draft-04/schema
  additionalProperties: false
  properties:
    postgresql_version:
      default: "9.6"
      enum:
      - "9.6"
      - "9.5"
      - "9.4"
      title: PostgreSQL Version
      type: string
  required:
  - postgresql_version
  type: object

Binding Create Parameter Schema:
  $schema: http://json-schema.org/draft-04/schema
  additionalProperties: false
  type: object

6.2.3.3. サービスのプロビジョニング

プロビジョニングとは、サービスが利用できるように提供することです。サービスをプロビジョニングするには、サービスインスタンスを作成して、そのインスタンスにバインドする必要があります

6.2.3.3.1. ServiceInstance の
注記

サービスインスタンスは、OpenShift namespace 内に作成する必要があります。

  1. 新規プロジェクトを作成します。

    $ oc new-project <project-name> 1
    1
    <project-name> は、プロジェクト名に置き換えます。
  2. 以下のコマンドを使用してサービスインスタンスを作成します。

    $ svcat provision postgresql-instance --class rh-postgresql-apb --plan dev --params-json  '{"postgresql_database":"admin","postgresql_password":"admin","postgresql_user":"admin","postgresql_version":"9.6"}' -n szh-project
      Name:        postgresql-instance
      Namespace:   szh-project
      Status:
      Class:       rh-postgresql-apb
      Plan:        dev
    
    Parameters:
      postgresql_database: admin
      postgresql_password: admin
      postgresql_user: admin
      postgresql_version: "9.6"
6.2.3.3.1.1. サービスインスタンスの詳細表示

サービスインスタンスの詳細を表示します。

$ svcat get instance
         NAME            NAMESPACE          CLASS         PLAN   STATUS
+---------------------+-------------+-------------------+------+--------+
  postgresql-instance   szh-project   rh-postgresql-apb   dev    Ready
6.2.3.3.2. ServiceBinding の作成

ServiceBinding リソースを作成する場合:

  1. サービスカタログコントローラーは、ブローカーサーバーと通信して、バインディングを開始します。
  2. ブローカーサーバーは、認証情報を作成し、サービスカタログコントローラーに対してその認証情報を発行します。
  3. サービスカタログコントローラーは、これらの認証情報をシークレットとしてプロジェクトに追加します。

以下のコマンドを使用してサービスバインディングを作成します

$ svcat bind postgresql-instance --name mediawiki-postgresql-binding
  Name:        mediawiki-postgresql-binding
  Namespace:   szh-project
  Status:
  Instance:    postgresql-instance

Parameters:
  {}
6.2.3.3.2.1. サービスバインディングの詳細表示
  1. サービスバインディングの詳細を表示します。

    $ svcat get bindings
                  NAME                NAMESPACE         INSTANCE         STATUS
    +------------------------------+-------------+---------------------+--------+
      mediawiki-postgresql-binding   szh-project   postgresql-instance   Ready
  2. サービスのバインディング後にインスタンスの詳細を確認します。

    $ svcat describe instance postgresql-instance
      Name:        postgresql-instance
      Namespace:   szh-project
      Status:      Ready - The instance was provisioned successfully @ 2018-06-05 08:42:55 +0000 UTC
      Class:       rh-postgresql-apb
      Plan:        dev
    
    Parameters:
      postgresql_database: admin
      postgresql_password: admin
      postgresql_user: admin
      postgresql_version: "9.6"
    
    Bindings:
                  NAME               STATUS
    +------------------------------+--------+
      mediawiki-postgresql-binding   Ready

6.2.4. リソースの定義

サービスカタログに関連するリソースを削除するには、サービスバインディングのバインドと、サービスインスタンスのプロビジョニングを解除する必要があります

6.2.4.1. サービスバインディングの削除

  1. サービスインスタンスに関連付けられた全サービスバインディングを削除します。

    $ svcat unbind -n <project-name> 1
      \ <instance-name> 2
    1
    サービスインスタンスを含むプロジェクト名
    2
    バインディングに関連するサービスインスタンス名

    以下に例を示します。

    $ svcat unbind -n szh-project postgresql-instance
    deleted mediawiki-postgresql-binding
    
    $ svcat get bindings
      NAME   NAMESPACE   INSTANCE   STATUS
    +------+-----------+----------+--------+
    注記

    このコマンドを実行すると、インスタンスに対するサービスバインディングすべてを削除します。インスタンス内から個別のバインディングを削除するには、svcat unbind -n <project-name> --name <binding-name> のコマンドを実行します。たとえば、svcat unbind -n szh-project --name mediawiki-postgresql-binding などです。

  2. 関連のシークレットが削除されたことを確認します。

    $ oc get secret -n szh-project
    NAME                       TYPE                                  DATA      AGE
    builder-dockercfg-jxk48    kubernetes.io/dockercfg               1         9m
    builder-token-92jrf        kubernetes.io/service-account-token   4         9m
    builder-token-b4sm6        kubernetes.io/service-account-token   4         9m
    default-dockercfg-cggcr    kubernetes.io/dockercfg               1         9m
    default-token-g4sg7        kubernetes.io/service-account-token   4         9m
    default-token-hvdpq        kubernetes.io/service-account-token   4         9m
    deployer-dockercfg-wm8th   kubernetes.io/dockercfg               1         9m
    deployer-token-hnk5w       kubernetes.io/service-account-token   4         9m
    deployer-token-xfr7c       kubernetes.io/service-account-token   4         9m

6.2.4.2. サービスインスタンスの削除

サービスインスタンスのプロビジョニングを解除します。

$ svcat deprovision postgresql-instance
deleted postgresql-instance

$ svcat get instance
  NAME   NAMESPACE   CLASS   PLAN   STATUS
+------+-----------+-------+------+--------+

6.2.4.3. サービスブローカーの削除

  1. サービスカタログのブローカーサービスを削除するには、ClusterServiceBroker リソースを削除します。

    $ oc delete clusterservicebrokers template-service-broker
    clusterservicebroker "template-service-broker" deleted
    
    $ svcat get brokers
               NAME                                                        URL                                              STATUS
    +-------------------------+-------------------------------------------------------------------------------------------+--------+
      ansible-service-broker    https://asb.openshift-ansible-service-broker.svc:1338/ansible-service-broker                Ready
  2. ブローカーの ClusterServiceClass リソースを表示して、ブローカーが削除されたことを確認します。

    $ svcat get classes
      NAME   DESCRIPTION
    +------+-------------+

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

 

テンプレートサービスブローカー (TSB) では、OpenShift Container Platform の最初のリリースより同梱されている「デフォルトのインスタントアプリおよびクイックスタートテンプレート」でサービスカタログが確認できるようになります。TSB は、Red Hat、クラスター管理者、ユーザー、サードパーティベンダーの誰が提供したものでも、OpenShift Container Platform「テンプレート」に書き込まれたものはサービスとして提供できます。

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

6.4. OpenShift Ansible Broker

6.4.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. OAB は定義されたコンテナーレジストリーと通信し、利用可能な APB を把握します。
  4. ユーザーは特定の APB をプロビジョニングする要求を実行します。
  5. プロビジョニング要求は OAB に移動し、APB でプロビジョニングメソッドを呼び出して、ユーザー要求に対応します。

6.4.2. Ansible Playbook Bundle

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

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

全体の設計および APB の作成方法についての詳細は、『APB Development Guide』を参照してください。