Home > database >  Helm: Expanding environment variables in values.yaml with helm install or upgrade
Helm: Expanding environment variables in values.yaml with helm install or upgrade

Time:11-17

In our Jenkins pipeline, I'm using a bash script to call the helm install command. We have a values.yaml containing most of the values to be passed to helm. However, few values are based upon environment variables and have to be passed using the --set argument. Here is the snippet:

helm install $RELEASE_NAME shared/phoenixmsp-app -f value.yaml \
    --set global.env.production=$production \
    --set global.cluster.hosts=${CONFIG[${CLUSTER_NAME}]} \
    --set nameOverride=$RELEASE_NAME \
    --set fullnameOverride=$RELEASE_NAME \
    --set image.repository=myhelm.hub.mycloud.io/myrepo/mainservice \
    --set-string image.tag=$DOCKER_TAG \
    --wait --timeout 180s --namespace $APP_NAMESPACE"

We want to move these --set parameters to values.yaml. The goal is to get rid of --set and simply pass the values.yaml.

Question: Is it possible to expand Environment Variables in values.yaml while calling with helm install or helm upgrade?

CodePudding user response:

The only way I think you can do that, if you really want to use a single yaml is to have a template values.yaml and either sed the values into it or use a templating language like jinja or mustache, then feed the resulting output into helm.

CodePudding user response:

--set is a good solution here, but if you really don't want that, dynamically write a second values file for the run-time values.

echo "
global:
  env:
    production: $production 
  cluster:
    hosts: ${CONFIG[${CLUSTER_NAME}]} 
nameOverride: $RELEASE_NAME 
fullnameOverride: $RELEASE_NAME 
image:
  repository: myhelm.hub.mycloud.io/myrepo/mainservice 
  tag: $DOCKER_TAG 
" > runtime.yaml

helm install $RELEASE_NAME shared/phoenixmsp-app -f value.yaml -f runtime.yaml \
  --wait --timeout 180s --namespace $APP_NAMESPACE

This really does nothing but slightly reduce the precedence, though.

If all these values are known ahead of time, maybe build your runtime.yaml in advance and throw it into a git repo people can peer-review before deployment time, and just use the variables to select the right file from the repo.

  • Related