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}
4
    name: [email protected]
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}
6
      name: [email protected]
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.

Ingress and Networking

Next - Reference documentation

GitOps

Last modified 3mo ago

Copy link

Contents

Helm Values File

Name Template

Chart Environment Variables File

Build Image Environment Variables