Configuration
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: [email protected]
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.
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 |
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.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 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.
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/[email protected]: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 [email protected] to use the container registry SHA:frontend:
service:
name: "frontend"
image:
repository: ${RELEASE_REGISTRY_PATH}
name: [email protected]
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 modified 3mo ago