DevOps tooling provider HashiCorp has released version 0.6 of its application deployment app Waypoint, which sees the relatively new project gaining a lot of features to make it fit better into a cloud-native toolchain.
Operation engineers are now, for example, able to install the Waypoint server into Kubernetes clusters via an official Helm chart, and indeed configure Waypoint to deploy with Helm as well. This approach is not only meant to win over those already using Helm, but also provides access to dynamic app information like artifact tags, and the option of using any Kubernetes resource which the opinionated Kubernetes plugin doesn’t really support.
Using the plugin still comes with its advantages, especially in its latest version, as the Waypoint team added easy options of setting up horizontal pod autoscaling for apps or adding ingress resources for a release. Teams investigating the use of Waypoint in combination with hosted Kubernetes offerings should give v0.6 a closer look as it integrates with container-building tool Kaniko for building Docker images in unprivileged Kubernetes pods.
To help teams to stay on top of their deployments, the latest Waypoint iteration also provides an overview of the resources created by deployments and releases, which should help to spot errors and will serve as the foundation for upcoming improvements such as status change notifications or deployment version diffs. Other new additions include the option to manage config variables through the UI, new commands to view and list workspaces, new functions for working with label selectors, and a labels variable for accessing the label set of an operation.
Meanwhile the team behind orchestrator project Nomad pushed out a beta for its upcoming 1.2 release. The most interesting new feature here surely has to be the system batch job — a new type of job for cluster-wide, short-lived tasks. According to a blog post accompanying the release, system batch jobs work without an update stanza, can be scheduled, and run on any node not excluded via constraints (but only on the clients that were ready when the job was submitted). They can also be parameterised and invoked using the dispatch command, and are especially well suited for regular clean-up or backup tasks.
Nomad’s UI has been fitted with a new Clients tab displaying all client nodes on which batch and sysbatch jobs run. Both kinds of jobs also come with an updated status section that includes new statuses “Not Scheduled” to showcase client nodes that didn’t run a job, and “Degraded” to mark jobs “in which any allocations did not complete successfully”.
The Nomad team also used the beta release to point users to a package manager which has just reached technical preview status. The project is called Nomad Pack and was developed as a way to define reusable application deployments. Teams can use it to group resources which are meant to be deployed together on Nomad into “Packs” that can be specified via Go templates and are organised into so-called registries.
Documentation for turning Nomad jobs into packs is available, as these (along with levant templates) are the only resources accepted for packs at the moment. The Nomad team is currently working on support for volumes and ACLs however, and also looks to enhance the project so that it comes with a search command, integrates with the Nomad CLI, and works with version control systems other than Git.