-
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
[Feature Request] Add local Helm Chart templates to repository chart release #494
Comments
@sboschman Hey! Thanks for the request, and the detailed explanation. If you don't mind paraphrasing, you want adhoc resources to be injected into the helm release, right? If so - yes, I felt similar frustration while using another charts, and wondered how I could fully manage all those with helm. That being said, I was thinking that using the https://github.com/helm/charts/tree/master/incubator/raw With the chart, instead of:
You'll write: releases:
- name: myprometheus-secret
chart: incubator/raw
values:
- resources:
- apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: prometheus-basic-auth-secret
stringData:
auth: {{ env "MY_PROM_SECRET" }}
- name: myprometheus
chart: stable/prometheus
values:
- values.yaml
secrets:
- secret/my-prometheus-secret.yaml A downside of this approach is that you need to inject the prom secret as an envvar OR maintain not only the secret value but the whole secret object within a For that, I was considering to enhance the releases:
- name: myprometheus-secret
chart: incubator/raw
values:
- templates:
- apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: prometheus-basic-auth-secret
stringData:
auth: {{` {{.Values.myPrometheusSecret}} `}}
secrets:
- secret/my-prometheus-secret.yaml
- name: myprometheus
chart: stable/prometheus
values:
- values.yaml I can send a PR to |
PTAL: helm/charts#12422 |
|
@mumoshu Thanks for your elaborate reply. Yes, it is basically about injecting adhoc / arbitrary resources into the release of a chart. Merging them into the release itself would be great, but I can live with the I have used envvar (required in helm template) for secrets before, and that is less than ideal for sure. Encrypting entire resource objects is also a pain, as they basically become unreadable to us poor humans. Being able to template stuff into I see you beat me to making changes to |
I have used the
where I have a pod manifest defined in the docker-image-change-watcher.yaml file. One issue though is that the |
Do you get the ci configmap using the I get the following results, using helmfile v0.47.0. Using the Use templates (:+1:):
Use resources (:-1:):
Use resources, and explicitly disable templates (:+1: 1:):
@mumoshu Can we circumvent ci in some other way (https://github.com/helm/charts/blob/master/incubator/raw/values.yaml#L68) ? Everyone using the |
indeed using the |
helm/charts#13633 should fix the ci-configmap issue. |
I still think that this core ask is a good idea. Consider for a moment a helm chart like Jenkins. It might be desirable to store the CasC in a config map to limit the size of the values file: then to apply said config map when changing the chart:
Where the values file will look something like this:
While this solution works, it's not as clean as it could be IMHO, as it's impossible to review diffs in the CasC which can lead to problems if some Junior Dev or Old School admin is trying to do some ClickOps. Maybe there's a way to copy a template to the chart directory using a hook. If so please lemme know and that would solve my issue with the diffs, and I think it would solve the core of this issue. Again not sure if that last part is possible. |
I did it like this:
the secret is looking like this:
|
incubator/raw is now deprecated : https://github.com/helm/charts/tree/master/incubator/raw |
Hey everyone! I was recently playing around with the idea of "a helmfile-builtin raw-chart-like feature" 25baebe. It turn any local directory containing "*.yaml.gotmpl" into a temporary helm chart by rendering each template with Helmfile's template context/funcs/data. Would it help? |
… directory Related to #494 This feature is mostly a built-in alternative to incubator/raw chart without external dependency and has access to helmfile's own template functions and template data. The expected use-case of this feature is to add arbitrary K8s resources to your deployment. Unlike the original issue raised in #494 this doesn't enable you to add arbitary resources to a release. That's another story. But this would be a good foundation for that, too.
… directory Related to #494 This feature is mostly a built-in alternative to incubator/raw chart without external dependency and has access to helmfile's own template functions and template data. The expected use-case of this feature is to add arbitrary K8s resources to your deployment. Unlike the original issue raised in #494 this doesn't enable you to add arbitary resources to a release. That's another story. But this would be a good foundation for that, too.
… directory (#1745) Related to #494 This feature is mostly a built-in alternative to the `incubator/raw` chart without external dependency and has access to helmfile's own template functions and template data. The expected use-case of this feature is to add arbitrary K8s resources to your deployment. Unlike the original issue raised in #494 this doesn't enable you to add arbitary resources to a release. That's another story. But this would be a good foundation for that, too.
I would really like that feature in order to be able to add k8s hooks as resources to the charts (instead of using the helmfile hooks directly).. |
Any chance this can be considered again, since incubator/raw is now deprecated? It seems like this request was pretty much turned down due to that workaround, while being limiting in terms of integrating with the chart. |
SO many charts don't include netpols, yet almost every production deployment we have requires one. The ability to add additional templates at release would be extremely helpful. |
Let me start with describing the issue I am trying to solve.
Many (official) Helm charts allow you to specify annotations on object descriptions (e.g. ingress descriptions). Ingress controllers support f.e. authentication by looking at annotations on the ingress objects. E.g.
ingress.kubernetes.io/auth-type
andingress.kubernetes.io/auth-secret
. Thisingress.kubernetes.io/auth-secret
annotation defines the name of the k8s secret containing the username/password for basic auth.But the charts don't offer a way to create the secret object. If the chart did include a secret template, you could have used the helm secret-plugin to render.
Manually creating the secrets feels bad...
Another option would be to create a helmfile release based on a local chart, having this local chart containing the secret template. Imho it would be a lot cleaner if this secret would be part of the same Helm release as f.e. the ingress object.
This makes me wonder if it is sensible to have a helmfile feature to merge arbitrary local Helm templates into the chart before rendering.
helmfile.yaml:
values.yaml:
templates/basic-auth-secret.yaml:
Feature request #392 describes how to get secrets from different backends/sources (Helm secret plugin / Vault / AWS / KeyHub ❤️ ) into helmfile. This feature request is about a way to get those secrets into k8s as
Secret
s as part to the release they belong to.Dream mode
Being able to add arbitrary Helm templates would allow me to do the following.
Define my own custom resource description containing all the metadata I need to sync a secret from a backend/source to a k8s
Secret
. A custom k8s controller would then be able to sync the secrets between backend/source and k8s. So changing the secret in the central secret store of truth would take effect without the need to do a deployment (helmfile sync
).And... deployers/releasers don't need access to the secrets themselves, as long as they know the metadata. Only the k8s controller requires access to the secrets.
The text was updated successfully, but these errors were encountered: