May 31, 2022
DRY Kubernetes Parameters
Written by: Michael Levan
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
Next, create some parameters inside of the
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: