CODEWITHSUNDEEP
kuberneteskubernetes-helm
public_html
public_html

Reputation: 349

Using Environment Variables with HELM

I plan to upgrade my project to HELM.

I have many environment variables that I have defined in deployment.yaml.

Best practice is it best to define the environment variables in the values.yaml file or the templates / deployment.yaml drop?

Can you help if there is a sample application you use?

Upvotes: 0

Views: 13610

Answers (3)

David Maze
David Maze

Reputation: 159761

There's four possible places you could set environment variables, and each has a use.

  1. Is the value essentially fixed, any time you'd run the container in any environment? For example, consider setting a Python application to not buffer its log output or specifying the container-internal port number. Set these in the image's Dockerfile:

    ENV PYTHONUNBUFFERED=1
ENV PORT=8000

  2. Is the value more or less fixed, any time you'd run the container in Kubernetes? Or, can you reliably calculate the value? In these cases, you can set the value directly in your templates/deployment.yaml file, maybe with Helm templating.

    env:
  - name: COORDINATOR_HOST
    value: {{ .Release.Name }}-coordinator  # another Service in the same chart
  - name: DATABASE_DRIVER
    value: postgresql                       # this chart doesn't support MySQL

  3. Does the value have a sensible default, but needs to be overridden sometimes? Put it in your chart's values.yaml.

    # concurrency specifies the maximum number of concurrent tasks
# to launch.
concurrency: 4

    This needs to be repeated in the templates/deployment.yaml as well

    env:
  - name: CONCURRENCY
    value: {{ quote .Values.concurrency }}

  4. Is the value only available at deployment time; or do you need to override one of these defaults? Use the helm install -f option to provide a per-environment value

    databaseHost: myapp-pg.qa.example.com

    or the similar helm install --set option. If it's reasonable to include a default value, also do so as in the previous example, but if not, you can use the required template function to give a reasonable error.

    env:
  - name: DATABASE_HOST
    value: {{ .Values.databaseHost | required "a databaseHost must be provided" }}

You can use any or all of these options, depending on the specific values, even within the same chart.

The one pattern I don't particularly recommend is giving an open-ended list of environment variables (or other raw Kubernetes YAML) in the values file. As an operator, this is hard to consume, and it especially doesn't interact well with the helm install --set option. I tend to prefer listing out each configurable option in the Helm values file, and would modify the templates/*.yaml (maybe behind a deploy-time flag) if I needed more advanced customization.

Upvotes: 1

Geraldo Andrade
Geraldo Andrade

Reputation: 111

Disclaimer: My answers are based on Helm 3. So let's get to it:

  • #1: No, in your values.yaml you define the static/default values. It's not the best approach to let static values in your template files (like deployment.yaml). To override the values of values.yaml The best practice is to use --set KEY=VALUE file. In this case, is totally possible to get the environment variable.
  • #2: Can you give an example? Yes, sure.

For example, I want to install Elasticsearch on my cluster using helm so I use the command:

helm install elastic/elasticsearch --version 7.8.0

But I do not want to use the default values of the chart. So I went to https://hub.helm.sh/charts/elastic/elasticsearch and https://github.com/elastic/helm-charts/blob/7.8/elasticsearch/values.yaml, saw what's possible to change, then I create the command:

helm install elastic/elasticsearch --set minimumMasterNodes=1 --set protocol=https  --version 7.8.0

But in my CD tool, the minimum master nodes are different values and since this is an environment variable I changed my command line to this:

helm install elastic/elasticsearch --set minimumMasterNodes=$MIN_MASTER_NODES --set protocol=https  --version 7.8.0

So, as a result, the command above will run with no problem in your CD tool once the MIN_MASTER_NODES environment variable is provided correctly.

Upvotes: 3

Vincent Rodomista
Vincent Rodomista

Reputation: 780

Your use of values.yaml to define environment vars is totally up to you. Is the value static? I'd have no problem leaving it in the deployment yaml. If it's a secret you should manage it either with k8s secrets or input it when you use helm install --set-value.. If the value is dynamic and is changed often or could be changed in the future that is the true use for values.yaml imo

Upvotes: 2

Related Questions