Henrik Høegh’s Post

View profile for Henrik Høegh

Senior manager platform engineering at VELUX | ex-Lunar | ex-Praqma | Keynote Speaker

Why you are most likely using Helm wrong when using it in a #GitOps setup What I see a lot of companies who use #Helm do, is to define the version (or tag) of the #docker image in the actual helm chart. Some hardcode it in the #template file, others in the default values.yaml file. And then when they need to release their software component, they create a new release of their Helm chart before releasing their software component. This mean that you have to make a change in two repositories. You'll need a new release of your Helm chart and one of your service. This is wrong in so many ways. If you are using #Flux you produce a #HelmRelease file. This file containers a reference to whatever value file in the chart you want to use as your default values, and you can add your own values that overload the default values. Your helm chart should only have a new release if there are changes to the actual templating part. In this section you can define the image tag / version. Like this :

  • No alternative text description for this image
Audun Nes

Kubernetes | GitOps | DevOps | AWS | Azure | Docker | Terraform | SRE | Linux | Git | Python | CI/CD | Ansible | Bash

10mo

As a side note to this, you can use Renovate Bot to propose PRs on Flux HelmReleases. Quite useful when using Flux to deploy 3rd Party Helm charts: https://docs.renovatebot.com/modules/manager/flux/

To view or add a comment, sign in

Explore topics