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.

[@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.

[@mw5224]

I was researching helmfile and this was perfect! There is not much out there for it. I agree that we should be moving to gitops tools instead of pipeline deployments but some places are not ready for that yet. Helmfile is a good next step past running helm commands in individual pipelines for each app.

[@learnwithraghuIT]

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

[@DevOpsToolkit]

You are welcome!

[@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 :)

[@hz8711]

Thank you for the good review and the HONEST comparison

[@AlexDresko]

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

[@wollginator]

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

[@javisartdesign]

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

[@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.

[@Farrukhw]

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

[@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

[@MsLawpan]

Thanks for you video.

[@yohenson]

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

[@gabrielladias420]

phenomenal video, thank you!

[@nickweiler3693]

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

[@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.

[@Flascoo]

thanks!

[@TankaNafaka]

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

[@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.

[@PatsevAnton]

Hi. Viktor. What do you think about helmwave?

[@DevOpsToolkit]

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

[@JimBrännlund]

What about using Helmfile for "bootstrapping" a cluster. eg, installing the initially needed tools/applications (incl. ArgoCD) so once it's bootstrapped, you can use ArgoCD for your own applications?

[@DevOpsToolkit]

That would be using helmfile only for the initial installation of argo CD which would deal with all other apps (including future updates of itself). In such a case, I'm not sure why bother with helmfile and not simply run helm install.

[@jimbrannlund4677]

Thanks for the fast reply! The issue I’m struggling with is how to make it obvious what the preferred order of install/applies are. Also, since Helm can’t handle installing to different namespaces, the dependencies are split in different folders. But it’s possible I’m coming at this the wrong way. I prefer Jsonnet, but we don’t use that at my current job.

[@DevOpsToolkit]

Sync order can be problematic with gitops tools but mostly for Cards created by third party tools. You haven't mentioned that so I'm assuming that's not the your case. For most of other types of resources it should not matter. Kubernetes is asynchronous by nature and resources should get eventually consistent. Part of the reason we're using kubernetes is to avoid orchestration where we decide what is done first, what is second, and so on. The need to define the order of what is done and when it's done often happens when people try to apply the logic from before kubernetes to kubernetes.

[@JimBrännlund]

@@DevOpsToolkit I guess you mean "Charts" :) And I'm mentioning it now, haha. To be specific when we bootstrap a cluster it's for things like External DNS, Istio, Cert Manager, Metrics Server, ArgoCD etc. So essentially only third party charts. While what you're saying is true, there are some exceptions, specifically w.r.t CRDs. As an example, you can't create a ClusterIssuer until you've applied the Cert Manager chart as that CRD won't exist before it. There are some other examples, where things can get stuck in a bad state due to ill-designed reconciliation loops etc. Granted, those are likely bugs, but it still happens. :) What I like, after a very shallow examination, with Helmfile is that what constitutes (in our case) a bootstrap is very explicitly defined. The question is, is it worth introducing another tool and dependency just for that. :) I really appreciate you taking the time! Merry Christmas!

[@DevOpsToolkit]

Autocorrect keeps changing charts into cards... I honestly think that helmfile is a waste of time. It was great in the past and i used it a lot before we got argo CD and flux. Now it is only a distraction that will lead you to a wrong path. It is incompatible with gitops. Whatever you choose, don't choose to combine both.

[@eldadyamin]

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

[@DevOpsToolkit]

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

[@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.

[@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.

[@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

[@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.

[@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.