1.5. 自動サービスバインディング
quarkus-kubernetes-service-binding エクステンションは、互換性のあるバインド可能な Operator によって提供される外部サービスへのアクセスを必要とするアプリケーションを検出した場合に、ServiceBinding リソースを自動的に生成できます。
自動サービスバインディングは、限られた一連のサービスタイプセットに対してのみ生成できます。
定着した Kubernetes および Quarkus サービス用語に合わせて、この章ではこれらのサービスタイプを "kind" と呼びます。
| サービスバインディングのタイプ | Operator | API バージョン | Kind |
|
| 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.2 の MongoDB Operator に対するサポートは、テクノロジープレビューとして提供され、クライアントのみに適用されます。
- Red Hat build of Quarkus 3.2 でサポートされている 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 の知識のみに依存し、クラスターにデプロイされたものが反映されない可能性があります。
生成されたリソースは、一般的なサービス 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
例 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
関連情報
- 使用可能なプロパティーの詳細は、Kubernetes サービスバインディング仕様の workload projection を参照してください。
改訂日時: 2024-05-10
