Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

5.8. サービスバインディング Operator を使用したワークロードのバインド

アプリケーション開発者は、バインディングシークレットを使用して、ワークロードを 1 つまたは複数のバッキングサービスにバインドする必要があります。このシークレットは、ワークロードによって使用される情報を保存するために生成されます。

たとえば、接続するサービスがすでにバインディングデータを公開しているとします。この場合、ServiceBinding カスタムリソース (CR) と共に、使用されるワークロードの必要になります。この ServiceBinding CR を使用することで、ワークロードはバインドするサービスの詳細と共にバインディング要求を送信します。

ServiceBinding CR の例

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
    name: spring-petclinic-pgcluster
    namespace: my-petclinic
spec:
    services:
1 

    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo
    application:
2 

      name: spring-petclinic
      group: apps
      version: v1
      resource: deployments
Copy to Clipboard Toggle word wrap

1
サービスリソースの一覧を指定します。
2
Deployment または PodSpec が組み込まれた同様のリソースを参照するサンプルアプリケーション。

上記の例で示されるように、ConfigMap または Secret 自体を、バインディングデータのソースとして使用されるサービスリソースとして直接使用することもできます。

5.8.1. 命名ストラテジー
リンクのコピー

命名ストラテジーは、binding.operators.coreos.com API グループでのみ利用できます。

命名ストラテジーは Go テンプレートを使用して、サービスバインディングリクエストでカスタムバインディング名を定義するのに役立ちます。命名ストラテジーは、ServiceBinding カスタムリソース (CR) のマッピングを含むすべての属性に適用されます。

バッキングサービスは、バインディング名をファイルまたは環境変数としてワークロードに反映します。ワークロードが特定の形式で反映されるバインディング名を要求し、バッキングサービスから反映されるバインディング名がその形式で利用できない場合、命名ストラテジーを使用してバインディング名を変更できます。

定義済みの後処理関数

命名ストラテジーを使用する一方、ワークロードの要求や要件によっては、任意の組み合わせで以下の定義済みの後処理関数を使用して、文字列を変換できます。

  • upper: 文字列を大文字に変換します。
  • lower: 文字列を小文字に変換します。
  • title: 特定の一部の語句を除いて、各語句の最初の文字が大文字になるように文字列を変換します。

事前に定義された命名ストラテジー

アノテーションで宣言されたバインディング名は、以下の事前に定義された命名ストラテジーに従って、ワークロードへの反映前に名前の変更に対して処理されます。

  • none: これが適用されると、バインディング名は変更されません。

    例

    テンプレートのコンパイル後、バインディング名は {{ .name }} の形式を取ります。 

    host: hippo-pgbouncer
port: 5432
    Copy to Clipboard Toggle word wrap

  • upper: namingStrategy が定義されていない場合に適用されます。これが適用されると、バインディング名キーのすべての文字列を大文字に変換します。

    例

    テンプレートのコンパイル後、バインディング名は {{ .service.kind | upper}}_{{ .name | upper }} の形式を取ります。 

    DATABASE_HOST: hippo-pgbouncer
DATABASE_PORT: 5432
    Copy to Clipboard Toggle word wrap

    ワークロードが別の形式を要求する場合は、カスタム命名ストラテジーを定義し、接頭辞とセパレーターを使用してバインディング名を変更できます (例:PORT_DATABASE)。

注記
  • バインディング名がファイルとして反映される場合、デフォルトでは、事前定義されたnone命名ストラテジーが適用され、バインディング名は変更されません。
  • バインディング名が環境変数として反映され、namingStrategy が定義されていない場合には、デフォルトでは事前定義された uppercase 命名ストラテジーが適用されます。
  • カスタムバインディング名と事前定義済みの後処理関数の別の組み合わせを使用して、カスタム命名ストラテジーを定義することで、事前に定義された命名ストラテジーを上書きできます。

5.8.2. 高度なバインディングオプション
リンクのコピー

高度なバインディングオプションは、binding.operators.coreos.com API グループでのみ利用できます。

5.8.2.1. ワークロードへの反映前のバインディング名の変更
リンクのコピー

ServiceBinding カスタムリソース (CR) の .spec.namingStrategy 属性で、バインディング名を変更するルールを指定できます。たとえば、PostgreSQL データベースに接続する Spring PetClinic サンプルアプリケーションについて考えてみましょう。この場合、PostgreSQL データベースサービスは、バインディングに使用するデータベースのホストおよびポートフィールドを公開します。Spring PetClinic サンプルアプリケーションは、バインディング名を使用してこの公開されたバインディングデータにアクセスできます。

例:ServiceBinding CR の Spring PetClinic サンプルアプリケーション

...
    application:
      name: spring-petclinic
      group: apps
      version: v1
      resource: deployments
...
Copy to Clipboard Toggle word wrap

