HashiCorp Nomad has officially reached version 1.0, bringing HCL2 support, dynamic application sizing, namespaces in the OSS version, and more.
We are pleased to announce the public beta of HashiCorp Nomad 1.0. Nomad is a simple and flexible orchestrator to deploy and manage containers and non-containerized applications across on-premises and cloud environments at scale. Nomad is widely adopted and used in production by organizations like Cloudflare, Roblox, Q2, Pandora, and more.
With this release, Nomad has achieved a major release in both functionality and quality, since the 1.0 designation is one that HashiCorp takes seriously. Nomad 1.0 beta introduces a major new capability with Dynamic Application Sizing, releases namespaces to be available in open source, and includes other new capabilities like the event stream, HCL2 support, Envoy versioning, CNI improvements, HashiCorp Consul namespace support, and topology visualization. Read on for more details.
Nomad 1.0 introduces an innovative new feature, Dynamic Application Sizing for Nomad Enterprise, enabling organizations to optimize the resource consumption of applications through sizing recommendations from Nomad. This feature removes the trial-and-error routine of setting resource requirements and expands Nomad’s functionality from simply deploying applications to right-sizing them in an intelligent and non-disruptive manner at scale.
As schedulers such as Nomad and Kubernetes have become mainstream in adoption and usage, enterprises have evolved from slow, ticket-based application deployment models to self-service workflows. In a self-service workflow, developers own their applications end-to-end and have free input into their deployment configs — enabling enterprises to achieve higher developer velocity and faster time-to-ship. However, self-service has created some unwanted byproducts: excess application overprovisioning, resource waste, and overspending.
Resource consumption is often unknown and varies widely from application to application. Resource consumption is also dynamic — as loads increase or new code is added, the resource usage profile of the application will change. Developers in a self-service workflow hard code the resource requirements (amount of CPU and memory) for their applications through trial-and-error “guesstimations.” Over time, the application’s resource requirements in a scheduler’s job file become static, set-and-forget characteristics.
The technical undertaking to continuously test, size, and re-test each application is non-trivial and time consuming. Developers often have little visibility, capacity, or incentive to size applications to their true, efficient levels of resource consumption. Operators, who are responsible for capacity and spend, face the difficult decision of controlling cost at the expense of development velocity or vice versa.
Dynamic Application Sizing monitors Nomad jobs, tracks their resource usage, and right-sizes applications to their most efficient levels of resource consumption through recommendations based on analysis of historical data. Application sizing can be customized to each enterprise’s needs from the frequency of recommendations to the sizing strategies themselves.
Namespaces (OSS): This feature enables jobs and their associated objects to be segmented from each other and other users to achieve multi-tenant clusters. This Enterprise feature is now available in open source.
Event Stream: View and subscribe to a single unified timeline that streams all high-level events to better understand how the Nomad cluster is performing. Observe state changes that occur at the Job, Allocation, Evaluation, Deployment, and Node levels in Nomad in real-time for stronger tracing and debuggability.
HCL2: Add powerful new expressibility into Nomad job files with the newest version of the HashiCorp Configuration Language (HCL2) syntax. With the addition of variables, functions, templating, and expression support, users can create dynamic and flexible configurations to adapt their Nomad job files to a range of internal needs within their organizations.
Dynamic Envoy Versioning: At runtime, Nomad will now query Consul locally to launch the Connect sidecar proxy task with the latest supported version of Envoy by default. This feature ensures people using Nomad and Consul together will always have a current, first-class compatibility that starts at the node level rather than the cluster.
CNI Improvements: IP addresses created via CNI or multi-host networks can now be exposed and registered directly with Consul.
Consul Namespace: Users on Consul Enterprise can now configure a single Nomad cluster to support a single Consul namespace.
Topology Visualization (UI): See all datacenter, node, and allocation information and their resource utilization in a Nomad cluster with this new UI feature. Users can utilize this to intuitively understand cluster capacity, observe how application deployments are distributed across nodes, and proactively identify suboptimal collocations of allocations to lower blast radius in node failures.
As we progress to general availability of Nomad 1.0 in the coming weeks, we’ll publish a series of blog posts from Nomad Engineering with technical deep dives for select features.
Here’s a recap of all things Nomad released in the past few weeks:
We invite you to download Nomad 1.0 beta and test these new features in your development or testing environments in advance of our GA release. For more information about Nomad 1.0, visit product docs. If you’re interested in Dynamic Application Sizing, you can start a free enterprise trial here.
We're excited about reaching 1.0 and are eager to see how these new features enhance your core Nomad experience. If you encounter any issues, please file a bug report in GitHub. For other questions, join our Discuss forums and get answers from the community and development team directly.
Visit HashiCorp Learn for our collection of new tutorials for Nomad 1.0.
On behalf of the Nomad team, thank you to our community! Your dedication and feedback help us make Nomad better. We are grateful for your time, passion, and support.
Learn the installation and verification workflow for any Linux distribution that does not include HashiCorp software in its package repository.
Learn how JWT-based authentication works in HashiCorp Nomad using a custom GitHub Action as an example of machine-to-machine authentication.
Managing multiple clusters of HashiCorp tools can be complicated. Target CLI eases the burden by using context profiles to easily switch between different clusters and environments.