[SOLVED] Easy Ways to Pull Environment Variables Using Helm Charts in Kubernetes
In this chapter, we will look at simple ways to pull environment variables in Kubernetes using Helm charts. Helm is a useful tool for managing applications in Kubernetes. It makes it easier to install and control applications. Knowing how to handle environment variables is very important for setting up applications well in Kubernetes. We will talk about different ways to use Helm charts to set and add environment variables. This will help us deploy applications with the right settings.
Here are the ways we will talk about in this article:
- Solution 1: Use ConfigMaps to Set Environment Variables
- Solution 2: Add Secrets as Environment Variables
- Solution 3: Use Values.yaml to Change Environment Variables
- Solution 4: Send Environment Variables from the Command Line
- Solution 5: Set Environment Variables in Deployment Templates
- Solution 6: Use Helm Hooks for Changing Environment Variables
By the end of this article, we will understand how to manage environment variables in our Kubernetes applications using Helm charts. For more related information, you can check our guides on how to set multiple commands in Kubernetes and the difference between ClusterIP and other service types. Let’s start with the solutions!
Solution 1 - Using ConfigMaps to Define Environment Variables
One of the best ways to pull environment variables in Helm charts is by using ConfigMaps. ConfigMaps help us keep environment settings separate from our application code. This makes our deployments easier to manage. This way is very useful when we need to handle non-sensitive configuration data.
Steps to Use ConfigMaps for Environment Variables
Create a ConfigMap: First, we define a ConfigMap in our Helm chart. We can do this in a YAML file inside the
templates
folder. Here is an example of a ConfigMap:apiVersion: v1 kind: ConfigMap metadata: name: my-config data: DATABASE_URL: "postgres://user:password@host:port/dbname" API_KEY: "your-api-key"
Reference the ConfigMap in your Deployment: Next, in the deployment YAML file, we can use the ConfigMap to set environment variables. Here is how we do it:
apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 1 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app-container image: my-app-image:latest env: - name: DATABASE_URL valueFrom: configMapKeyRef: name: my-config key: DATABASE_URL - name: API_KEY valueFrom: configMapKeyRef: name: my-config key: API_KEY
Deploy the ConfigMap and Deployment: After we create our ConfigMap and change the deployment, we use Helm to install or upgrade our chart:
helm install my-release ./my-chart
Advantages of Using ConfigMaps
- Separation of Concerns: ConfigMaps keep our configuration apart from our application code.
- Dynamic Updates: We can change the ConfigMap without redeploying the application, depending on how our application reloads settings.
- Version Control: We can control the version of our ConfigMaps with our Helm charts.
Using ConfigMaps to define environment variables in our Helm charts is a good practice. It helps us make our Kubernetes deployments more flexible. For more tips on managing Kubernetes configurations, we can check this article on how to set configurations in Kubernetes.
Solution 2 - Injecting Secrets as Environment Variables
Injecting secrets as environment variables in our Kubernetes apps is a good way to handle sensitive data. This includes things like passwords, API keys, and tokens. Helm charts help us add Kubernetes Secrets to our deployments easily. This makes our apps more secure and flexible.
Step-by-Step Guide to Injecting Secrets
Create a Kubernetes Secret: First, we need to make a Kubernetes Secret that holds the sensitive info we want to use as environment variables. We can do this with the command below:
kubectl create secret generic my-secret --from-literal=username=myuser --from-literal=password=mypassword
This command makes a secret called
my-secret
with two key-value pairs:username
andpassword
.Reference the Secret in Your Helm Chart: Next, we need to change our Helm chart’s deployment template to use the secret. We edit the
deployment.yaml
file in our chart and add this under thespec.containers
section:env: - name: DB_USERNAME valueFrom: secretKeyRef: name: my-secret key: username - name: DB_PASSWORD valueFrom: secretKeyRef: name: my-secret key: password
In this part,
DB_USERNAME
andDB_PASSWORD
will get the values from themy-secret
Kubernetes Secret.Deploy Your Helm Chart: After we change our Helm chart, we deploy it with this command:
helm install my-release ./my-chart
We should replace
my-release
with our chosen release name and./my-chart
with where our Helm chart is.
Verification
To check if the environment variables are set right, we can look at the logs of our pods or run a shell in our pod:
kubectl exec -it <pod-name> -- /bin/sh
Once we are in the pod, we can run:
echo $DB_USERNAME
echo $DB_PASSWORD
This should show the values we set in our Kubernetes Secret.
Best Practices
- Limit Access: We should make sure that only the necessary pods can access the Secrets. We do this by setting good RBAC policies.
- Use Helm Values: If we want to make our secrets
easy to change, we can put the secret names and keys in our
values.yaml
file and use them in our deployment template.
Following these steps lets us inject secrets as environment variables in our Helm charts. This helps keep our app secure. For more info about Kubernetes secrets and how to manage them, we can check this article.
Using this way to deploy sensitive info as environment variables with Kubernetes Secrets is a common practice in the industry. This helps our apps stay secure and follow good practices.
Solution 3 - Using Values.yaml to Override Environment Variables
One good way to manage environment variables in our Helm charts is to
use the values.yaml
file. This method helps us set
environment variables that we can easily change when we install or
upgrade. This makes our Kubernetes deployments more flexible and easy to
maintain.
Step-by-step Guide
Define Environment Variables in
values.yaml
: First, we need to write our environment variables in thevalues.yaml
file. This file is usually in the main folder of our Helm chart. Here is an example of how to set it up:env: DATABASE_URL: "postgres://user:password@host:5432/dbname" API_KEY: "your_api_key"
Modify the Deployment Template: Next, we should change our deployment template. This is often in
templates/deployment.yaml
. We will use the Helm templating to add these values to the environment section of our container:apiVersion: apps/v1 kind: Deployment metadata: name: { { .Release.Name } } spec: replicas: 1 selector: matchLabels: app: { { .Release.Name } } template: metadata: labels: app: { { .Release.Name } } spec: containers: - name: your-container image: your-image:latest env: - name: DATABASE_URL value: { { .Values.env.DATABASE_URL | quote } } - name: API_KEY value: { { .Values.env.API_KEY | quote } }
In this code, the
env
part of the container uses the values we set invalues.yaml
. The| quote
makes sure that the values are correctly quoted in the YAML we create.Override Values at Install/Upgrade: When we install or upgrade our Helm chart, we can change these environment variables directly from the command line. We use the
--set
flag. For example:helm install my-release ./my-chart --set env.DATABASE_URL="postgres://newuser:newpassword@host:5432/newdbname" --set env.API_KEY="new_api_key"
This command will install our Helm chart and replace the values in
values.yaml
with the ones we provide. This is very useful when we want to customize settings for different environments like development, staging, or production.Using Multiple Values Files: We can also keep multiple value files for different environments and choose which file to use when we install:
helm install my-release ./my-chart -f values-production.yaml
This way, we can have a separate
values-production.yaml
file that holds production-specific environment variables. This makes our deployments cleaner and easier to manage.
Conclusion
Using the values.yaml
file to manage environment
variables in Helm charts is a good practice. It helps us be more
flexible and keeps our Kubernetes applications easy to maintain. By
setting default values in values.yaml
and allowing easy
changes, we can adjust our deployments for different environments
without changing our templates. For more tips on managing Kubernetes
settings, we can check this
article on setting environment variables.
Solution 4 - Passing Environment Variables from the Command Line
We can pass environment variables to our Helm charts using command line arguments. This happens during the Helm install or upgrade process. This way, we can change how our applications work without changing the Helm chart files.
To pass environment variables from the command line with Helm, we use
the --set
flag. This flag helps us change specific values
that are in our values.yaml
file.
Example Command
Let’s say we want to set the environment variable
DATABASE_URL
for our application. We can run this
command:
helm install my-release my-chart --set env.DATABASE_URL="postgres://user:password@host:port/dbname"
In this command, my-release
is the name of our Helm
release. my-chart
is the path to our Helm chart. We use the
--set
flag to set the environment variable.
Modifications in the Deployment Template
To make sure that the environment variables from the command line are used in our Kubernetes deployment, we need to mention them in our deployment template. Here is how we can set up our deployment template to use these variables:
apiVersion: apps/v1
kind: Deployment
metadata:
name: { { .Release.Name } }
spec:
replicas: 1
template:
spec:
containers:
- name: my-container
image: my-image:latest
env:
- name: DATABASE_URL
value: { { .Values.env.DATABASE_URL | quote } }
Important Notes
- The
| quote
function makes sure that the value is in the correct format as a string in the generated manifest. - Only the environment variables we specify in the command line will
change those in the
values.yaml
file. This makes this method flexible for different environments or settings.
Conclusion
Using the command line to pass environment variables during Helm deployments helps us customize our application’s settings easily. This method is very useful for CI/CD pipelines. We can add secret keys or configuration details without changing the Helm chart.
For more details about managing environment variables in Kubernetes, you can check this resource on how to set environment variables in Kubernetes.
Solution 5 - Setting Environment Variables in Deployment Templates
We can set environment variables directly in our Helm chart’s deployment templates. This helps to make sure our Kubernetes pods have the right settings when they run. By doing this, we can put environment variables right in the YAML file. It makes it easy to manage and change them based on what we need for our deployment.
Step-by-Step Guide to Setting Environment Variables
Open Your Deployment Template: Go to the
templates
folder of our Helm chart. Open the deployment YAML file. This file is usually found attemplates/deployment.yaml
.Define Environment Variables: In the
spec.containers
part of our deployment template, we can define environment variables under theenv
field. We can use fixed values or values from ourvalues.yaml
file or Kubernetes Secrets and ConfigMaps.
Example: Defining Static Environment Variables
Here is a simple example to set static environment variables in our deployment template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 2
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: my-app-image:latest
env:
- name: DATABASE_URL
value: "postgres://user:password@database:5432/mydb"
- name: APP_MODE
value: "production"
Example: Using Values from values.yaml
To make our deployment more flexible, we can use values from our
values.yaml
file. Here is how we can do this:
- Define Variables in values.yaml:
databaseUrl: "postgres://user:password@database:5432/mydb"
appMode: "production"
- Reference Variables in Your Deployment Template:
env:
- name: DATABASE_URL
value: { { .Values.databaseUrl | quote } }
- name: APP_MODE
value: { { .Values.appMode | quote } }
Using ConfigMaps and Secrets
We can also set environment variables using ConfigMaps and Secrets. This is a better way for sensitive information. Here is a short overview of how to do this:
- ConfigMap Example:
apiVersion: v1
kind: ConfigMap
metadata:
name: my-app-config
data:
DATABASE_URL: "postgres://user:password@database:5432/mydb"
In our deployment template, we can reference the ConfigMap like this:
env:
- name: DATABASE_URL
valueFrom:
configMapKeyRef:
name: my-app-config
key: DATABASE_URL
- Secret Example:
apiVersion: v1
kind: Secret
metadata:
name: my-app-secret
type: Opaque
data:
DATABASE_PASSWORD: <base64_encoded_password>
We can reference it in our deployment template like this:
env:
- name: DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: my-app-secret
key: DATABASE_PASSWORD
Conclusion
Setting environment variables in deployment templates is a strong way
to configure applications running in Kubernetes with Helm charts. We can
use static values, dynamic references from values.yaml
, and
safely inject data from ConfigMaps and Secrets. This gives us a flexible
and secure way to deploy. For more tips on managing configurations and
fixing common issues in Kubernetes, check our articles on Kubernetes
Secrets and ConfigMaps.
Solution 6 - Using Helm Hooks for Dynamic Environment Variables
Helm hooks are a useful feature. They let us do something at specific times during the release cycle of a Helm chart. We can use this feature to set dynamic environment variables for our applications in Kubernetes. By using Helm hooks, we can create resources that run before or after we install, upgrade, or delete a release. This is great for setting up configurations or environment variables based on what is happening at runtime.
Steps to Use Helm Hooks for Dynamic Environment Variables
Define a Hook in Your Helm Chart: First, we need to define a hook in one of our Kubernetes resource definitions. We can do this by adding an annotation to our Kubernetes manifest files.
Create a ConfigMap or Secret: The hook can create a ConfigMap or Secret that holds the dynamic environment variables. We can then use this resource in our application’s deployment.
Reference the ConfigMap or Secret in Your Deployment: In our deployment template, we can reference the ConfigMap or Secret we created earlier to set the environment variables for our application.
Example Implementation
Here’s a simple example showing how to use dynamic environment variables with Helm hooks.
Step 1: Create a Hook Manifest
We will create a new YAML file in our Helm chart (like
templates/hook-configmap.yaml
):
apiVersion: v1
kind: ConfigMap
metadata:
name: dynamic-env-vars
annotations:
"helm.sh/hook": pre-install,pre-upgrade
data:
MY_DYNAMIC_VAR: "This is a dynamic value set by Helm hook"
In this example, we define a ConfigMap called
dynamic-env-vars
. This will be created before we install or
upgrade the Helm release.
Step 2: Modify Your Deployment
Next, we need to change our deployment template to use the dynamic
environment variable. For example, in
templates/deployment.yaml
, we can add:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: my-app-image:latest
env:
- name: MY_DYNAMIC_VAR
valueFrom:
configMapKeyRef:
name: dynamic-env-vars
key: MY_DYNAMIC_VAR
In this deployment configuration, the environment variable
MY_DYNAMIC_VAR
gets its value from the
dynamic-env-vars
ConfigMap.
Benefits of Using Helm Hooks
- Dynamic Initialization: We can set environment variables based on the current state of our application or environment. This gives us more flexibility when we deploy.
- Separation of Concerns: Using hooks helps us keep the logic for setting environment variables separate from the main application settings. This makes it easier to manage.
- Lifecycle Control: Hooks let us control when the environment variables are set. This way, they are ready before our application starts.
Conclusion
Using Helm hooks for dynamic environment variables in our Kubernetes applications gives us more flexibility and control during deployment. By following the steps above, we can manage environment variables based on dynamic conditions. This ensures our applications are correctly set up when they run. For more information about best practices in Kubernetes, we can check out how to set multiple commands in Kubernetes or learn about other features of Helm.
Conclusion
In this article, we looked at some ways to get environment variables with Helm charts in Kubernetes. We talked about using ConfigMaps and Secrets. We also covered changing values.yaml, passing variables from the command line, and setting them in deployment templates. Each way helps us make our Kubernetes deployments more flexible and secure.
By learning these methods, we can make sure our applications work well. For more information, check our guides on how to set environment variables and managing pod issues.
Comments
Post a Comment