I have created a helm directory called clickhouse:
Inside the template subdirectory I have a crd.yaml (kind: CustomResourceDefinition) which has to be run before the installation.yaml (kind: ClickHouseInstallation). Right now the installation.yaml is run first when I run the command
$ helm upgrade -i clickhouse ./charts/clickhouse
How do I change the order?
Notes:
I noted that there's a static order by reading through this thread. Since ClickHouseInstallation is not a part of that list I'm curious of how helm orders it and how to change that order.
Also here's the yaml files
crd.yaml
installation.yaml
I think you can try to use Helm hooks like
annotations:
"helm.sh/hook": post-install
Let your crd.yaml have pre-install and then your installation.yaml could have post-install. Please look through the docs for Helm hooks, there might be some downsides in regards to what you want to achieve.
Another way to solve this (might be trivial and not so elegant) would be creating a separate helm chart for the installation.yaml and then just run the crd chart first.
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 a helm chart containing Kubernetes job but unfortunately helm upgrade won't work because the image name is immutable so logically I need to do a delete and install but I will loose my set values.yaml if they were customised in the first place.
How can I keep the values before deleting the chart and use them for new install to simulate an upgrade? I couldn't find anything in documentations or here.
Thanks
EDIT:
First you need to get your previous values with helm get values <release-name>
So you could redirect the values to a file with:
helm get values <release-name> -o yaml > values.yaml
And then do a helm install again
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
If I run kubectl apply -f <some statefulset>.yaml separately, is there a way to bind the stateful set to a previous helm release? (eg by specifying some tags in the yaml file)
As far as I know - you cannot do it.
Yes, you can always create resources via templates before installing the Helm chart.
However, I have never seen a solution for your question.