mirror of
https://github.com/kemko/nomad.git
synced 2026-01-04 09:25:46 +03:00
53b083b8c5
* Move commands from docs to its own root-level directory * temporarily use modified dev-portal branch with nomad ia changes * explicitly clone nomad ia exp branch * retrigger build, fixed dev-portal broken build * architecture, concepts and get started individual pages * fix get started section destinations * reference section * update repo comment in website-build.sh to show branch * docs nav file update capitalization * update capitalization to force deploy * remove nomad-vs-kubernetes dir; move content to what is nomad pg * job section * Nomad operations category, deploy section * operations category, govern section * operations - manage * operations/scale; concepts scheduling fix * networking * monitor * secure section * remote auth-methods folder and move up pages to sso; linkcheck * Fix install2deploy redirects * fix architecture redirects * Job section: Add missing section index pages * Add section index pages so breadcrumbs build correctly * concepts/index fix front matter indentation * move task driver plugin config to new deploy section * Finish adding full URL to tutorials links in nav * change SSO to Authentication in nav and file system * Docs NomadIA: Move tutorials into NomadIA branch (#26132) * Move governance and policy from tutorials to docs * Move tutorials content to job-declare section * run jobs section * stateful workloads * advanced job scheduling * deploy section * manage section * monitor section * secure/acl and secure/authorization * fix example that contains an unseal key in real format * remove images from sso-vault * secure/traffic * secure/workload-identities * vault-acl change unseal key and root token in command output sample * remove lines from sample output * fix front matter * move nomad pack tutorials to tools * search/replace /nomad/tutorials links * update acl overview with content from deleted architecture/acl * fix spelling mistake * linkcheck - fix broken links * fix link to Nomad variables tutorial * fix link to Prometheus tutorial * move who uses Nomad to use cases page; move spec/config shortcuts add dividers * Move Consul out of Integrations; move namespaces to govern * move integrations/vault to secure/vault; delete integrations * move ref arch to docs; rename Deploy Nomad back to Install Nomad * address feedback * linkcheck fixes * Fixed raw_exec redirect * add info from /nomad/tutorials/manage-jobs/jobs * update page content with newer tutorial * link updates for architecture sub-folders * Add redirects for removed section index pages. Fix links. * fix broken links from linkcheck * Revert to use dev-portal main branch instead of nomadIA branch * build workaround: add intro-nav-data.json with single entry * fix content-check error * add intro directory to get around Vercel build error * workound for emtpry directory * remove mdx from /intro/ to fix content-check and git snafu * Add intro index.mdx so Vercel build should work --------- Co-authored-by: Tu Nguyen <im2nguyen@gmail.com>
128 lines
5.2 KiB
Plaintext
128 lines
5.2 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Glossary
|
|
description: Nomad key concepts include allocation, authoritative regions, bin packing, client, datacenters, deployment, driver, evaluation, job, node, node pool, regions, server, task, and task group.
|
|
---
|
|
|
|
# Glossary
|
|
|
|
This glossary provides definitions and explanations for important terms and
|
|
concepts used in Nomad.
|
|
|
|
## 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.
|
|
|
|
## Authoritative and Non-Authoritative Regions
|
|
|
|
The authoritative region is the region in a federated multi-region cluster that
|
|
holds the source of true for entities replicated across regions, such as ACL
|
|
tokens, policies, and roles, namespaces, and node pools.
|
|
|
|
All other regions are considered non-authoritative regions and replicate these
|
|
entities by pulling them from the authoritative region.
|
|
|
|
## Bin Packing
|
|
|
|
Bin Packing is the process of filling bins with items in a way that maximizes
|
|
the utilization of bins. This extends to Nomad, where the clients are "bins"
|
|
and the items are task groups. Nomad optimizes resources by efficiently bin
|
|
packing tasks onto client machines.
|
|
|
|
## Client
|
|
|
|
A Nomad client is an agent configured to run and manage tasks using available
|
|
compute resources on a machine. The agent is responsible for registering with
|
|
the servers, watching for any work to be assigned and executing tasks. The
|
|
Nomad agent is a long lived process which interfaces with the servers.
|
|
|
|
## Datacenters
|
|
|
|
Nomad models a datacenter as an abstract grouping of clients within a
|
|
region. Nomad clients are not required to be in the same datacenter as the
|
|
servers they are joined with, but do need to be in the same
|
|
region. Datacenters provide a way to express fault tolerance among jobs as
|
|
well as isolation of infrastructure.
|
|
|
|
## Deployment
|
|
|
|
Deployments are the mechanism by which Nomad rolls out changes to cluster state
|
|
in a step-by-step fashion. Deployments are only available for Jobs with the type
|
|
`service`. When an Evaluation is processed, the scheduler creates only the
|
|
number of Allocations permitted by the [`update`][] block and the current state
|
|
of the cluster. The Deployment is used to monitor the health of those
|
|
Allocations and emit a new Evaluation for the next step of the update.
|
|
|
|
## Driver
|
|
|
|
A Driver represents the basic means of executing your **Tasks**. Example
|
|
Drivers include Docker, QEMU, Java, and static binaries.
|
|
|
|
## 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.
|
|
|
|
## Job
|
|
|
|
A Job is a specification provided by users that declares a workload for
|
|
Nomad. A Job is a form of _desired state_; the user is expressing that the
|
|
job should be running, but not where it should be run. The responsibility of
|
|
Nomad is to make sure the _actual state_ matches the user desired state. A
|
|
Job is composed of one or more task groups.
|
|
|
|
## Node
|
|
|
|
A more generic term used to refer to machines running Nomad agents in client
|
|
mode. Despite being different concepts, you may find `node` being used
|
|
interchangeably with [`client`](#client) in some materials and informal
|
|
content.
|
|
|
|
## Node Pool
|
|
|
|
Node pools are used to group [nodes](#node) and can be used to restrict which
|
|
[jobs](#job) are able to place [allocations](#allocation) in a given set of
|
|
nodes. Example use cases for node pools include segmenting nodes by environment
|
|
(development, staging, production), by department (engineering, finance,
|
|
support), or by functionality (databases, ingress proxy, applications).
|
|
|
|
## Regions
|
|
|
|
Nomad models infrastructure as regions and datacenters. A region will contain
|
|
one or more datacenters. A set of servers joined together will represent a
|
|
single region. Servers federate across regions to make Nomad globally aware.
|
|
|
|
In federated clusters one of the regions must be defined as the [authoritative
|
|
region](#authoritative-and-non-authoritative-regions).
|
|
|
|
## Server
|
|
|
|
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. More information about latency
|
|
requirements for servers can be found in [Network
|
|
Topology](/nomad/docs/deploy/production/requirements#network-topology).
|
|
|
|
## Task
|
|
|
|
A Task is the smallest unit of work in Nomad. Tasks are executed by drivers,
|
|
which allow Nomad to be flexible in the types of tasks it supports. Tasks
|
|
specify their driver, configuration for the driver, constraints, and resources
|
|
required.
|
|
|
|
## 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.
|
|
|
|
[`update`]: /nomad/docs/job-specification/update
|