Helm and Harness: Tips and Tricks

Hi all!

This will be a rather short post, mainly around some Helm Tips and Tricks, especially in regards to Harness and how to make administration and maintenance easier.

If you haven’t already, make sure to check out the Harness Helm blog (here is part 1) for a good understanding of what Helm is and why people use it.

Rather than explain all of Helm, its origins, and why you would use it; I’m going to assume that you are either currently using it or looking into using it.

I will start by posting my git repo for all Harness related items. Feel free to follow if you’d like to see more!

The essential idea behind the setup in the git repo is that we want to make any of the files related to deployments, services, namespace, etc. as highly templatized as we can. This includes the use of conditional wrappers, lists, etc.

Once this is done, the values file will then be able to dictate what should and should not be deployed. As you can see, although the values file is rather long, all we would need to do now is dictate what we need in the values file by evaluating the booleans to true or false, and then set which values are appropriate for the application. Currently, this is setup in a GitOps style, where the values.yaml file will need to be updated for each new version of an application, which could then trigger Harness to deploy out for you. However, if you were to add ${artifact.metadata.image} to the image: value, you could have Harness trigger the deployment when a new container is uploaded to your artifact repo, which Harness would then feed into the Chart for you.

Either way, this will make the administration of Helm much simpler.

I will continue to add useful items to that Git repo as I build or come across them!

Don’t forget to Comment/Like/Share!