サービスバインディング
概要
Red Hat build of Quarkus ドキュメントへのフィードバックの提供 リンクのコピーリンクがクリップボードにコピーされました!
エラーを報告したり、ドキュメントを改善したりするには、Red Hat Jira アカウントにログインし、課題を送信してください。Red Hat Jira アカウントをお持ちでない場合は、アカウントを作成するように求められます。
手順
- 次のリンクをクリックして チケットを作成します。
- Summary に課題の簡単な説明を入力します。
- Description に課題や機能拡張の詳細な説明を入力します。問題があるドキュメントのセクションへの URL も記載してください。
- Submit をクリックすると、課題が作成され、適切なドキュメントチームに転送されます。
第1章 サービスバインディング リンクのコピーリンクがクリップボードにコピーされました!
Quarkus でサービスバインディングおよびワークロードのプロジェクションを使用して、最小限の設定でアプリケーションをバッキングサービスに接続します。
OpenShift Service Binding Operator の非推奨
OpenShift Service Binding Operator は OpenShift Container Platform (OCP) 4.13 以降では非推奨となり、将来の OCP リリースで削除される予定です。
次の章では、Red Hat build of Quarkus バージョン 2.7.5 で追加され、バージョン 3.15 では テクノロジープレビュー になっているサービスバインディングとワークロードプロジェクションを説明します。
一般的に、OpenShift のアプリケーションとサービスはデプロイ可能なワークロードとも呼ばれ、サービスの URL や認証情報などの追加情報を取得するために、他のサービスに接続する必要があります。
Service Binding Operator は、簡単に必要な情報を取得し、拡張ツール自体の使用に直接影響を与えたり決定したりすることなく、環境変数を通じてアプリケーションや quarkus-kubernetes-service-binding 拡張などのサービスバインディングツールで利用できるようにします。
Quarkus は、サービスをアプリケーションにバインドするための Service binding specification for Kubernetes をサポートします。
具体的には、Quarkus は仕様の ワークロードプロジェクション 部分を実装しているため、アプリケーションはデータベースやブローカーなどのサービスを最小限の設定でバインドできます。
利用可能なエクステンションのサービスバインディングを有効にするには、アプリケーションの依存関係に quarkus-kubernetes-service-binding エクステンションを含めます。
サービスバインディングとワークロードプロジェクションには、次のエクステンションを使用できます。
-
quarkus-jdbc-mariadb -
quarkus-jdbc-mssql -
quarkus-jdbc-mysql -
quarkus-jdbc-postgresql -
quarkus-mongo-client- テクノロジープレビュー -
quarkus-kafka-client -
quarkus-messaging-kafka
-
quarkus-reactive-mssql-client- テクノロジープレビュー -
quarkus-reactive-mysql-client -
quarkus-reactive-pg-client
-
1.1. ワークロードプロジェクション リンクのコピーリンクがクリップボードにコピーされました!
ワークロードプロジェクションは、Kubernetes クラスターからサービスの設定を取得するプロセスです。この設定は、特定の規則に従うディレクトリー構造の形式をとり、マウントされたボリュームとしてアプリケーションまたはサービスに接続されます。
kubernetes-service-binding エクステンションは、このディレクトリー構造を使用して設定ソースを作成します。これにより、データベースやメッセージブローカーなどの追加モジュールを設定できるようになります。
アプリケーション開発中にワークロードプロジェクションを使用して、アプリケーションのコードや設定を変更せずに、アプリケーションを開発データベースやローカルで実行される他のサービスに接続できます。
ディレクトリー構造がテストリソースに含まれ、結合テストに渡されるワークロードプロジェクションの例は、Kubernetes Service Binding データソース GitHub リポジトリーを参照してください。
k8s-sbディレクトリーは、すべてのサービスバインディングのルートです。この例では、
fruit-dbという名前データベース 1 つのみをバインドします。このバインディングデータベースには、データベースタイプとしてpostgresqlを指定するtypeファイルがあります。ディレクトリー内の他のファイルは、接続を確立するために必要な情報を提供します。-
Red Hat build of Quarkus プロジェクトが、OpenShift Container Platform によって設定された
SERVICE_BINDING_ROOT環境変数から情報を取得すると、ファイルシステム内に存在する生成された設定ファイルを見つけ、それを使用して設定ファイルの値を特定のエクステンションのプロパティーにマップできます。
1.2. Service Binding Operator の概要 リンクのコピーリンクがクリップボードにコピーされました!
Service Binding Operator は、Service Binding Specification for Kubernetes を実装する Operator であり、アプリケーションへのサービスのバインドを単純化するために使用できます。
ワークロードプロジェクション をサポートするコンテナー化されたアプリケーションは、ボリュームマウントのフォーマットでサービスバインディング情報を取得します。Service Binding Operator は、バインディングサービス情報を読み取り、それを必要とするアプリケーションコンテナーにマウントします。
アプリケーションとバインドされたサービスの相関関係は、どのサービスがどのアプリケーションにバインドされるかを宣言する ServiceBinding リソースを通して表現されます。
Service Binding Operator は ServiceBinding リソースを監視します。このリソースは、どのアプリケーションがどのサービスにバインドされるかを Operator に通知します。リストされたアプリケーションがデプロイされると、Service Binding 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リソースの例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記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
quarkus.kubernetes-service-binding.services.db-demo.api-version=postgres-operator.crunchydata.com/v1beta1 quarkus.kubernetes-service-binding.services.db-demo.kind=DatabaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
application.properties 内に以前の設定プロパティーを追加した後、quarkus-kubernetes と quarkus-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
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-dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.4. 半自動メソッドを使用した ServiceBinding カスタムリソースの生成 リンクのコピーリンクがクリップボードにコピーされました!
ServiceBinding リソースを半自動的に生成できます。以下の手順は、アプリケーションの設定とデプロイに使用する Operator のインストールを含む、OpenShift Container Platform のデプロイメントプロセスを示しています。
この手順では、Service Binding Operator と Crunchy Data の PostgreSQL Operator をインストールします。
PostgreSQL Operator は、サードパーティーのコンポーネントです。PostgreSQL Operator のサポートポリシーと使用条件は、ソフトウェアベンダーである Crunchy Data にお問い合わせください。
次の手順には、PostgreSQL クラスターの作成、単純なアプリケーションのセットアップ、その後のプロビジョニングされたクラスターへのデプロイとバインドが含まれます。
前提条件
- OpenShift Container Platform 4.12 クラスターを作成している。
- OperatorHub からクラスター全体に Operator をインストールするために必要な、OperatorHub および OpenShift Container Platform への管理者権限を持っている。
以下がインストールされている。
-
OpenShift、
oc、オーケストレーションツール - Maven と Java
-
OpenShift、
手順
以下の手順では、HOME (~) ディレクトリーを保存先およびインストール先として使用します。
OpenShift Container Platform Web UI から Service Binding Operator をインストールする に記載された手順を使用して、Service Binding Operator バージョン 1.3.3 以降をインストールします。
インストールを確認します。
oc get csv -w
oc get csv -wCopy to Clipboard Copied! Toggle word wrap Toggle overflow Service Binding Operator の
phaseがSucceededに設定されたことを確認し、次のステップに進みます。
Web コンソールまたは CLI を使用して、OperatorHub から Crunchy PostgreSQL Operator をインストールします。
インストールを確認します。
oc get csv -w
oc get csv -wCopy to Clipboard Copied! Toggle word wrap Toggle overflow Operator の
phaseがSucceededに設定されたことを確認し、次のステップに進みます。
PostgreSQL クラスターを作成します。
新しい OpenShift Container Platform namespace を作成します。これは、後でクラスターを作成し、アプリケーションをデプロイするために使用します。ここで説明する手順では、この namespace を
demoと呼びます。oc new-project demo
oc new-project demoCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のカスタムリソースを作成し、
pg-cluster.ymlとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この YAML は、Service Binding Operator Quickstart から再利用しています。
作成したカスタムリソースを適用します。
oc apply -f ~/pg-cluster.yml
oc apply -f ~/pg-cluster.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記このコマンドは、
pg-cluster.ymlファイルが HOME ディレクトリーに保存されていることを前提としています。Pod でインストールを確認します。
oc get pods -n demo
oc get pods -n demoCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
インストールが完了して Pod が
READY状態になるまで待ちます。
-
インストールが完了して Pod が
PostgreSQL データベースにバインドする Quarkus アプリケーションを作成します。
ここで作成するアプリケーションは、Hibernate と Panache を使用して PostgreSQL に接続する基本的な
todoアプリケーションです。アプリケーションを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PostgreSQL への接続、すべての必要リソースの生成、およびアプリケーション用コンテナーイメージの構築に必要なエクステンションをすべて追加します。
./mvnw quarkus:add-extension -Dextensions="rest-jackson,jdbc-postgresql,hibernate-orm-panache,openshift,kubernetes-service-binding"
./mvnw quarkus:add-extension -Dextensions="rest-jackson,jdbc-postgresql,hibernate-orm-panache,openshift,kubernetes-service-binding"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例に示すように、単純なエンティティーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow エンティティーを公開します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ServiceBindingリソースを生成して、ターゲット PostgreSQL クラスターにバインドします。サービス座標を指定してバインディングを生成し、データソースを設定します。
-
apiVersion:
postgres-operator.crunchydata.com/v1beta1 -
kind:
PostgresCluster name:
pg-cluster次の例に示すとおり、これは接頭辞
quarkus.kubernetes-service-binding.services.<id>.を設定して行います。idは、プロパティーをグループ化するために使用され、任意の値を割り当てることができます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
apiVersion:
いくつかの初期データを指定して
import.sqlスクリプトを作成します。INSERT INTO todo(id, title, completed) VALUES (nextval('hibernate_sequence'), 'Finish the blog post', false);INSERT INTO todo(id, title, completed) VALUES (nextval('hibernate_sequence'), 'Finish the blog post', false);Copy to Clipboard Copied! Toggle word wrap Toggle overflow
アプリケーション (
ServiceBindingを含む) をデプロイし、クラスターに適用します。mvn clean install -Dquarkus.kubernetes.deploy=true -DskipTests
mvn clean install -Dquarkus.kubernetes.deploy=true -DskipTestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow デプロイメントが完了するまで待ちます。
検証
デプロイメントを確認します。
oc get pods -n demo -w
oc get pods -n demo -wCopy to Clipboard Copied! Toggle word wrap Toggle overflow インストールを確認します。
ローカルで HTTP ポートにポート転送し、
/todoエンドポイントにアクセスします。oc port-forward service/todo-example 8080:80
oc port-forward service/todo-example 8080:80Copy to Clipboard Copied! Toggle word wrap Toggle overflow Web ブラウザーで、以下の URL を開きます。
http://localhost:8080/todo
http://localhost:8080/todoCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.5. 自動サービスバインディング リンクのコピーリンクがクリップボードにコピーされました!
quarkus-kubernetes-service-binding エクステンションは、互換性のあるバインド可能な Operator によって提供される外部サービスへのアクセスを必要とするアプリケーションを検出した場合に、ServiceBinding リソースを自動的に生成できます。
自動サービスバインディングは、限られた一連のサービスタイプセットに対してのみ生成できます。
定着した Kubernetes および Quarkus サービス用語に合わせて、この章ではこれらのサービスタイプを "kind" と呼びます。
| サービスバインディングのタイプ | Operator | API バージョン | 種類 |
|
| postgres-operator.crunchydata.com/v1beta1 | PostgresCluster | |
|
| pxc.percona.com/v1-9-0 | PerconaXtraDBCluster | |
|
| psmdb.percona.com/v1-9-0 | PerconaServerMongoDB |
- Red Hat build of Quarkus 3.15 の MongoDB Operator に対するサポートは、テクノロジープレビューとして提供され、クライアントのみに適用されます。
- Red Hat build of Quarkus 3.15 でサポートされている Panache エクステンションのリストは、Quarkus application configurator ページを参照してください。
1.5.1. 自動データソースバインディング リンクのコピーリンクがクリップボードにコピーされました!
従来のデータベースでは、データソースが次のように設定されている場合に自動バインドが開始します。
quarkus.datasource.db-kind=postgresql
quarkus.datasource.db-kind=postgresql
上記が設定されていると、アプリケーション内に quarkus-datasource、quarkus-jdbc-postgresql、quarkus-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
services:
- apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
name: postgresql
データソースの名前を次のように指定します。
quarkus.datasource.fruits-db.db-kind=postgresql
quarkus.datasource.fruits-db.db-kind=postgresql
生成された ServiceBinding 内の service が、次のように表示されます。
services: - apiVersion: postgres-operator.crunchydata.com/v1beta1 kind: PostgresCluster name: fruits-db
services:
- apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
name: fruits-db
同様に、mysql を使用する場合はデータソースの名前を次のように指定できます。
quarkus.datasource.fruits-db.db-kind=mysql
quarkus.datasource.fruits-db.db-kind=mysql
生成された service には以下が含まれます。
services: - apiVersion: pxc.percona.com/v1-9-0 kind: PerconaXtraDBCluster name: fruits-db
services:
- apiVersion: pxc.percona.com/v1-9-0
kind: PerconaXtraDBCluster
name: fruits-db
1.5.1.1. 自動サービスバインディングのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
自動サービスバインディング機能は、できる限り手動設定を排除するために開発されましたが、生成された ServiceBinding リソースを手動で変更することが必要になる場合もあります。
生成プロセスは、アプリケーションから展開した情報とサポートされている Operator の知識のみに依存し、クラスターにデプロイされたものが反映されない可能性があります。
生成されたリソースは、一般的なサービス kind でサポートされているバインド可能な Operator の知識と、潜在的な不一致を防ぐために開発された一連の規則のみに基づきます。
- ターゲットリソース名はデータソース名と一致しません。
- そのサービス kind のデフォルト Operator ではなく、特定の Operator を使用する必要があります。
- ユーザーがデフォルトまたは最新以外のバージョンを使用する必要がある場合は、バージョンの競合が発生します。
命名規則:
- ターゲットリソースの座標は、Operator タイプとサービス kind に応じて確立されます。
-
デフォルトでは、ターゲットリソース名は
postgresql、mysql、mongoなどのサービス kind と一致します。 - 名前付きデータソースの場合は、そのデータソース名が使用されます。
-
クライアントの名前は、名前付き
mongoクライアントに使用されます。
例 1: 名前の不一致
名前の不一致を修正するために生成された ServiceBinding を変更する必要がある場合は、quarkus.kubernetes-service-binding.services プロパティーを使用してサービス名をサービスキーとして指定します。
通常、service key はサービスの名前 (例: データソースの名前、mongo クライアントの名前など) です。この値が使用できない場合は、postgresql、mysql、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
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.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
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
改訂日時: 2025-10-03