Configuration

The Helm values file

Helm uses one or more values.yaml files to populate the chart templates.

You can add environment variables to the Helm values file. For example, here is a values.yaml file that uses Release autogenerated environment variables:

web:
  image:
    repository: ${RELEASE_REGISTRY_PATH}
    name: web@sha256
    tag: ${WEB_REGISTRY_IMAGE_SHA}
  hostname: ${WEB_INGRESS_HOST}
  url: "jdbc:postgresql://${WEB_RDS_DB_POOL_HOST}:5432/web"

You can use any of the custom environment variables or Release autogenerated environment variables found in the environment variables configuration in your Helm values files.

Name template

Helm allows you to specify a name or name_template to name objects in Kubernetes. Helm charts will populate .Release.name with the value specified by the name_template. By default, Release sets the name_template to the name of the application defined in your application configuration.

The following example shows how to override the default name_template set by Release:

helm:
  name_template: acme-app
...
charts:
- name: vault
  repo_url: https://helm.releases.hashicorp.com
  add: hashicorp
  install: hashicorp/vault
  directory: helm/vault
  values: 
  - values.yml
  name_template: vault
- name: backend
  directory: backend
  values: 
  - values.yaml

It can be useful to override the name_template if you're creating an application template that will be used for multiple applications or on-premise deployments. Helm charts often prefix deployments with the name_template, so you may need to adjust hostnames for internal networking when using the same Application Template for two applications.

This table illustrates how name_template affects the naming of deployments:

Application Name
Name Template
Chart Name Template
Service Name
Deployment Name

acme-app

vault

acme-app-vault

acme-app

vault

vault

vault

acme-app

backend

vault

backend-vault

acme-app

acme

vault

acme-vault

acme-app

acme

vault

vault

vault

Helm chart environment variables

Release allows you to reference environment variables from your source control repository. These values will be loaded by Release and can be used to populate the Helm values.yaml file.

Take a look at this example env_file definition for a Helm chart:

charts:
- name: frontend
  name_template: frontend
  directory: frontend
  values: 
  - values.yaml
  env_file: "/config/frontend.env"
- name: backend
  name_template: backend
  directory: backend
  values: 
  - values.yaml
  env_file: "/config/customers/${customer_name}.env"

You can also define environment variables in the Release environment variables configuration file, which can be used as a reference to an environment-specific configuration. In our example above, you can see that backend loads an env_file based on the CUSTOMER_NAME environment variable set in Release.

Build image environment variables

If you use Release to build your container images and Helm charts to deploy them, you need to use the environment variables generated by Release in the values.yaml file to properly start up your containers.

Release uses the container registry SHA from your container images to allow for the rollback of your application should something go wrong. Using a container registry tag to reference a build is common in many Helm charts, like the example shown below. However, tags can move across images in a given container registry, making it hard to track what code is deployed.

Generated build and container registry environment variables

This table shows example generated values for a container build named backend:

Generated Variable Key
Example Value

RELEASE_REGISTRY_ENDPOINT

12345678900.dkr.ecr.us-east-1.amazonaws.com

RELEASE_REGISTRY_PATH

12345678900.dkr.ecr.us-east-1.amazonaws.com/acme/acme-app

BACKEND_REGISTRY_IMAGE_URL

12345678900.dkr.ecr.us-east-1.amazonaws.com/acme/acme-app/backend@sha256:4852bafb7f7cf76375d0e090f737926210de462ef35c9f9616f8a2e17ebb0dda

BACKEND_REGISTRY_IMAGE_SHA

4852bafb7f7cf76375d0e090f737926210de462ef35c9f9616f8a2e17ebb0dda

Each build defined in Release will generate <SERVICE>_REGISTRY_IMAGE_URL and <SERVICE>_REGISTRY_IMAGE_SHA environment variables to be used in the Helm values.yaml file.

The example values.yaml file below references a build generated by Release and demonstrates a common pattern seen in open-source Helm charts when referencing container images. Notice that we set name to frontend@sha256 to use the container registry SHA:

frontend:
  service:
    name: "frontend"
    image:
      repository: ${RELEASE_REGISTRY_PATH}
      name: frontend@sha256
      tag: ${FRONTEND_REGISTRY_IMAGE_SHA}

This example Helm chart template references a build generated by Release:

containers:
- name: {{ .Values.frontend.service.name }}
  image: {{ .Values.frontend.image.repository }}/{{ .Values.frontend.image.name }}:{{ .Values.frontend.image.tag }}
 

Release-generated environment variables are injected into the values.yaml file and properly reference the container image built by Release.

Last updated