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 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.
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.
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 :)
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.
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.
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.
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
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?
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.
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
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.
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.
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.
@@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
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
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 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 ?
@@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 TH-cam comments).
@@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.
What do you think? Is Helmfile worth the investment?
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)
Helm has a problem, how to share DRY settings between charts, eg. db details
Needs another layer of templating for values.yaml
@@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.
What if i want to pass template into values.yaml?
Create a separate values file.
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.
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.
Thanks a lot, Vimal.
The best real time knowledge on Kubernetes . Thanks a lot for these videos.
You are welcome!
Thanks ! just to clarify, the templating feature is also part of yaml language, See YAML Anchors and Aliases
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 :)
Thank you for the good review and the HONEST comparison
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.
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.
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.
I'm supposed to be going to sleep, but this was great!
Good one, comes at the right time, thanks a lot!
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
Very informative and useful video... very well taught... Thank you :)
1:33 I believe these are referred to as 'Umbrella Charts.'
I would say its the terraform version of helm. it even has init and apply. and by the way you are great teacher
phenomenal video, thank you!
Thanks for you video.
btw check direnv if you want to inject env vars dynamicaly when you cd to some dir with helmfiles
Hi. Viktor. What do you think about helmwave?
I haven't used it (yet). Adding it to my TODO list...
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?
I love your content and thanks for sharing your knowledge
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.
Great video! Is helmfile compatible or can work with OAM?
It can. It works with any type of k8s resource.
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
Have you seen th-cam.com/video/2Kc3fUJANAc/w-d-xo.html. It's a video I published last week and it does what you described.
thanks!
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.
You're right. I should have talked more about plugins.
while executing commands in shell you can skip export, just do foo=bar hellm command args etc ...
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.
Do you have some good examples for using environments and layers through bases? I am struggling with that
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.
@@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
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
I abandoned helmfile in the meantime. It stopped being useful with the adoption of gitops tools like argo CD and flux.
thx
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 ?
I recommend updating Argo CD app or application set manifests instead of creating different Helm value files for different environments.
@@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 ?
@@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 TH-cam comments).
@@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.