Why write non-secret metadata as PLACEHOLDER in kubernetes yaml files? (from here):
namespace: PLACEHOLDER
Any reason to replace it with a later sed command? why not simply write it inside the yaml file?
Those values are normally replaced or overridden later, either by sed within a CI/CD pipeline like Jenkins, or (as indicated by the question you linked to) by Helm.
With helm, you can override values within the yamls either with a second yaml, or at the command line using --set switches.
So I could have
helm install nginx --values values.yaml --values values2.yaml
and the placeholder value in values.yaml would get overridden by the value in values2.yaml
Placeholders are often used to deliberately break an install is someone tries to install it without passing in the right values.yaml
For example:
helm install my-chart
Could break because of the placeholder value, but
helm install my-chart --values production.values.yaml
would install because the placeholder values are overridden and the chart can install correctly.
Based on my experience, when you see files like this, they might be used in some sort of pipelines to deploy them in multiple clusters. These files, from my prior experience, act like templates when you don't want to go all in with Helm charts for a single ConfigMap or Secret or a different isolated resource. This allows you to replace these placeholders with values corresponding with you cluster, region etc.
Hope this makes sense.
Related
I am working with the Community Prometheus helm charts, and am trying to override the existing configmap without having to install with helm, then do a kubectl apply. I was curious if there is a way to either:
During the helm install set my configmap in place of the one it installs
If not, the chart provides a custom value to set your configurations. This is going to include a lot of lines and I wanted to avoid putting this in the command, so I was wondering what is the best way to to just cat the file out and set it as the value instead.'
If it helps, I am essentially passing a --set rules.custom here and then wanting to fill in the configmap myself. If I can just override the configmap with my own that would be even better.
I want to intercept the helm YAML and customize it using a Python script, and then install it. I have been doing something like helm template | python3 script... | kubectl apply -f - but of course this doesn't create a helm release in my cluster, so I lose out on helm rollback etc.
I have considered using Kustomize but it doesn't have the features that I'd like.
Is there a way to take pre-generated YAML, like that from helm template or helm install --dry-run and then install/upgrade that using helm?
Isn't that what post-renderers are for?
See https://helm.sh/docs/topics/advanced/#post-rendering
A post-renderer can be any executable that accepts rendered Kubernetes manifests on STDIN and returns valid Kubernetes manifests on STDOUT. It should return an non-0 exit code in the event of a failure. This is the only "API" between the two components. It allows for great flexibility in what you can do with your post-render process.
A post renderer can be used with install, upgrade, and template. To use a post-renderer, use the --post-renderer flag with a path to the renderer executable you wish to use:
$ helm install mychart stable/wordpress --post-renderer ./path/to/executable
I haven't used it myself yet, but it looks interesting if you want to run your own alternative kustomize.
See https://github.com/vmware-tanzu/carvel-ytt/tree/develop/examples/helm-ytt-post-renderer for an example that is not kustomize.
I have helm charts created for a microservice that I have built and everything is working as expected. Now, I have created a new k8s namespace and I want to try to deploy the same helm charts as my old namespace. Although, I have just one value that I need it different while everything else remain the same.
Do I have to create another values.yaml for the new namespace and copy everything over and update the one field I want updated ? Or is there any other way ? I do not want to use the --set method of passing updates to the command line.
David suggested the right way. You can use different values.yaml where you can specify the namespace you want to deploy the chart:
$ helm install -f another-namespace-values.yaml <my-release> .
It's also entirely possible to launch helm chart with multiple values.
For more reading please check values section of helm docs.
I want to deploy nextcloud with helm and a custom value.yaml file that fits my needs. Do i have to specify all values given from the original value.yaml or is it possible to only change the values needed, Eg if the only thing I want to change is the host adress my file can look like this:
nextlcoud:
host: 192.168.178.10
instead of copying this file and changing only a few values.
As the underlying issue was resolved by the answer of user #Kun Li, I wanted to add some examples when customizing Helm charts as well as some additional reference.
As asked in the question:
Do i have to specify all values given from the original value.yaml or is it possible to only change the values needed
In short you don't need to specify all of the values. You can change only some of them (like the host from your question).
The ways to change the values are following:
Individual parameters passed with --set (such as helm install --set foo=bar ./mychart)
A values file if passed into helm install or helm upgrade with the -f flag (helm install -f myvals.yaml ./mychart)
If this is a subchart, the values.yaml file of a parent chart
The values.yaml file in the chart
You can read more about it by following official Helm documentation:
Helm.sh: Docs: Chart template guide: Values files
A side note!
Above points are set in the order of priority. The first one (--set) will have the highest priority to override the values.
Example
A side note!
This examples assume that you are in the directory of a pulled Helm chart and you are using Helm v3
Using the nextcloud Helm chart used in the question you can set the nextcloud.host value by:
Pulling the Helm chart and editing the values.yaml
Creating additional new-values.yaml to pass it in (the values.yaml from Helm chart will be used regardless with lower priority):
$ helm install NAME . -f new-values.yaml
new-values.yaml
nextcloud:
host: 192.168.0.2
Setting the value with helm install NAME . --set nextcloud.host=192.168.0.2
You can check if the changes were done correctly by either:
$ helm template . - as pointed by user #David Maze
$ helm install NAME . --dry-run --debug
you misspelled the nextcloud to nextlcoud in your value file.
How can I execute "helm install" command and re-install resources that I have defined in "templates"? I have some custom resources that already exist so I want to re-install them. It is possible to do that through a parameter in helm command?
I think your main question is:
I have some custom resources that already exist so I want to re-install them.
Which means DELETE then CREATE again.
Short answer
No.. but it can be done thru workaround
Detailed answer
Helm manages the RELEASE of the Kubernetes manifests by either:
creating helm install
updating helm upgrade
deleting helm delete
However, you can recreate resources following one of these approaches :
1. Twice Consecutive Upgrade
If your chart is designed to enable/disable installation of resources with Values ( .e.g: .Values.customResources.enabled) you can do the following:
helm -n namespace upgrade <helm-release> <chart> --set customResources.enabled=false
# Then another Run
helm -n namespace upgrade <helm-release> <chart> --set customResources.enabled=true
So, if you are the builder of the chart, your task is to make the design functional.
2. Using helmfile hooks
Helmfile is Helm of Helm.
It manage your helm releases within a single file called helmfile.yaml.
Not only that, but it also can call some LOCAL commands before/or/after installing/or/upgrading a Helm release.
This call which happen before or after, is named hook.
For your case, you will need presync hook.
If we organize your helm release as a Helmfile definition , it should be :
releases:
- name: <helm-release>
chart: <chart>
namespace: <namespace>
hooks:
- events: ["presync"]
showlogs: true
command: kubectl
args: [ "-n", "{{`{{ .Release.Namespace }}`}}", "delete", "crd", "my-custom-resources" ]
Now you just need to run helmfile apply
I know that CRD are not namespaced, but I put namespace in the hook just to demonstrate that Helmfile can give you the namespace of release as variable and no need to repeat your self.
You can use helm upgrade to upgrade any existing deployed chart with changes.
The upgrade arguments must be a release and chart. The chart argument can be either: a chart reference(example/mariadb), a path to a chart directory, a packaged chart, or a fully qualified URL. For chart references, the latest version will be specified unless the --version flag is set.
To override values in a chart, use either the --values flag and pass in a file or use the --set flag and pass configuration from the command line, to force string values, use --set-string. In case a value is large and therefore you want not to use neither --values nor --set, use --set-file to read the single large value from file.
You can specify the --values'/'-f flag multiple times. The priority will be given to the last (right-most) file specified. For example, if both myvalues.yaml and override.yaml contained a key called 'Test', the value set in override.yaml would take precedence
For example
helm upgrade -f myvalues.yaml -f override.yaml redis ./redis
easier way I follow, especially for pre existing jobs during helm upgrade is do kubectl delete job db-migrate-job --ignore-not-found