What's new in Boundary 0.1.5
Boundary 0.1.5 has been released with several new features that make Boundary more capable in multi-datacenter and multi-region environments, drive more insights into Boundary’s resources by conveying what actions a user can perform on a resource, and allow a user to list resources recursively in scope. Additionally, we’ve added a new
migrate command that provides an easier upgrade path with fail-safes in the event of migration issues. We’ll cover all these features in more detail below!
The Boundary target-aware workers feature allows the ability to specify a boolean-expression filter against worker tags to control which workers are allowed to handle a given target’s session. This enables a worker to effectively be “tied” to a given target, forcing the session to occur through a specified worker for a specific target. This feature allows Boundary to be a key player in a multi-datacenter/multi-region cloud operating model by allowing a single set of controllers to live in one region, and then have workers in many regions where each set of workers can be tied to a specific network slice (VPC or other) where the targets they are proxying live.
One of Boundary's biggest user asks has been to make it more straightforward to view and list resources on the command line. With 0.1.5 we’ve landed two improvements:
<resource> list -scope-id $project-idcommands to survey their resources across all of their org’s projects, they now have a streamlined boundary
<resource> list -scope-id $org-id -recursiveto list all resources across an org.
In addition to being useful in their own right, these features are also foundational for future improvements in users’ abilities to filter and search for resources based on their parameters.
While new features are added to Boundary, like the Target-Aware workers, the backing database schema must be updated to support these features. The migrate command gives you a way to do that. Simply stop all the running controllers, run
boundary database migrate and all the changes will be applied to the database in a single transaction.
Even though the migrate command is resilient to errors due to utilizing PostgreSQL transactions, it is still highly recommended that you follow good database practices and backup prior to migrating. This is also valuable in case you decide you want to stick with an older version of Boundary since the migrate command is a one-way switch that does not allow reverting back to an older version. In this release, and in future releases where new features require an update to the DB, boundary will not let you start a new controller but will direct you to use the
boundary database migrate command.
To learn more about Boundary, please visit the project website at boundaryproject.io, github.com/hashicorp/boundary for the source code, and HashiCorp Learn to find our step-by-step tutorials to get started with Boundary.
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.
See a potential method for securing application content and components hosted within Kubernetes using Boundary as an alternative to ingress controllers.
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.