There is no such thing as a robust helm chart. Null was not the billion dollar mistake: templating languages were.
LunicLynx 8 hours ago [-]
I like helm charts but find it very difficult to work confidently on them. Mainly because of yaml and probably not the right tools.
So to one degree I wonder what tools are other people using to get a better experience doing this?
misnome 6 hours ago [-]
We do rendered manifest pattern. The chart gets rendered into a single yaml, that get checked into it's own branch and PR. That way, any changes can be easily inspected before merging and can work with confidence that e.g. changing a setting or updating isn't going to change ALL of the objects. It's also extremely easy to (trustingly) roll back to previous states.
The only downside is that you can't really prune excess objects with this method. We're pushed to use Argo for deployment which I don't really gel with, but I trust it to apply the yaml, and at the very least it highlights when objects need to be removed.
rjzzleep 3 hours ago [-]
KCL fixes a lot of issues, but it doesn't seem to gain any traction. And it's not this unusable mess that ksonnet or jsonnet is.
Honestly my take on Helm charts is to keep them as simple as possible. All the complicated stuff you see in public charts people publish? Yeah stay far, far away from that. Our Helm charts at my job are 95% plain YAML files with an occasional variable insertion to handle cases where you need different hostnames (etc) based on the environment being deployed to. They are a pleasure to work with because they are so simple.
Even some of the examples in TFA (like the optional persistent storage one) are IMO way more complex than what you should use Helm for. At that point you're better off using a programming language to generate the YAML based on some kind of state object you create. It's way too error prone to do that stuff with YAML templating imo.
thecopy 7 hours ago [-]
I also get uneasy feeling, that the "values.yaml" section, it feels often underspecified and a black-box.
gouggoug 8 hours ago [-]
I wish timoni[1] would take off.
It’s based on Cue and doesn’t rely on templating.
[1] timoni.sh
tuananh 5 hours ago [-]
few years ago, everyone thought Cue is gonna replace YAML.
Event Dagger (a big Cue believer) deprecated their Cue SDK back in 2023.
tuananh 5 hours ago [-]
we built a argocd preview that render diff for MR.
reviewing a MR that upgrade helm chart version is a lot less scary.
2 days ago [-]
Rendered at 14:57:29 GMT+0000 (Coordinated Universal Time) with Vercel.
So to one degree I wonder what tools are other people using to get a better experience doing this?
The only downside is that you can't really prune excess objects with this method. We're pushed to use Argo for deployment which I don't really gel with, but I trust it to apply the yaml, and at the very least it highlights when objects need to be removed.
https://www.kcl-lang.io/
Even some of the examples in TFA (like the optional persistent storage one) are IMO way more complex than what you should use Helm for. At that point you're better off using a programming language to generate the YAML based on some kind of state object you create. It's way too error prone to do that stuff with YAML templating imo.
It’s based on Cue and doesn’t rely on templating.
[1] timoni.sh
Event Dagger (a big Cue believer) deprecated their Cue SDK back in 2023.
reviewing a MR that upgrade helm chart version is a lot less scary.