We are using helm charts templates for deployment to kube and Azure devops for CI/CD.in my values.yaml data in below section will change as per environment and saved as config map in pod.
My question is how can I update it during deployment in azure pipeline. We are using Helm upgrade task OR any other way to handle it better.
environment:
enabled: true
env:
enabled: false
internalConfigMap:
enabled: true
**data:
AZ_DIRECTORY: xxx
MODEL_ID_SVM: xxx
MODEL_ID_MULTI: xxx
MODEL_THRESHOLD_SVM: 'xx'
SINGLE_ACC_ENDPT: 'xx'
MODEL_WT_SVM: 'xx'**
here is deployment task:(ignore indentation)
task: HelmDeploy#0
displayName: Helm upgrade
inputs:
command: upgrade
chartType: Name
chartName: chart/$(chartname)
releaseName: $(chartname)-${{ parameters.CI_ENVIRONMENT_SLUG }}
namespace: $(NAMESPACE)
connectionType: Azure Resource Manager
#azureSubscriptionEndpoint: ${{ variables.AZ_SUBSCRIPTION }}
#azureResourceGroup: $(AKS_RESOURCE_GROUP)
# kubernetesCluster: $(K8S_CLUSTER)
install: true
waitForExecution: true
useClusterAdmin: true
overrideValues: |
template.image.tag=$(imagetag)
Option 1: One value file per environment
If you have one values.yaml per environment (environment1-values.yaml, environment2-values.yaml etc) you can refer to different files for each stage in your pipeline.
The Helm Upgrade command accepts the parameter valueFile which you can use to point to the correct values.yaml for the environment you are deploying to
(Optional) Specify values in a YAML file or a URL. For example,
specifying myvalues.yaml will result in helm install
--values=myvals.yaml
Option 2: Override values on deployment
The Helm Upgrade command accepts the parameter overrideValues by which you can pass values directly to helm:
(Optional) Set values on the command line. You can specify multiple
values by separating values with commas. For example,
key1=val1,key2=val2. You can also specify multiple values by
delimiting them with newline as so: key1=val1 key2=val2 Please note
that if you have a value which itself contains newlines, use the
valueFile option, else the task will treat the newline as a delimiter.
The task will construct the helm command by using these set values.
For example, helm install --set key1=val1 ./redis
In your case this would mean
overrideValues: template.image.tag=$(imagetag),environment.internalConfigMap.data.AZ_DIRECTORY=xxx,environment.internalConfigMap.data.MODEL_ID_SVM=xxx
Related
I have the following value in values.yaml, and changes are made on the deployment side depending on the situation.
test:
test1: false
default: true
ingress-nginx:
enabled: true
tags:
test.default: true
I don't want the dependencies in the Chart.yaml file to install when I set test1 to true. But no matter what I did it didn't work.
dependencies:
- name: ingress-nginx
version: "4.0"
repository: https://kubernetes.github.io/ingress-nginx
condition: ingress-nginx.enabled
tags:
- test.default: true
- test.test1: false
Helm doesn't support Boolean logic in the dependency setup. The only supported conditions are:
If dependencies: contains a condition:, that names a path into the values structure, and if it is true then the dependency is installed. If more than one path is specified in a comma-separated string, the first path that exists is used; if none of the paths exist, go to 2.
Otherwise, if dependencies: contains tags: and the values do as well, then if any of the values' tags matching the dependencies' tags are true, install the dependency.
In both cases, the logic is "if something is true then install the dependency". There is no way to tell Helm to install a dependency only if a value is false. In your example, since there's a condition:, that will usually take precedence (unless the ingress-nginx: { enabled: } values doesn't exist at all).
The easiest thing to do here is just use that enabled value. There are multiple sources of values, including the helm install --set option and additional values files passed via helm install -f; the chart's values.yaml file is used mostly as defaults. So you can set this dependency to "on" in the chart's values
# values.yaml
ingress-nginx:
enabled: true
but then have an add-on "profile" values that disables it
# test1.yaml
ingress-nginx:
enabled: false
and specify that additional values file when you install the chart
helm install myapp . -f test1.yaml
If you did want to use tags: here then you'd need to invert the value of the tag. In the dependencies: section you'd specify the inverted tag name as a string, and omit the condition:
# Chart.yaml
dependencies:
- name: ingress-nginx
tags:
- not-test1
# no condition:
In the top-level values file, you'd specify some default for it, probably "on"
# values.yaml
tags:
not-test1: true
Then when you install the chart, you can disable this. (An override values file as in the previous example would also work.)
helm install myapp . --set tags.not-test1=false
I have some Helm value files.
There are value.yaml, value.dev.yaml, value.test.yaml, ... file.
In value.dev.yaml:
env:
"Environment" "development"
For some parameters in value.yaml file, I expected they override or insert them into pod parameters while deployment.
If I set up them into each value.dev.yaml, value.test.yaml,... it works with helm upgrade --install --set env.parameter=$variable
Now I want to define all variables in value.yaml file and expect them insert (override) them in to pods while deployment.
In value.yaml file :
env:
"Appconfig": "dev"
I'd like to combine them while deployment:
env:
"Environment": "development"
"Appconfig": "dev"
Apreciate your help !
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:
$ helm install -f myvalues.yaml -f override.yaml myredis ./redis
Ref Helm Install Doc
I want get name of resources from helm release. But I don't understand how.
I don't find anything
helm get all RELEASE_NAME --template '{{range .items}}{{.metadata.name}}{{end}}'
helm get all has a somewhat constrained set of options for its --template option; it gets passed in a single .Release object, and the set of created Kubernetes options is stored in text in a .Release.Manifest field.
helm get all RELEASE_NAME --template '{{ .Release.Manifest }}'
# returns the manifest as a string
There's a dedicated helm get manifest subcommand that returns the manifest as YAML.
Once you have the YAML, you need to extract the resource names from it. One approach is to use a tool like yq that can do generic queries over YAML:
helm get manifest RELEASE_NAME | yq eval '.metadata.name' -
I am using a helm chart (with sub-charts) to deploy my application.
I am using a value file for setting values.
I am looking a way to set variables in my value file (or any other place) that will be valid for my value file.
I have some sections (services) in my value files that I need to use the same value in it
so I am looking for a variable in my value file.
Is there any way that I can use variables for my value file?
Thx
Helm on its own can't do this.
If you control all of the charts and subcharts, you can allow specific values to have embedded Go templating. Helm includes a tpl extension function that will let you render an arbitrary string as a template. So if you have values
global:
commonKey: some value
otherKey: '{{ .Values.global.commonKey }}'
then you can render
- name: OTHER_KEY
value: '{{ tpl .Values.otherKey . }}'
But, you have to use tpl every place you access the key value(s); if you don't control the subcharts you may not be able to do this.
Higher-level tools may also let you do this. I'm familiar in particular with Helmfile which lets you declare multiple Helm charts and their settings, but also lets you use almost-Helm templating in many places. So your helmfile.yaml could specify:
environments:
default:
# These values are available when rendering templates in this file
values:
- commonKey: some value
releases:
- name: my-service
namespace: my-service
chart: ./charts/my-service
values:
# List items can be file names or YAML dictionaries.
# If it's a dictionary, arbitrary nested values.yaml content.
# If it's a *.yaml.gotmpl file name, templating is applied to the file.
- otherKey: '{{ .Values.commonKey }}'
yetAnotherKey: '{{ .Values.commonKey }}'
- ./my-service.yaml.gotmpl
Helmsman is simpler, but can only set chart values from environment variables; but I believe you can reference the same environment variable in different setString: options. You could also do something similar with the Terraform Helm provider, using Terraform's native expression syntax, particularly if you're already familiar with Terraform.
How do you override values in a Helm list with --set param in Azure DevOps?
Simple use case in values.yaml:
environment:
- name: foo
value: override_me
- name: bar
value: override_me
- name: baz
value: override_me
In the deployment.yaml file I use it like so:
env:
{{ toYaml .Values.environment | indent 10}}
One thing that kind of works, but not really, is:
environment[0].name=foo,environment[0].value=hello,{...}
The problem with this override is that it will override the entire list, even if I only want to replace value [0], not [1] and [2].
Also I get parsing errors when I pass url:s or int's (not on localhost, only AZ DevOps) - to overcome that paring error, you can escape it with \" - but then the chart is messed up - even though it passes the validation.
So, is it possible to override the env list in my case in Azure DevOps helm deployment? Or do I need to restructure the list to individual key=value pairs?
I've got weird experience when doing this, in 2 similar cases in one case it replaces them, in one overrides the whole array. so in the second case what I had to do is this:
environment:
- name: v1
value: keep_me
- name: v2
value: keep_me
- name: v3
value: keep_me
- name: foo
value: override_me
- name: bar
value: override_me
and I was doing this in the Azure Devops:
--set environment[3].name=foo,environment[03.value=xxx
for the other one I didnt have to do that, it would gladly overwrite only the values I've input. no idea why it did that.
Get yourself some variables defined in the task:
Use a standard set:
I was using a bash task in a release pipeline pointed at a deploy.sh file which existed as a published artifact. You need to chmod +x the file for this to work properly.