Low-code DevOps Configuration Management

“Low-code” DevOps might seem like an oxymoron. Read on to learn about how CloudTruth’s centralized configuration data platform with built-in Liquid templating can be your “low-code” DevOps superpower.

In any DevOps-centric environment, the primary two goals are:

• Repeatability
• Ensure values (secrets, parameters, variables, configs, etc.) are in the proper place

One of the biggest things that engineers focus on while creating repeatable processes in an environment is doing so with certain values. Variables, secrets, parameters, application configurations, and many other pieces of data.

A good example is when you’re creating Infrastructure-as-Code. You want the process of creating an environment to be repeatable, but to make the process truly repeatable, you need to set it up for all stages; development, staging, and production. To do that, you need the proper values.

In this blog post, you’ll see how CloudTruth brings together a low-code DevOps solution to make this possible.

Implicit Values

When you’re thinking about values that are needed, the range of what those values actually are is pretty broad. It can be anything from variables in a Terraform configuration to parameters that are passed in at runtime in a CICD pipeline. Regardless of what type of values they are, they need to be readily available across any environment.

When thinking about the implicit values that are inside of an environment, you’ll most likely have different values across environments. Some organizations not only have multiple environments, but configurations are incredibly different. For example, maybe in a dev environment, you want 2 replicas for a Kubernetes application, but in staging and production, it’s 5 replicas.

You need a way to specify those values throughout an environment and CloudTruth does it in a low-code way.

As an example, below you’ll see an environment called default. The default environment can contain many parameters but focus on the appname parameter.

Although having a default appname that you can use is great, that’s not realistic for almost any production-level environment. You instead need to specify values for each environment.

Below you’ll see four environments:

• development
• production
• qa
• staging

Notice how each environment can inherit the default value, but that doesn’t really help you much for a multi-stage scenario.

Instead, you can specify a value for each environment. As you can see below, development, production, QA, and staging all have different values.

Templating

When thinking about templates, like Terraform configuration files or Kubernetes manifests, the difference between needing values and needing templates for each environment isn’t that much different. You want to use a template across multiple environments just like you want to use a parameter or variable name across multiple environments that hold different values.

With CloudTruth, you can save one template and control the parameters/values that are passed into the template by utilizing CloudTruth parameters for each environment.

As an example, take a look at the screenshot below. You can see the Kubernetes manifest that’s creating a Persistent Volume. The environment that’s being used is the development environment.

Then, let’s say you want a template for the staging environment, you simply just change the environment to staging.

Now you have one Persistent Volume Kubernetes manifest that you can use across any environment. All you have to do is change the environment and once you do, the correct parameters will be ingested into the Kubernetes manifest based on the environment.