Nomad
job Block
Placement | job |
The job
block is the top-most configuration option in the job specification.
A job is a declarative specification of tasks that Nomad should run. Jobs have
one or more task groups, which are themselves collections of one or more tasks.
Job names are unique per region or namespace.
job "docs" {
constraint {
# ...
}
datacenters = ["us-east-1"]
node_pool = "prod"
group "example" {
# ...
}
meta {
my-key = "my-value"
}
parameterized {
# ...
}
periodic {
# ...
}
priority = 100
region = "north-america"
task "docs" {
# ...
}
update {
# ...
}
}
job
Parameters
all_at_once
(bool: false)
- Controls whether the scheduler can make partial placements if optimistic scheduling resulted in an oversubscribed node. This does not control whether all allocations for the job, where all would be the desired count for each task group, must be placed atomically. This should only be used for special circumstances.constraint
(Constraint: nil)
- This can be provided multiple times to define additional constraints. See the Nomad constraint reference for more details.affinity
(Affinity: nil)
- This can be provided multiple times to define preferred placement criteria. See the Nomad affinity reference for more details.spread
(Spread: nil)
- This can be provided multiple times to define criteria for spreading allocations across a node attribute or metadata. See the Nomad spread reference for more details.datacenters
(array<string>: ["*"])
- A list of datacenters in the region which are eligible for task placement. This field allows wildcard globbing through the use of*
for multi-character matching. The default value is["*"]
, which allows the job to be placed in any available datacenter.node_pool
(string: <optional>)
- Specifies the node pool to place the job in. The node pool must exist when the job is registered. Defaults to"default"
.group
(Group: <required>)
- Specifies the start of a group of tasks. This can be provided multiple times to define additional groups. Group names must be unique within the job file.meta
(Meta: nil)
- Specifies a key-value map that annotates with user-defined metadata.name
(string: <optional>)
- Specifies a name for the job, which otherwise defaults to the job ID.migrate
(Migrate: nil)
- Specifies the groups strategy for migrating off of draining nodes. If omitted, a default migration strategy is applied. Only service jobs with a count greater than 1 support migrate blocks.namespace
(string: "default")
- The namespace in which to execute the job. Prior to Nomad 1.0 namespaces were Enterprise-only.parameterized
(Parameterized: nil)
- Specifies the job as a parameterized job such that it can be dispatched against.periodic
(Periodic: nil)
- Allows the job to be scheduled at fixed times, dates or intervals.priority
(int: 50)
- Specifies the job priority which is used to prioritize scheduling and access to resources. Must be between 1 andjob_max_priority
inclusively, with a larger value corresponding to a higher priority. If value 0 is provided this will fallback tojob_default_priority
. Priority only has an effect when job preemption is enabled. It does not have an effect on which of multiple pending jobs is run first.region
(string: "global")
- The region in which to execute the job.reschedule
(Reschedule: nil)
- Allows to specify a rescheduling strategy. Nomad will then attempt to schedule the task on another node if any of its allocation statuses become "failed".type
(string: "service")
- Specifies the Nomad scheduler to use. Nomad provides theservice
,system
,batch
, andsysbatch
(new in Nomad 1.2) schedulers.update
(Update: nil)
- Specifies the task's update strategy. When omitted, a default update strategy is applied.vault
(Vault: nil)
- Specifies the set of Vault policies required by all tasks in this job.vault_token
(string: "")
- Specifies the Vault token that proves the submitter of the job has access to the specified policies in thevault
block. This field is only used to transfer the token and is not stored after job submission.It is strongly discouraged to place the token as a configuration parameter like this, since the token could be checked into source control accidentally. Users should set the
VAULT_TOKEN
environment variable when running the job instead.consul_token
(string: "")
- Specifies the Consul token that proves the submitter of the job has access to the Service Identity policies associated with the job's Consul Connect enabled services. This field is only used to transfer the token and is not stored after job submission.It is strongly discouraged to place the token as a configuration parameter like this, since the token could be checked into source control accidentally. Users should set the
CONSUL_HTTP_TOKEN
environment variable when running the job instead.
job
Examples
The following examples only show the job
blocks. Remember that the
job
block is only valid in the placements listed above.
Docker Container
This example job starts a Docker container which runs as a service. Even though the type is not specified as "service", that is the default job type.
job "docs" {
group "example" {
task "server" {
driver = "docker"
config {
image = "hashicorp/http-echo"
args = ["-text", "hello"]
}
resources {
memory = 128
}
}
}
}
Batch Job
This example job executes the uptime
command on 10 Nomad clients in the fleet,
restricting the eligible nodes to Linux machines.
job "docs" {
type = "batch"
constraint {
attribute = "${attr.kernel.name}"
value = "linux"
}
group "example" {
count = 10
task "uptime" {
driver = "exec"
config {
command = "uptime"
}
}
}
}
Consuming Secrets
This example shows a job which retrieves secrets from Vault and writes those secrets to a file on disk, which the application then consumes. Nomad handles all interactions with Vault.
job "docs" {
group "example" {
task "cat" {
driver = "exec"
config {
command = "cat"
args = ["local/secrets.txt"]
}
template {
data = "{{ secret \"secret/data\" }}"
destination = "local/secrets.txt"
}
vault {
policies = ["secret-readonly"]
}
}
}
}
When submitting this job, you would run:
$ VAULT_TOKEN="..." nomad job run example.nomad.hcl