サービスバインディング
概要
第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
-
quarkus-reactive-mssql-client- テクノロジープレビュー -
quarkus-reactive-mysql-client -
quarkus-reactive-pg-client
-
1.1. ワークロードプロジェクション リンクのコピーリンクがクリップボードにコピーされました!
ワークロードプロジェクションは、Kubernetes クラスターからサービスの設定を取得するプロセスです。この設定は、特定の規則に従うディレクトリー構造の形式を取り、アプリケーションまたはマウントされたボリュームとしてのサービスに割り当てられます。kubernetes-service-binding エクステンションは、このディレクトリー構造を使用して設定ソースを作成します。これにより、データベースやメッセージブローカーなどの追加モジュールを設定できるようになります。
アプリケーション開発中のワークロードのプロジェクションを使用して、実際のアプリケーションコードや設定を変更せずに、アプリケーションを開発データベースまたは他のローカル実行サービスに接続できます。
ディレクトリー構造が test リソースに含まれ、統合テストに渡されるワークロードプロジェクションの例は、Kubernetes Service Binding データソース GitHub リポジトリー を参照してください。
-
k8s-sbディレクトリーは、すべてのサービスバインディングのルートです。この例では、fruit-dbという名前データベース 1 つのみをバインドします。このバインディングデータベースには、typefile があります。これは、データベースタイプとして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-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
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 (~) ディレクトリーを保存先およびインストール先として使用します。
OpenShift Container Platform Web UI から Service Binding Operator をインストールする に記載された手順を使用して、Service Binding Operator バージョン 1.0 以降をインストールします。
インストールを確認します。
oc get csv -n openshift-operators -w-
Service Binding Operator の
フェーズがSucceededに設定されている場合は、次のステップに進みます。
-
Service Binding Operator の
Web コンソールまたは CLI を使用して、OperatorHub から Crunchy PostgreSQL Operator をインストールします。手順へのリンクは、デプロイと使用 セクションを参照してください。
インストールを確認します。
oc get csv -n openshift-operators -w-
Operator の
フェーズがSucceededに設定されている場合は、次のステップに進みます。
-
Operator の
PostgreSQL クラスターを作成します。
クラスターを作成し、後でアプリケーションをデプロイするスペースで新規 OpenShift Container Platform namespace を作成します。この手順では、namespace は
demoと呼ばれます。oc new-project demo次のカスタムリソースを作成し、
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 から再利用しています。
作成したカスタムリソースを適用します。
oc apply -f ~/pg-cluster.yml注記このコマンドは、
pg-cluster.ymlファイルを HOME に保存していることを前提としています。Pod をチェックしてインストールを確認します。
oc get pods -n demo-
Pod が
READY状態になるまで待機します。これは、インストールが完了したことを示します。
-
Pod が
PostgreSQL データベースにバインドする Quarkus アプリケーションを作成します。
作成するアプリケーションは、Hibernate と panache を使用して PostgreSQL に接続するシンプルな
todoアプリケーションです。アプリケーションを生成します。
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"PostgreSQL への接続、すべての必要リソースの生成、およびアプリケーション用コンテナーイメージの構築に必要なエクステンションをすべて追加します。
./mvnw quarkus:add-extension -Dextensions="resteasy-reactive-jackson,jdbc-postgresql,hibernate-orm-panache,openshift,kubernetes-service-binding"次の例に示すように、単純なエンティティーを作成します。
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; } }エンティティーを公開します。
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(); } }
ServiceBindingリソースを生成して、ターゲット PostgreSQL クラスターにバインドします。サービス座標を指定してバインディングを生成し、データソースを設定します。
-
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
-
apiVersion:
いくつかの初期データを指定して
import.sqlスクリプトを作成します。INSERT INTO todo(id, title, completed) VALUES (nextval('hibernate_sequence'), 'Finish the blog post', false);
アプリケーション (
ServiceBindingを含む) をデプロイし、クラスターに適用します。mvn clean install -Dquarkus.kubernetes.deploy=true -DskipTests- デプロイメントが完了するまで待ちます。
検証
デプロイメントを確認します。
oc get pods -n demo -wインストールの検証
ローカルで http ポートにポート転送し、
/todoエンドポイントにアクセスします。oc port-forward service/todo-example 8080:80以下の URL をブラウザーで開きます。
http://localhost:8080/todo
1.5. 自動サービスバインディング リンクのコピーリンクがクリップボードにコピーされました!
quarkus-kubernetes-service-binding エクステンションは、アプリケーションが利用可能なバインド可能な Operator によって提供される外部サービスにアクセスする必要があることを検知した後に、ServiceBinding リソースを自動的に生成できます。
自動サービスバインディングは、限られた数のサービスタイプに対して生成できます。本章では、Kubernetes および Quarkus サービスの確立された用語と一致するように、これらのサービスタイプを種類として説明します。
| サービスバインディングのタイプ | Operator | API バージョン | Kind |
|
| postgres-operator.crunchydata.com/v1beta1 | PostgresCluster | |
|
| pxc.percona.com/v1-9-0 | PerconaXtraDBCluster | |
|
| 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-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
データソースの名前を次のように指定します。
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 のタイプとサービスの種類に基づいて決定されます。
-
ターゲットリソース名はデフォルトで、
postgresql、mysql、mongoなどのサービスの種類と一致するように設定されます。 - 名前付きデータソースの場合は、データソースの名前が使用されます。
-
名前付きの
mongoクライアントでは、クライアントの名前が使用されます。
例 1: 名前の不一致
生成された ServiceBinding を変更して名前の不一致を修正する必要がある場合は、quarkus.kubernetes-service-binding.services プロパティーを使用して、サービス名をサービスキーとして指定します。
サービスキー は通常、サービスの名前(データソースの名前、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
例 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