X
  • August 9, 2019

Integrating OCI Service Broker with Autonomous Transaction Processing in the Real World

David Cabelus
Senior Principal Product Manager

By Dave Cabelus and Sherwood Zern

A lot is going on in Oracle Cloud Infrastructure these days! Autonomous databases, serverless functions, artificial intelligence built into applications, and so much more. And even though these big things are exciting, it’s the details that make Oracle Cloud so good. One of those details is the latest release of OCI Service Broker for Kubernetes. In release 1.2.0, we extend support for using Service Broker to create a service binding to an existing service instance—a service that you might have created using the Oracle Cloud Infrastructure Console or CLI.

What Does Service Broker Do?

If you aren’t familiar with Service Broker, you use it to perform the following actions:

  • Create Oracle Cloud Infrastructure service instances that your application needs, such as an Object Storage bucket or an Autonomous Transaction Processing database.
  • Create bindings to those services created by Service Broker.

Then, you can deploy the application that uses those services.

After you undeploy the application that uses the services, you use Service Broker to perform the following actions:

  • Delete the service bindings that it created.
  • Delete the services that it created.

Doing all of that enables you to encapsulate the application’s dependencies with the application so that you can deploy and undeploy all of that as a unit. And, you do it all through a single tool: kubectl. This promotes application portability: not only is the application in a container, so it has what it needs at runtime, but the cloud service dependencies—dependencies that are external to the container—are also linked through use of Service Broker.

Before Service Broker 1.2.0

In theory, every application would have a dedicated set of cloud services that it depends on. In practice, however, many applications share a cloud service instance with another microservice, or use a cloud service instance that has already been set up in an environment. For example, many microservice architectures use publish-subscribe messages for asynchronous execution. If a microservice listens on a given stream or messaging endpoint, the publishing applications need to know where to publish their messages. Another example is a relational database. Many times, even in dev-test scenarios, there is an existing database with prepopulated test data, ready for an application to test against. And you would never imagine a dedicated data warehouse for each microservice. In these cases, the microservice doesn’t need a dedicated database; it needs to connect to the existing database.

This is the slight mismatch between Service Broker design and the microservice use case: the expectation that the service lifecycle is managed by Service Broker, and Service Broker can create service bindings only for the services that it manages. If your application needed to connect to an existing service instance created by an external process, Service Broker couldn’t create a service binding for it.

Service Broker 1.2.0 to the Rescue!

With this release, DevOps teams can deploy their applications into a Kubernetes environment and leverage existing Oracle Cloud Infrastructure service instances (Autonomous Transaction Processing, Autonomous Data Warehouse, Object Storage, and Streaming).

The workflow for using Service Broker with existing service instances is similar to the normal Service Broker pattern:

  1. Create a service instance: Well, in this case, we have to register the existing service with Service Broker, not actually create it. Service Broker can create service bindings only to the services that it created or knows about, so we have to teach it about the existing cloud service instance before we can create service bindings to it. Note that Service Broker won’t manage the lifecycle of an existing service instance that is registered in this way. You can’t use Service Broker to update any parameters of the existing service instance.
  2. Create a service binding: This step is the same as it is for cloud service instances created by Service Broker.
  3. Deploy the application: Same as usual.
  4. Undeploy the application: Same as usual.
  5. Delete the service binding: This step is the same as it is for cloud service instances created by Service Broker.
  6. Delete service instances: This step is a little different for “registered” existing services. Service Broker deletes only service instances that it created. For registered services, Service Broker deletes only the registration.

Let’s walk through the details using an existing Autonomous Database instance with the Autonomous Transaction Processing workload type. In this case, I have an Autonomous Transaction Processing instance that I created with the Oracle Cloud Infrastructure Console.

If I want to deploy a microservice that would use that existing instance, I would perform the steps outlined in the rest of this post.

These steps that you have already installed OCI Service Broker in your Oracle Container Engine for Kubernetes cluster.

All of the YAML file examples used in this post are taken from the samples at https://github.com/oracle/oci-service-broker/tree/master/charts/oci-service-broker/samples.  

Prerequisite: Create a Kubernetes Secret with My Database Password

As a best practice for password management, create a Kubernetes secret to store the database password and the Oracle Wallet password. Encryption is strongly encouraged.

For the full scenario, we need the ADMIN password for the database and a password to use when we create an Oracle Wallet in the service binding. So, we create a secret with the password and walletPassword values in base64 encoding:

echo '{ "password" : "yourPassword1@here"}' | base64
echo '{ "walletPassword" : "yourWalletPwd2@here"}' | base64

The resulting YAML file looks as follows:

Use the following command to create the secret:

kubectl create -f /Users/path/atp-demo-secret-2.yaml

Step 1: Register the Existing Instance with OCI Service Broker

After you create the secret, register the existing Autonomous Transaction Processing instance with Service Broker. Registration is a provisioning step that tells Service Broker where to find the instance. It requires the following parameters:

  • name: The display name of the instance.
  • ocid: The OCID of the instance.
  • compartmentId: The OCID of the compartment where the instance is provisioned.
  • provisioning: Set the provisioning flag value to false.

Note: Each Oracle Cloud Infrastructure service has specific parameters for creating the registration. For details, see the documentation.

The YAML file for the instance looks as follows:

Use the following command to register the instance:

kubectl create -f /Users/path/atp-existing-instance.yaml

When you call svcat get instances, the service instance appears with all the other instances. For example:

       NAME          NAMESPACE          CLASS             PLAN     STATUS  +------------------+-----------+----------------------+----------+-------+  
osb-atp-demo-1       default     atp-service            standard   Ready    
osb-demo-pre-exist   default     atp-service            standard   Ready    
testbucket           default     object-store-service   standard   Ready    
testbucket2          default     object-store-service   standard   Ready 

Remember that OCI Service Broker doesn’t manage the lifecycle of an existing service instance that is registered this way. You can’t use Service Broker to update any parameters of the existing service instance.

Step 2: Create a Service Binding to the Existing Instance

After an existing service is registered with Service Broker, the rest of the use case is the same as if Service Broker provisioned the instance. To create a service binding to the instance, we need a YAML file with the wallet password as a parameter. Because we put the wallet password in a Kubernetes secret, our YAML file refers to that secret.

Use the following command to create the binding:

kubectl create -f /Users/path/atp-binding-existing.yaml

To verify that the service binding was created, call svcat get bindings. Some example results:

             NAME              NAMESPACE        INSTANCE        STATUS 
+----------------------------+-----------+--------------------+--------+
  atp-demo-binding             default     osb-atp-demo-1       Ready  
  osb-demo-pre-exist-binding   default     osb-demo-pre-exist   Ready  
  test-bucket-binding          default     testbucket           Ready  

Step 3: Deploy the Application

The samples in the OCI Service Broker source code include a deployment YAML file that describes how to use an init container to take the values in the Autonomous Transaction Processing service binding and put them in environment variables or in a volume mount. After that, your application can use those values to connect to the database.

Steps 4–6: Undeploy, Delete Binding, and Delete Instance

The details for these steps are identical to the regular Service Broker use case.

Remember, though, that deleting a service instance that was not truly provisioned by Service Broker doesn’t delete the instance; it deletes only the registration of the instance. Service Broker can manage the lifecycle only of service instances that it creates.

More Information

For an introduction to OCI Service Broker for Kubernetes, see the following blog posts:

To learn more, or to try out OCI Service Broker, go to the OCI Service Broker page on GitHub.

To read about the details of registering and binding to Oracle Cloud Infrastructure services, see the documentation.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.