Cloudant DB with IBM Cloud Operator
Last updated
Was this helpful?
Last updated
Was this helpful?
Currently, the Example Health patient-ui
app is using a dummy in-memory patient. In this exercise, you'll create a Cloudant service in IBM Cloud and populate it with patient data. Cloudant is a NoSQL database-as-a-service, based on CouchDB.
Let's understand exactly how Operators work. In the first exercise, you deployed a simple application using a DeploymentConfig and Pods -- these are "default resources" that come with OpenShift. A custom resource definition allows you to create resources that are not necessarily running within Kubernetes, such an IBM Cloud service. Operators manage the lifecycle of resources and create CRDs, allowing you to manage custom resources the native "Kubernetes" way.
Navigate to your OpenShift console, access the Administrator view, and click Operators > OperatorHub
Find the IBM Cloud Operator, and hit Install
Keep the default options and hit Subscribe:
You may need to wait a few seconds and refresh for the operator to show up as Installed
:
Next, you'll need to set your IBM Cloud credentials so that the Operator knows how/where to create your Cloudant service. The operator needs to create the service in your own account, rather than the shared IBM lab account.
Remember: Pick your own account, not IBM.
Next, set your CF org, space and resource group where the Cloudant service will be created. Resource group is usually named default
or Default
-- case-sensitive.
Verify that all fields are set:
If any of these fields are not set, the Operator will fail to create your service!
Make sure you're logged in to the cluster in this terminal session. Otherwise you must re-run the command oc login
with the cluster information:
.
Use the helper script provided by IBM to create a new API token, and register it as a secret in your OpenShift cluster:
Verify that all the fields in data
are set for the configmap (org
, region
, resourceGroup
and space
) and secret (api-key
and region
):
Output:
Once the Operator is installed, the Custom Resource Definitions to create the Cloudant service are also available. Navigate to your OpenShift dashboard, ensure you're in the Administrator view, navigate to your Installed Operators and click the IBM Cloud Operator:
You'll see that there's two APIs available -- a Service and a Binding. A Service will allow us to create the actual Cloudant service itself -- do that first by clicking Create Instance under Service. Copy and replace the following YAML:
Hit Create.
Wait a couple minutes for the service to provision. You can check the status by clicking on your service, and looking for Message: Online:
You can also debug any potential issues here. If you already have a Cloudant "Lite" service, you won't be able to create another. To work around this issue, edit the service yaml to use standard
instead of lite
. Note that "Standard Cloudant" is a paid service. Another option is to navigate to your IBM Cloud dashboard and delete your existing instance of the lite
Cloudant.
You may need to switch to your own account using the switcher on the top right.
Next, create the "binding" resource for your Operator (instead of Service as you did above):
The binding should get created fairly quickly -- you can check the status by clicking on your binding, and looking for Message: Online. By navigating to the Resources tab, you can see that the cloudant-binding secret is created. Click that to see your credentials for accessing your Cloudant DB, stored securely in a secret:
Now you'll create the Node.js app that will populate your Cloudant DB with patient data. It will also serve data to the front-end application that we deployed in the first exercise.
Make sure you're in the project example-health:
Run the following command to create this application:
The app will crash and fail to start repeatedly because the credentials to the Cloudant DB haven't been set yet.
Let's fix this by setting the environment variable to the cloudant-binding secret we created earlier. Navigate to the deployment config for the patient-db
app by clicking the app, and then selecting the name next to DC:
Go to the Environment tab, click Add from Config Map or Secret and create a new environment variable named CLOUDANT_URL. Choose the cloudant-binding secret, then choose url for the Key. Hit the Save button.
Go back to the Topology tab, and the patient-db should successfully start shortly.
The patient-ui
application has a configuration option for the backend database. To start using the database you configured above, follow the steps below to configure it.
Access your patient-ui application again and click Settings.
To find your routes, you can use the OpenShift console or type oc get routes
.
Input the route http://patient-db:8080/
and hit the node OpenShift icon.
You won't need to expose this application with the oc expose
command. This is because your frontend patient-ui
application can talk to the backend patient-db
without the network request leaving the cluster. Kubernetes keeps an internal DNS record of the services which resolve to the IPs of the running application.
Your application is now backed by the mock patient data in the Cloudant DB! You can log-in using any user-id/password in the Cloudant DB, for example "opall:opall".
Launch the Cloudant dashboard and click the patients
db.
Click through the different patients you can log-in as.
After verifying that there's no bugs and the service is "online", double-check that the Cloudant service exists in your account:
In a real-world application, these passwords should not be stored as plain-text. To review the patients (and alternate logins) in the Cloudant DB, navigate to your services in IBM Cloud . Click cloudant-service.