例:ServiceBinding CR の PostgreSQL データベースサービス

...
    services:
    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo
...
Copy to Clipboard Toggle word wrap

namingStrategy が定義されておらず、バインディング名が環境変数として反映される場合、バッキングサービスの host: hippo-pgbouncer 値および反映される環境変数は以下の例のように表示されます。

例

DATABASE_HOST: hippo-pgbouncer
Copy to Clipboard Toggle word wrap

ここでは、以下のようになります。

DATABASE

kind バックエンドサービスを指定します。

HOST

バインディング名を指定します。

POSTGRESQL_{{ .service.kind | upper }}_{{ .name | upper }}_ENV 命名ストラテジーを適用すると、サービスバインディングリクエストで準備したカスタムバインディング名の一覧が以下の例のように表示されます。

例

POSTGRESQL_DATABASE_HOST_ENV: hippo-pgbouncer
POSTGRESQL_DATABASE_PORT_ENV: 5432
Copy to Clipboard Toggle word wrap

以下の項目は、POSTGRESQL_{{ .service.kind | upper }}_{{ .name | upper }}_ENV 命名ストラテジーで定義される表現について説明しています。

  • .name: バッキングサービスが公開するバインディング名を参照します。上記の例では、バインディング名は HOST および PORT です。
  • .service.kind: バインディング名が命名ストラテジーで変更されるサービスリソースの種類を参照します。
  • upper: Go テンプレート文字列をコンパイルする際に文字列を後処理するために使用する文字列関数。
  • POSTGRESQL: カスタムバインディング名の接頭辞。
  • ENV: カスタムバインディング名の接尾辞。

前述の例と同様に、namingStrategy で文字列テンプレートを定義し、バインディング名のそれぞれのキーがサービスバインディングリクエストによってどのように準備されるかを定義できます。

5.8.2.2. カスタムバインディングデータの作成
リンクのコピー

アプリケーション開発者は、以下の状況でカスタムバインディングデータを作成できます。

  • バッキングサービスがバインディングデータを公開しない。
  • 公開される値が、ワークロードによって要求される形式では利用できません。

たとえば、バッキングサービス CR がホスト、ポート、およびデータベースユーザーをバインディングデータとして公開するが、ワークロードはバインディングデータを接続文字列として使用することを要求するケースを考えてみます。バッキングサービスを表す Kubernetes リソースの属性を使用して、カスタムバインディングデータを作成できます。

例

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
    name: spring-petclinic-pgcluster
    namespace: my-petclinic
spec:
    services:
    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo
1 

      id: postgresDB
2 

    - group: ""
      version: v1
      kind: Secret
      name: hippo-pguser-hippo
      id: postgresSecret
    application:
      name: spring-petclinic
      group: apps
      version: v1
      resource: deployments
    mappings:
      ## From the database service
      - name: JDBC_URL
        value: 'jdbc:postgresql://{{ .postgresDB.metadata.annotations.proxy }}:{{ .postgresDB.spec.port }}/{{ .postgresDB.metadata.name }}'
      ## From both the services!
      - name: CREDENTIALS
        value: '{{ .postgresDB.metadata.name }}{{ translationService.postgresSecret.data.password }}'
      ## Generate JSON
      - name: DB_JSON
3 

        value: {{ json .postgresDB.status }}
4
Copy to Clipboard Toggle word wrap

1
バッキングサービスリソースの名前。
2
オプションの識別子。
3
ファイルの内容または環境の値として反映される生成された JSON 名。JSON 名には、バッキングサービスのカスタムリソースの属性が含まれます。
4
ファイルの内容または環境の値として反映される生成された JSON 値。JSON 値には、バッキングサービスのカスタムリソースの属性が含まれます。

5.8.3. PodSpec に準拠していないセカンダリーワークロードのバインド
リンクのコピー

サービスバインディングの一般的なシナリオでは、バッキングサービス、ワークロード (デプロイメント)、およびサービスバインディング Operator を設定する必要があります。PodSpec に準拠しておらず、プライマリーワークロード (デプロイメント) とサービスバインディング Operator の間にあるセカンダリーワークロード (アプリケーション Operator の場合もあります) が関与するシナリオについて考えてみます。

このようなセカンダリーワークロードリソースの場合、コンテナーパスのロケーションは任意です。サービスバインディングの場合、CR のセカンダリーワークロードが PodSpec に準拠していない場合、コンテナーパスのロケーションを指定する必要があります。これにより、バインディングデータがServiceBinding カスタムリソース (CR) のセカンダリーワークロードで指定されたコンテナーパスに反映されます (たとえば、Pod 内にバインディングデータを配置したくない場合)。

サービスバインディング Operator により、コンテナーのパスまたはシークレットパスの場所の値を設定し、これらのパスをカスタムロケーションにバインドすることができます。このオプションは、バインディングデータが環境変数として反映される場合に、binding.operators.coreos.com API グループでのみ利用できます。

