X

A blog about Oracle's Database Cloud Service Technology

  • September 20, 2018

Building Microservices on Oracle Autonomous Transaction Processing Service

Kris Bhanushali
Sr. Principal Product Manager

Containers allow us to package apps along with all their dependencies and provide a light-weight run time environment that provides isolation similar to a virtual machine, but without the added overhead of a full-fledged operating system.

The topic of containers and microservices is a subject on its own but suffice to say that breaking up large, complex software into more manageable pieces that run isolated from each other has many advantages. Its easier to deploy, diagnose and provides better availability since failure of any microservice limits downtime to a portion of the application.

Its important to have a similar strategy in the backend for the database tier. But the issue is if you run multiple databases for each application then you end up having to maintain a large fleet of databases and the maintenance costs can go through the roof. Add to that having to manage security and availability for all of them.

This is where the Oracle’s autonomous database cloud service comes in. It is based on a pluggable architecture similar to application containers where one container database holds multiple pluggable databases. Each of these pluggable databases or PDBs are completely isolated from each other, can be deployed quickly and can be managed as a whole so that you incur the cost of managing a single database while deploying multiple micro services onto these PDBs.

The Autonomous cloud service takes it a step further. It is self managing, self securing and highly available. There is no customer involvement in backing it up, patching it or even tuning it for most part. You simply provision, connect and run your apps.

Oracle even provides a 99.995 SLA. That is a maximum of 2 minutes, 11.5 seconds of downtime per month.

 

Note there are two Docker files in the repository. That’s because we have two different applications – ATPnodeapp and aOne. Both of these are node.js applications which mimic as microservices in our case.

ATPnodeapp simply makes a connection to the ATP database and does not require any schema setup. aOne, on the other hand is a sample marketplace application and requires schema and seed data to be deployed in the backend. If you plan to use that app, you will need to first run the create_schema.sql scripts on the database. Btw, the app is called aOne since its built on the angularjs, Oracle, node and express stack J …yeah baby!

Let’s provision an ATP instance to start with.

Log into your Oracle Cloud infrastructure account. Once logged in, from the top left hamburger menu, select Autonomous Transaction Processing

Oracle Cloud Infrastructure allows logical isolation of users within a tenant through Compartments. This allows multiple users and business units to share a tenant account while being isolated from each other.

 

Once you have chosen the compartment assigned to you, you can then click to create your ATP instance.

On the Create ATP form, enter a display name, DB name and an admin password. You can also choose an instance shape, specified by the CPU count and storage size. Default CPU is 1 core and storage is 1 TB which is also the minimum.

Hit  button at the bottom and your database will be provisioned in a few minutes. That is all it takes. Of course, if you do not like logging on to web consoles you can use the REST API interface to programmatically deploy ATP instances along with your application stack

Now, if you wish to deploy the aOne app, you would need to connect to your database using a SQL client and run the create_schema script in the default admin schema or create a suitable user schema for the application.

https://github.com/kbhanush/ATPDocker/blob/master/aone/create_schema.sql

You will also need to download the secure connectivity credentials file from the database admin console.Unzip and store the wallet folder in the same folder as your application under /wallet_NODEAPPDB2.  This folder is copied into your container image when you run the docker file. Alternatively, you can choose to remove that command from your docker file and manually copy the file to your image when you run your container. That way, if you build and store your docker image in the public docker repository you certainly don’t want your credentials files in there.

In your wallet folder, edit sqlnet.ora and replace the contents of that file with the following text-

WALLET_LOCATION = (SOURCE = (METHOD = file) (METHOD_DATA = (DIRECTORY=$TNS_ADMIN)))

This tells the driver to look for the wallet in the path setup in variable TNS_ADMIN

Assuming you have downloaded the Dockerfile, database wallet and created the backend schema, you can now build your docker image

Ensure you are in a folder that contains the wallet folder /wallet_NODEAPPDB2 when you run this command

$ docker build –t aone .

-t options gives your image a tag ‘aone’. Don’t forget to include the period in the end. It means ‘use the Dockerfile in the current folder.

You can also specify your dockerfile as,

$docker build –t atpnodeapp –f Dockerfile2 .

 

[ Note: this will build another app called ATPnodeapp in the image]

 

If all goes well, your image should be ready in less than a minute. Note that the entire image is about 400 megs.

 

Note that docker creates multiple image files as it builds each layer. Your final image would show at the top of the list and will have the tag you chose.

 

$ docker images –a

 

REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE

aone                    latest              b8db0c7d015e        10 days ago         408MB

<none>                  <none>              44af88220a69        10 days ago         408MB

<none>                  <none>              ed6b184684cb        10 days ago         408MB

<none>                  <none>              d192d0f45d3f        10 days ago         402MB

<none>                  <none>              c9fe8df71a18        10 days ago         402MB

<none>                  <none>              04b8fcac90ea        10 days ago         402MB

<none>                  <none>              251c11bebdb1        10 days ago         402MB

<none>                  <none>              5801d93521ba        10 days ago         402MB

<none>                  <none>              86f9bbbd6de2        10 days ago         402MB

 

Finally, you would need to launch your docker image change the dbuser, password and connect string to match your database in dbconfig.js

$ docker run aone

Once inside the image,

# cd /opt/oracle/lib/ATPDocker/aone/scripts

# cat dbconfig.js

module.exports= {

user: "nodeuser",

password: "password"

connectString: "nodeappdb2_high" }

 

Replace the user, password and connectString to match the database and user you just created.

 

To run your node.js app,

$ node server.js   &

Node responds with this message –

aOne listening on port 3050

 

Now to check out the app on a browser, you will need to bridge port 3050 on the container to your local host. Exit nodejs, make sure you kill the process and shut down and exit the container.

Re-run the container with the following docker command –

$ docker run –i –p 3050:3050 –t <tagname>

Open a browser on your local host and go to http://localhost:3050

This is what you see if your app ran successfully,

You just built and provisioned an entire application stack consisting of a microservice and a enterprise grade, self managing database. You can push your docker image to a public/private docker repository and it can be pushed to any container orchestration service either on-prem or with any cloud provider. Your database is autonomous – it provisions quickly, backs up, patches and tunes itself as needed.

 

Join the discussion

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