Announcing HashiCorp Waypoint 0.2.0

Configuration syncing, templating, and path variables come to Waypoint to enable you to better build, deploy, and release applications across any platform.

Today, we are happy to announce 0.2.0 of HashiCorp Waypoint, an open source project that provides 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.2.0 can sync application configuration (including secrets) with external sources such as Kubernetes ConfigMaps, HashiCorp Vault, and more. The waypoint.hcl file can now use variables to access dynamic information about build artifacts and deploys. And there is a new family of functions for templating external files such as Dockerfiles and Kubernetes configs.

Download and try Waypoint 0.2.0 now from the Waypoint project website. Continue reading to learn more about what’s new in this release and how these new features make it easier for you to deploy and manage your apps.

Syncing Config and Secrets
for Your Apps

Waypoint can now configure your application via environment variables that are synced with an external system such as Kubernetes ConfigMaps, HashiCorp Vault, Amazon Parameter Store, and other systems that have a configuration source plugin available. And when these values change, your apps are automatically updated and restarted.

Applications often expose configuration such as database URLs and ports to listen on in the form of environment variables. Prior versions of Waypoint allowed you to set these directly using the waypoint config CLI:

$ waypoint config set DATABASE_URL="postgresql://example.com:5432"

This method has several downsides: the value has to be known ahead of time, the value must be shared with a Waypoint user, and the value is stored on the Waypoint server. Modern applications instead often use external configuration services such as Kubernetes ConfigMaps or Amazon Parameter Store to store these values. This enables a separation of concerns and the storage of the value in a potentially more secure location.

Now, in Waypoint 0.2, configuration values can additionally be synced with external systems. The example below shows how we can use the waypoint.hcl file to specify that the DATABASE_URL configuration be synced from a Kubernetes Secret instead:

config {  env = {    DATABASE_URL = configdynamic("kubernetes", {      name   = "database-info" # Secret name      key    = "url"      secret = true    })  }}

In the example, the DATABASE_URL environment variable will sync with the url key in the database-info Kubernetes Secret. The "sync" actively watches the defined source, updates the environment variable whenever the value changes, and restarts your application. 

You can mix and match both dynamically synced and static values, along with dynamic values from multiple sources. The following example shows a blog where the theme is synced with a Kubernetes ConfigMap, the database authentication is synced with Vault, and the database address is a static value:

project = "blog"  app = "web" {   config {       env = {           THEME = configdynamic("kubernetes", {               name = "blog-config"               key = "theme"           })            DATABASE_HOST = "postgresql"            DATABASE_USERNAME = configdynamic("vault", {               path = "database/postgres/blog"               key = "username"           })            DATABASE_PASSWORD = configdynamic("vault", {               path = "database/postgres/blog"               key = "password"           })       }   }    # ...}

This feature does not require any additional sidecars or cluster configuration. Configuration syncing is built directly into the Waypoint Entrypoint. This can make it significantly easier to use dynamic configuration services.

And for multi-platform users, the above example works identically whether you're deploying to Kubernetes, Nomad, AWS ECS, or any other Waypoint-supported platform. You're able to share and access the same configuration sources anywhere.

Learn more about configuration syncing.

Templating and Variables

Results of prior operations such as builds and deploys are now available to future operations allowing waypoint.hcl configuration to be less repetitive and more dynamic. Additionally, a new family of templating functions can be used to render files such as Kubernetes Configs and Dockerfiles with access to all these variables.

Results of prior operations such as builds and deploys are now available to future operations allowing waypoint.hcl configuration to be less repetitive and more dynamic. Additionally, a new family of templating functions can be used to render files such as Kubernetes Configs and Dockerfiles with access to all these variables.

Below is a complete example combining these two features:

app "blog" {  build {    use "docker" {      dockerfile = templatefile("${path.app}/Dockerfile.tpl", {        theme = "rainbow"      })    }     registry {      use "docker" {        image = artifact.image        tag = gitrefpretty()      }    }  }   # ... }

The Docker builder uses the templatefile function to template the Dockerfile with the variable theme. The Dockerfile template is referenced using the new path.app variable which clearly shows the template is relative to the app directory. Then, the Docker registry step uses the artifact.image variable to match the image name from the build for pushing to a registry.

This example is relatively simple, but the concept can be extended to support increasingly complex use cases. Continuing further, the deploy stage would now have access to the artifact variable as well and might use this while templating a directory of Kubernetes YAML files with the templatedir function, for example.

Like configuration syncing, templating and variables help build the foundation for using Waypoint with all types of apps by providing support for reusability and consistency. 

Learn more about templating and available variables.

Other Improvements

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

  • waypoint logs now shows entrypoint-related logs. This is an important improvement to diagnose why features such as configuration syncing may not work or why your application may have failed to launch.
  • waypoint exec has had a number of stability issues resolved and now behaves better in non-PTY environments. waypoint exec has access to all configuration variables including synced values.
  • The Waypoint server now supports online backup and restore to more safely operate the server in production. This is available via API as well as the waypoint server CLI.

What's Next for Waypoint

We regularly update the Waypoint roadmap on the project’s website with what we have planned. You can also see what we are currently working on in the project’s milestones in GitHub. For example, we used the 0.2.0 milestone for tracking and completing the work in this release. 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

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