DRY Kubernetes Parameters

There are, what feels like, a million software development best practices. Those best practices typically trickle down from software development to things like Infrastructure-as-Code and configuration languages. Because you can use the best practices across many different types of code, it makes sense to implement them for every environment. Let’s explore the concept of DRY Kubernetes parameters.

In this blog post, you’ll learn about what DRY development is and how CloudTruth can help.

What is DRY (Don’t Repeat Yourself)?

To think about what a DRY Kubernetes parameter implementation looks like, consider this common scenario. Let’s say you have three stages; Dev, Staging, and Prod. Within each of those stages, you’re more than likely using different Kubernetes manifests with different values. For example, maybe you’re using the latest version of a Docker image for the Dev environment, but specifying a different version of a Docker image for production. Another example is maybe in Dev you’re using 1 to 2 replicas and in Prod, you’re using 3 to 4 for Kubernetes application deployment.

The examples above mean you’re constantly repeating code, creating repetitive patterns, and a ton of redundancy.

With DRY Kubernetes parameters, the configuration only appears once. There aren’t multiple Kubernetes manifests that are doing the same thing, but slightly different. There’s one Kubernetes manifest that gets called upon for each environment.

How CloudTruth Helps

Going off of the Kubernetes manifest example in the previous section What is DRY (Don’t Repeat Yourself), let’s talk about what CloudTruth can do to help in this scenario. The Kubernetes Manifest, for example, can be thought of as a stateless application running Nginx. To run Nginx, you need to create a few parameters so the k8s manifest can be used throughout multiple environments:

• The application name itself
• The Docker image name
• The version of the Docker image
• What port to use
• The replicas that you want for each environment

An example screenshot is below.

Once you have parameters set up, you can feed those parameters into a Kubernetes manifest template inside of CloudTruth. That way, for each environment (Dev, Staging, Prod, etc.) you can utilize different values per parameter.

Implementing DRY Configs With CloudTruth

Now that you understand the theory behind it all, let’s learn how to set this up via CloudTruth.

First things first, you’ll need a CloudTruth project. You can create one called kubernetes-secrets.

Next, create some parameters inside of the kubernetes-secrets project.

cloudtruth --project kubernetes-secrets parameter set --value nginx app_name
cloudtruth --project kubernetes-secrets parameter set --value 3 replicas
cloudtruth --project kubernetes-secrets parameter set --value 80 port
cloudtruth --project kubernetes-secrets parameter set --value nginx image_name
cloudtruth --project kubernetes-secrets parameter set --value latest nginx_version

Once the parameters are created, in the directory of your choosing, create a new Kubernetes manifest called deployment.yaml and copy/paste in the following manifest code:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: 
  namespace: default
  labels:
    app: 
spec:
  replicas: 
  selector:
    matchLabels:
      app: 
  template:
    metadata:
      labels:
        app: 
    spec:
      containers:
      - name: 
        image: :
        ports:
        - containerPort: 
---
apiVersion: v1
kind: Service
metadata:
  name: 
  labels:
    run: 
spec:
  ports:
  - port: 
    protocol: TCP
  selector:
    run: 

Open up a terminal and run the following command, which will push the Kubernetes manifest template up to CloudTruth to be used for Kubernetes Deployments. The command below:

• Specifies the CloudTruth project name
• Tells the CloudTruth CLI that you want to create/set a template
• Specifies which Kubernetes manifest you’re using
• Names the manifest “deployment” inside of the CloudTruth UI

cloudtruth --project 'kubernetes-secrets' template set --body deployment.yaml deployment

Once the template is pushed to CloudTruth, you’ll see a new template name like the below screenshot.

You can now create parameters, secrets, and configuration data for Dev, Staging, Prod, or any other stage of your choosing.

Wrapping Up DRY Kubernetes Parameters

Best practices in software development are created for a reason. A lot of those amazing best practices also get used in the DevOps and SRE space. Keeping configurations DRY is one of them. CloudTruth helps in not only storing parameters, secrets, and configuration data, but it also helps developers and DevOps engineers consolidate code and workloads.

Check out more details on the CloudTruth Kubernetes integration and open source Kubernetes operator.

If you’d like to get started with CloudTruth today, there is a free forever version here.

Here’s a short video on this topic: