waypoint

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.

Jan 13 2022Taylor Dolezal

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 the waypoint.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.

New Waypoint UI for deployments

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.

Timeline view

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.

Running waypoint exec in the UI

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.

Waypoint Open ID sign in

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

Kubernetes

Sign up for the latest HashiCorp news

By submitting this form, you acknowledge and agree that HashiCorp will process your personal information in accordance with the Privacy Policy.

More blog posts like this one

HashiCorp at AWS re:Invent: Your blueprint for cloud success
November 21 2023 | Company
HashiCorp at AWS re:Invent: Your blueprint for cloud success

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.

Five trends in cloud infrastructure and what they mean
October 23 2023 | Company
Five trends in cloud infrastructure and what they mean

From AI to the edge, HashiCorp Co-Founder and CTO Armon Dadgar shares his insights on where the cloud is headed, and what that means.

Infrastructure and security releases open HashiConf 2023
October 11 2023 | Products & Technology
Infrastructure and security releases open HashiConf 2023

HashiConf 2023 unveils key announcements covering infrastructure and workflow enhancements as well as new security lifecycle management capabilities.