I have this issue. I need to setup oauth2-proxy in kubernetes via helm, and I need it to use injected vault secret for configuration of proxy. I know that this would be possible by defining
'command' : ['sh', '-c', 'source /vault/secrets/client-secret && '], in some override-values.yaml i would create, but problem is that this helm chart values.yaml file does not provide any keyword like "command" and i am using it as a dependency chart so I cannot directly edit it's manifests.
Is there any way how can I define command for a pod of dependency helm chart even if it does not have command key in values? chart link: https://artifacthub.io/packages/helm/oauth2-proxy/oauth2-proxy if somebody wants to see
I also tried to reference secrets in the configuartion file for the proxy but i got error that i should not provide values like this: client_secret=$(cat /vault/secrets/secret), and many other things
Related
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.
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.
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
I want to use the pre-install hook of helm,
https://github.com/helm/helm/blob/master/docs/charts_hooks.md
in the docs its written that you need to use annotation which is clear but
what is not clear how to combine it ?
apiVersion: ...
kind: ....
metadata:
annotations:
"helm.sh/hook": "pre-install"
for my case I need to execute a bash script which create some env variable , where should I put this pre-hook script inside my chart that helm can use
before installation ?
I guess I need to create inside the templates folder a file which called: pre-install.yaml is it true? if yes where should I put the commands which create the env variables during the installation of the chart?
UPDATE
The command which I need to execute in the pre-install is like:
export DB=prod_sales
export DOMAIN=www.test.com
export THENANT=VBAS
A Helm hook launches some other Kubernetes object, most often a Job, which will launch a separate Pod. Environment variable settings will only effect the current process and children it launches later, in the same Docker container, in the same Pod. That is: you can't use mechanisms like Helm pre-install hooks or Kubernetes initContainers to set environment variables like this.
If you just want to set environment variables to fixed strings like you show in the question, you can directly set that in a Pod spec. If the variables are, well, variable, but you don't want to hard-code them in your Pod spec, you can also put them in a ConfigMap and then set environment variables from that ConfigMap. You can also use Helm templating to inject settings from install-time configuration.
env:
- name: A_FIXED_VARIABLE
value: A fixed value
- name: SET_FROM_A_CONFIG_MAP
valueFrom:
configMapKeyRef:
name: the-config-map-name
key: someKey
- name: SET_FROM_HELM
value: {{ .Values.environmentValue | quote }}
With the specific values you're showing, the Helm values path is probably easiest. You can run a command like
helm install --set db=prod_sales --set domain=www.test.com ...
and then have access to .Values.db, .Values.domain, etc. in your templates.
If the value is really truly dynamic and you can't set it any other way, you can use a Docker entrypoint script to set it at container startup time. In this answer I describe the generic-Docker equivalents to this, including the entrypoint script setup.
You can take as an example the built-in helm-chart from arc* project, here is the source code.
*Arc - kind of bootstraper for Laravel projects, that can Dockerize/Kubernetize existing apps written in this PHP framework.
You can place ENV in POD.yaml under the template folder. That will be the easiest option.
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.