What is Nomad?
Who uses Nomad?
Here are some stack decisions, common use cases and reviews by companies and developers who chose Nomad in their tech stack.
Our backend consists of two major pools of machines. One pool hosts the systems that run our site, manage jobs, and send notifications. These services are deployed within Docker containers orchestrated in Kubernetes. Due to Kubernetes’ ecosystem and toolchain, it was an obvious choice for our fairly statically-defined processes: the rate of change of job types or how many we may need in our internal stack is relatively low.
The other pool of machines is for running our users’ jobs. Because we cannot dynamically predict demand, what types of jobs our users need to have run, nor the resources required for each of those jobs, we found that Nomad excelled over Kubernetes in this area.
We’re also using Helm to make it easier to deploy new services into Kubernetes. We create a chart (i.e. package) for each service. This lets us easily roll back new software and gives us an audit trail of what was installed or upgraded.
- Handles the scheduling and upgrading of the applications over time
- With built-in dry-run execution, Nomad shows what scheduling decisions it will take before it takes them. Operators can approve or deny these changes to create a safe and reproducible workflow
- Nomad runs applications and ensures they keep running in failure scenarios. In addition to long-running services, Nomad can schedule batch jobs, distributed cron jobs, and parameterized jobs
- Stream logs, send signals, and interact with the file system of scheduled applications. These operator-friendly commands bring the familiar debugging tools to a scheduled world