-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Allow helm to add external files to chart deployment #3276
Comments
Hi Lena, Current way: Lets assume we use "firstspirit" as chart repository name, that provides then the chart(s) to the customer. Then the customer can deploy your chart via the call:
Within your chart you can now validate if all required keys have values set (ssl cert(s), license, ..). As another pros, the customer can automize the SSL cert generation by third-party tools and generate by himself the .yml files for setting your kubernetes secret values outside of Helm and passing the generated files to Helm for the "helm install" command. Best regards, |
Hi Markus,
I wanted to not force users to provide base64-encoded strings in yaml files, but instead give the files directly. However, the files need to be part of the chart itself and cannot be given from the outside, hence this ticket. |
I have this exact need. My chart publishes a secret read from file at I believe files for https://github.com/kubernetes/helm/blob/master/pkg/chartutil/files.go#L32 |
I am quite sure |
One alternative solution is to distribute your certs and licences as a separate helm release. Where you put them into config maps with a name that your service deployment knows about, use a configmap/secrets volume mount in your service deployment. |
Maybe that was what @cr4igo already suggested :) |
We're having the same problem with a very similar use case: We have certificates for Apple and Googles push notification services; we have different certificates for our test and production environments so we can't just bundle the certificate into the Chart (ignoring the security concerns around doing so); we would ideally like to be able to put the file path into the values file and have Helm load that file. I don't have any good suggestions to how to tell Helm that the string in the values file is a relative file path - perhaps wrapping it in some sort of e.g.
secret.yaml
|
I think, this is a duplicate of #1754 |
I don't think it's a duplicate, this is about allowing helm to access files on absolute paths outside of helm chart "root". Example:
This fails to render if pointing to files inside helm repo, ie: If the same file copied to helm root and pointed with relative path, the same command works. |
Hi, I would like to suggest an approach similar to C-preprocessor... by default have the search path within the chart, however add --search-directories= parameter to allow additional directories. This will meet security requirements as sysadmin must specify where additional files resides, it will make the Files::glob work properly. What do you think? USE CASE include additional set of files to configmap/secrets using .Files.Glob from directory outside of the chart package, without extracting the package. PROBLEM package must not escape authorized search directories. SOLUTION add --search-directories parameter to search files in additional directories specified by sysadmin, the files will be loaded into the fileset of the chart, available to the Files object. |
Apologies for the delay on a response. The core team (including myself) has been focusing solely on getting an alpha release of Helm 3 out the door, so any development on significant contributions to Helm 2 have been much harder to dedicate resources for peer review and design work at this time. The proposal in the OP ( |
Hello, Any update on the status of this issue? How is it going for Helm 3? |
I am asking too.. would very much like it for traefik ssl stuff f.ex. :) |
AFAIK nobody from the community has started tackling this work for Helm 2. |
Hi, What's the latest on this topic? We are also looking for the requested behaviour. Thanks |
Same as earlier. No update. |
Still waiting for an update on this |
It should also be great if you provide an option like |
I'm marking this feature as "Help Wanted". It'd be great to have this feature, but we're busy re-working the architecture for Helm 3 that we don't have the time to focus on implementing new features like this one. If you're interested in contributing this feature for Helm 3, please let us know so we can try to co-ordinate efforts/merge conflicts with the rest of the team.
If there are further updates, we'll share them here. Thanks! |
In case it helps anyone, i've managed to work around this limitation for my needs. My folder structure:
My problem: I was trying to copy the content of the config files into a k8s configMap, but i've hit the limitation where i couldn't reference the config files, as they are external to the helm chart. My solution: I've used the set-file to copy the content of the config file
And in my helm deployment yaml it's referenced like this:
(edited multiple time to fix line breaks without success) |
Such a needed feature for certificates primarily.. Else it gets far too complex for the job |
Ah, I get it now. I have misinterpreted the title. |
it would be great to see this feature becomes alive. For the upstream helm chart, randomly, we need to add additional configmap or secrets to the charts. |
not able to access the link |
Amazing how this simple ask can't be implemented over 5 years later. Helm really has some of the worse maintenance and management of any large-scale open source projects. |
+1 |
Do you know go? This IS an open source tool. Not a maintainer, but I'm sure they'd be happy to review a pr |
Let’s stop making software and grow potatoes instead, so we can stop blaming each other and rather express our frustrations to gods of rain and sunshine. |
@alexpirine |
I myself wanted this back in 2018 and commented here. I gave up on waiting anything. I can only give a very general unsolicited advice: just find out another way to do things. You can’t wait for another five years. Helm might very well be dead by that time and replaced by something newer and fancier (there are already 2 or 3 good candidates). And we will have other issues. We are constantly creating new problems for ourselves by creating new technology. |
@alexpirine |
I sometimes wish I was a farmer instead. 👨🌾
I managed to circumvent my need for including files by using a symlink to whatever file I needed (outside of the chart) and then reference it with The chart looks something like
And running a helm upgrade produces a warning
It works, but it really makes you wish you were a potato farmer instead. |
@Eeemil |
git repositories support symlinks, though unsure how well they are supported outside of *nix. |
This would be great also because in some cases, you create helm charts to have a whole software stack setup the right way and have the end user bring his own configuration (BYOC maybe? 😅), a bit like the BYOL model. Would allow to bring a "flat" file, potentially templated out from another software. Kubernetes is already complex enough for most people, if you add Helm, the step to get into the ecosystem is quite high IMO. |
Hello, I do render ALL my Manifests in a subchart knowing how to package towards the Cluster. However there is one artefact -- an OpenApiSpec -- which is to be delivered by a secret. But for the users of this chat there is no need to know how push this information into the cluster -- all they actually need is a values.yaml and the open-api-spec.yaml for this Service. |
When we need to use custom JS transform in Replicator, we specify transform: type: js config: ./transform.js in replicator configuration. Problem is that this configuration references an external file that is currently not in Helm chart. Helm does not allow to mount external files into pod at the time of the deployment, see Helm issue <helm/helm#3276>. This change adds a `transform.js` file into Helm chart that we can reference in our configuration during deployment. the content if this file is set from chart values, and we can overwrite this during installation. Bu default, the transform file is not used and the content of `transform.js` is empty. To use the transform, we need to overwrite `transform` section in application configuration, and overwrite `transform.js` file itself: helm install replicator-with-transform \ es-replicator/es-replicator \ --values values.yml \ --set-file transformJs=./local-transform.js `values.yml` should overwrite `transform` section: transform: type: js config: ./transform.js Local file `local-transform.js` should define transformations / filters as per <https://replicator.eventstore.org/docs/features/transforms/js/>.
PR in: #10077 Unfortunately: #10077 (comment) |
+1 |
I read in many comments that the problem can be solved using a syslink.
In the base-chart I used {{ (.Files.Glob "configMap/*").AsConfig | indent 2 }} |
I solve my problem in argocd using the plugin https://github.com/crumbhole/argocd-lovely-plugin anche patching with kustomize+ helm... |
Hello,
currently Helm does not support including files that are not part of the chart to be included in the deployment of the chart (as far as I understand, due to security reasons, and since Tiller only has access to files inside the chart).
Our use case is adding some SSL certificates, as well as some license files, to the helm chart deployment. Our software runs on premises in our customer's data center, and we'd like to give them a helm chart to ease installation. The license files are custom per customer, so they cannot be included in the chart.
Of course, we can instruct our customer to untar the chart, place the files, and then deploy the chart directory, but that is cumbersome and error-prone.
Proposal: Add a flag, such as
--include-file=foobar-license.conf
that will include a file to the chart before sending it to tiller. This way, it would only happen upon explicit user request and not "under the hood".In case I misunderstood something and there is an easy way to achive something similar, I'd be happy to hear about that :).
The text was updated successfully, but these errors were encountered: