Waypoint 0.7 Reimagines UI and Extends Deployment Workflows
Waypoint 0.7 focuses on enhancing user experience with a significant UI redesign, improved support for more complex deployment workflows, and extensible CI integrations.
We are pleased to announce the general availability of HashiCorp Waypoint 0.7. Waypoint is an application deployment tool that aims to deliver a PaaS-like experience for Kubernetes, Amazon ECS, and other platforms. This release of Waypoint is a significant step forward in enhancing the user experience around securing, configuring, and extending Waypoint for your organization.
Here are some of the significant features in this release:
- UI redesign: Many new user experience workflows have been added by refactoring the Waypoint UI. New UX items include a dropdown for environment selection, icon updates, and a timeline associated with building, deployment, and release information.
- Triggers: The Waypoint CLI now supports scripting and continuous integration (CI) lifecycle operations using triggers. When a trigger is loaded, it executes a specific Waypoint operation for a specific project. This release supports running triggers through the gRPC library, and a future Waypoint release will support running triggers through HTTP.
- External data fetching: The
waypoint.hcl
file can now fetch data from external systems such as HashiCorp Vault, HashiCorp Terraform Cloud, Kubernetes ConfigMaps, and more. For example, it is now possible to source certificate ARNs directly from Terraform Cloud rather than hardcoding them into thewaypoint.hcl
file. - Workspace-scoped configuration: Teams can scope plugin configuration to target a specific workspace. For example, you can now change the Kubernetes namespace, Docker image name, etc., depending on the current workspace. You can even change complete plugin types: Docker for development, Kubernetes for production, etc.
This release includes many new features, workflow enhancements, general improvements, and bug fixes. The Waypoint 0.7 changelog contains a detailed list of all changes in this release.
» UI Redesign
Waypoint focuses on allowing teams to deploy, manage, and observe their applications through the command-line interface (CLI) and user interface (UI) within a web browser.
Notable changes for the Waypoint UI include displaying individual artifacts in a panel beside a sidebar list that contains the same artifact types, like in a list of deployments, which persists instead of redirecting to a different page for each artifact.
The new UI for Waypoint’s deployments list
Timelines show on an artifact’s details page and help teams see which artifacts relate to build, deployment, and release steps.
Waypoint’s updated timeline view
Teams can now use waypoint exec
within the Waypoint browser UI. exec
in the UI allows for commands to be run within a deployment to help with operations like troubleshooting, running database migrations, or checking application configuration.
waypoint exec
in the Waypoint UI
The Waypoint UI now supports OpenID Connect (OIDC) login flows. The server-side components existed in Waypoint 0.6, but the 0.7 release adds functionality to the UI by allowing teams to sign in with OIDC via their browser.
The OpenID connect sign in
» Triggers
Waypoint 0.7 introduces a new core piece of functionality called triggers. Triggers are pre-configured Waypoint lifecycle operations used for execution inside continuous integration environments. Users can configure operations like deploying the latest build, running a status report on all applications in a project, running a waypoint up
operation on all applications in a project, and more.
Triggers can be invoked directly inside an environment with a gRPC request that tells Waypoint to execute the pre-configured action. Trigger configurations are project-scoped, where their actions can operate on every application defined in a project or target a single application inside a project.
With this first iteration in Waypoint 0.7, the Waypoint server will support only executing triggers through gRPC. However, in upcoming versions of Waypoint, HTTP requests will initiate running Triggers, making Waypoint use in CI even more accessible than it is today.
Triggers can be created via the Waypoint CLI as shown here:
$ waypoint trigger create \
-project=<project-name> \
-app=<app-name> \
-workspace=<workspace-name> \
-name=<trigger-name> \
-op=<op>
Trigger "<trigger-name>" (<trigger-id>) has been created
Trigger ID: <trigger-id>
Once created, the CLI command will print out the generated trigger id, which is usable in any environment to trigger that operation. For example, you can run a trigger with grpcurl
:
$ grpcurl -d '{"ref": {"id": "<trigger-id>"}}' -H "Authorization: `waypoint user token`" waypoint.server.address hashicorp.waypoint.Waypoint/RunTrigger
When you execute a trigger, it will return a list of job IDs queued to run with the Waypoint server as soon as possible.
You can also use the Waypoint CLI to list current trigger configurations:
$ waypoint trigger list
» Trigger Configs
ID | NAME | WORKSPACE | PROJECT | APPLICATION | OPERATION
-----------------------------+----------------------+-----------+-------------+-------------+---------------------------
01FS57XXWAZRFMTSW2XVPEM41V | up-trigger | default | go-gitops-0 | go | up
01FS57Y4TC7HGQCXKM5C22VCF6 | build | default | go-gitops-0 | go | build
01FS57YBR2FB38NE08X7AWSJ52 | deploy-latest-go | default | go-gitops-0 | go | deploy
01FS57YH4TQMSP6HZ1QZ03QE2R | release-latest | default | go-gitops-0 | go | release
01FS582B3X8VW0251C1XDQ56RR | deploy-statusreport | default | go-gitops-0 | go | status report deployment
01FS58DAXTE832BM5JMG1Z2XMA | release-statusreport | default | go-gitops-0 | go | status report release
Or you can inspect a specific trigger configuration, like the “deploy-statusreport”
trigger that will regenerate a status report on the latest deployment for an application:
$ waypoint trigger inspect -json 01FS582B3X8VW0251C1XDQ56RR
{
"id": "01FS582B3X8VW0251C1XDQ56RR",
"name": "deploy-statusreport",
"activeTime": "2022-01-11T19:03:48.094407514Z",
"authenticated": true,
"statusReport": {
"deployment": {
"application": {
"application": "go",
"project": "go-gitops-0"
},
"workspace": {
"workspace": "default"
}
}
},
"workspace": {
"workspace": "default"
},
"project": {
"project": "go-gitops-0"
},
"application": {
"application": "go",
"project": "go-gitops-0"
}
}
Learn more about triggers in the documentation.
» External Data Fetching
Waypoint 0.7 introduces the ability to fetch and use external data in your waypoint.hcl
configuration using the dynamic
function. This data can be sourced from Vault, Terraform Cloud, AWS Secrets Manager, and more.
Below is an example of using an AWS ACM certificate ARN from a Terraform Cloud output value:
variable "acm-cert-arn" {
type = string
default = dynamic("terraform-cloud", {
organization = "dadgarcorp"
workspace = "ws-6fIaMNotRealXSQUv"
output = "aws_cert_arn"
})
}
release {
use "kubernetes" {
load_balancer = true
annotations = {
"service.beta.kubernetes.io/aws-load-balancer-ssl-cert" = var.acm-cert-arn
}
}
}
Waypoint is extendable using plugins to support additional data sources, and we plan to continue to expand the list of officially supported data sources.
Learn more about fetching external data in the Waypoint documentation.
» Workspace-Scoped Configuration
Waypoint 0.7 enables users to alter their plugin configuration based on the active workspace. Workspaces have been a mechanism to simulate environments and other organizational constructs since Waypoint 0.1, and we've been expanding the functionality of workspaces over time.
An example use case is to change the Kubernetes namespace of a deployment depending on the workspace and to be able to try a different plugin type in a separate workspace:
app "my-app" {
deploy {
use "kubernetes" {
namespace = "default"
}
workspace "production" {
use "kubernetes" {
namespace = "production"
}
}
workspace "new-platform" {
use "nomad" {
// nomad configuration here
}
}
}
}
In this example, "my-app"
will deploy into the "default"
Kubernetes namespace by default and into the "production"
namespace if the currently active Waypoint workspace is "production"
. Workspace-scoped configuration helps to change configuration based on environments.
The configuration also introduces unique behavior when the "new-platform"
workspace uses HashiCorp Nomad and shows how workspace-scoped configuration potentially enables migration or experimentation with new systems. Consult Waypoint’s documentation for more information about workspace and label scoping.
» What’s Next for Waypoint?
The complete list of new features and improvements in Waypoint 0.7 is too long to detail in this post. For a complete listing of changes in Waypoint 0.7, please see the CHANGELOG.
One of our primary focuses is improving workflows around multiple environments (staging, production, etc.) in future Waypoint releases. Working with various environments using Kubernetes is a manual and error-prone process. We hope to bring significant automation and opinionated workflows to streamline this process better.
We hope you enjoy Waypoint 0.7!
» Next Steps
- Download Waypoint 0.7 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.
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.