clusters

agent

A Nomad agent is a Nomad process running in server or client mode. Agents are the basic building block of a Nomad cluster.

dev agent

A Nomad development agent is a special configuration that provides useful defaults for running experiments with Nomad. It runs in server and client mode and does not persist its cluster state to disk, which allows your agent to start from a repeatable clean state without having to remove disk based state between runs.

client mode

Client agents are responsible for registering themselves with the servers, watching for any work to be assigned, and executing tasks. Clients create a multiplexed connection to the servers. This enables topologies that require NAT punch-through. Once connected, the servers use this connection to forward RPC calls to the clients as necessary.

server mode

Nomad servers are the brains of the cluster. There is a cluster of servers per region and they manage all jobs and clients, run evaluations, and create task allocations. The servers replicate data between each other and perform leader election to ensure high availability. Servers federate across regions to make Nomad globally aware. All servers in a region are members of the same gossip domain and consensus group.

leader server

The leader is a Nomad server that performs the bulk of the cluster management. It is in charge of applying plans, deriving Vault tokens for the workloads, and maintaining the cluster state.

follower server

Non-leader Nomad servers. Followers create scheduling plans and submit them to the leader to provide more scheduling capacity to the cluster.

objects

job

A job defines one or more task groups which contain one or more tasks.

job specifications

The Nomad job specification (or "jobspec" for short) defines the schema for Nomad jobs. This describes the type of the job, the tasks and resources necessary for the job to run, and also includes additional job information (like constraints, spread, autoscaler policies, Consul service information, and more).

task group

A task group is a set of tasks that must be run together. For example, a web server may require that a log shipping co-process is always running as well. A task group is the unit of scheduling, meaning the entire group must run on the same client node and cannot be split. A running instance of a task group is an allocation.

task driver

A task driver represents the basic means of executing your tasks. Nomad provides several built-in task drivers: Docker, QEMU, Java, and static binaries. Nomad also allows for third-party task drivers through its pluggable architecture.

task

A task is the smallest unit of work in Nomad. Tasks are executed by task drivers, which allow Nomad to be flexible in the types of tasks it supports. Tasks specify their required task driver, configuration for the driver, constraints, and resources required.

allocation

An allocation is a mapping between a task group in a job and a client node. A single job may have hundreds or thousands of task groups, meaning an equivalent number of allocations must exist to map the work to client machines. Allocations are created by the Nomad servers as part of scheduling decisions made during an evaluation.

evaluation

Evaluations are the mechanism by which Nomad makes scheduling decisions. When either the desired state (jobs) or actual state (clients) changes, Nomad creates a new evaluation to determine if any actions must be taken. An evaluation may result in changes to allocations if necessary.

scheduling

bin packing

Bin packing is an algorithm that gets its name from the real world exercise of arranging irregularly sized objects into boxes or bins. The bin packing algorithm attempts to create the most-dense arrangement of objects thereby using the fewest boxes. In Nomad's case, these objects are deployed allocations. Bin packing benefits people who are using metered-billing platforms by consolidating the utilization and highlighting over-provisioning which could then be reduced.

spread scheduling

Spread scheduling is the opposite of bin packing. The goal of spread scheduling is to distribute as level a load as possible across a fleet of machines. This scheduling algorithm is best for people who have on-premises datacenters or committed nodes that they are already invested in.