2015-09-23 21:58:25 +00:00
|
|
|
---
|
|
|
|
layout: "docs"
|
|
|
|
page_title: "Runtime Environment"
|
|
|
|
sidebar_current: "docs-jobspec-environment"
|
|
|
|
description: |-
|
|
|
|
Learn how to configure the Nomad runtime environment.
|
|
|
|
---
|
|
|
|
|
|
|
|
# Runtime Environment
|
|
|
|
|
2015-09-26 00:09:35 +00:00
|
|
|
Some settings you specify in your [job specification](/docs/jobspec/) are passed to tasks
|
2015-09-24 21:37:32 +00:00
|
|
|
when they start. Other settings are dynamically allocated when your job is
|
2015-09-23 21:58:25 +00:00
|
|
|
scheduled. Both types of values are made available to your job through
|
|
|
|
environment variables.
|
|
|
|
|
|
|
|
## Resources
|
|
|
|
|
|
|
|
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
|
2015-10-12 02:33:02 +00:00
|
|
|
tell you which resources have been allocated after evaluation and placement.
|
2015-09-23 21:58:25 +00:00
|
|
|
|
|
|
|
### CPU and Memory
|
|
|
|
|
2015-09-24 21:37:32 +00:00
|
|
|
Nomad will pass CPU and memory limits to your job as `NOMAD_CPU_LIMIT` and
|
2015-09-23 21:58:25 +00:00
|
|
|
`NOMAD_MEMORY_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.
|
2015-09-23 22:19:31 +00:00
|
|
|
|
|
|
|
Both CPU and memory are presented as integers. The unit for CPU limit is
|
2015-10-12 02:36:50 +00:00
|
|
|
`1024 = 1Ghz`. The unit for memory is `1 = 1 megabytes`.
|
2015-09-23 21:58:25 +00:00
|
|
|
|
|
|
|
Writing your applications to adjust to these values at runtime provides greater
|
|
|
|
scheduling flexibility since you can adjust the resource allocations in your
|
2015-09-26 00:09:35 +00:00
|
|
|
job specification without needing to change your code. You can also schedule workloads
|
2015-09-23 22:19:31 +00:00
|
|
|
that accept dynamic resource allocations so they can scale down/up as your
|
|
|
|
cluster gets more or less busy.
|
2015-09-23 21:58:25 +00:00
|
|
|
|
2015-11-18 23:51:39 +00:00
|
|
|
### Networking
|
2015-09-23 21:58:25 +00:00
|
|
|
|
2015-11-20 01:21:57 +00:00
|
|
|
Nomad assigns IPs and ports to your jobs and exposes them via environment
|
|
|
|
variables. See the [Networking](/docs/jobspec/networking.html) page for more
|
|
|
|
details.
|
2015-09-23 21:58:25 +00:00
|
|
|
|
2015-11-18 03:36:05 +00:00
|
|
|
### Task Directories <a id="task_dir"></a>
|
2015-10-16 00:28:25 +00:00
|
|
|
|
|
|
|
Nomad makes the following two directories available to tasks:
|
|
|
|
|
|
|
|
* `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 shouldn't be shared by tasks in the task group.
|
|
|
|
|
|
|
|
Both 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
|
|
|
|
binded to the container, while on `exec` on Linux the directories are mounted into the
|
|
|
|
chroot. Regardless of how the directories are made available, the path to the
|
|
|
|
directories can be read through the following environment variables:
|
|
|
|
`NOMAD_ALLOC_DIR` and `NOMAD_TASK_DIR`.
|
|
|
|
|
2015-09-23 21:58:25 +00:00
|
|
|
## Meta
|
|
|
|
|
2015-09-26 00:09:35 +00:00
|
|
|
The job specification also allows you to specify a `meta` block to supply arbitrary
|
2015-09-23 21:58:25 +00:00
|
|
|
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 `NOMAD_META_{KEY}={value}`,
|
2015-09-26 00:09:35 +00:00
|
|
|
where `key` is UPPERCASED from the job specification.
|
2015-09-23 21:58:25 +00:00
|
|
|
|
|
|
|
Currently there is no enforcement that the meta values be lowercase, but using
|
|
|
|
multiple keys with the same uppercased representation will lead to undefined
|
|
|
|
behavior.
|