Supporting Multiple Teams on a Single Nomad Cluster
This demo walks through an example use case where multiple teams in a large enterprise need to use a centrally managed Nomad cluster for workload orchestration across a hybrid infrastructure.
Senior Solutions Engineer, HashiCorp
When multiple teams need to employ workflow orchestration for their application deployments across a heterogeneous infrastructure, a popular tool for this is the cluster scheduler. But how do all of those teams use a scheduler and comply with IT requirements without having to use outdated ticket-based methods?
Nomad Enterprise is a massively scalable scheduler with several features that allow IT departments to centralize server fleet resource management. The "guardrail" features of Nomad Enterprise that enable a more modern self-service deployment workflow by all of these teams include:
- ACLs (Access Control Lists): Control who is allowed to deploy resources, and the types and numbers of resources they are allowed to deploy.
- Namespaces: Prevent scheduling conflicts with other teams and allow separated team management and rules within the same cluster.
- Resource quotas: Restrict the aggregate resources that each namespace can use in each region.
- Policy code: Use HashiCorp's policy as code language, Sentinel, to make more granular, logic-based restrictions on resource deployment such as:
- The types of jobs or drivers individuals can use
- Some very specific situations they are allowed to deploy in
- And much more
In this demo, solutions engineer Roger Berlind will showcase all of these features in a scenario with 1 Nomad server, 3 Nomad clients in AWS, 2 teams (Dev and QA), and 2 users that are about to collide in their deployments.
0:00 — Brief overview of Nomad
3:54 — Key Nomad features that allow teams to share clusters
8:28 — Demo: Using ACLs, namespaces, quotas, and Sentinel policies to manage multiple teams on a single Nomad cluster
27:41 — Q&A
» Additional resources
- GitHub repo for this demo (Note: You will need a Nomad Enterprise free trial)
- Companion blog post for this hangout
- Are these all Enterprise only features?
- Namespaces, Sentinel, and resource quotas are enterprises only.*
- How does Nomad compare and differ from Kubernetes?
- They are both orchestration tools, Nomad has less bells and whistles making it easier to install and operate. Additionally, it is technology agnostic, being able to deploy containers, JARs, executables, and others.*
- Are their any plans to have access to Sentinel, namespaces, and quotas on Nomad OSS?
- No, these are enterprise problems and require enterprise solutions.*
- This is only one cluster, could I have multiple clusters connected?
- There is more than one way to do this, you can have multiple clusters connected as different Datacenters and Regions(Federation)*
- How could you integrate Nomad with Vault and Consul?
- If you have Consul running on the same node, the integration is native, or you can configure Vault and Consul in the Nomad configuration file. Using Vault and Consul is done via the jobfile itself.*
- Are there any plans to have job-level ACLs? (For Example: “I want to give access to these jobs but not these”)
- How do I enable auto complete on Nomad and is it available in Open Source or just Enterprise?
- nomad -autocomplete-install*
- Do you have to run commands from the Nomad server or can they be remote?
- You can run commands remotely via APIs*
- How does Consul Connect integrate with Nomad?
- Native integration— It's a roadmap feature, it is coming soon. Currently, Consul Connect can be done via a script initializing the proxy and calling it as a job from your tasks.*
- How are the TLS configurations dynamically reloaded in Nomad?
- Typically, at which point in their Nomad adventures do you typically see companies moving from Nomad OSS to Nomad Entreprise?