サービスバインディング


Red Hat build of Quarkus 2.13

概要

このガイドでは、現在テクノロジープレビューとして利用可能な Red Hat ビルドの Quarkus 2.13 のサービスバインディングおよびワークロードのプロジェクション機能について説明します。

第1章 サービスバインディング

本章では、バージョン 2.7.5 で Red Hat ビルドの Quarkus に追加され、バージョン 2.13 の テクノロジープレビュー にあるサービスバインディングおよびワークロードのプロジェクションについて説明します。

通常、OpenShift アプリケーションとサービスは、デプロイ可能なワークロード とも呼ばれるため、サービス URL や認証情報などの追加情報を取得するには、他のサービスに接続する必要があります。

サービスバインディング Operator は、この情報の取得に必要な通信を管理します。次に、この Operator は以下を判別します。

  • サービスコンシューマーがそのようなサービスにバインドする予定
  • quarkus-kubernetes-service-binding エクステンションなどのアプリケーションとサービスバインディングのツール

Quarkus は、サービスをアプリケーションにバインドする ために Kubernetes の Service Binding Specification をサポートします。

具体的には、Quarkus は仕様の Workload Projection 部分を実装しているため、ユーザー設定を必要とせずに、データベースやブローカーなどのサービスにアプリケーションをバインドできます。

利用可能なエクステンションのサービスバインディングを有効にするには、quarkus-kubernetes-service-binding エクステンションをアプリケーションの依存関係に追加します。

  • サービスバインディングとワークロードプロジェクションには、次のエクステンションを使用できます。

    • quarkus-jdbc-mariadb
    • quarkus-jdbc-mssql
    • quarkus-jdbc-mysql
    • quarkus-jdbc-postgresql
    • quarkus-mongo-client - テクノロジープレビュー
    • quarkus-kafka-client
    • quarkus-smallrye-reactive-messaging-kafka

1.1. ワークロードプロジェクション

ワークロードプロジェクションは、Kubernetes クラスターからサービスの設定を取得するプロセスです。この設定は、特定の規則に従うディレクトリー構造の形式を取り、アプリケーションまたはマウントされたボリュームとしてのサービスに割り当てられます。kubernetes-service-binding エクステンションは、このディレクトリー構造を使用して設定ソースを作成します。これにより、データベースやメッセージブローカーなどの追加モジュールを設定できるようになります。

アプリケーション開発中のワークロードのプロジェクションを使用して、実際のアプリケーションコードや設定を変更せずに、アプリケーションを開発データベースまたは他のローカル実行サービスに接続できます。

ディレクトリー構造が test リソースに含まれ、統合テストに渡されるワークロードプロジェクションの例は、Kubernetes Service Binding データソース GitHub リポジトリー を参照してください。

注記
  • k8s-sb ディレクトリーは、すべてのサービスバインディングのルートです。この例では、fruit-db という名前データベース 1 つのみをバインドします。このバインディングデータベースには、type file があります。これは、データベースタイプとして postgresql を示し、ディレクトリー内の他のファイルは接続を確立するために必要な情報を提供します。
  • Quarkus プロジェクトが OpenShift Container Platform によって設定された SERVICE_BINDING_ROOT 環境変数から情報を取得したら、ファイルシステムにある生成された設定ファイルを見つけて、その設定を使用して configuration-file の値を特定の拡張機能のプロパティーにマップできます。

1.2. Service Binding Operator の概要

サービスバインディング Operator は、Service Binding Specification for Kubernetes を実装する Operator であり、アプリケーションへのサービスのバインディングを単純化します。ワークロードプロジェクション をサポートするコンテナー化されたアプリケーションは、ボリュームマウントの形式でサービスバインディング情報を取得します。Service Binding Operator は、バインディングサービス情報を読み取り、それを必要とするアプリケーションコンテナーにマウントします。

アプリケーションとバインドされたサービスの相関関係は、どのサービスがどのアプリケーションにバインドされるかを宣言する ServiceBinding リソースを通して表現されます。

Service Binding Operator は ServiceBinding リソースを監視します。このリソースは、どのアプリケーションがどのサービスにバインドされるかを Operator に通知します。リストされたアプリケーションがデプロイされると、サービスバインディング Operator はアプリケーションに渡す必要のあるすべてのバインディング情報を収集し、バインディング情報を使用してボリュームマウントをアタッチしてアプリケーションコンテナーをアップグレードします。

