»ConfigMaps and Secrets

Waypoint provides multiple options for accessing ConfigMap and Secret resources within your deployed application. This can be used or instead of Waypoint's native application configuration functionality.

This page will focus on Waypoint-specific mechanisms for injecting configuration into your application, and it all requires the Waypoint Entrypoint to be injected and configured. Please note that if you're using the Helm or kubernetes-apply deployment plugins, you do not need to use the Waypoint entrypoint and you can access ConfigMaps and Secrets using standard Kubernetes practices. Even if you are using Helm or raw YAML, you can also mix in any of the techniques noted below as well.

»Environment Variables

You can set environment variables for your application directly in the waypoint.hcl file using the config stanza. Static environment variables like this can also be set using the web UI or CLI.

config {
  env = {
    MY_API_KEY = "abcd1234"
  }
}

app "my-app" {
  // ...
}

config {
  env = {
    MY_API_KEY = "abcd1234"
  }
}

app "my-app" {
  // ...
}

But, it's not a good idea to put something like an API key directly in your Waypoint configuration. A better idea would be to use a Kubernetes Secret and access it from there. Waypoint lets you do this with dynamic configuration:

config {
  env = {
    MY_API_KEY = dynamic("kubernetes", {
      name   = "my-secret" # Secret name
      key    = "apiKey"
      secret = true
    })
  }
}

app "my-app" {
  // ...
}

config {
  env = {
    MY_API_KEY = dynamic("kubernetes", {
      name   = "my-secret" # Secret name
      key    = "apiKey"
      secret = true
    })
  }
}

app "my-app" {
  // ...
}

»Files

You can also create files from configuration values. For example, if we wanted to create a JSON file with our API key from the environment variable example above, we can do the following:

config {
  internal = {
    MY_API_KEY = dynamic("kubernetes", {
      name   = "my-secret" # Secret name
      key    = "apiKey"
      secret = true
    })
  }

  file = {
    "config/config.json" = templatefile("${path.project}/config.json", {
      api_key = config.internal.MY_API_KEY,
    })
  }
}

app "my-app" {
  // ...
}

config {
  internal = {
    MY_API_KEY = dynamic("kubernetes", {
      name   = "my-secret" # Secret name
      key    = "apiKey"
      secret = true
    })
  }

  file = {
    "config/config.json" = templatefile("${path.project}/config.json", {
      api_key = config.internal.MY_API_KEY,
    })
  }
}

app "my-app" {
  // ...
}

{
  "api_key": "${api_key}"
}

{
  "api_key": "${api_key}"
}

This example shows two new concepts: internal variables for creating intermediary values that can be used in other configuration values and files for creating configuration files.

The file config/config.json will be written relative to your application deployment path. You could also specify an absolute path if you want the file to be written in an exact location. The files are written by a user with the same permissions as the running application when deployed, so ensure it is a path you have permission to write to.

»File Change Notification

If an input to a configuration file changes while the application is deployed, Waypoint will send a signal to the deployed application (by default SIGUSR2). The application can listen for this signal to reload configuration.

For example, if you change the my-secret secret (as used in the example above) after you had already deployed your application, Waypoint would detect the change, update the file, and then send a SIGUSR2 signal to your running application.

This is a big improvement over native Kubernetes mechanisms which update the file but depend on the running application to watch the filesystem for changes. For more information, including how to change the signal Waypoint sends, see the reference documentation.