Search…
Configuration

Helm Values File

Helm uses values.yaml to populate the chart templates. Release adds the ability to inject environment variables into the Helm values file.
1
web:
2
image:
3
repository: ${RELEASE_REGISTRY_PATH}
5
tag: ${WEB_REGISTRY_IMAGE_SHA}
6
hostname: ${WEB_INGRESS_HOST}
7
url: "jdbc:postgresql://${WEB_RDS_DB_POOL_HOST}:5432/web"
Copied!
Example values.yaml using Release generated environment variables
Any of the custom or Release generate environment variables found in the environment variable configuration can be used in your Helm values.yaml file.

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 . Release by default sets the name_template to the name of the application that's defined in your application configuration.
1
helm:
2
name_template: acme-app
3
...
4
charts:
5
- name: vault
6
repo_url: https://helm.releases.hashicorp.com
7
add: hashicorp
8
install: hashicorp/vault
9
directory: helm/vault
10
values: values.yml
11
name_template: vault
12
- name: backend
13
directory: backend
14
values: values.yaml
Copied!
Example of overriding the default name_template set by Release
Overriding the name_template is useful when creating an application template used for multiple applications or for on-premise deployments. Helm charts often prefix all of the deployments with the name_template which may require you to adjust hostnames for internal networking when using the same application template for two applications.
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
Example of how name_template affects the naming of the deployments
As you can see from the table above using the defining name_template affects the services naming and ultimately how your services will reference one another.

Chart Environment Variables File

Release allows you to reference an environment variable from your source control repository. These values will be loaded by Release and can be used to populate the Helm values.yaml.
1
charts:
2
- name: frontend
3
name_template: frontend
4
directory: frontend
5
values: values.yaml
6
env_file: "/config/frontend.env"
7
- name: backend
8
name_template: backend
9
directory: backend
10
values: values.yaml
11
env_file: "/config/customers/${customer_name}.env"
Copied!
Example env_file definition for Helm charts
You can also define an environment variable in the Release environment variable configuration when can be used as a reference to an environment specific configuration. In the above example you can see that backend is loading an env_file based on the CUSTOMER_NAME environment variable set in Release.

Build Image Environment Variables

When using Release to build your container images and using Helm charts to deploy them, you will need to use the environment variables generated by Release in the values.yaml to properly start up your containers.
Release uses the container registry SHA from your container images to allow for rollback of your application when something goes 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 got deployed.

Generated Build and Container Registry Environment Variables

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/[email protected]:4852bafb7f7cf76375d0e090f737926210de462ef35c9f9616f8a2e17ebb0dda
BACKEND_REGISTRY_IMAGE_SHA
4852bafb7f7cf76375d0e090f737926210de462ef35c9f9616f8a2e17ebb0dda
The table above shows example generated values for a container build named backend
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.yamlfile. Here is a common pattern seen in open source Helm charts when referencing container images. Notice that we set name to [email protected] to use the container registry SHA.
1
frontend:
2
service:
3
name: "frontend"
4
image:
5
repository: ${RELEASE_REGISTRY_PATH}
7
tag: ${FRONTEND_REGISTRY_IMAGE_SHA}
Copied!
Example values.yaml file which references a build generated by Release
1
containers:
2
- name: {{ .Values.frontend.service.name }}
3
image: {{ .Values.frontend.image.repository }}/{{ .Values.frontend.image.name }}:{{ .Values.frontend.image.tag }}
4
Copied!
Example Helm chart template which references a build generated by Release
As you can see from the examples above, the Release generated environment variables will be injected into the values.yaml and properly reference the container image built by Release.