waypoint

Announcing HashiCorp Waypoint 0.3

Git repository polling and remote runners come to HashiCorp Waypoint to enable powerful workflows such as GitOps, along with more major improvements.

We are happy to announce version 0.3 of HashiCorp Waypoint, an open source project that gives developers a consistent workflow to build, deploy, and release applications across any platform. Waypoint enables developers to get their applications from development to production in a single file and deploy using a single command: waypoint up.

Waypoint 0.3 features many major new features that enable GitOps workflows, deployment to AWS Lambda, remote runners for operations such as builds and deploys, and more. Here are brief descriptions of the major features and improvements:

  • GitOps: Projects can be configured to watch a Git repository and trigger a waypoint up whenever a change is detected. The Git commit is now recorded alongside any operation, so you can know exactly which commit a deployment, artifact, or other operations are associated with.
  • AWS Lambda: Waypoint can now build and deploy AWS Lambda workloads. Deployments to Lambda support all the same advanced features of Waypoint, such as application configuration, waypoint exec, log streaming, etc.
  • Runners: Waypoint utilizes runners to execute Waypoint operations remotely. Runners are responsible for performing builds and deploys, polling projects for changes, and more.

Download and try Waypoint 0.3 now from the Waypoint project website. Continue reading to learn more about the new features and improvements in this release.

»GitOps

Waypoint now supports the fundamentals for a GitOps workflow where waypoint up operations are triggered automatically when changes are detected in a Git repository. You can create a project, configure Git repository settings, and watch Waypoint polling for changes entirely in the web UI.

In the short video below, we create a new project that points to a Git repository. After the project is created, Waypoint automatically detects that we haven't yet deployed the latest commit and runs a waypoint up.

One of the goals for Waypoint is to support a diverse set of workflows. When Waypoint first launched, we supported only a CLI-based workflow. This new GitOps functionality enables Git-oriented workflows. Further, these can both be used interchangeably, so if one team prefers GitOps, another team prefers the CLI, and another team likes doing both situationally, they can all use Waypoint the way they want to.

»AWS Lambda

This release of Waypoint adds support for building and deploying applications to AWS Lambda. The example waypoint.hcl file below shows a configuration to deploy to Lambda:

project = "waypoint-lambda"

app "waypoint-lambda" {
  build {
    use "docker" {}

    registry {
      use "aws-ecr" {
        region     = "us-west-2"
        repository = "waypoint-lambda"
        tag        = "waypoint-lambda"
      }
    }
  }

  deploy {
    use "aws-lambda" {
      region = "us-west-2"
    }
  }

  release {
    use "aws-alb" {}
  }
}
project = "waypoint-lambda" app "waypoint-lambda" {  build {    use "docker" {}     registry {      use "aws-ecr" {        region     = "us-west-2"        repository = "waypoint-lambda"        tag        = "waypoint-lambda"      }    }  }   deploy {    use "aws-lambda" {      region = "us-west-2"    }  }   release {    use "aws-alb" {}  }}

Some challenges while developing with AWS Lambda are viewing logs, opening a shell for debugging, etc. Waypoint makes the entire deploy-to-debug workflow a consistent experience; waypoint exec and waypoint logs work for Lambda workloads in the same way they work for containerized workloads:

$ waypoint exec bash
Connected to deployment v1
bash-4.2#

$ waypoint logs
Version: 1
2021-04-06T22:32:32.230Z ZFHDQ6: Handling ALB request for unknown user
2021-04-06T22:32:32.230Z ZFHDQ6: END RequestId: 1547f54c-5578-45d3-96d3-2c02f75c5f33
2021-04-06T22:32:32.230Z ZFHDQ6: REPORT RequestId: 1547f54c-5578-45d3-96d3-2c02f75c5f33
Duration: 13.39 ms	Billed Duration: 14 ms	Memory Size: 256 MB	Max Memory Used: 105 MB
$ waypoint exec bashConnected to deployment v1bash-4.2# $ waypoint logsVersion: 12021-04-06T22:32:32.230Z ZFHDQ6: Handling ALB request for unknown user2021-04-06T22:32:32.230Z ZFHDQ6: END RequestId: 1547f54c-5578-45d3-96d3-2c02f75c5f332021-04-06T22:32:32.230Z ZFHDQ6: REPORT RequestId: 1547f54c-5578-45d3-96d3-2c02f75c5f33Duration: 13.39 ms	Billed Duration: 14 ms	Memory Size: 256 MB	Max Memory Used: 105 MB

Waypoint was designed from the beginning to support multiple paradigms: containers, VMs, serverless. For the initial launch, we focused on container-based workloads on top of platforms such as HashiCorp Nomad, Kubernetes, Amazon ECS, etc. The AWS Lambda support in Waypoint 0.3 shows the flexibility of Waypoint to support other paradigms such as serverless, and future versions of Waypoint will continue to build on this flexibility.

The HashiCorp Learn team has published a new AWS Lambda Tutorial that shows you how you can start using this new feature in Waypoint.

»Remote Runners

Waypoint can now perform operations such as build and deploy remotely using a new process called a "runner.” Runners can run anywhere they have connectivity to the Waypoint Server, and clients of the server such as the CLI can invoke operations remotely.

Runners are one of the main components that enable the GitOps functionality. When a change in Git is detected, Waypoint queues a waypoint up to run on any available runner.

To run a runner, use the waypoint runner agent command:

$ WAYPOINT_SERVER_ADDR=<server addr> \
  WAYPOINT_SERVER_TLS=true \
  WAYPOINT_SERVER_TOKEN=<auth token> \
  waypoint runner agent

» Runner configuration:
  Server address: waypoint.example.com:9701

» Runner logs:

...
$ WAYPOINT_SERVER_ADDR=<server addr> \  WAYPOINT_SERVER_TLS=true \  WAYPOINT_SERVER_TOKEN=<auth token> \  waypoint runner agent » Runner configuration:  Server address: waypoint.example.com:9701 » Runner logs: ...

Remote runners also enable necessary security functionality, since users of the CLI no longer need direct access to the targets they're deploying to or credentials to access those targets. The CLI needs only access to the Waypoint server, and the runner processes can be the only thing that has the credentials necessary to deploy.

»Other Improvements

Waypoint 0.3 contains many other improvements. To highlight a few:

  • A Terraform Cloud config sourcer was added, which lets Waypoint deployments use outputs from Terraform state. For example, this is a beneficial way to reference an RDS endpoint or other resources managed by Terraform. If the output value changes — such as from another Terraform apply — Waypoint will automatically restart running applications with the new value.
  • Waypoint now supports building Docker images in unprivileged environments without a Docker daemon. This enables remote runners to do Docker builds in hosted environments such as GKE or ECS.
  • The Kubernetes deployment platform now attempts in-cluster auth if available, allowing deployments within a remote runner running within a pod to authenticate automatically with Kubernetes.
  • When creating a project, you can now store the waypoint.hcl file contents on the Waypoint server rather than alongside your project source code. This makes it easy to manage existing applications.

»What's Next for Waypoint

We're already hard at work on the next major release of Waypoint, focusing on building significant foundational features for the project. We expect the next version of Waypoint to support variables within the waypoint.hcl file that support "mutable" deployment patterns such as Helm, raw Nomad job files, and more.

You can also see what we are currently working on in the project’s milestones in GitHub. Please check out the 0.4.0 milestone for an up-to-date list of what we're working on. If you have any questions or suggestions about how we can continue to improve the Waypoint project, please let us know in the Waypoint Discuss forums.

»Learn More


Sign up for the latest HashiCorp news