Runner Configuration
Warning
This content is part of the legacy version of Waypoint that is no longer actively maintained. For additional information on the new vision of Waypoint, check out this blog post and the HCP Waypoint documentation.
Runners may require additional configuration such as cloud credentials, Docker registry credentials, etc. Waypoint enables runners to be configured with environment variables and files at runtime, either globally or specific to certain environments.
Environment Variables
Via the CLI
You can set environment variables using waypoint config
with the -runner
flag:
This will expose these environment variables on every runner (including
a CLI runner when an operation runs locally). To unset any variables, assign it to
an empty value. You may view the set of runner configuration values using
waypoint config get
:
Security note: HCP Waypoint stores these values encrypted within its backend using HashiCorp Vault. If that's unsatisfactory, you can set the environment variables manually when manually running the runner.
Security note: On a self hosted Waypoint server, these configuration values are stored as plaintext in the Waypoint server data file. If you do not want to store any secrets on the Waypoint server, you must set the environment variables manually when manually running the runner.
You can use the -scope
flag paired with flags such as -project
,
-label-scope
, and -workspace-scope
to set runner variables that are only
available within certain scoped situations. Unscoped variables are globally sent to
all runners.
Consider an example where you're using a dev
and a prod
workspace in Waypoint.
These workspaces match up to your dev
and prod
environments.
For this example, let's assume that you use Nomad (with an ACL-enabled cluster), and
your dev
and prod
environments are separated into different namespaces by the name names. These two different workspaces need to be configured by Waypoint to deploy
to the proper environments in Nomad.
To accomplish this, you would set your runner config to use workspace-scoped
config: a Nomad token with permissions to submit jobs to the dev
namespace
is used for the dev
Waypoint workspace, and another token with permissions to
submit jobs to the prod
namespace for the prod
Waypoint workspace. Here's what
that could look like:
With configurations set in this way, operations executed in a given workspace will
use the NOMAD_TOKEN
configured for the corresponding environment automatically.
Via the waypoint.hcl
File
Environment variables for runners can also be set via the waypoint.hcl
file. This uses the same syntax as the config
stanza:
This configuration is scoped only to the project or application of
the waypoint.hcl
file.
Files
Using the waypoint.hcl
file, you can configure data to be stored in files
that are available to runners when running operations for that project or application.
You cannot configure files to be available globally to the server. This behaves similarly to
application configuration files.
Note: The user that is running the runner must have permission to write to the given file paths. File paths are not cleaned up after the runner operation completes as this feature presume On-demand runners are in use, as they are the most common production deployment setup.
Dynamic Values
When using the waypoint.hcl
format, runners may make use of
dynamic values to source configuration
from external sources. The runner
stanza also has access to
internal values for composing multiple
values together.
Note that runner variables only have access to internal variables
specified within the runner
stanza. Variables specified at the app-level
config
stanza are not inherited.
For example, the following is not valid:
Runner profiles
To modify the way that Waypoint launches on-demand runners, see runner profiles.