I have 2 different values.yaml files per stage and production environment such as values.dev.yaml > values.prod.yaml and using with Helm 3. I would like to learn the best practices how to pass environment variables per environments.For instance we need to set different parameters to NODE_ENV variable.
-Should I specify the variable as hard coded as below and pass the environment variables when running helm upgrade/install command with --set flag?
-What is the correct way to use go template to do this. Can we specify something {{ .Values.node_env.value}} and then pass this env value in values yaml and use only -f values.yaml flag?
containers:
- name: {{ .Chart.Name }}
securityContext:
{{- toYaml .Values.securityContext | nindent 12 }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- name: http
containerPort: 8080
protocol: TCP
resources:
{{- toYaml .Values.resources | nindent 12 }}
env:
- name: "NODE_ENV"
value: "stage"
- name: "NODE_ENV"
value: "production"
If you have one value file per environment (it is not clear to me this is your case.) like values.prod.yaml (for prod) and values.dev.yaml (for dev), then your templeate can look like this.
This will cause the template to look for extraEnv: in your values{dev/prod}.yaml and iterate over all key/values from that section.
env:
{{- range $key, $value := .Values.extraEnv }}
- name: {{ $key }}
value: {{ $value | quote }}
{{- end }}
In your values.dev.yaml files you add all your KEY: values that are specific for this environment. Note you can have multiple key values here, all of them will be loaded. In this case we have NODE_ENV, ANOTHER_KEY, YET_ANOTHER_KEY - all of them will be loaded.
extraEnv:
NODE_ENV: stage
ANOTHER_KEY: value
YET_ANOTHER_KEY: value
same in your values.prod.yaml multiple KEY: value pairs can be specified and all of them will be loaded.
extraEnv:
NODE_ENV: production
ANOTHER_KEY: value
Related
I am using Helm 3. I have two values.yaml files. In common/values.yaml I have defined:
deployment:
ports:
- name: http
protocol: TCP
The common is of the type library. In my-app, which is of the type application, the common is added as a dependency. In my-app/values.yaml I have added:
deployment:
ports:
- containerPort: 8081
I have defined a template _deployment.yaml in common/templates. In this file I am trying to merge these two deployment dictionaries into one by using:
{{- $deployment := merge .Values.common.deployment .Values.deployment -}}
When I am printing {{ $deployment }}, it is giving output:
map[ports:[map[containerPort:8080 name:http protocol:TCP]]]
And if I do:
{{- $deployment := merge .Values.deployment .Values.common.deployment -}}
The output of {{ $deployment }} is:
map[ports:[map[containerPort:8081]]]
Moreover the output of {{ .Values.common.deployment }} is:
map[ports:[map[name:http protocol:TCP]]]
And the output of {{ .Values.deployment }} is:
map[ports:[map[containerPort:8081]]]
What I would like to have after merging is:
deployment:
ports:
- name: http
protocol: TCP
containerPort: 8081
Any advice you could give would be much appreciated.
Looks like the merge operation does not work as expected on lists (it's a common problem, as the merge operation is ambiguous on list: should a list be appended or replaced when merging ?)
Anyway, I would suggest to merge the ports data with:
{{- $ports := merge .Values.deployment.ports[0] .Values.common.deployment.ports[0] -}}
and render the result with:
deployment:
ports:
- {{- toJson $ports }}
HTH
We have some database migration jobs that we occationally want to run before deploy a new version of an app. The common approach for this in ArgoCD seems to be to use PreSync hooks, which I have tested and which seems to work, but I'm finding it a little bit limited in terms of functionality, and am unsure if I'm missing something or if that's just how it is.
How I would like it to work, is to only run the db migration jobs when they have changed in some way (most likely a new image), however the way presync jobs seem to be designed (and understandably so) is to always run the specified job on every sync. Functionally, this is fine, the migration job will take ~20 seconds to start and finish and end up doing nothing, however it's clearly not ideal to have this happen for every single unrelated change.
I'm hoping there is some way of accomplishing this "ArgoCD natively" that's I'm just missing.
The job template i'm using currently (and which runs each sync) is this:
{{- define "project.migration_job" -}}
{{- $appsettings := (get .Values.global.apps .name) }}
---
apiVersion: batch/v1
kind: Job
metadata:
generateName: {{ .name }}-
annotations:
argocd.argoproj.io/hook: PreSync
spec:
template:
spec:
automountServiceAccountToken: false
containers:
- name: {{ .name }}
image: "{{ .Values.global.repo }}/{{ .name }}:{{ $appsettings.image }}"
resources:
requests:
memory: {{ $appsettings.memory | default "256Mi" | quote }}
cpu: {{ $appsettings.cpu | default "75m" | quote }}
limits:
memory: {{ $appsettings.memory | default "256Mi" | quote }}
cpu: {{ $appsettings.cpu | default "75m" | quote }}
env:
{{- include "project.environment_variables" (dict "Values" .Values "env" .env) | trim | nindent 12 -}}
{{- include "project.secret_environment_variables" (dict "Values" .Values "secrets" .secrets) | trim | nindent 12 }}
restartPolicy: Never
backoffLimit: 2
{{ end -}}
Thanks for any help.
I don't know if there's a native solution, but this could help:
In your PreSync hook:
IMAGE_TAG_TO_DEPLOY: Get the image tag that will be deployed from the source repo (Ex.: curl -LSs https://x-access-token:"$GITHUB_TOKEN#raw.githubusercontent.com/company/project/master/path-to-image-tag.yaml" and parse the image tag value)
COMMIT_ID_TO_DEPLOY: Find the commit ID that corresponds to IMAGE_TAG_TO_DEPLOY
COMMIT_ID_DEPLOYED: Find the commit ID pointed to by a git tag named currently-deployed
If COMMIT_ID_TO_DEPLOY == COMMIT_ID_DEPLOYED, end the PreSync Hook
Perform the required actions for the PreSync hook.
Add the git tag currently-deployed to COMMIT_ID_TO_DEPLOY in your git repo
I could not find anything by just googling, does Helm support private values?
So I have my chart and my values.yaml
privateProp: hello
publicProp: world
I have some values that I want to exposed to the end user of my chart and others that I do not want, however those "private" values are being used in many places.
For example: publicProps is overridable by the user of the chart, but I would like to block access to privateProp, however it is reused in many places:
containers:
name: {{.Values.privateProp}}
nodeSelector:
name: {{.Values.privateProp}}
I saw there is {{$privateProp := "hello"}}, but it is not clear how I can access it elsewhere in my files
How can I achieve this?
Ok, I have found a solution to my problem.
You can create a file called _variables.tpl, the name does not matter
and then declare a variable:
{{- define "privateProp" -}}
{{- print "hello" -}}
{{- end -}}
and then you can use it wherever you want in your chart by doing this:
spec:
containers:
- name: {{ .Values.dashboard.containers.name }}
image: {{ .Values.dashboard.containers.image.repository }}:{{ .Values.dashboard.containers.image.tag }}
imagePullPolicy: Always
ports:
- containerPort: {{ include "privateProp" . }} # <== This
I'm using Helm for to deploy multiple K8s deployments. In some deployments I need to include extra environment variables, but for the majority of deployment the standard env. variables are enough. I would like to have named template for those deployments that must have extra env. variables.
Can I include a named template only if the named template exist?
Something like this:
{{ range $idx, $svc := .Values.services }}
kind: Deployment
metadata:
name: {{ $svc.name }}
spec:
containers:
- name: {{ $svc.name }}
env:
- name: JAVA_OPTS
- value: {{ $svc.javaOpts }}
# if template_exists (print $svc.name "-env")
{{ include (print $svc.name "-env") . | indent 12 }}
# end
{{- end -}}
It's in pseudo-code. How to do the # if part?
Thank you.
The easiest way would be to add additional key like templateExists: true to your services and check it with a simple if statement in your deployment:
{{- if $svc.templateExists }}
{{ include (print $svc.name "-env") . | indent 8 }}
{{- end -}}
services:
svc1:
templateExists: true
name: svc1
javaOpts: "-Xms128m -Xmx512m"
svc2:
name: svc2
javaOpts: "-Xms256m -Xmx512m"
Here is a solution that I came up now. I check if there are any files in the chart that matches the pattern [service]-env.yaml and if there are then I include the content of that file in the deployment.
{{- range $path, $_ := $f.Glob "**-env.yaml" }}
{{- if contains $svc.app.name $path }}
{{ $f.Get $path | indent 8 }}
{{- end }}
{{- end }}
That way, for services that require extra env. variables we can include a file in files/service-env.yaml and those variables will be added to the deployment. For services that do not require such variables, it's left empty.
I have a helm chart template, and I would like to use the result of whoami as a template variable. How do I do this?
So if my values.yaml file has:
env:
uniqueId: {{ whoami? }}
how might I do this?
note: I am on os x, so whoami I believe assumes a linux environment, however, in the spirit of this being deployment agnostic I presume there is a non-unix way of doing this.
The Helm Chart's "values.yaml" file is typically for default values. Anything that you'd like to override should be done at time of install/upgrade of the chart.
The Helm docs show a lot of different ways in which values can be used: https://github.com/kubernetes/helm/blob/master/docs/charts.md
In this case, one option is to set the value on the command line:
helm install -set env.whoami=$(id -un) ./your-chart.tgz
You could then have a value.yaml file like:
env:
whoami: "default"
Finally, you can use it in a template like:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Chart.Version }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
env:
- name: WHOAMI
value: {{ .Values.env.whoami }}
Obviously your template will vary, the above is just a snippet.