Helmfile - How to manage Kubernetes Helm releases

[@DevOpsToolkit]

What do you think? Is Helmfile worth the investment?

[@oftheriverinthenight]

For sure, I started to use at the end of the past year and help a lot in some deployment at work. Most utility for me: * Posibility of create a values.yaml.gotmpl * Using SOPS for the secrets * Using incubator/raw for custom resources not available on common helm charts * helmfile can be with ArgoCD, but need to create a custom image and onfigManagementPlugins (still investigating this method at the moment)

[@pietersmit621]

Helm has a problem, how to share DRY settings between charts, eg. db details Needs another layer of templating for values.yaml

[@DevOpsToolkit]

@@pietersmit621 Can you tell me a bit more about your scenario? Typically, I would have a chart with a DB with most common default values and then include that chart as a dependency of an app and overwrite DB values with those that are specific to the app. I'm guessing that your scenario is a bit different.

[@MegaAVINASH24]

What if i want to pass template into values.yaml?

[@DevOpsToolkit]

Create a separate values file.

[@javisartdesign]

Thanks ! just to clarify, the templating feature is also part of yaml language, See YAML Anchors and Aliases

[@vimalneha]

You are a great educator Viktor. No one has taught me more than you, be it at oreilly or toolkit series. Since 2017 i am learning from you.

[@DevOpsToolkit]

Thanks a lot, Vimal.

[@yohenson]

I would say its the terraform version of helm. it even has init and apply. and by the way you are great teacher

[@videonext376]

I rather like how helmfile handles 'helmfile template --output-dir=XXX', compared to how helm does base. Instead of rendering out as a single giant yaml, it renders to a directory structure of each sub-chart and each template in that sub-chart. You can then commit that entire directory structure to git, to have a record of the rendered layout of the cluster definition in a format that is very nice for diffs and pull requests.

[@nickweiler3693]

1:33 I believe these are referred to as 'Umbrella Charts.'

[@bogdanbliznuk7355]

Thanks for the video, Viktor! IMHO, layering and composition in kustomize look much better. Also, you can do some diff checks with the "kubectl diff " command. Besides that extensibility & maintainability of the helm charts is still a big concern. So, I'd pick a single tool for manifests management and layering - kustomize.

[@DevOpsToolkit]

In my case, I often end up mixing both Helm and Kustomize. Some 3rd-party apps are easier with Helm if I do not need much more than what is already envisioned by whomever is maintaining them, while I prefer Kustomize when whatever a 3rd-party chart is not giving me what I need. As for the internal apps, Kustomize works better as long as those less experienced with k8s do not need to change much (Helm values are easier for them). In any case, I tend to end up with both, and I don't think that's big of a deal. There's nothing wrong choosing the right tool depending on a scenario. Argo CD (or Flux) helps a lot since, among other benefits, I can focus on updating Argo CD app manifests no matter whether they are referencing a Helm chart, Kustomize, or something else. If I go to your sentence that says "So, I'd pick a single tool for manifests management and layering", I agree. If there would have to be one, it would be Kustomize.

[@hz8711]

Thank you for the good review and the HONEST comparison

[@TankaNafaka]

btw check direnv if you want to inject env vars dynamicaly when you cd to some dir with helmfiles

[@MsLawpan]

Thanks for you video.

[@soubinan]

Definitely it worth the investment, at least for particular environments where: - Deployments needs variable imbrication/combination of dependencies depending features requirements - Applications releases need to be managed with some automation - There is no real saas environment to leverage gitops principles in production I was searching for a concrete demo and I had not found nothing really clear until now. Thank you a lot! So good content! as usual :)

[@teebu]

great video, i wish you talked about the plugins for at least 30 more seconds. the helm-diff hits you right away and you feel like you're doing something wrong.

[@DevOpsToolkit]

You're right. I should have talked more about plugins.

[@learnwithraghuIT]

The best real time knowledge on Kubernetes . Thanks a lot for these videos.

[@DevOpsToolkit]

You are welcome!

[@Farrukhw]

Very informative and useful video... very well taught... Thank you :)

[@Flascoo]

thanks!

[@skurtzemann]

Thanks to take helmfile out of the shadows :) I use it since 2019 and was great to install charts in a declarative way and mostly to have a diff before applying changes ! I agree with you : since I switch to Argo CD and GitOps pattern, i use less helmfile because it overlap... But it's useful for local testing of charts

[@wollginator]

Good one, comes at the right time, thanks a lot!

[@AlexDresko]

I'm supposed to be going to sleep, but this was great!

[@luccapessoa4494]

What is the best option to organize an infrastructure repository that implements core-tools in Kubernetes like: ingress-controller, aws-alb, secrets-provider-class and etc... using helmfile or using kustomize? Has the community set any standards?

[@luccapessoa4494]

I love your content and thanks for sharing your knowledge

[@DevOpsToolkit]

With the emergence of GitOps tools like Argo CD and Flux, I don't think there is the need for Helmfile. GitOps is the way to go today. As for Kustomize... That's my preferable way to define internal apps while I keep Helm to third-party apps.

[@manojkumar-ro5yp]

