In this post, we will set up OpenShift Environment Variables on a deployment configuration following a step-by-step approach.

Environment variables are a key component in any production-level application. Many times, we want to control the runtime behavior of an application using environment variables. Common environment variables can be database credentials, feature toggle flags and so on.

Also, often times, we want to avoid modifying and building the code base each time we make such a change. The value for these variables can be modified in a deployment environment to make our application behave differently.

OpenShift also provides this facility to developers. And that is what we are going to explore in this post.

Step 1 – Using an Environment Variable in our Application

We have a basic NodeJS application that creates a HTTP server to accept incoming HTTP requests.

const http = require("http");
const url = require("url");

const server = http.createServer(async (req, res) => {
  const { pathname } = url.parse(req.url);

  if (pathname === "/health") {
    res.writeHead(200, {
      "Content-type": "text/html",
    });

    res.end("<h1>Application is Up and Running</h1>");
  } else if (pathname === "/unhealthy") {
    res.writeHead(404, {
      "Content-type": "text/html",
    });

    res.end("<h1>Page Not Found</h1>");
  } else {
    res.writeHead(200, {
      "Content-type": "text/html",
    });
    res.end(
      `<h1>Hello World from OpenShift NodeJS App in POD NAME: ${process.env.MY_POD_NAME}</h1>`
    );
  }
});

server.listen(8000, () => {
  console.log("Listening to requests on Port 8000");
});

Here, we are using an environment variable in our Hello World message.

Hello World from OpenShift NodeJS App in POD NAME: ${process.env.MY_POD_NAME}

Basically, NodeJS injects a bunch of environment variables using the process.env object. We can also add more variables to this process.env object. In this case the variable name is MY_POD_NAME.

In other words, we have to inject a variable name MY_POD_NAME for it to be available in our NodeJS application.

Step 2 – Adding Environment Variable in Deployment Config

To inject an environment variable, we have to click on the deployment configuration and navigate to the Environment tab. In case you wish to know how we created the deployment config, please refer to this post.

It should appear like below:

openshift enviroment variables deployment config

As you can see, we have entered one environment variable called MY_POD_NAME. We are accessing the value of this same variable in our NodeJS application.

Basically, here we are hooking into the OpenShift Downward API to access the name of the pod in which the application is running.

We can also add the environment variable directly into the YAML file as below:

spec:
      containers:
        - env:
            - name: MY_POD_NAME
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.name

Here, metadata.name provides the value of the pod.

After saving the environment variable changes, OpenShift will re-deploy the application.

In the next step, we can click the URL Route of our application to check the response.

openshift route output

As seen above, the pod name is now printing in the Hello World response message. This indicates that our environment variable was injected properly into the run time environment.

Conclusion

With this, we have successfully injected OpenShift Environment Variables into the Deployment Configuration of our application.

Since we have added it in the deployment configuration, the same environment properties will be available in all the pods that use the configuration.

In similar way, we can inject more environment variables depending on the need of our application. In the next post, we will look at enabling liveness and readiness probes for our OpenShift deployment.

Categories: BlogOpenShift

Saurabh Dashora

Saurabh is a Software Architect with over 12 years of experience. He has worked on large-scale distributed systems across various domains and organizations. He is also a passionate Technical Writer and loves sharing knowledge in the community.

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *