I have a helm chart i need to package using the command helm package https://helm.sh/docs/helm/#helm-package but issue is i need to replace values.yaml file with extra config file depending on what environment
normally i reference this extra config file with
for QA
helm install -f myvalues-qa.yaml -f override-qa.yaml --set foo=bar-qa --set foo=newbar-qa ./redis
for PROD
helm install -f myvalues-prod.yaml -f override-prod.yaml --set foo=bar-prod --set foo=newbar-prod ./redis
but now since i want to package this redis helm charts, how do i package it so that i can switch which config files or extra vars depending the environment?
Here is what i tried
helm package -f myvalues-qa.yaml ./redis
Error: unknown shorthand flag: 'f' in -f .
What is best way to approach this?
When packaging a Helm chart it isn't possible to customize values. That's because of a helm chart is a generic definition of an app, reusable for one environment to another, which is customized at installing via values.
Apart from that, I understand that you need a way to store the definition of a release (including the helm chart and the values) for every specific environment. There are plenty of tools that let you define a release in a declarative way, here are some:
Helmfile
Landscaper
Reckoner
So, you have a packaged chart where you store the generic app and another file(s) where you store the definitions of the releases of this chart.
Related
I have multiple subcharts under one helm chart. I install those using the command
helm install my-app . --values values.dev.yaml
It is working fine. All subcharts are part of a one release. Now I have requirements that other member will be starting working those individual subcharts and want to upgrade their subchart without deleting/upgrading the entire application's subchats and in the same release
so when for upgrading one one say frontend subchart from it. I tried
helm upgrade my-app ./charts/frontend --values values.dev.yaml.
It will terminate all the other pods and will keep only pod for this subchart frontend running. Is there any way to upgrade only subcharts of the application without touching the other subcharts?
Just run helm upgrade on the top-level chart normally
rm requirements.lock
helm dependency update
helm upgrade my-app . -f values.dev.yaml
This will "redeploy" the entire chart, including all of its subcharts, but Helm knows to not resubmit unchanged objects to Kubernetes, and Kubernetes knows to not take action when an unmodified object is submitted.
Helm subcharts have some limitations; in addition to what you describe here about not being able to separately manage subcharts' versions, they will also flatten recursive dependencies together (if A depends on B depends on Redis, and A depends on C depends on Redis, B and C will share a single Redis installation and could conflict). If you need to separately manage the versions, consider installing the charts as separate top-level releases.
If your sub-charts are 3rd party dependencies (i.e. you are combining some charts together in a single chart), you can update the external charts by updating Helm dependencies:
Once in the Helm chart dir, where Chart.yaml lives, run
$ helm dependency update
To make sure you get the latest dependency, update Helm repos first:
$ helm repo update && helm dependency update
This will download the latest dependent charts (or the latest allowed, depending on your Chart.yaml config.
Please Note that helm dependency update will download txz files. If no action is taken (i.e. ignore them in git), they could end up version-controlled in your git repo.
Hi everyone,
I have deployed a Kubernetes cluster based on kubeadm and for the purpose of performing HorizontalPodAutoscaling based on the Custom Metrics, I have deployed prometheus-adpater through Helm.
Now, i want to edit the configuration for prometheus-adpater and because i am new to Helm, i don't know how to do this. So could you guid me how to edit the deployed helm charts?
I guess helm upgrade is that are you looking for.
This command upgrades a release to a specified version of a chart and/or updates chart values.
So if you have deployed prometheus-adapter, you can use command helm fetch
Download a chart from a repository and (optionally) unpack it in local directory
You will have all yamls, you can edit them and upgrade your current deployed chart via helm upgrade
I found an example, which should explain it to you more precisely.
You're trying to customize an installed chart. Please use this guide Customizing the Chart Before Installing.
The key parts:
There are two ways to pass configuration data during install:
--values (or -f): Specify a YAML file with overrides. This can be specified multiple times and the rightmost file will take precedence
--set name=value: Specify overrides on the command line
There are a couple more ways to customize a Helm Chart values:
You may create a file with defined config and then helm install my-app [chart] -f /path/to/myconfig.yaml
As an example for a config file, please refer, for example, to redis one.
The second one is to check for the files the helm repo add or helm repo update create. You may check with helm env the variable HELM_REPOSITORY_CACHE that shows where those files are.
Untar the chart and look for the values config file or even go to the Kubernetes manifests /templates for a more in-depth customization. Then, install the chart.
I'm new to Helm and I haven't quite fully grasped the concepts yet. What I'm currently trying to do is to create a custom chart that basically just sets specific values for another chart that's available in the default stable repository. Pretty much what I want to do is have this:
helm install \
-f my-custom-values.yaml \
stable/target-chart \
--name=my-release
changed into
helm install my-apps/my-release
With my-release using the same values in my-custom-values.yaml. It's essentially bundling the pre-existent chart into a new one with my custom values.
Is there a way to do this? I think I might be able to clone the source chart, but I don't feel like that's a practical thing to do.
What is the issue with the first variation? If you have a custom values.yaml that you can pass to helm why do you need to remove it from the command line?
But if you are ready to play around a bit... :)
One way of doing this would be creating your own chart, that will be mainly empty but consist of a requirements.yaml that refers to stable/target-chart.
requirements.yaml (just beside Chart.yaml)
dependencies:
- name: stable/target-chart
version: 1.0.0.0.0.0
alias: somealiasforvaluesyaml
In your values.yaml you then overwrite the values of that sub-chart:
somealiasforvaluesyaml:
keyfromthattargetchart: newvalue
subkeyfromthattargetchart:
enabled: true
setting: "value"
The alias you give in the requirements.yaml is the section in your values.yaml from your chart.
Before installing you need to tell helm to update these requirements:
helm repo update
helm dependency update
and then just helm install this (virtual?) chart. This chart does not contain any resources to it would not be called a package in linux package managers - but they also use transitional packages or packages that just are a collection of others (like the build-essential)
Considering you already have the values.yaml to overwrite the ones in the target-chart this is all a bit much? Since the cust-values .yaml to pass to install with -f just needs to contain the customization as it will ammend the values.yaml from the target-chart your first command in the question looks like the correct way to go.
I deployed a helm chart using config-v1.yaml. I added some data to my helm chart app via an api exposed in the helm chart
I want to deploy/update the current chart with values from config-v2.yaml because there is a feature I want to expose.
When I use helm upgrade -f config-v2.yaml my-chart stable/chart. The previous helm version is blown away meaning the data I added with the API is gone. So I figure I need to add a volume to my container.
When I add a PersistentVolume and PersistentVolumeClaim, the app fails to update with values from config-v2.yaml which means I don't get the new features I want.
What is the proper way to do these types of updates to helm charts?
To upgrade, use '--reuse-values' flag as you are providing extra customization to the existing values.
In your case, you can use
helm upgrade --reuse-values -f config-v2.yaml my-chart stable/chart
Please refer the docs.
Use the '--version' flag to set your version. Look up current version first via 'helm list -A' and set it. This issue caught me as well.
I want to export already templated Helm Charts as YAML files. I can not use Tiller on my Kubernetes Cluster at the moment, but still want to make use of Helm Charts. Basically, I want Helm to export the YAML that gets send to the Kubernetes API with values that have been templated by Helm. After that, I will upload the YAML files to my Kubernetes cluster.
I tried to run .\helm.exe install --debug --dry-run incubator\kafka but I get the error Error: Unauthorized.
Note that I run Helm on Windows (version helm-v2.9.1-windows-amd64).
We need logs to check the Unauthorized issue.
But you can easily generate templates locally:
helm template mychart
Render chart templates locally and display the output.
This does not require Tiller. However, any values that would normally
be looked up or retrieved in-cluster will be faked locally.
Additionally, none of the server-side testing of chart validity (e.g.
whether an API is supported) is done.
More info: https://helm.sh/docs/helm/helm_template/
Amrit Bera's solution will only work with local helm chart, per the details of your question you want it to work with remote helm chart, that's a feature that will be added to Helm v3 (Work in Progress currently).
RehanSaeed posted the following workaround (https://github.com/helm/helm/issues/4527)
Basically:
mkdir yamls
helm fetch --untar --untardir . 'stable/redis' #makes a directory called redis
helm template --output-dir './yamls' './redis' #redis dir (local helm chart), export to yamls dir
The good thing about this is you can mix this technique with weaveworks flux for git ops + this gives you another option for using Helm v2 without tiller, in addition to the Tiller Plugin (which lets you run tiller locally, but doesn't work smoothly).
Straight from the helm install --help
To check the generated manifests of a release without installing the chart,
the '--debug' and '--dry-run' flags can be combined. This will still require a
round-trip to the Tiller server.
If you want to see only the resolved YAML you can use
helm template .
I prefer to see it on a file
helm template . > solved.yaml
This is not the answer for the question but this post on stackoverflow
is the first one which was displayed in searchengines when i was
searching for a solution of my problem and solved it by myself reading
the Helm CLI docs. I post it here anyway because maybe someone else is
searching for the same usecase as i did.
For already installed Helm charts on a Kubernetes cluster you can use the following command to export/download all information for a named release:
helm get all <release-name>
or
helm get all <release-name> > installed-kubernetes-resources.yaml
If you only want e.g. the manifests or values instead of all, just replace the all command appropriately (get more details by using helm get --help):
Usage:
helm get [command]
Available Commands:
all download all information for a named release
hooks download all hooks for a named release
manifest download the manifest for a named release
notes download the notes for a named release
values download the values file for a named release
If you want to export the information for a named release with a distinct revision you can use the flag --revision int in your get command (helm get all --help). To list all possible revisions of your named release just use the command helm history <release-name>.
My Helm CLI version:
version.BuildInfo{Version:"v3.5.0", GitCommit:"32c22239423b3b4ba6706d450bd044baffdcf9e6", GitTreeState:"clean", GoVersion:"go1.15.6"}