Service Binding Operator は、次のアクションを実行します。

  • 特定のサービスにバインドすることが意図されたワークロードの ServiceBinding リソースを監視します
  • ボリュームマウントを使用してワークロードにバインディング情報を適用する

次の章では、自動および半自動のサービスバインディングアプローチとそのユースケースについて説明します。どちらかの方法では、kubernetes-service-binding 拡張機能は ServiceBinding リソースを生成します。半自動アプローチでは、ユーザーはターゲットサービスの設定を手動で提供する必要があります。自動アプローチでは、ServiceBinding リソースを生成する限定されたサービスセットに対して、追加の設定は必要ありません。

1.3. 半自動サービスバインディング

サービスバインディングプロセスでは、まずユーザーが、特定のアプリケーションにバインドされる必要なサービスを指定します。この式は、kubernetes-service-binding エクステンションによって生成された ServiceBinding リソースに要約されます。kubernetes-service-binding エクステンションを使用すると、ユーザーは最小限の設定で ServiceBinding リソースを生成できるため、プロセス全体が簡略化されます。

次に、バインディングプロセスを実行する Service Binding Operatorが ServiceBinding リソースから情報を読み取り、必要なファイルをコンテナーにマウントします。

  • ServiceBinding リソースの例:

    apiVersion: binding.operators.coreos.com/v1beta1
    kind: ServiceBinding
    metadata:
     name: binding-request
     namespace: service-binding-demo
    spec:
     application:
       name: java-app
       group: apps
       version: v1
       resource: deployments
     services:
     - group: postgres-operator.crunchydata.com
       version: v1beta1
       kind: Database
       name: db-demo
       id: postgresDB
    注記
    • quarkus-kubernetes-service-binding エクステンションを使用すると、同じ情報をよりコンパクトに表現できます。以下に例を示します。

      quarkus.kubernetes-service-binding.services.db-demo.api-version=postgres-operator.crunchydata.com/v1beta1
      quarkus.kubernetes-service-binding.services.db-demo.kind=Database

application.properties 内に以前の設定プロパティーを追加した後、quarkus-kubernetesquarkus-kubernetes-service-binding エクステンションの組み合わせにより、ServiceBinding リソースが自動的に生成されます。

前述の db-demo プロパティー設定識別子には 2 つのロールがあり、次のアクションも実行します。

  • api-version プロパティーと api-version プロパティーを相互に関連付けてグループ化します。
  • カスタムリソースの name プロパティーを定義します。これは、必要に応じて後で編集できます。以下に例を示します。

    quarkus.kubernetes-service-binding.services.db-demo.api-version=postgres-operator.crunchydata.com/v1beta1
    quarkus.kubernetes-service-binding.services.db-demo.kind=Database
    quarkus.kubernetes-service-binding.services.db-demo.name=my-db

1.4. 半自動メソッドを使用して ServiceBinding カスタムリソースを生成する

ServiceBinding リソースをセミコロンで生成できます。以下の手順は、アプリケーションの設定およびデプロイのための Operator のインストール方法など、OpenShift Container Platform のデプロイメントプロセスを示しています。

次の手順では、Crunchy Data から Service Binding Operator および PostgreSQL Operator をインストールします。

重要

PostgreSQL Operator は、サードパーティーのコンポーネントです。PostgreSQL Operator のサポートポリシーと使用条件については、ソフトウェアベンダーである Crunchy Data にお問い合わせください。

次に、この手順では PostgreSQL クラスター(簡単なアプリケーション)を作成し、最後に、これをプロビジョニングされたクラスターにバインドします。

前提条件

  • OpenShift Container Platform 4.10 クラスターを作成している。
  • OperatorHub からクラスター全体の Operator をインストールするのに必要な OperatorHub および OpenShift Container Platform 管理者権限にアクセスできる。
  • 以下がインストールされている。

    • oc オーケストレーションツール
    • Maven と Java

手順

以下の手順では、HOME (~) ディレクトリーを保存先およびインストール先として使用します。

  1. OpenShift Container Platform Web UI から Service Binding Operator をインストールする に記載された手順を使用して、Service Binding Operator バージョン 1.0 以降をインストールします。

    1. インストールを確認します。

      oc get csv -n openshift-operators -w
      • Service Binding OperatorフェーズSucceeded に設定されている場合は、次のステップに進みます。
  2. Web コンソールまたは CLI を使用して、OperatorHub から Crunchy PostgreSQL Operator をインストールします。手順へのリンクは、デプロイと使用 セクションを参照してください。

    1. インストールを確認します。

      oc get csv -n openshift-operators -w
      • Operator の フェーズSucceeded に設定されている場合は、次のステップに進みます。
  3. PostgreSQL クラスターを作成します。

    1. クラスターを作成し、後でアプリケーションをデプロイするスペースで新規 OpenShift Container Platform namespace を作成します。この手順では、namespace は demo と呼ばれます。

      oc new-project demo
    2. 次のカスタムリソースを作成し、pg-cluster.yml として保存します。

      apiVersion: postgres-operator.crunchydata.com/v1beta1
      kind: PostgresCluster
      metadata:
        name: hippo
      spec:
        openshift: true
        image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:ubi8-14.2-1
        postgresVersion: 14
        instances:
          - name: instance1
            dataVolumeClaimSpec:
              accessModes:
              - "ReadWriteOnce"
              resources:
                requests:
                  storage: 1Gi
        backups:
          pgbackrest:
            image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:ubi8-2.38-0
            repos:
            - name: repo1
              volume:
                volumeClaimSpec:
                  accessModes:
                  - "ReadWriteOnce"
                  resources:
                    requests:
                      storage: 1Gi
      注記

      この YAML は、Service Binding Operator Quickstart から再利用しています。

    3. 作成したカスタムリソースを適用します。

      oc apply -f ~/pg-cluster.yml
      注記

      このコマンドは、pg-cluster.yml ファイルを HOME に保存していることを前提としています。

    4. Pod をチェックしてインストールを確認します。

      oc get pods -n demo
      • Pod が READY 状態になるまで待機します。これは、インストールが完了したことを示します。
  4. PostgreSQL データベースにバインドする Quarkus アプリケーションを作成します。

    • 作成するアプリケーションは、Hibernate と panache を使用して PostgreSQL に接続するシンプルな todo アプリケーションです。

      1. アプリケーションを生成します。

        mvn com.redhat.quarkus.platform:quarkus-maven-plugin:2.13.9.SP2-redhat-00003:create \
          -DplatformGroupId=com.redhat.quarkus.platform \
          -DplatformVersion=2.13.9.SP2-redhat-00003 \
          -DprojectGroupId=org.acme \
          -DprojectArtifactId=todo-example \
          -DclassName="org.acme.TodoResource" \
          -Dpath="/todo"
      2. PostgreSQL への接続、すべての必要リソースの生成、およびアプリケーション用コンテナーイメージの構築に必要なエクステンションをすべて追加します。

        ./mvnw quarkus:add-extension -Dextensions="resteasy-reactive-jackson,jdbc-postgresql,hibernate-orm-panache,openshift,kubernetes-service-binding"
      3. 次の例に示すように、単純なエンティティーを作成します。

        package org.acme;
        
        import javax.persistence.Column;
        import javax.persistence.Entity;
        
        import io.quarkus.hibernate.orm.panache.PanacheEntity;
        
        @Entity
        public class Todo extends PanacheEntity {
        
            @Column(length = 40, unique = true)
            public String title;
        
            public boolean completed;
        
            public Todo() {
            }
        
            public Todo(String title, Boolean completed) {
                this.title = title;
            }
        
        }
      4. エンティティーを公開します。

        package org.acme;
        
        import javax.transaction.Transactional;
        import javax.ws.rs.*;
        import javax.ws.rs.core.Response;
        import javax.ws.rs.core.Response.Status;
        import java.util.List;
        
           @Path("/todo")
           public class TodoResource {
        
               @GET
               @Path("/")
               public List<Todo> getAll() {
                 return Todo.listAll();
               }
        
               @GET
               @Path("/{id}")
               public Todo get(@PathParam("id") Long id) {
                   Todo entity = Todo.findById(id);
                   if (entity == null) {
                       throw new WebApplicationException("Todo with id of " + id + " does not exist.", Status.NOT_FOUND);
                   }
                   return entity;
               }
        
               @POST
               @Path("/")
               @Transactional
               public Response create(Todo item) {
                   item.persist();
                   return Response.status(Status.CREATED).entity(item).build();
               }
        
               @GET
               @Path("/{id}/complete")
               @Transactional
               public Response complete(@PathParam("id") Long id) {
                   Todo entity = Todo.findById(id);
                   entity.id = id;
                   entity.completed = true;
                   return Response.ok(entity).build();
               }
        
        
               @DELETE
               @Transactional
               @Path("/{id}")
               public Response delete(@PathParam("id") Long id) {
                   Todo entity = Todo.findById(id);
                   if (entity == null) {
                       throw new WebApplicationException("Todo with id of " + id + " does not exist.", Status.NOT_FOUND);
                   }
                   entity.delete();
                   return Response.noContent().build();
               }
        
           }
  5. ServiceBinding リソースを生成して、ターゲット PostgreSQL クラスターにバインドします。

    1. サービス座標を指定してバインディングを生成し、データソースを設定します。

      • apiVersion: postgres-operator.crunchydata.com/v1beta1
      • kind: PostgresCluster
      • name: pg-cluster

        これを行うには、以下の例のように quarkus.kubernetes-service-binding.services.<id>. 接頭辞を設定します。id は、プロパティーをグループ化するために使用され、任意のものにすることができます。

        quarkus.kubernetes-service-binding.services.my-db.api-version=postgres-operator.crunchydata.com/v1beta1
        quarkus.kubernetes-service-binding.services.my-db.kind=PostgresCluster
        quarkus.kubernetes-service-binding.services.my-db.name=hippo
        
        quarkus.datasource.db-kind=postgresql
        quarkus.hibernate-orm.database.generation=drop-and-create
        quarkus.hibernate-orm.sql-load-script=import.sql
    2. いくつかの初期データを指定して import.sql スクリプトを作成します。

      INSERT INTO todo(id, title, completed) VALUES (nextval('hibernate_sequence'), 'Finish the blog post', false);
  6. アプリケーション (ServiceBinding を含む) をデプロイし、クラスターに適用します。

    mvn clean install -Dquarkus.kubernetes.deploy=true -DskipTests
    • デプロイメントが完了するまで待ちます。

検証

  1. デプロイメントを確認します。

    oc get pods -n demo -w
  2. インストールの検証

    1. ローカルで http ポートにポート転送し、/todo エンドポイントにアクセスします。

      oc port-forward service/todo-example 8080:80
    2. 以下の URL をブラウザーで開きます。

      http://localhost:8080/todo

1.5. 自動サービスバインディング

quarkus-kubernetes-service-binding エクステンションは、アプリケーションが利用可能なバインド可能な Operator によって提供される外部サービスにアクセスする必要があることを検知した後に、ServiceBinding リソースを自動的に生成できます。

注記

自動サービスバインディングは、限られた数のサービスタイプに対して生成できます。本章では、Kubernetes および Quarkus サービスの確立された用語と一致するように、これらのサービスタイプを種類として説明します。

Expand
表1.1 自動サービスバインディングをサポートする Operator

サービスバインディングのタイプ

Operator

API バージョン

Kind

postgresql

CrunchyData Postgres

postgres-operator.crunchydata.com/v1beta1

PostgresCluster

mysql

Percona XtraDB Cluster

pxc.percona.com/v1-9-0

PerconaXtraDBCluster

mongo

Percona MongoDB

psmdb.percona.com/v1-9-0

PerconaServerMongoDB

重要
  • MongoDB Operator の Red Hat ビルドの Quarkus 2.13 のサポートはテクノロジープレビューとして提供され、クライアントにのみ適用されます。
  • Red Hat ビルドの Quarkus 2.13 でサポートされる Panache エクステンションのリストは、Quarkus application configurator ページを参照してください。

1.5.1. 自動データソースバインディング

従来のデータベースでは、データソースが次のように設定されている場合に自動バインドが開始されます。

quarkus.datasource.db-kind=postgresql

以前の設定は、quarkus-datasourcequarkus-jdbc-postgresqlquarkus-kubernetes、および quarkus-kubernetes-service-binding プロパティーが含まれると、postgresql データベースタイプの ServiceBinding リソースが生成されます。

生成された ServiceBinding リソースは、使用している postgresql Operator と一致する Operator リソースの apiVersion プロパティーと kind プロパティーを使用して、サービスまたはリソースをアプリケーションにバインドします。

データベースサービスの名前を指定しない場合は、db-kind プロパティーの値がデフォルトの名前として使用されます。

 services:
 - apiVersion: postgres-operator.crunchydata.com/v1beta1
   kind: PostgresCluster
   name: postgresql

データソースの名前を次のように指定します。

quarkus.datasource.fruits-db.db-kind=postgresql

生成された ServiceBinding 内の service が、次のように表示されます。

 services:
 - apiVersion: postgres-operator.crunchydata.com/v1beta1
   kind: PostgresCluster
   name: fruits-db

同様に、mysql を使用する場合はデータソースの名前を次のように指定できます。

quarkus.datasource.fruits-db.db-kind=mysql

生成された service には以下が含まれます。

 services:
 - apiVersion: pxc.percona.com/v1-9-0
   kind: PerconaXtraDBCluster
   name: fruits-db
1.5.1.1. 自動サービスバインディングのカスタマイズ

自動サービスバインディング機能は、できるだけ多くの手動設定を排除するために開発されましたが、生成された ServiceBinding リソースを手動で変更する必要がある場合があります。生成プロセスは、アプリケーションから抽出された情報と、サポートされている Operator の知識だけに依存しており、クラスターにデプロイされる内容を反映していない可能性があります。生成されたリソースは、一般的なサービスの種類と、次のような不一致を防ぐために開発された一連の規則に対して、サポートされているバインド可能なオペレーターに関する純粋な知識に基づいています。

  • ターゲットリソース名がデータソース名と一致しない。
  • そのサービスの種類についてデフォルトの Operator ではなく、特定の Operator を使用する必要があります。
  • ユーザーがデフォルトまたは latest 以外のバージョンを使用する必要がある場合に発生するバージョンの競合

表記規則

  • ターゲットリソースの座標は、Operator のタイプとサービスの種類に基づいて決定されます。
  • ターゲットリソース名はデフォルトで、postgresqlmysqlmongo などのサービスの種類と一致するように設定されます。
  • 名前付きデータソースの場合は、データソースの名前が使用されます。
  • 名前付きの mongo クライアントでは、クライアントの名前が使用されます。

例 1: 名前の不一致

生成された ServiceBinding を変更して名前の不一致を修正する必要がある場合は、quarkus.kubernetes-service-binding.services プロパティーを使用して、サービス名をサービスキーとして指定します。

サービスキー は通常、サービスの名前(データソースの名前、mongo クライアントの名前など)です。この値が利用できない場合は、postgresqlmysql mongo などのデータソースタイプが代わりに使用されます。

サービスタイプ間の名前の競合を避けるには、接頭辞として service key の前に特定のデータソースタイプ (postgresql-<person> など) を付けます。

次の例は、PostgresCluster リソースの apiVersion プロパティーをカスタマイズする方法を示しています。

quarkus.datasource.db-kind=postgresql
quarkus.kubernetes-service-binding.services.postgresql.api-version=postgres-operator.crunchydata.com/v1beta2

例 2: データソースのカスタム名の適用

例 1 では、db-kind(postgresql)がサービスキーとして使用されていた。この例では、データソースの名前が規則に従って付けられているため、データソース名(fruits-db)が代わりに使用されます。

次の例は、名前付きデータソースの場合はデータソース名がターゲットリソースの名前として使用されることを示しています。

quarkus.datasource.fruits-db.db-kind=postgresql

これは、次の設定と同じ効果があります。

quarkus.kubernetes-service-binding.services.fruits-db.api-version=postgres-operator.crunchydata.com/v1beta1
quarkus.kubernetes-service-binding.services.fruits-db.kind=PostgresCluster
quarkus.kubernetes-service-binding.services.fruits-db.name=fruits-db

改訂日時: 2024-04-23

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る