5.8.3.1. コンテナーパスのカスタムロケーションの設定
リンクのコピー

PodSpec に準拠しておらず、spec.containers パスに置かれているコンテナーを持つセカンダリーワークロード CR について考えてみます。

例: セカンダリーワークロード CR

apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    containers:
    - name: hello-world
      image: quay.io/baijum/secondary-workload:latest
      ports:
      - containerPort: 8080
Copy to Clipboard Toggle word wrap

手順

  • ServiceBinding CR で値を指定して spec.containers パスを設定し、このパスを spec.application.bindingPath.containersPath カスタムロケーションにバインドします。

    例:ServiceBinding CR とカスタムロケーションの spec.containers パス

    apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
    name: spring-petclinic-pgcluster
spec:
    services:
    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo
      id: postgresDB
    - group: ""
      version: v1
      kind: Secret
      name: hippo-pguser-hippo
      id: postgresSecret
    application:
    1 
    
      name: spring-petclinic
      group: apps
      version: v1
      resource: deployments
    application:
    2 
    
      name: secondary-workload
      group: operator.sbo.com
      version: v1
      resource: secondaryworkloads
      bindingPath:
        containersPath: spec.containers
    3
    Copy to Clipboard Toggle word wrap

    1
    Deployment または PodSpec が組み込まれた同様のリソースを参照するサンプルアプリケーション。
    2
    PodSpec に準拠していないセカンダリーワークロード。
    3
    コンテナーパスのカスタムロケーション。

コンテナーパスのロケーションを指定した後に、サービスバインディング Operator はバインディングデータを生成します。これは、ServiceBinding CR のセカンダリーワークロードで指定されるコンテナーパスで利用できます。

以下の例は、 envFromフィールドとsecretRefフィールドを持つspec.containersパスを示しています。

例:envFrom および secretRef フィールドのあるセカンダリーワークロード CR

apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    containers:
    - env:
1 

      - name: ServiceBindingOperatorChangeTriggerEnvVar
        value: "31793"
      envFrom:
      - secretRef:
          name: secret-resource-name
2 

      image: quay.io/baijum/secondary-workload:latest
      name: hello-world
      ports:
      - containerPort: 8080
      resources: {}
Copy to Clipboard Toggle word wrap

1
サービスバインディング Operator で生成される値を持つコンテナーの一意の配列。これらの値はバッキングサービス CR に基づいています。
2
サービスバインディング Operator によって生成される Secret リソースの名前。

5.8.3.2. シークレットパスのカスタムロケーションの設定
リンクのコピー

PodSpec に準拠しておらず、spec.secret パスに置かれているシークレットのみを持つセカンダリーワークロード CR を考えてみます。

例: セカンダリーワークロード CR

apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    secret: ""
Copy to Clipboard Toggle word wrap

手順

  • ServiceBinding CR で値を指定して spec.secret パスを設定し、このパスを spec.application.bindingPath.secretPath カスタムロケーションにバインドします。

    例:ServiceBinding CR とカスタムロケーションの spec.secret パス

    apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
    name: spring-petclinic-pgcluster
spec:
...
    application:
    1 
    
      name: secondary-workload
      group: operator.sbo.com
      version: v1
      resource: secondaryworkloads
      bindingPath:
        secretPath: spec.secret
    2 
    
...
    Copy to Clipboard Toggle word wrap

    1
    PodSpec に準拠していないセカンダリーワークロード。
    2
    Secret リソースの名前が含まれるシークレットパスのカスタムロケーション。

シークレットパスのロケーションを指定した後に、サービスバインディング Operator はバインディングデータを生成します。これは、ServiceBinding CR のセカンダリーワークロードで指定されるシークレットパスで利用できます。

以下の例は、binding-request 値による spec.secret パスを示しています。

例:binding-request 値が設定されたセカンダリーワークロード CR

...
apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    secret: binding-request-72ddc0c540ab3a290e138726940591debf14c581
1 

...
Copy to Clipboard Toggle word wrap

1
サービスバインディング Operator によって生成される Secret リソースの一意の名前。

5.8.4. バッキングサービスからのワークロードのバインド解除
リンクのコピー

oc ツールを使用して、バッキングサービスからワークロードのバインドを解除できます。

  • バッキングサービスからワークロードのバインドを解除するには、これにリンクされている ServiceBinding カスタムリソース (CR) を削除します。 

    $ oc delete ServiceBinding <.metadata.name>
    Copy to Clipboard Toggle word wrap

    例

    $ oc delete ServiceBinding spring-petclinic-pgcluster
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    spring-petclinic-pgcluster

    ServiceBinding CR の名前を指定します。

5.8.5. 関連情報
リンクのコピー

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat