Waypoint 0.8 Adds Secret Values for Input Variables
HashiCorp Waypoint 0.8 introduces targetable runners, secret values for input variables, and a new command line tool that adds new insight to Waypoint operations.
We are excited to announce the general availability of HashiCorp Waypoint 0.8. Waypoint is an application deployment tool that aims to deliver a PaaS-like experience for Kubernetes, Amazon ECS, and other platforms.
This release adds several significant new features, including secret values for input variables, targetable runners, runner adoption, instance counts in deployment status reports, and a Waypoint job command line tool for job introspection:
» Secret Values for Input Variables
Waypoint 0.8 brings additional enhancements to Waypoint’s input variables system. Users will now see the final set of input variable values used as part of the output for a build
, deploy
, release
, or up
operation. To ensure that sensitive values are not so easily displayed, Waypoint now allows marking a variable as sensitive
in the variable-declaration block. Sensitive variables will have their values displayed as a SHA256 hashed value, composed of the server cookie as the salt along with the set value. Therefore, the user running an operation can verify whether the expected value was used by verifying the outputted SHA256 hashed value.
Marking a variable sensitive
in the waypoint.hcl
definition looks like this:
variable "auth_email" {
sensitive = true
type = string
default = “myemail@mycorp.com”
}
Here is the resulting output value displayed:
To retrieve the server cookie, use the waypoint server cookie
command:
$ waypoint server cookie
WPC01FZ1FB3FQ1BYABXVN67FAPXJE
Then verify by combining the cookie with the value you expected Waypoint to use:
$ echo -n "WPC01FZ1FB3FQ1BYABXVN67FAPXJEmyemail@mycorp.com" | sha256sum
63fc1b8d861dd448c9ae7eaae3102e8a6dd14b838c8bbf1c0ed2f4eceb967d0c
» Targetable Runners
With Waypoint 0.8, users can target specific remote runners for an application or project, using a runner ID or labels. This allows for significantly more complex workflows involving multiple regions, environments, and clusters; as well as greater customization and control over how Waypoint launches on-demand runners. Runner and runner profile management via the command line (runner list
, runner inspect
, runner profile list
, and runner profile inspect
) will also reflect these changes with new information about runner labels and target runners.
Users can define runner profiles, which contain the configurations necessary to launch a runner. With Waypoint 0.7, we introduced the ability to give a name to a runner profile, and use that name to choose which set of runner configurations to use for an application or project; however, any remote runner could use any runner profile, which may result in namespace and service account errors in multi-cluster environments. With Waypoint 0.8, users can not only specify the runner profile to use, they can also choose which runner can use that profile, either by targeting a specific runner by ID or any available runner that matches all of a set of runner labels.
For example, Waypoint users can target runners in a specific Kubernetes cluster and just provide those runners with Kubernetes service account authentication, while other runners do not need network access or credentials to the Kubernetes cluster.
Example waypoint.hcl
:
project = "example"
app "example" {
runner {
profile = {
"default" = "dev"
"prod" = "prod"
}[workspace.name]
}
…
}
Example runner profile setup:
runner profile set -plugin-type=kubernetes -name=dev -target-runner-label=env=dev -env-var=…
Example runner inspect:
$ waypoint runner inspect test
» Runner:
ID: test
Adoption State: pending
Kind: remote
Labels: map[env:dev]
Online: false
» Runner Adoption
Waypoint runners now must be formally adopted before they are assigned any work. Prior to Waypoint 0.8, Waypoint runners utilized a "pre-shared key" to immediately authenticate. Now, runners are able to launch without any secrets and a Waypoint administrator can see metadata about pending runners and adopt them into the cluster (or reject them).
This makes it much easier to automate runner deployments, since they don't require authentication information. As part of this work, we also expose more metadata about a runner so that administrators can be confident knowing what a specific runner is used for.
All runners can be seen using the waypoint runner list
command and can be adopted or rejected using the waypoint runner adopt
command. A runner can also be rejected after it is adopted in case a runner is compromised or decommissioned.
» Instance Counts in Deployment Status Reports
With Waypoint 0.8, status reports will now include information on the number of instances currently connected to the Waypoint server via Entrypoint. Each status report contains a deployment summary, which will now include the count of connected instances that are using Entrypoint for features such as logs, configuration, or waypoint exec
.
» Waypoint Job Command Line Tool for Job Introspection
With this new command line tool, debugging job failures in Waypoint has never been easier. This release introduces additional introspection into the job system of Waypoint through waypoint job
. Prior to the 0.8 release, it was difficult to see the status of operations in Waypoint without digging through the server or runner logs and finding the exact job details. The new job command line tool supports listing and filtering existing job data from the Waypoint server, inspecting the state and result of an existing job, or safely canceling a running job.
Whenever an operation like running waypoint up
locally or remotely fails, or if you wish to gain more insight into what the job system is doing for automated GitOps deployments, waypoint job list
is there to help you debug. If there’s a job in the list that you wish to know more about, running waypoint job inspect <job-id>
will reveal details such as the kind of configuration that was used, the job's current status, or any error messages that resulted in the job failing.
In the list of jobs below, you can see that a few of them are in the error state. If you list again, filtering using the -state
flag on error, you can see only “error” jobs. Then, if you copy that failing job ID and run waypoint job inspect <job-id>
, you can see exactly why that job failed.
$ waypoint job list
» Waypoint Jobs
ID | OPERATION | STATE | TIME COMPLETED | TARGET RUNNER | WORKSPACE | PROJECT | APPLICATION
-----------------------------+--------------+---------+----------------+----------------------------+-----------+--------------------+--------------
01FZZSQ6BAG46301BN2J809EPR | StatusReport | Success | 27 seconds ago | 01FZZSPSVK6FKWZWJ0EKRM2RTR | default | k8s-tetris-project | tetris
01FZZSQ5TBS2V5SHM8CT8RNM89 | Release | Success | 27 seconds ago | 01FZZSPSVK6FKWZWJ0EKRM2RTR | default | k8s-tetris-project | tetris
01FZZSQ5JYWX9G2WY1SM84EAG5 | StatusReport | Success | 27 seconds ago | 01FZZSPSVK6FKWZWJ0EKRM2RTR | default | k8s-tetris-project | tetris
01FZZSPTBMPJWAM7S3YWSRJ4E9 | Deploy | Success | 28 seconds ago | 01FZZSPSVK6FKWZWJ0EKRM2RTR | default | k8s-tetris-project | tetris
01FZZSPPQ60HBKCAHTW8WEWRFM | Deploy | Error | 41 seconds ago | 01FZZSPP75D2E81G86ZE0BT8KB | default | k8s-tetris-project | tetris
01FZZSPGQZ2S30PJXFZDK408Q5 | Build | Success | 46 seconds ago | 01FZZSPG7Z5JMJGE3BH14Q4Z9K | default | k8s-tetris-project | tetris
01FZZSPAVASRQ7RG1CQ3HR9YGV | Build | Error | 53 seconds ago | 01FZZSPAB9F2NH6P56P1VYJYT9 | default | k8s-tetris-project | tetris
01FZZSC259R3GDR63QMEJJY228 | Up | Success | 5 minutes ago | 01FZZSC1NAGJ7SZKSY4F679XFD | default | k8s-tetris-project | tetris
$ waypoint job list -state=Error
» Waypoint Jobs
ID | OPERATION | STATE | TIME COMPLETED | TARGET RUNNER | WORKSPACE | PROJECT | APPLICATION
-----------------------------+-----------+-------+----------------+----------------------------+-----------+--------------------+--------------
01FZZSPPQ60HBKCAHTW8WEWRFM | Deploy | Error | 52 seconds ago | 01FZZSPP75D2E81G86ZE0BT8KB | default | k8s-tetris-project | tetris
01FZZSPAVASRQ7RG1CQ3HR9YGV | Build | Error | 1 minute ago | 01FZZSPAB9F2NH6P56P1VYJYT9 | default | k8s-tetris-project | tetris
```
```
$ waypoint job inspect 01FZZSPPQ60HBKCAHTW8WEWRFM
» Job Configuration
ID: 01FZZSPPQ60HBKCAHTW8WEWRFM
Operation: Deploy
Target Runner: 01FZZSPP75D2E81G86ZE0BT8KB
Workspace: default
Project: k8s-tetris-project
Application: tetris
» Job Results
State: Error
Complete Time: 1 minute ago
Cancel Time: 1 minute ago
Error Message: context canceled
» Next Steps
The complete list of new features and improvements in Waypoint 0.8 is too long to detail here. For a complete listing of changes in Waypoint 0.8, please see the CHANGELOG. Finally, don’t miss these Waypoint resources:
- Download Waypoint 0.8 from the project website.
- Learn more about Waypoint with tutorials on the HashiCorp Learn site.
- Contribute to the Waypoint project and participate in its community.
- Extend Waypoint by creating a plugin.
We hope you enjoy Waypoint 0.8!
Sign up for the latest HashiCorp news
More blog posts like this one
Terraform, Packer, Nomad, and Waypoint updates help scale ILM at HashiConf 2024
New Infrastructure Lifecycle Management (ILM) offerings from HashiCorp Terraform, Packer, Nomad, and Waypoint help organizations manage their infrastructure at scale with reduced complexity.
HCP Waypoint now GA with enhancements to golden workflow capabilities
Announced last year, HCP Waypoint is now generally available and so are templates and add-ons. The new release features HCP API support and an upgraded workflow for templates.
HCP Waypoint actions is now in public beta
The beta of HCP Waypoint actions to let platform teams expose Day 2+ operations and workflows to developers.