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:
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:
Here is the resulting output value displayed:
To retrieve the server cookie, use the waypoint server cookie
command:
Then verify by combining the cookie with the value you expected Waypoint to use:
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
:
Example runner profile setup:
Example runner inspect:
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.
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
.
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.
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:
We hope you enjoy Waypoint 0.8!
HashiCorp Waypoint 0.11 allows quicker integration with Terraform Cloud and easier creation of Terraform providers for Waypoint.
Before we ring in the new year, here’s a look back at some of the most important moments in 2022 for HashiCorp.
Learn how to source dynamic secrets from HashiCorp Vault in your Waypoint deployments using dynamic configuration.