Easy and Flexible Application Deployment with HashiCorp Nomad

Editor's Notes

• #2: Thanks Amanda! Hello to everybody on the line. As Amanda mentioned, I’d like to spend a few minutes going over how the HashiCorp product portfolio fits together and also give a brief technical overview of Nomad before we jump into Nic's demo.
• #3: HashiCorp has been around for almost six years. We have found that as organizations move from monolithic applications running on dedicated infrastructure to service-oriented applications running across multiple cloud providers, there are a common set of challenges that are encountered. HashiCorp's mission is to enable a consistent set of workflows as organizations make this transition and to do so with a suite of products that have well-defined scope and are loosely coupled but elegantly integrate with each other to form a solid/complete solution rather than taking an all-in-one platform type approach. Our four primary products - Terraform, Vault, Consul and Nomad together enable an organization to provision, secure, connect and run any infrastructure for any application (respectively).
• #4: So, I am going to quickly introduce each of the products at a high level in case anyone on the call isn't familiar. Starting from the bottom of the slide. Terraform provides a common infrastructure provisioning workflow across private cloud, public cloud and external services with built-in dependency management and an "as code" approach. Moving up the stack, Vault enables a unified secrets management workflow across cloud providers and identity sources. Consul provides a backbone that more-or-less enables an organization to connect, configure and monitor their services across data centers and regions. Consul is widely used today for service discovery and dynamic configuration, for example. And finally, Nomad enables a common workflow for both container-based and legacy application deployment. And again - like the other products - it does so in a way that elegantly spans both private infrastructure and public cloud providers.
• #5: The enterprise versions of the products add collaboration, operations and governance features that help organizations address the challenges that arise as the scale and complexity of their internal operational platform increases.
• #6: So, Nomad is HashiCorp’s scheduler and application deployment tool. The product niche that it fits into is often referred to as container management or container orchestration. It is the newest of the four primary HashiCorp products and was designed first and foremost in accordance with HashiCorp principles. It is workflow oriented. It is simple and modular, and can be easily combined with our other tools to solve the wider challenges. But in many ways Nomad’s design was also a response to the operational challenges and the lack of flexibility that we observed with some of the other container management tools.
• #7: At a high level, Nomad’s goal is to enable an organization to easily run any application on any infrastructure at any scale with the characteristics listed here. Nomad is easy to learn; it has a very simple mental model. It’s easy to use for both developers and operators. Nomad is flexible and can be easily integrated into your existing workflows. It supports all workload types. Nomad is dead simple to federate across regions and cloud providers. It is also easy to scale and elegantly integrates with other HashiCorp tooling.
• #8: Lets cover how Nomad works at a high level before we turn it over to Nic. Nomad uses a simple client/server architecture. The servers handle application placement across a set of client nodes, optimizing for resource efficiency and accounting for the defined priority and constraints. From a workflow perspective, Nomad enables a user to define the deployment requirements for an application which can then be submitted to any server.
• #9: Nomad’s job specification is declarative and uses the HashiCorp Configuration Language (HCL) which will be familiar to any Terraform users. The job spec defines the deployment schema for the application and includes the task definition, the driver (which may or may not be Docker), the image, resource reservations, job priority, constraints, service registrations and any other information required to deploy the application. I’ll go over the job spec in more detail in a few minutes.
• #10: From an operational perspective, Nomad consists of a single binary that can run in either client or server mode. Three or more servers form a highly available control plane to handle scheduling. The servers store state internally and use a Raft-based consensus protocol for state replication and automatic leader election. This makes Nomad highly available out of the box. There is no etcd or Zookeeper external dependency. The clients register with the servers, wait for work to be assigned and execute tasks. A single, logical cluster defines a region which can contain multiple data centers.
• #11: Multiple regions can be easily federated together with a single CLI command. Nomad natively uses a gossip protocol for cross region cluster membership and failure detection. Work can be scheduled across the region boundary.
• #12: As mentioned earlier, Nomad stores and replicates state internally across all servers. This architecture enables an optimistically concurrent and parallelized scheduling strategy that can yield thousands of job placements per second (a key advantage for batch processing workloads).
• #13: I am going to finish up by quickly running through the job spec in a bit more detail. A job can be submitted to exactly one region but can request placement across multiple data centers within that region.
• #14: Type indicates whether the job is a service, a batch job or a system job. System jobs run on every node automatically.
• #15: The group stanza defines a series of tasks that should be co-located on the same Nomad client. This is similar to a pod in Kubernetes.
• #16: The task stanza defines an individual unit of work, such as a web application or a batch processing task.
• #17: The task stanza includes the driver and the image (next slide)
• #18: .. as well as the resource requirements for the task.
• #19: Constraints limit placement based on client properties or metadata and can be specified at the job, group or task levels.
• #20: Priority can be specified at the job level. Higher priority jobs will be sorted the top of the evaluation and planning queues for scheduling.
• #21: The env stanza can be used to populate the task's environment before starting.
• #22: The periodic stanza allows a job to run at fixed times, dates, or intervals (similar to cron).
• #23: The update stanza can be used to perform rolling, canary-based or blue/green job updates. Updates can be gated on Consul health check status and automatically reverted. Nic will be demonstrating updates as part of the demo.
• #24: There are a couple of different ways that Nomad integrates with Consul. The service stanza in the job spec can be used to register services and health checks in Consul. The template stanza can be used to update configuration files and environment variables in a running task based on Consul KV data. This feature uses consul-template under the hood. A Nomad cluster can also be automatically bootstrapped if a Consul deployment already exists.
• #25: And finally, Nomad supports a first-class Vault-based workflow for secrets retrieval. The vault stanza in the job spec allows a task to specify that it requires a token from an existing instance of Vault. Nomad will automatically retrieve a Vault token for the task upon job placement. The template stanza can be used for automatic secret renewal and re-rendering of configuration files (or updating environment variables).