In the previous article, we introduced the Service Binding Operator and explained how it functions. In this article, we'll look at a more advanced topic—custom environment variables—and walk through a typical usage scenario.
Custom environment variables
To make binding applications (e.g., legacy Java applications that depend on JDBS strings) together with backing services more flexible, the Service Binding Operator supports the optional use of custom environment variables. To use custom environment variables, an application developer creates a ServiceBindingRequest that looks like the one shown in Figure 1:
ServiceBindingRequest that uses custom environment variables.The custom environment variables, which in this example access a PostgreSQL database, are defined under customEnvVar and provide custom binding information for the application to bind with its needed backing services.
The Service Binding Operator in action
The best way to appreciate the features provided by the Service Binding Operator is to see them in action in a typical usage scenario. A set of example scenarios and operators that manage backing services is being developed in parallel with Service Binding Operator. (Links to these scenarios and backing operators are included in the final section of this article.)
Let's use one of these scenarios and operators as an example. For the backing service, we will use a PostgreSQL database managed by this sample operator. For the application being bound to this backing service, we’ll use this Java, Spring Boot example application that implements a fruit inventory system.
The documentation included with this and other example applications includes the full set of instructions, including admin tasks such as installing the Service Binding Operator and the backing service. In this illustration, we will focus on the steps taken by an application developer and the actions performed by the Service Binding Operator.
Before we begin, we have to install the Service Binding Operator. The operator is available through the OperatorHub in the Red Hat OpenShift console's console's Administrative perspective as shown in Figure 1:
The sequence of application developer steps and Service Binding Operator actions is as follows.
Step 1: Import the app
The application developer logs into the Red Hat OpenShift console's Developer perspective and creates a new app by referencing the application's source repo, as shown in Figure 3:
Step 2: Create the database that the app will use
The app developer now creates the database that the app will use, as shown in Figure 4. Note that at this point, the app and the backing service for the database are not bound together:
OpenShift creates a Deployment for the app, starts a pod for the app, deploys the app, and provides a route to the app. At this point, the app is running but without its backing service. Our example app is constructed so that it can display its main page, but any attempt to create new entries in the fruit inventory fails and raises an alert due to the lack of a backing service database, as shown in Figure 5:
Step 3: Show intent to bind by creating a ServiceBindingRequest
At this point, the application developer signals the intent to bind the application together with a backing service by creating a ServiceBindingRequest. This ServiceBindingRequest includes custom environment variables that provide database connection information such as a username, password, and connection URL, plus a reference (ResourceRef) that refers to the backing database service by name, as shown in Figure 6:
ServiceBindingRequest.Step 4: The Service Binding Operator shares binding information with the application
This information is collected by the Service Binding Operator into an intermediary secret, which is then shared with the application. The binding information corresponds to the application’s labels and backing service connection attributes.
Step 5: The Service Binding Operator detects changes to the application’s Deployment
The Service Binding Operator reconciles these changes. The entity in control of that pod (for example, a Deployment or DeploymentConfig) restarts the pod to have the changes take effect, resulting in what you see in Figure 7:
The application can now access the backing service database, as we see in Figure 8:
What’s next?
The Service Binding Operator is 100% open source. Download the code, kick the tires, provide feedback and ideas for new features, and contribute code!
Resources
- The Service Binding Operator GitHub repo.
- A set of examples, each of which illustrates a usage scenario for the Service Binding Operator, is being developed in parallel with the Operator. Each example includes documentation and can be run either through the OpenShift web console or command-line client.
- Sample Backing Service Operators are available here.
