-
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
Use values/secrets from within a remote chart #324
Comments
Well, here's a total hack that appears to work for this use case: releases:
- name: my-chart
namespace: my-namespace
chart: my-charts/my-chart
set:
- name: throwaway
value: {{ exec "helm" (list "fetch" "my-charts/my-chart" "--untar") }}
values:
- my-chart/helm_vars/values.yaml
- my-chart/helm_vars/beta/values.yaml
secrets:
- my-chart/helm_vars/secrets.yaml
- my-chart/helm_vars/beta/secrets.yaml Values and secrets from the downloaded chart appear to get consumed properly. It'd be nice if there was a better way to accomplish this. Even if it's just a better place to run |
@witten Hey! Thanks for the feature request. Looks like you have a very interesting use-case 👍 We're planning to implement hooks #295. With that perhaps you could write helmfile.yaml like: releases:
- name: my-chart
namespace: my-namespace
chart: my-charts/my-chart
# ...
hooks:
preChartLoad: # register as many commands as you want to this hook
- command: {{` helm fetch {{ .Chart }} --untar`}} Would it work for you? |
Yup, that would totally work. And a I think the only question for you is whether you'd rather enable this use case via a hook, or whether it's the sort of thing that would be better supported as a first-class Helmfile feature. (Assuming you want to enable this use case at all.) Either way works for me. |
+1 this would be very useful |
Makes sense! How about
Yeah, I think so too. You can probably achieve that with helmfile.yaml templates, or maybe kind of plugins #325.
I'm not yet sure what would be the best way! It may make sense to give it an out-of-box support if several users use it. But hooks, that already has other use-case, seems to support this specific feature well. I'd just begin with hooks then! |
@2ZZ Thanks for the feedback! Would you mind sharing your exact use-case(s)? |
@mumoshu our use case is the same, we want to store multiple environments values files within a packaged helm chart. This way we can easily version control the config in the same repository as the helm chart itself. |
That'd work. In terms of use cases, I'm actually surprised that storing values/secrets inside of a Helm chart isn't more common. I honestly don't know how most organizations distribute and deploy values/secrets with Helm/Helmfile if they're not using charts for that. Clone a copy of the source for every deploy? Mostly I'm just musing rhetorically here. |
Currently this, to avoid the need of maintaining an internal helm chart repository. But yeah, having something like S3 to store charts bundled with secrets and values seems to make cloning unnecessary and results in faster deployments. Is that your intention? |
Yes, and performance aside, just because of the logistics of it. I currently have dozens of separate repositories, each one with a separate chart (+ values + secrets). If I want to deploy all of these charts via a single The chart repository I happen to be using is ChartMuseum. |
Resolves roboll#295 Resolves roboll#330 Resolves roboll#329 (Supports templating of only `releases[].hooks[].command` and `args` right now Resolevs roboll#324
Resolves roboll#295 Resolves roboll#330 Resolves roboll#329 (Supports templating of only `releases[].hooks[].command` and `args` right now Resolevs roboll#324
Resolves roboll#295 Resolves roboll#330 Resolves roboll#329 (Supports templating of only `releases[].hooks[].command` and `args` right now Resolevs roboll#324
Resolves roboll#295 Resolves roboll#330 Resolves roboll#329 (Supports templating of only `releases[].hooks[].command` and `args` right now Resolves roboll#324
Resolves roboll#295 Resolves roboll#330 Resolves roboll#329 (Supports templating of only `releases[].hooks[].command` and `args` right now Resolves roboll#324
Resolves roboll#295 Resolves roboll#330 Resolves roboll#329 (Supports templating of only `releases[].hooks[].command` and `args` right now Resolves roboll#324
@witten You can use |
My use case: I'm using Helm charts hosted on a private package server not only as a means of packaging up and distributing Kubernetes templates, but also for distributing associated per-environment values and secrets. This means that our helm-secrets files are included in the charts themselves. The main benefit of an approach like this versus keeping the secrets separately is that we don't need a source code checkout (or more realistically, n source code checkouts, one per chart) to deploy. Instead, we can just use the remote chart on the chart server (effectively a build artifact) and deploy it directly.
Where Helmfile comes in is that I'd like to declare several Helm charts to deploy in a
helmfile.yaml
'sreleases:
, and have Helmfile able to pull the relevant values and secrets out of remote charts during deployment (helmfile sync
). Under the hood, this might work by firsthelm fetch
ing each remote chart so that the values and secrets files can be accessed.Also, there's the question of how to refer to those values/secrets. As far as I know,
values:
andsecrets:
currently are interpreted asabsolute paths orpaths relative to the current directory. What we'd need for this feature request to work is a path relative to the root of the remote chart.First, is something like this possible today? Perhaps with
exec
or some other mechanism? If not, does this make sense as a feature request?The text was updated successfully, but these errors were encountered: