Nomad is a personal favorite when I need a straightforward, single-binary orchestrator that just works. Its built by HashiCorp, the folks behind Terraform and Vault, and it takes a minimalistic approach to scheduling and managing containerized (and even non-containerized) workloads. Nomad might be the perfect fit if youve ever felt that Kubernetes is overkill for a simpler workload.
In this post, Ill walk you through installing Nomad, spinning it up in a small environment, and running a workload to see it in action. By the end, youll have a solid hands-on feel for how to use Nomad. Lets dive right in.
Why Nomad?
For me, Nomad offers a couple of killer advantages:
Simplicity : Nomad is a single, self-contained binary that can manage containers, VMs, and standalone applications. Configuration is straightforward and uses HCL (HashiCorp Configuration Language), which you might already know from Terraform.
Low Overhead : In contrast to something like Kubernetes, which demands multiple components (etcd, kube-scheduler, kube-apiserver, etc.), Nomad keeps the architecture lean, meaning fewer moving parts and less operational complexity.
Scale Without the Bloat : Just because its simple doesnt mean its small-time. Nomad can run at massive scale. Start small on a single node, then grow into a cluster as your needs evolve.
Broad Workload Support : Containerized apps are the norm these days, but if you have legacy apps or specialized workloads, Nomad accommodates them too. This flexibility makes it easier to transition older systems into orchestrated environments without rewriting everything.
Setting Up Nomad Locally
Lets talk about setting up a Nomad environment on your local machine for a quick test. Ill assume youre running on some flavor of Linux or macOS. If youre on Windows, you can still follow along using WSL2 or a VM.
Download Nomad
Head over to the official Nomad Releases page and download the appropriate binary. Extract it, move it to a directory in your PATH (like/usr/local/bin), and youre good to go. For instance:Development Agent
Nomad has a dev mode, which is a single-process setup that runs the server and client in one goperfect for local testing. Simply run:
Nomad Architecture at a Glance
In a more robust setup, Nomad is typically deployed as a cluster of server nodes and client nodes:
Server nodes handle scheduling decisions and maintain cluster state.
Client nodes run workloads assigned to them by the servers.
But for now, dev mode is all we need. Later on, you could spin up a 3-node server cluster with as many clients as you want.
Running Your First Nomad Job
A Nomad job describes what you want to run, how many instances, resource constraints, etc. Jobs are written in HCL, so itll feel familiar if youve ever used Terraform. Lets do a quick example by running a Docker-based web server.
Basic HCL Job File
Create a file called nginx.nomad:
job "nginx-web" { datacenters = ["dc1"] type = "service" group "web-group" { count = 1 task "web" { driver = "docker" config { image = "nginx:latest" ports = ["http"] } resources { cpu = 100 memory = 128 } } network { port "http" { static = 8080 } } }}
Lets break it down:
job "nginx-web" : Defines our job name and type. Were calling it a service because its a long-running service.
group "web-group" : A group can contain multiple tasks that share resources and networking. Here, we only have one task.
task "web" : Tells Nomad to run an Nginx container. We specify the docker driver.
network : Maps the containers port to a static host port (8080 in this case) so you can access it on
localhost:8080.
Run the Job
Launch it with:
nomad job run nginx.nomad
Nomad will parse the file, create the job, and schedule it on the local dev client. If all goes well, youll see output indicating the job has been placed.
Verify Its Running
Head to your browser at http://localhost:4646 and click on Jobs. You should see nginx-web running. Now try http://localhost:8080 in your browser. Nginxs default Welcome page means its working!
Scaling the Service
Nomad makes scaling super easy. Just update the count parameter in your job file. For instance, change it to:
count = 2
Then run:
nomad job run nginx.nomad
Nomad will place an additional instance of the container, though in dev mode youre still on a single node, so youll have multiple containers on the same host. In a multi-node cluster, Nomad automatically figures out which clients have room.
Stopping or Updating the Job
If you want to stop the job, you can run:
nomad job stop nginx-web
For updates, just modify the HCL file (like changing the Docker image to a different version), then re-run nomad job run nginx.nomad. Nomad will handle rolling updates gracefully, spinning up new tasks before shutting down old ones (as long as you specify appropriate update stanzas).
Integrating with Other HashiCorp Tools
Because Nomad shares the same style of configuration as Terraform and the same developer DNA as Vault and Consul, its easy to create an entire stack:
Consul for service discovery and dynamic DNS.
Vault for secrets management.
Terraform for provisioning the underlying infrastructure.
Nomad can automatically register services with Consul, making them discoverable to other services in your environment. Storing secrets in Vault means you can dynamically inject credentials into your Nomad jobs. It all plays nicely together.
Why I Use Nomad Over Alternatives
Ive used Kubernetes for years, but Nomad is my go-to when:
Speed of Setup : Nomad dev mode is unbelievably quick. One binary, one command, done.
Fewer Dependencies : I dont need etcd or a separate container runtime beyond Docker. Less to break, less to learn.
Flexibility : I can run Docker tasks, raw exec tasks, or even handle batch jobs and system workloads in a single cluster.
Dont get me wrong Kubernetes excels in large, complex ecosystems. But if you want a more lightweight orchestrator or have a hybrid mix of containerized and legacy apps, Nomads a breath of fresh air.
Pro Tips (Anticipating What You Might Need Next)
High Availability : If you plan to run in production, spin up at least three Nomad server nodes. That ensures if one server goes down, the cluster can still schedule workloads.
Autopilot : Nomads built-in autopilot features let you automatically manage upgrades, Raft snapshots, and more to keep the cluster healthy.
Authentication and ACLs : In a multi-user setup, you can integrate Nomads ACL system to restrict who can submit jobs or read cluster data.
Plugins : There are driver plugins for everything from Docker to QEMU to AWS ECS tasks. You can run basically anything that can be launched from a command line or third-party tool.
Monitoring : Nomad exposes metrics that are easy to integrate with Prometheus, Grafana, or whatever your favorite monitoring stack is.
Final Thoughts
Nomad may look unassuming as a single binary, but dont let that fool you. Its a robust orchestrator that simplifies complex workload management. Whether youre prototyping a new service, gradually migrating from manual server management, or just want to avoid the overhead of a full-fledged Kubernetes stack, Nomad can handle it.
Why not give it a shot in your own environment? If youve got that messy monolith or a small container workload, Nomad might be exactly the tool you need to keep everything running smoothly without drowning in complexity.
Sources
Hope this helps you get started with Nomad. Let me know if you run into any snags or come up with a clever integration Im always interested in new ways to push this awesome orchestrator.
]]>
Top comments (0)