Ephemeral Environments: Namespaces

Hey all,

Of the many different benefits in DevOps and the codifying of everything, the ephemeral environment is one of great benefit and great mystery. Figuring out how to create an environment, bootstrap it, deploy to it, test the deploy, and then tear it down is not the easiest thing to do.

For this post, here is an example of how to do this using payload info from a Git repo, through a trigger, which creates a namespace of the same payload value, and then deploy to it. If you’d like an example of how Harness is doing this internally, here is a great blog post to read

Harness Service

The first thing to do is create a Harness Service for Kubernetes. My advice in this case is to use Go Templatized YAML (similar to Helm) to make it easier in the long run (to see an example of this, you’ll just need to create a new Kubernetes Service in Harness and you’ll see a pre-built template).

One of the initial issues with Git Payloads is that the values from the payload may not be in a good format for K8s namespaces (using / or UPPERCASE LETTERS, etc), so you’ll need to make sure that you understand what will be coming in trough the payload, what consistencies there are, and what you’ll need to convert to make it work.

In this example, we will assume that there will be both / and UPPERCASE, but there will be a consistency as well. Example: Payload value is 374/BRANCH-12345 and we only want branch-12345 for the namespace.

In the Harness Service, in the values.yaml file, you’ll need to put in a key:value pair for the namespace like namespace: ${regex.extract("BRANCH-[0-9]+$", workflow.variables.branch)}

This will extract the last part of the value from the Payload and pass it to the namespace.yaml file. To convert the values to lowercase, we will use a YAML trick, adding {{.Values.namespace | lower}} for the conversion

Environment and Infrastructure Definition

Because of this, we can add anything we want to in the namespace field for the Environment’s Infrastructure Definition (in this case, we use default)


The last thing to do is to add the Workflow Variable in the workflow to match what is from the regex in step 1

You can supplement the Trigger Payload Value by simply deploying and adding the value in the Deployment form


To check the output, just open the Execution Context on the right and make sure the name of the namespace is correct

Hopefully that helps!

Don’t forget to Like/Comment/Share!