Kubernetes Operators are an awesome way to simplify work for developers to setup and maintain complex applications in Kubernetes or Red Hat OpenShift.
The IBM Cloud Operator provides you the ability to bind IBM Cloud services to your applications running in Kubernetes or RedHat OpenShift and create, update, and delete IBM Cloud services from within the cluster by calling Kubernetes APIs, instead of needing to use several IBM Cloud APIs in addition to configuring your app for Kubernetes.
That example shows how to bind an existing Cloudant service instance in IBM Cloud to an application running in Red Hat OpenShift. The content of the example is related to the usage of the Red Hat OpenShift with IBM Cloud Open Labs. In these labs you can use a preconfigured OpenShift environment for four hours at no charge to run workshops by your own. By the way, here you can find the related source code for the examples.
It is related to lab2 in the open labs, as you see in the image below.

My example instruction does expect you already have a setup of the …
- … IBM Cloud Operator in your Red Hat OpenShift cluster.
- … IBM Cloud Cloudant service instance with a Cloud Foundry service alias running in IBM Cloud.
Note: I use my service names as an example in the documentation, you have to replace them with your service names ;-).
Overview of dependencies between IBM Cloud and Red Hat OpenShift¶
The following image contains an overview of the dependencies between IBM Cloud and Red Hat OpenShift for the example.
It contains following items:
- IBM Cloud
- Existing Cloudant service instance
- Existing Cloudant service alias
- IBM Cloud Operator configuration
Lets start with the major steps you should be aware of:
Step 1: Verify you have a Cloudant service instance¶
Step 2: Verify that you have a Cloud Foundry service alias for your Cloudant service instance¶
Step 3: Configure your operator service¶
This is the configuration for my example. For more details please visit the documentation for services in the IBM Cloud Operator. You see that the externalName: hackathon-node-red-tsuedbro-CloudantNoSQLDB
uses the of the Cloud Foundry alias name.
apiVersion: ibmcloud.ibm.com/v1
kind: Service
metadata:
annotations:
ibmcloud.ibm.com/self-healing: enabled
name: hackathon-node-red-cloudant-rh-alias
spec:
plan: Alias
serviceClass: cloudantnosqldb
serviceClassType: CF
externalName: hackathon-node-red-tsuedbro-cloudantNoSQLDB
For more information please visit the GitHub project and understand the service properties.
Note: If you don’t have a service alias, you can create one with this command.
ibmcloud resource service-alias-create "{ALIAS_NAME}" --instance-name "{IAM_SERVICE_NAME}" -s "{SPACENAME}"
Step 4: Create a service instance using the configuration from the last step¶
Use our installed operator to create the service instance.
Step 5: Verify your created service instance¶
Step 6: Configure your operator binding¶
This is the configuration for my example. For more details please visit the documentation “bindings of the IBM Cloud Operator”
apiVersion: ibmcloud.ibm.com/v1
kind: Binding
metadata:
name: cloudant-binding
spec:
serviceName: hackathon-node-red-cloudant-rh-alias
Step 5: Create a binding instance using the configuration from the last step¶
Just use our installed operator to create the binding instance.
Step 6: Verify your created service instance¶
Step 7: Configure environment variable of your backend application¶
Step 8: Verify the database access in for application¶
Now you should be able to use the database in your application.
Note: You have to do some additional steps for the configuration in the frontend application, but that’s documented in the lab2.

Summary¶
The IBM Cloud Operator really simplifies the setup of integrations to IBM Cloud services to applications.
Maybe this was useful for you and let’s see what’s next?
Greetings,
Thomas
#Operator, #OpenShift, #IBMCloudOperator, #CloudFoundryAlias, #OpenLabs
Leave a Reply