Hi I have one doubt. In helmfile I additionally added one file to name it as values.yaml. I need to over write the values over the helm chart values.yaml. How to add that value and how I check it worked or not

[@DevOpsToolkit]

I abandoned helmfile in the meantime. It stopped being useful with the adoption of gitops tools like argo CD and flux.

[@tanzeemahmed9774]

Hi, I really enjoy your teaching style. I work as an automation tester and want to understand how to setup Jenkins on k8s such that every time I trigger a test run through Jenkins, a new Jenkins slave machine is created and destroyed after test run completes. Can you please recommend a good starting article or video that can help me get started? Thanks

[@DevOpsToolkit]

Have you seen kzbin.info/www/bejne/aHzGZJmLf6aBd8U. It's a video I published last week and it does what you described.

[@TankaNafaka]

while executing commands in shell you can skip export, just do foo=bar hellm command args etc ...

[@DevOpsToolkit]

You're right. It's one of the habits that became muscle memory so I do them without thinking. Another one, for example, is that I got used to write commands in a way that they can fit into all formats (e.g., printed books) so they always fit into 40 chars per line. That, however, does not make any sense in Gists I make for the videos. Nevertheless, it became a habit that I'm failing to get rid of.

[@eldadyamin]

Great video! Is helmfile compatible or can work with OAM?

[@DevOpsToolkit]

It can. It works with any type of k8s resource.

[@PatsevAnton]

Hi. Viktor. What do you think about helmwave?

[@DevOpsToolkit]

I haven't used it (yet). Adding it to my TODO list...

[@gabrielladias420]

phenomenal video, thank you!

[@Masupialmi85]

Do you have some good examples for using environments and layers through bases? I am struggling with that

[@DevOpsToolkit]

Unfortunately, all of the examples I had around that area are in repos of a customer I'm not working for anymore :( On top of that, the more I use GitOps tools, the less need I'm having for Helmfile. Right now, I'm not using Helmfile at all. With Argo CD or Flux, I could not justify it.

[@Masupialmi85]

@@DevOpsToolkit I managed to build a layered infrastructure with the help of the gitlab Helmfile repo. Personally I also prefer ArgoCD but I have some cases where I just want to install from a Jenkins pipeline. Helmfile is really nice in this case especially when showing the diff

[@ViacheslavHudzovskyi]

thx

[@ShyamKumar-yn2jw]

i use argocd + helm. Is there any tools that updates helm value file before creating chart for different environments ? eg : ingress for different env's or any other good solutions ?

[@DevOpsToolkit]

I recommend updating Argo CD app or application set manifests instead of creating different Helm value files for different environments.

[@ShyamKumar-yn2jw]

@@DevOpsToolkit thanks for the reply. We wanted to make that chart available for download for customers. To make the value fields blank/commented like public helm chart on master branch, any solutions are available ?

[@DevOpsToolkit]

@@ShyamKumar-yn2jw I think that there are two separate needs. One is to have Helm charts always up to date with the latest release, and the other is to have a Helm chart running in an environment and with env-specific values. I tend to cover the latter case with Argo CD. That's the case explained in your initial question that says `eg : ingress for different env's or any other good solutions`. Charts for customers (or charts in general) are a different story. Normally, you do not update them every time you make a release except with tags of images. That should be automated and I tend to use either `sed` or `yq` (github.com/mikefarah/yq) in my pipelines. Essentially, it's 1) clone the repo, 2) replace a tag with a new tag, 3) push it back to the repo. The rest of the changes to charts tend to be manual since they are usually about adding new values, or changing templates. Now, to clarify, I assumed that by "charts for customers" you meant charts that customers install themselves. If it's about charts that you deploy for your customers, then the solution is still to have Argo CD apps that contain whatever values are specific to each customer. You can update those app manifests using the same logic as for charts (e.g., `sed` or yq`) except that for updating tags you can also use Argo CD Image Updater that will push changes to repos whenever you push images with specific tags. P.S. It quite possible that I misunderstood your questions/use-cases and that my answers are off the topic. Please let me know if that's the case. You can send me a private message on Twitter (@vfarcic) or LinkedIn (www.linkedin.com/in/viktorfarcic/) and we can organize a HangOuts or a Zoom session and discuss it in more detail (if that helps more than KZbin comments).

[@ShyamKumar-yn2jw]

@@DevOpsToolkit its actually a chart that customer will install by themselves. Like how users use charts like grafana and Prometheus. I was wondering how they test their value file in master branch. Thanks a lot for your reply. I think ruamel or sed will be the easiest way to update i guess.

[@underlecht]

Other great video, thank you. Good to hear Helmfile can manage many charts. (I am Kustomize lover).

[@DevOpsToolkit]

I also prefer Kustomize. Helmfile does simplify a lot of things. Still, I prefer using Argo CD or Flux. They are not the same but, from the release perspective, their objectives are similar and I believe that Argo/Flux are better choices, especially since they work with (almost) any package/templating mechanism (including Kustomize). I think that Helmfile is great only for those who a) use Helm and b) do not want to (or are not ready to) switch to GitOps-way of managing releases (e.g., if deploying directly through CI/CD pipelines).