github.com/smintz/nomad@v0.8.3/website/source/docs/runtime/environment.html.md.erb (about) 1 --- 2 layout: "docs" 3 page_title: "Environment - Runtime" 4 sidebar_current: "docs-runtime-environment" 5 description: |- 6 Learn how to configure the Nomad runtime environment. 7 --- 8 9 # Runtime Environment 10 11 Some settings you specify in your [job specification][jobspec] are passed 12 to tasks when they start. Other settings are dynamically allocated when your job 13 is scheduled. Both types of values are made available to your job through 14 environment variables. 15 16 ## Summary 17 18 <%= partial "envvars.html.md" %> 19 20 ~> Port labels and task names will have any non-alphanumeric or underscore 21 characters in their names replaced by underscores `_` when they're used in 22 environment variable names such as `NOMAD_ADDR_<task>_<label>`. 23 24 ## Task Identifiers 25 26 Nomad will pass both the allocation ID and name as well as the task, group and 27 job's names. These are given as `NOMAD_ALLOC_ID`, `NOMAD_ALLOC_NAME`, 28 `NOMAD_ALLOC_INDEX`, `NOMAD_JOB_NAME`, `NOMAD_GROUP_NAME` and `NOMAD_TASK_NAME`. 29 The allocation ID and index can be useful when the task being run needs a unique 30 identifier or to know its instance count. 31 32 ## Resources 33 34 When you request resources for a job, Nomad creates a resource offer. The final 35 resources for your job are not determined until it is scheduled. Nomad will 36 tell you which resources have been allocated after evaluation and placement. 37 38 ### CPU and Memory 39 40 Nomad will pass CPU and memory limits to your job as `NOMAD_CPU_LIMIT` and 41 `NOMAD_MEMORY_LIMIT`. Your task should use these values to adapt its behavior to 42 fit inside the resource allocation that nomad provides. For example, you can use 43 the memory limit to inform how large your in-process cache should be, or to 44 decide when to flush buffers to disk. 45 46 Both CPU and memory are presented as integers. The unit for CPU limit is 47 `1024 = 1GHz`. The unit for memory is `1 = 1 megabyte`. 48 49 Writing your applications to adjust to these values at runtime provides greater 50 scheduling flexibility since you can adjust the resource allocations in your 51 job specification without needing to change your code. You can also schedule workloads 52 that accept dynamic resource allocations so they can scale down/up as your 53 cluster gets more or less busy. 54 55 ### Networking 56 57 Nomad assigns IPs and ports to your jobs and exposes them via environment 58 variables. See the [Networking](/docs/job-specification/network.html) page for more 59 details. 60 61 ### Task Directories 62 63 Nomad makes the following directories available to tasks: 64 65 * `alloc/`: This directory is shared across all tasks in a task group and can be 66 used to store data that needs to be used by multiple tasks, such as a log 67 shipper. 68 * `local/`: This directory is private to each task. It can be used to store 69 arbitrary data that should not be shared by tasks in the task group. 70 * `secrets/`: This directory is private to each task, not accessible via the 71 `nomad alloc fs` command or filesystem APIs and where possible backed by an 72 in-memory filesystem. It can be used to store secret data that should not be 73 visible outside the task. 74 75 These directories are persisted until the allocation is removed, which occurs 76 hours after all the tasks in the task group enter terminal states. This gives 77 time to view the data produced by tasks. 78 79 Depending on the driver and operating system being targeted, the directories are 80 made available in various ways. For example, on `docker` the directories are 81 bound to the container, while on `exec` on Linux the directories are mounted into the 82 chroot. Regardless of how the directories are made available, the path to the 83 directories can be read through the `NOMAD_ALLOC_DIR`, `NOMAD_TASK_DIR`, and 84 `NOMAD_SECRETS_DIR` environment variables. 85 86 ## Meta 87 88 The job specification also allows you to specify a `meta` block to supply arbitrary 89 configuration to a task. This allows you to easily provide job-specific 90 configuration even if you use the same executable unit in multiple jobs. These 91 key-value pairs are passed through to the job as `NOMAD_META_<key>=<value>` 92 environment variables. Prior to Nomad 0.5.5 the key was uppercased and since 93 then both the original case and an uppercased version are injected. The 94 uppercased version will be deprecated in a future release. 95 96 Currently there is no enforcement that the meta keys be lowercase, but using 97 multiple keys with the same uppercased representation will lead to undefined 98 behavior. 99 100 [jobspec]: /docs/job-specification/index.html "Nomad Job Specification" 101 [vault]: /docs/vault-integration/index.html "Nomad Vault Integration"