Projecting binding data

This section provides information on how you can consume the binding data.

Consumption of binding data

After the backing service exposes the binding data, for a workload to access and consume this data, you must project it into the workload from a backing service. Service Binding Operator automatically projects this set of data into the workload in the following methods:

  1. By default, as files.

  2. As environment variables, after you configure the .spec.bindAsFiles parameter from the ServiceBinding resource.

Configuration of the directory path to project the binding data inside workload container

By default, Service Binding Operator mounts the binding data as files at a specific directory in your workload resource. You can configure the directory path using the SERVICE_BINDING_ROOT environment variable setup in the container where your workload runs.

Example: Binding data mounted as files

  1. $SERVICE_BINDING_ROOT (1)
  2. ├── account-database (2)
  3. ├── type (3)
  4. ├── provider (4)
  5. ├── uri
  6. ├── username
  7. └── password
  8. └── transaction-event-stream (2)
  9. ├── type
  10. ├── connection-count
  11. ├── uri
  12. ├── certificates
  13. └── private-key
1Root directory.
2Directory that stores the binding data.
3Mandatory identifier that identifies the type of the binding data projected into the corresponding directory.
4Optional: Identifier to identify the provider so that the application can identify the type of backing service it can connect to.

To consume the binding data as environment variables, use the built-in language feature of your programming language of choice that can read environment variables.

Example: Python client usage

  1. import os
  2. username = os.getenv("USERNAME")
  3. password = os.getenv("PASSWORD")

Computation of the final path for projecting the binding data as files

The following table summarizes the configuration of how the final path for the binding data projection is computed when files are mounted at a specific directory:

Table 1. Summary of the final path computation
SERVICE_BINDING_ROOTFinal path

Not available

/bindings/<ServiceBinding_ResourceName>

dir/path/root

dir/path/root/<ServiceBinding_ResourceName>

In the previous table, the <ServiceBinding_ResourceName> entry specifies the name of the ServiceBinding resource that you configure in the .metadata.name section of the custom resource (CR).

To access and consume the binding data within the existing SERVICE_BINDING_ROOT environment variable, use the built-in language feature of your programming language of choice that can read environment variables.

Example: Python client usage

  1. from pyservicebinding import binding
  2. try:
  3. sb = binding.ServiceBinding()
  4. except binding.ServiceBindingRootMissingError as msg:
  5. # log the error message and retry/exit
  6. print("SERVICE_BINDING_ROOT env var not set")
  7. sb = binding.ServiceBinding()
  8. bindings_list = sb.bindings("postgresql")

In the previous example, the bindings_list variable contains the binding data for the postgresql database service type.

Projecting the binding data

Depending on your workload requirements and environment, you can choose to project the binding data either as files or environment variables.

Prerequisites

  • You understand the following concepts:

    • Environment and requirements of your workload, and how it works with the provided services.

    • Consumption of the binding data in your workload resource.

    • Configuration of how the final path for data projection is computed for the default method.

  • The binding data is exposed from the backing service.

Procedure

  1. To project the binding data as files, determine the destination folder by ensuring that the existing SERVICE_BINDING_ROOT environment variable is present in the container where your workload runs.

  2. To project the binding data as environment variables, set the value for the .spec.bindAsFiles parameter to false from the ServiceBinding resource in the custom resource (CR).

Additional resources