Some settings you specify in your job specification are passed to tasks when they start. Other settings are dynamically allocated when your job is scheduled. Both types of values are made available to your job through environment variables.
|The path to the shared |
|The path to the task |
|Path to the task's secrets directory. See here for more information.|
|Memory limit in MB for the task|
|The maximum memory limit the task may use if client has excess memory capacity, in MB. Omitted if task isn't configured with memory oversubscription.|
|CPU limit in MHz for the task|
|Allocation ID of the task|
|Allocation name of the task|
|Allocation index; useful to distinguish instances of task groups. From 0 to (count - 1). The index is unique within a given version of a job, but canaries or failed tasks in a deployment may reuse the index.|
|Job's ID, which is equal to the Job name when submitted through CLI but can be different when using the API|
|ID of the Job's parent if it has one|
|Datacenter in which the allocation is running|
|Namespace in which the allocation is running|
|Region in which the allocation is running|
|The metadata value given by |
|The task's Vault token. See Vault Integration for more details|
|Host IP for the given port |
|Port for the given port |
|Port on the host for the port |
|Deprecated. Host IP for the given port |
|Deprecated. Port for the given port |
|Deprecated. Host |
|Deprecated. Port on the host for the port |
|IP for the given |
|Port for the given |
|Local address |
|Local address |
|Consul-related Variables (only set for connect native tasks)|
|Specifies the address to the local Consul agent. Will be automatically set to a unix domain socket in bridge networking mode, or a tcp address in host networking mode.|
|Specifies the Consul ACL token used to authorize with Consul. Will be automatically set to a generated Connect service identity token specific to the service instance if Consul ACLs are enabled.|
|Specifies whether HTTPS should be used when communicating with consul. Will be automatically set to true if Nomad is configured to communicate with Consul using TLS.|
|Specifies whether the HTTPS connection with Consul should be mutually verified. Will be automatically set to true if Nomad is configured to verify TLS certificates.|
|Specifies the path to the CA certificate used for Consul communication. Will be automatically set if Nomad is configured with the |
|Specifies the path to the Client certificate used for Consul communication. Will be automatically set if Nomad is configured with the |
|Specifies the path to the CLient Key certificate used for Consul communication. Will be automatically set if Nomad is configured with the |
|Specifies the server name to use as the SNI host for Consul communication. Will be automatically set if Consul is configured to use TLS and the task is in a group using bridge networking mode.|
Port labels and task names will have any non-alphanumeric or underscore
characters in their names replaced by underscores
_ when they're used in
environment variable names such as
Nomad will pass both the allocation ID and name, the deployment ID that created
the allocation, the job ID and name, the parent job ID as well as
the task and group's names. These are given as
NOMAD_TASK_NAME. The allocation ID
and index can be useful when the task being run needs a unique identifier or to
know its instance count.
When you request resources for a job, Nomad creates a resource offer. The final resources for your job are not determined until it is scheduled. Nomad will tell you which resources have been allocated after evaluation and placement.
»CPU and Memory
Nomad will pass CPU and memory limits to your job as
NOMAD_MEMORY_MAX_LIMIT. Your task should use these
values to adapt its behavior to fit inside the resource allocation that nomad
provides. For example, you can use the memory limit to inform how large your
in-process cache should be, or to decide when to flush buffers to disk.
Both CPU and memory are presented as integers. The unit for CPU limit is
1024 = 1GHz. The unit for memory is
1 = 1 megabyte.
Writing your applications to adjust to these values at runtime provides greater scheduling flexibility since you can adjust the resource allocations in your job specification without needing to change your code. You can also schedule workloads that accept dynamic resource allocations so they can scale down/up as your cluster gets more or less busy.
Nomad assigns IPs and ports to your jobs and exposes them via environment variables. See the Networking page for more details.
Nomad creates a working directory for each allocation on a client. The allocation working directory contains a task working directory for each task in the allocation.
Nomad makes the following directories available to tasks, relative to the task working directory:
alloc/: This directory is shared across all tasks in a task group and can be used to store data that needs to be used by multiple tasks, such as a log shipper.
local/: This directory is private to each task. It can be used to store arbitrary data that should not be shared by tasks in the task group.
secrets/: This directory is private to each task, not accessible via the
nomad alloc fscommand or filesystem APIs and where possible backed by an in-memory filesystem. It can be used to store secret data that should not be visible outside the task.
These directories are persisted until the allocation is removed, which occurs hours after all the tasks in the task group enter terminal states. This gives time to view the data produced by tasks.
Depending on the driver and operating system being targeted, the directories
are made available in various ways. For example, on
docker the directories
are bound to the container, while on
exec on Linux the chroot is built in
the task working directory, and the directories are mounted into that
chroot. Regardless of how the directories are made available, the path to the
directories can be read through the
NOMAD_SECRETS_DIR environment variables.
For more details on the task directories, see the Filesystem internals.
The job specification also allows you to specify a
meta block to supply arbitrary
configuration to a task. This allows you to easily provide job-specific
configuration even if you use the same executable unit in multiple jobs. These
key-value pairs are passed through to the job as
environment variables. Prior to Nomad 0.5.5 the key was uppercased and since
then both the original case and an uppercased version are injected. The
uppercased version will be deprecated in a future release.
Currently there is no enforcement that the meta keys be lowercase, but using multiple keys with the same uppercased representation will lead to undefined behavior.
»Host environment variables
Nomad passes the environment variables defined in the client host to tasks when
java task drivers. The variables that are
passed to the tasks can be controlled using the client configuration