Skip to Content
Technical Articles

SAP on Google Cloud: HANA HDI containers and CI/CD pipelines (pt.2)

 

We built an application with managed containers using Node.js and Golang for the frontend and backend modules and HDI containers on SAP HANA. We defined a CI/CD pipeline to keep them consistent.

In this blog post, we’ll explain what the CI/CD pipeline looks like and how it incorporated the concept of HDI containers. This follows part 1.

The application

As you see in the boxes inside of boxes above, our application has three micro-services:

  • A frontend, a web application written in Node.js
  • A backend application, written in Golang, that also talks to the translate API
  • A database access layer responsible for talking to SAP HANA using the Node.js client for SAP HANA

You can create this app yourself, hopefully for free and without swiping a credit card. We published this Qwiklab that will spin up a HANA Express machine on Google Cloud for you while you complete the lab. The initial free Qwiklab credits should be enough to run this lab. I’d recommend you clone the app into your own GitHub so you can use it afterwards.

The pipeline

I think the pipeline is better understood when in action. So let’s say we are a group of developers working on the different microservices that comprise our application.

Here’s how the tooling overlords would govern our day (or how we govern them, we’ll see…)

Shared Git Repository

We chose Google Cloud Source as a private git repository. This repo and its master branch were “born” with the application.

You know what else was born with the first deployment? An HDI container!

Creating the HDI container

Just like we have a branch that acts as the main branch, we’ll have an HDI container that will act as the reference to all and will be loaded with test data.

Here’s an example of how this first container was created using the hana-cli.

Here’s the asciinema if you want to follow along/ copy and paste.

The default-env.json file now contains credentials to this container. The Node.js library hdi-deploy will look for a file with this name or the environment variable VCAP_SERVICES to connect to SAP HANA and deploy our new tables and other artifacts into the HDI container.

We will use the contents in this file to create an environment variable called VCAP_SERVICES later.

Starting a change

hana-cli connect -s
hana-cli createContainer -c RUN_LS -e -s

Now I have the new credentials for this container in a new .json file. I will go ahead and make a change to the table I pulled:

Using the new credentials in the default-env.json file, the ones for my RUN_LS container, I will deploy this change. The default-env.json file should be in the /db folder, from where we run these commands:

npm install
npm start

This calls the hdi-deploy module so it can create an HDI container and create a schema with my tables.

Since our credentials are not meant to leave our local environment, let’s make sure the .gitignore file includes these default.env*.json files.

 

We should now see the change in my Git branch in Google Cloud Source:

Merging a change

Asciinema here.

And after we have merged the changes, the main branch is now showing them… as expected:

Automated deployment and testing

The tool we are using to coordinate this is Cloud Build. We are using a trigger to start the build and test process every time there is a push into the main branch:

Using the docker container and injecting the VCAP_SERVICES as an environment variable, so that the Node.js deployer can do its magic with the main HDI container, RUN:

(Originally posted in medium.com)

2 Comments
You must be Logged on to comment or reply to a post.