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:
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 cookieWPC01FZ1FB3FQ1BYABXVN67FAPXJE
Then verify by combining the cookie with the value you expected Waypoint to use:
$ echo -n "WPC01FZ1FB3FQ1BYABXVN67FAPXJEmyemail@mycorp.com" | sha256sum63fc1b8d861dd448c9ae7eaae3102e8a6dd14b838c8bbf1c0ed2f4eceb967d0c
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
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.
$ 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
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!
Do cloud right with The Infrastructure Cloud from HashiCorp. Unlock developer potential while controlling cloud costs and risk.
Looking back on a busy year, we’re proud of so many technical accomplishments. We’re even more excited about the future.
If you’re attending AWS re:Invent in Las Vegas, Nov. 27 - Dec. 1, visit us for breakout sessions, expert talks, and product demos to learn how to accelerate your adoption of a cloud operating model.