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:
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:
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:
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:
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
:
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:
This example Helm chart template references a build generated by Release:
Release-generated environment variables are injected into the values.yaml
file and properly reference the container image built by Release.
Last updated