Developing NodeJS microservice for an OpenShift Cluster — Part II

Nagesh Subrahmanyam
Nov 1 · 6 min read

Abstract

This is the second article in a series that describes the development and deployment of a microservice in NodeJS for an OpenShift cluster. For the sake of simplicity, this series considers minishift as the OpenShift (v3.11) cluster running on a Mac laptop with 8 GB RAM. The artifacts developed for OpenShift are covered in Part I.

Here is an index of the articles:

  1. Part I — Developing NodeJS microservice for an OpenShift Cluster — Part I — Project description
  2. Part II — Developing NodeJS microservice for an OpenShift Cluster — Part II (this article) — OpenShift artifacts creation with CLI and NodeJS considerations
  3. Part III — Developing NodeJS microservice for an OpenShift Cluster — Part III — OpenShift artifacts creation with web console and NodeJS considerations

Introduction

This article describes the considerations for NodeJS application development. It also puts the application together with the artifacts developed in Part I for a final solution.

NodeJS Application development

The Part I article described the NodeJS application to be driven by a configuration file for server port number and Redis instance details. The server details were provided by a ConfigMap that is itself referenced in the DeploymentConfig.

NodeJS Application development — Server configuration

Let’s take a look into the ConfigMap. To list the configuration maps, run the command oc get configmap and look into details of the configuration map, run the command oc get configmap/custdemo-cfgmap-custapi.

Configuration Map added in OpenShift
  1. Under Data in the console output, the key custapi.config has the value as the JSON document api-server-config.json as described in Part I article.
  2. In the DeploymentConfig, the key env under containers refers to the key CUSTDEMO_CONFIG. It is this key that will be available to the NodeJS application as environment variable.
  3. The value of the key, in the DeploymentConfig, is set to the key custapi.config in the custdemo-cfgmap-custapi configuration map.
  4. To access the environment variable in NodeJS application, use process.env.CUSTDEMO_CONFIG. Since the value is a JSON document, the NodeJS application will parse it as a JSON document i.e. JSON.parse(process.env.CUSTDEMO_CONFIG)
  5. Refer utils/argcheck.js in the GitHub repository to see this in action.

NodeJS Application development —Redis server

The Part I article defined a Service and an Endpoint to connect to an Redis instance with its external IP address. The environment variables related to this Service are automatically added to every pod in the namespace. Specifically, the environment variables are CUSTDEMO_EXT_CACHE_SERVICE_HOST and CUSTDEMO_EXT_CACHE_SERVICE_PORT. Note, the CUSTDEMO_EXT_CACHE is derived from the service name in openshift-demo-service.yaml.

These variables can be accessed in NodeJS as process.env.CUSTDEMO_EXT_CACHE_SERVICE_HOST and process.env.CUSTDEMO_EXT_CACHE_SERVICE_PORT. Refer utils/argcheck.js in the GitHub repository to see this in action.

This flow into environment variables is depicted in the diagram below.

Flow of environment variables into NodeJS application

NodeJS Application deployment

The following options for launching of applications exist:

This article focuses on ‘path of least resistance’ and demonstrates the usage of oc CLI and YAML files.

Launching the artifacts and application

The OpenShift artifacts are created in the order as shown below. While all of these artifacts can be created from the web console also, this article describes the CLI approach for sake of simplicity.

  • Project
  • ConfigMap for server configuration
  • Service and Endpoint for Redis
  • Route for exposing the API end-point service.
  • DeploymentConfig for referencing the configuration map.

You may clone this repository — https://github.com/nsubrahm/openshift-demo-artifacts.git — for YAML files to create the artifacts or read through rest of this section to create the YAML files by hand.

In the cloned version, ensure that, the IP address and the port number of the Redis instance is changed in yaml/openshift-demo-endpoint.yaml file.

YAML file — ConfigMap

Using the contents of api-server-config.json, create a YAML file, openshift-demo-configmap.yaml to create a configuration map for the API end-point.

Configuration map for properties of the Customer Demo APIs

Notes:

  1. The value of namespace should be same as the name of the project.
  2. The port number (line 10) and database number (line 13) may be changed, if required.

YAML file — Service

There are two ways a NodeJS API end-point — hosted in an OpenShift cluster — can connect to an external service.

  1. Connect via IP address
  2. Connect via FQDN

This article demonstrates the connection to Redis data store via the IP address through Service and Endpoint. To create a Service, create a YAML file openshift-demo-service.yaml, with the contents below.

Service definition for external Redis instance

Notes:

  1. The value of namespace should be same as the name of the project.
  2. The port number (line 11) should be the one configured for Redis instance. By default, it is 6379.

YAML file — Endpoint

To create an Endpoint, create a YAML file openshift-demo-endpoint.yaml, with the contents below.

End-point definition for external Redis instance

Notes:

  1. The name (line 4) should be same as the one created for Service object above.
  2. The value of namespace (line 5) should be same as the name of the project.
  3. The ip (line 8) should be set to the IP address of the external Redis instance.
  4. The name (line 10) should be same as the one set in Service object above.
  5. The port (line 11) should be set to the port number of the external Redis instance.

YAML file — Route

To create a Route for the Service of API end-point, create a YAML file openshift-demo-route.yaml using the contents below.

Route definition to expose the service

Notes:

  1. The value of name (line 6) will be used to generate the URL for external consumption.
  2. The value of namespace (line 5) should be same as the name of the project.
  3. The value of name (line 11) should be same as the name of the Service object created from the oc new-app command.

YAML file — Deployment Configuration

To create a DeploymentConfig for the application, create a YAML file, openshift-demo-deployment-config.yaml using the contents shown below.

Create OpenShift objects and application

To create objects and application defined in the YAML files above, use the oc commands as shown below.

List of artifacts created

The artifacts can be located via the web console under the project custdemo or via oc get console command for the appropriate resource e.g. oc get service for services, etc.

A key point to be noted here is the fact that, oc new-app actually results in the following:

  1. Build Configuration — oc get bc will show the build configurations. A build is also triggered using that build configuration.
  2. Service — is generated for port 8080 by default and can be located via oc get service.
  3. Deployment Configuration — is generated by default to launch the appropriate pods and can be locate via oc get dc.

As a result of the build, an Image Stream is also created and can be located via oc get is. Also, pods are created as a result of the deployment configuration. They can be located as oc get pods.

A route is also created to expose the service for the API end-point. The URL for this route can be seen under the HOST/PORT column in the output of oc get route. Note that, the custdemo-apis is called out as the name in the openshift-demo-route.yaml.

Redis connection

Recall that, the connection to the external Redis instance was set-up with a Service and an Endpoint. The logs of the deployment configuration should look something this:

API end-point launch logs
  1. Line 18 shows that the application connected to Redis successfully. Note the IP address shown. It is definitely not the same as that of the external Redis instance. Recall that, the Service is visible internally only. The connection is established because an Endpoint references the Service.
  2. Run the command oc get service to locate the custdemo-ext-cache service as defined in the openshift-demo-service.yaml . The IP address seen under CLUSTER-IP column is same as seen in the deployment configuration longs.
Redis service

Testing

The application can be tested using Postman using scripts as provided here: https://github.com/nsubrahm/openshift-demo-postman

Note: Ensure that the host name matches the one seen in the Route object created with openshift-demo-route.yaml.

On CLI, with curl, the following commands can be run for testing:

  1. Add a customer — curl -X POST http://custdemo-apis-custdemo.192.168.99.100.nip.io/customers -d ‘{“name”:”OpenShiftDemo”,”address”:”Hebbala, Bengaluru, INDIA”}’. That should result in a response as {“message”:{“key”:934081943}}.
  2. Get customer with a ID — curl -X GET http://custdemo-apis-custdemo.192.168.99.100.nip.io/customer/934081943
  3. Edit customer with a ID — curl -X PUT http://custdemo-apis-custdemo.192.168.99.100.nip.io/customer/934081943 -d ‘{“name”:”OpenShiftDemo”,”address”:”Indiranagara, Bengaluru, INDIA”}’
  4. Remove customer with a ID — curl -X DELETE http://custdemo-apis-custdemo.192.168.99.100.nip.io/customer/934081943

Nagesh Subrahmanyam

Written by

Software Architect — converts voice of customer to realistic, monetized products.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade