Skip to main content

[SOLVED] How to pull environment variables with Helm charts - kubernetes

[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

  1. 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"
  2. 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
  3. 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

  1. 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 and password.

  2. 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 the spec.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 and DB_PASSWORD will get the values from the my-secret Kubernetes Secret.

  3. 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

  1. Define Environment Variables in values.yaml: First, we need to write our environment variables in the values.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"
  2. 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 in values.yaml. The | quote makes sure that the values are correctly quoted in the YAML we create.

  3. 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.

  4. 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

  1. Open Your Deployment Template: Go to the templates folder of our Helm chart. Open the deployment YAML file. This file is usually found at templates/deployment.yaml.

  2. Define Environment Variables: In the spec.containers part of our deployment template, we can define environment variables under the env field. We can use fixed values or values from our values.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:

  1. Define Variables in values.yaml:
databaseUrl: "postgres://user:password@database:5432/mydb"
appMode: "production"
  1. 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

  1. 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.

  2. 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.

  3. 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