Prepare and link bind Oracle Database Cloud, Application Container Cloud, Application Container Cache and Event Hub image 43

Prepare and link bind Oracle Database Cloud, Application Container Cloud, Application Container Cache and Event Hub

A fairly common combination of Oracle Public Cloud services that I use together – for example for the implementation of microservices – is DBaaS, Application Container Cloud, Application [Container] Cache and Event Hub. In this article, I show the sequence of steps I went through in the Oracle Public Cloud console a few days back to prepare a demo environment for my presentations at Devoxx Morocco in Casablanca. Alternatively, I could have used the command line psm tool and a few straightforward scripts to create the cloud environments. The set up I set out to create looks like this:imageSeveral Node applications will run on Application Container Cloud. Each will have service bindings to the same Application Container Cache (a black box powered by Oracle Coherence), a specific schema in a designated pluggable database in an Oracle Database instance and [a specific topic on] Event Hub (with Apache Kafka inside). The applications on Application Container Cloud need public ip adresses, as does the Topic on Event Hub. For my convenience in this demo, I also want to be able access the database directly from my laptop on a public IP address.

This article will show the steps for provisioning the following cloud services – and show where applicable how to enable network access from the public internet:

  • Database Cloud
  • Application Container Cloud
  • Event Hub
  • Application Container Cache

The article also shows how service bindings are created for applications on Application Container Cloud to the cache, the Event Hub and the DBaaS instance.

Database Cloud

image

image

image

image

image

After some time, I received an email, informing me that creation of the database instance was complete:

image

This is reflected in the service console:

image

I can drill down on the service instance

image

and check out the details – such as 150 GB of storage that has been allocated (a bit excessive for my little demo environment) and the public IP address that has been assigned

In order to enable network access from the public internet to the database on port 1521, I need to enable network access rules.

image

In this case, enable the access rule for port 1521:

image

image

At this point, I can check for example from SQL Developer running on my laptop if the database cloud instance is indeed accessible:

image

Note the composition of the Service name – from the DB Name, the name of the identity domain and the fixed string oraclecloud.internal.

Similarly, connecting through SQLcl shows that the database in the cloud is up and running and accessible:

image

Application Container Cloud

image

I create an application [container] for the Node   runtime:

image

In this case, I have uploaded a barebones node application – packaged in a zip-file order-ms.zip – along with a manifest.json file that describes several things, among which how to run this application (“node order-ms.js”)

image

When the upload is complete, the creation of the application commences

image

image

imageNow it is done creating:

image

and the current state of the application can be inspected:

image

The URL for the application has been assigned and is publicly accessible:

image

I can make a test call to the order-ms application:

image

To easily access the logging from the application container – which is written to my Storage Cloud environment – I use Cloudberry for OpenStack (see blog article Graphical file explorer tool on top of Oracle Storage Cloud Service – CloudBerry for easy file inspection and manipulation) which has support for Oracle Storage Cloud:

image

And now the log files are accessible in the desktop tool:

image

At this point, we are mid way to realizing the environment setup:

image 

Next is the service binding from Application Container to DBaaS – for injecting the database access details into the Node application – without having to explicitly hard code the database name, network address and other access details in the Node application itself. The Service Binding produces environment variables for these details that the application can simply read.

image

image

image

The application has to be restarted in order to have changes in service bindings or environment variables applied.

Event Hub and Topic

This earlier blog article – Setting up Oracle Event Hub (Apache Kafka) Cloud Service and Pub & Sub from local Node Kafka client – describes the provisioning of the Event Hub Platform service is in detail. In this particular case, I used one of the predefined stacks to create an environment with Event Hub and Big Data Compute Cloud through the Oracle Cloud Stack Manager:

image

image

image

image

image

Unfortunately, creation of this stack ran for many hours (more than seven) and ultimately failed. It did however provision the Event Hub Platform – a very generously sized Apache Kafka Cluster.

image

image

The next steps for me are to create a Topic on this Platform and to allow access to the platform from the public internet so that Kafka clients can publish to and consume from this topic.

Access rules are required for the Zookeeper Port (2181) and the Kafka Server port (6667).

image

image

image

Next, create a Topic devoxx-topic:

image

image

image

image

Details for the new topic – including its fully qualified name (including the identity domain name, which suggests some sort of multitenancy going on under the covers)

image

This where we are now with the environment:

image

The next step is creating a service binding from the order-ms application on Application Container Cloud to the Event Hub instance:

image

image

And now the event hub details are available inside the Node application through a few additional environment variables, based on this service binding:

image

Application Container Cache

The final service required is the Application Container Cache – an in-memory grid that acts as a very fast key-value store. Using simple HTTP calls we can put stuff (such as JSON documents, simple values, images and other binary blocks) in the cache for safe keeping across multiple requests, multiple instances of an application and also multiple applications. The cache can be used to hold the closest thing to session state or application state in our stateless microservices architecture.

image

image

image

image

And now the cache is ready:

image

Note: the cache cannot be accessed directly outside the identity domain in the Oracle public cloud. In fact, only applications running on the Application Container Cloud can access this cache.

A service binding to the cache from an application on Application Container cloud can be created when the applicationis first created:

image

or in the more usual way.

That means that now the environment we need has been fully provisioned and bound and is available to run our services on.

image