Separating Practitioner Concerns From the Toolset: Using Nomad to Get Work Done

The scale of our environments requires that we know our deployment footprint and how to optimize resource utilization for it. Leveraging Nomad's architecture can simplify infrastructure complexities so you can optimize the 'where and how' of applications running in your server fleet and third-party clouds.

Nomad is a scheduler—an orchestration tool concerned with service architectures. It provides configuration, coordination, and management of those architectures with one simple workflow for developers to deploy containerized and non-containerized workflows efficiently.

So when do you want to consider a tool like Nomad? In this video, HashiCorp solutions engineer Josh Jordan points out four contexts that are ripe for Nomad:

• High Availability (HA): Not just having it, but leveraging it strategically for the business.
• Efficient Resource Utilization: Bin packing your containers or VMs so you get the most for your money.
• Hybrid IT Environments: Most companies still aren't using a bunch of containers, which means that a tool like Nomad, which can manage VMs, containers, and Kubernetes clusters all with one workflow, is a helpful utility.
• Dependencies: Nomad has frictionless integration with Consul, Vault, and the major cloud vendors along with their services.

All of these contexts will be on full display in this demo using HA services in a hybrid infrastructure environment.

Here's the GitHub repo so you can follow along.

Outline

0:00 — Introduction to Nomad contexts

9:35 — Demo: HA services in a hybrid ecosystem

26:05 — Q&A

Q&A

• Does Nomad route traffic to services via % allocations when doing canary deployments? (unanswered in the hangout but answered here)

The short answer is no because a canary deployment is intended to create predictability in service deployments to infrastructure; however, Nomad doesn't get in your way if you want to do A/B testing for services you deploy. You would need to leverage your router, proxy, etc to do it. NGINX supports A/B configurations when routing to services.

• Are there issues running Nomad with Vagrant vs Docker? (unanswered in the hangout but answered here)

I may have misunderstood the question, but I believe this was a reference to running Nomad in Vagrant or Docker, to which I'm not aware of any issues other than you probably don't want to do either of these for production. You could run your servers in either, but definitely not the clients. Following the deployment architecture is always recommended.

If the question pertained to running Vagrant or Docker as a driver, the answer is not concise.

Docker is one of the supported Nomad Drivers, Vagrant is not.

I've never tried it, but you may be able to leverage the Raw Exec driver to run Vagrant without isolation and map its port config to Nomad's port listing as a static port. Seems experimental, but I'd love to hear what you find out.

We are bringing Driver plugins to Nomad 0.9, so you may be able to write your own Vagrant driver in the future, but I'm not sure what the constraints are to confirm this at present.

• Does Nomad support rebalancing containers throughout nodes? For example, if some nodes go down and new ones come up, will the containers will be spread out evenly?
• What happens to Nomad clients if servers are unavailable for a period of time and then they come back after a while?
• Can you put limits on the amount of memory resources used per job with Nomad?
• Is there a way to limit teams to run jobs only on certain clients in the open source version of Nomad?
• How does Nomad differ from Kubernetes? (Comparison article, more commentary)
• In canary deployments can we establish in Nomad the amount of traffic through blue or green deployments? Yes, is a routing question.

Slides