-
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
Can helmfile be used to sync config to multiple clusters in one run? #728
Comments
Just my two cents. I really like the following approach:
However it won't be a single command to sync stuff, but a sequence of commands like It's too bad as of now the latter doesn't work with the tillerless plugin: #642 Multi-cluster support is the thing I would really like to have as a first-class citizen. UPD: in my original post I made an assumption that it might be possible to set |
It's possible since #682 :) |
@aegershman Thanks a lot for your kind words and the positive feedback! It's really encouraging :) First of all, I do want helmfile to deal with multiple clusters/contexts nicely. Probably I'll be open to add any features/changes to helmfile for that.
I have not thought about it throughoutly yet. But I believe it is possible. At the simplest form, we can currently do: releases:
- name: prod-app1
kubeContext: prod
- name: preview-app1
kubeContext: preview-app1 With go templates the possibility is endless.
So you may have the root When you've kubeContext that is fixed per each environment values:
- values.yaml #contains {prod,preview}Version
helmfiles:
- path: git+ssh://git@github.com/yourorg/envs//prod@helmfile.yaml?v={{.Values.prodVersion}}
- path: git+ssh://git@github.com/yourorg/envs//preview@helmfile.yaml?v={{.Values.previewVersion}} In case you have a "template" or "skeleton" helmfile.yaml that is used to generate environment helmfiles, the root would look like:
// Note that the top-level So I believe you can try this today without waiting any improvement on helmfile side, unless you use tillerless. |
I've done this by having a There are only a few problems I've run into:
# THIS helmfile, e.g. helmfile.yaml, runs "quiet", but when the "delegate helmfiles" under `helmfiles:` run, they don't respect the --quiet flag:
helmfiles:
- path: config/cert-manager/helmfile.yaml
- path: config/scf/helmfile.yaml Besides those issues, it's pretty easy to manage multiple clusters using helmfile (assuming you have all the proper Feel free to address any of the comments I made or close it whenever you like 👍 thanks! |
Saw lot of issues on on kube-context but didn't get a definitive answer. helmDefaults: I have this kind of config in my helmfile but the context is not switching. Does that work with helm3 ? |
I think this is a very good point, if the releases are kubeContext aware, the hooks linked to those releases should be context aware as well. After all, the hooks are designed to prep the cluster before the release and if the release is bound to the cluster most likely the prep command should point to that too. |
First off let me say I really appreciate this project && all the contributors and maintainers who make it possible. Using helmfile has been a noticeable improvement over using "raw" helm in conjunction with Makefiles and bash to manage chart lifecycles on clusters. Thanks a lot for making the operationalization of my team's clusters more declarative and reproducible. Alright, with that pandering out of the way 😉 --
Is it possible to have multiple
helmfile
definitions be applied against multiple/different clusters during ahelmfile sync
run?For example, when I'm operating on a single cluster, I have a single
helmfile
that describes it. To target it, you can usekubectl config use-context mycluster
and thenhelmfile sync
to apply the helmfile to that targeted cluster. But perhaps there a way to applyhelmfile
to multiple clusters within one run ofhelmfile sync
without having to switch contexts and re-run sync.Some usability thoughts:
helmfile.yaml
's for different clusters, and then have all of them be applied in a singlehelmfile sync
?releases:
key?Thanks very much for your time 👍
The text was updated successfully, but these errors were encountered: