-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] how does helmfile compares to helmsman? #240
Comments
@luisdavim Hey! From my perspective, helmsman seems to have superior documentation and seems to have several features such as:
helmfile seems to be more handy when you want helm-secret support and more templating. helmfile is capable of templating helmfile.yaml and values.yaml. In addition, #214 would allow us to leverage even more helm plugins. #227 will allow you to make each helmfile.yaml and values.yaml self-containted, that would help you organize a bunch of helm apps cleanly. But I'm not an expert in helmsman. Please correct me or drop more information on helmsman, so that I can learn more to grow the helm ecosystem together |
Hi, Thanks for answering. We've just started looking into a solution like this, so far, helmsman seems to be a better fit for us but helmfile seems to have better adoption and faster development pace so I guess we'll have to keep an eye on both of them for now. Thanks |
@luisdavim Thanks for the response! Out of curiosity, what were your specific reasons to choose helmsman over other solutions? I'm eager to learn about your use-case. Perhaps it may be a great source of inspiration to shape what we want for declarative management of helm releases in general! |
This would be a great addition to helmfile
|
The primary reason I use helmfile over something like helmsmen is the templating and structure as it's less verbose. |
@mumoshu it was the closest to the needs we had for our pipelines. |
ya, overall it looks like solve similar issues, but in very different manners. |
@sstarcher Would it be achievable via #205? |
@luisdavim Thanks for sharing your insights Let me comment one by one for perhaps better comparison of the tools, and to provide more contexts to users of the both tools.
That's a valid point! I was personally considering to use helm-tiller, not to rely on server-side tiller at all. That is Probably you want to create the serviceaccount passed to Not sure how helmfile would support that though! Perhaps, if the plugin system (#214) realized, we could author a plugin to declaratively manage tiller-per-ns things, too? Or just add some documentation to explain how you could write bash to achieve that.
Interesting! So, you're doing exactly what is described in the helmsman's docmentation about "move charts across namespaces"? You may already know, but helmfile also accept which namespace the release should be installed, via releases:
- name: myapp
chart: ./mychart
namespace: {{ env "HELMFILE_ENV" | default "default" }}-myapp Although this may look similar to your helmsman config, helmfile as of today is unable to change the namespace of the release. That's due to that on Perhaps we could enhance helmfile as suggested in #197, so that you could write: releases:
- name: myapp
chart: ./mychart
namespace: production-myapp
installed: {{ if eq (env "HELMFILE_ENV") "production" }}true{{ end }}
- name: myapp
chart: ./mychart
namespace: staging-myapp
installed: {{ if eq (env "HELMFILE_ENV") "staging" }}true{{ end }}
helmfile does support private repos locked with username/password or tls client auth.
I definitely agree on usefulness of
Would your use-case required a kind of terraform plan files? helmfile doesn't support it.
Interesting! If you are talking about the workflow of "fix the problematic chart, and rerun helmsman, repeat, to converge the current state to the desired one", probably helmfile could support it via #205. But in case helmsman is doing a fancier thing than just |
Also, helmfile doesn't merge multiple DSFs into one like suggested in the helmsman issue Praqma/helmsman#62. Instead, helmfile allows templating DSFs with golang text/template to achieve the same goal. See #96 for more context. Moreover, |
I like the idea of merging multiple files, it's like docker-compose and terraform tfvars work, my Idea there is to have layers that can be common and layers that are specific to each environment. Helmsman doesn't have support for templating but it does support using environment variables directly on the DSF. For the failed releases I think all it does is, it deletes the failed release and creates a new one and you can choose if you want to purge or not. As I've said, for now we're going with helmsman but I do see that helmfile is evolving much faster, do I'll keep an eye on it. |
@luisdavim Thanks for all the comments! First of all, I do know you're going with helmsman. I just wanted to learn from your user-case so that I can shape how helmfile could help various users in the future!
I think I have the same sentiment with you. Also, #59 #96 are very relevant requests from our users. It would be just that, helmfile targets to manage a bunch of releases, while keeping DSFs small and concise. That's why I added the feature to split a DSF into multiple loosely coupled DSFs. But obviously it doesn't reduce repetition among DSFs. The merge feature would indeed help reducing repetition required in order to write a lot of similar DSFs.
I definitely agree with the benefit of having a common set of configs and layers. If there's a chance helmfile supports it, helmfile.yaml can be enhanced to accept multiple yaml docs to be merged in the order of occurrence, rather than #96, to make the merge ordering concise. {{ readFile "commons.yaml" }}
---
{{ readFile "layer.yaml" }}
---
# your custom helmfile.yaml content on top of the commons and the layer begins... In your awesome PR to helmsman, I believe the merge ordering is specified via the order of command-line flags. helmfile will likely to keep helmfile.yaml self-contained #59 (comment). So, how the tool merges commons and layers will remain different between helmsman and helmfile.
Awesome! Thanks again for your comments! |
Noted about how we should handle failed releases #256. |
I've implemented a bunch of features recently so the only remaining features that were inspired by this discussion are #270 and #256. #270 has been already implemented but not yet merged, because it lacks concrete use-cases right now. An alternative to #270 that is already usable is #227. You can import and merge any yaml files into Please comment on respective issues in case someone finds those features useful! Thanks. |
that's awesome @mumoshu |
Probably we can close this now? 😃 |
Very late to the party, I find Helmsman has a better level of abstraction and suites CI/CD delivery well, however, Helmfile suites those who don't want the details obfuscated, and pairs well with a GitOps delivery approach. |
Hi,
I would like to know, from your point of view, how you think helmsman and helmfile compare to each other.
Thanks.
The text was updated successfully, but these errors were encountered: