github.com/kardianos/nomad@v0.1.3-0.20151022182107-b13df73ee850/website/source/docs/jobspec/environment.html.md (about) 1 --- 2 layout: "docs" 3 page_title: "Runtime Environment" 4 sidebar_current: "docs-jobspec-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](/docs/jobspec/) are passed to tasks 12 when they start. Other settings are dynamically allocated when your job is 13 scheduled. Both types of values are made available to your job through 14 environment variables. 15 16 ## Resources 17 18 When you request resources for a job, Nomad creates a resource offer. The final 19 resources for your job are not determined until it is scheduled. Nomad will 20 tell you which resources have been allocated after evaluation and placement. 21 22 ### CPU and Memory 23 24 Nomad will pass CPU and memory limits to your job as `NOMAD_CPU_LIMIT` and 25 `NOMAD_MEMORY_LIMIT`. Your task should use these values to adapt its behavior to 26 fit inside the resource allocation that nomad provides. For example, you can use 27 the memory limit to inform how large your in-process cache should be, or to 28 decide when to flush buffers to disk. 29 30 Both CPU and memory are presented as integers. The unit for CPU limit is 31 `1024 = 1Ghz`. The unit for memory is `1 = 1 megabytes`. 32 33 Writing your applications to adjust to these values at runtime provides greater 34 scheduling flexibility since you can adjust the resource allocations in your 35 job specification without needing to change your code. You can also schedule workloads 36 that accept dynamic resource allocations so they can scale down/up as your 37 cluster gets more or less busy. 38 39 ### IPs and Named Ports 40 41 Each task will receive port allocations on a single IP address. The IP is made 42 available through `NOMAD_IP.` 43 44 If you requested reserved ports in your job specification and your task is successfully 45 scheduled, these ports are available for your use. Ports from `reserved_ports` 46 in the job spec are not exposed through the environment. If you requested 47 dynamic ports in your job specification these are made known to your application via 48 environment variables `NOMAD_PORT_{LABEL}`. For example 49 `dynamic_ports = ["HTTP"]` becomes `NOMAD_PORT_HTTP`. 50 51 Some drivers such as Docker and QEMU use port mapping. If a driver supports port 52 mapping and you specify a numeric label, the label will be automatically used as 53 the private port number. For example, `dynamic_ports = ["5000"]` will have a 54 random port mapped to port 5000 inside the container or VM. These ports are also 55 exported as environment variables for consistency, e.g. `NOMAD_PORT_5000`. 56 57 Please see the relevant driver documentation for details. 58 59 <a id="task_dir">### Task Directories</a> 60 61 Nomad makes the following two directories available to tasks: 62 63 * `alloc/`: This directory is shared across all tasks in a task group and can be 64 used to store data that needs to be used by multiple tasks, such as a log 65 shipper. 66 * `local/`: This directory is private to each task. It can be used to store 67 arbitrary data that shouldn't be shared by tasks in the task group. 68 69 Both these directories are persisted until the allocation is removed, which 70 occurs hours after all the tasks in the task group enter terminal states. This 71 gives time to view the data produced by tasks. 72 73 Depending on the driver and operating system being targeted, the directories are 74 made available in various ways. For example, on `docker` the directories are 75 binded to the container, while on `exec` on Linux the directories are mounted into the 76 chroot. Regardless of how the directories are made available, the path to the 77 directories can be read through the following environment variables: 78 `NOMAD_ALLOC_DIR` and `NOMAD_TASK_DIR`. 79 80 ## Meta 81 82 The job specification also allows you to specify a `meta` block to supply arbitrary 83 configuration to a task. This allows you to easily provide job-specific 84 configuration even if you use the same executable unit in multiple jobs. These 85 key-value pairs are passed through to the job as `NOMAD_META_{KEY}={value}`, 86 where `key` is UPPERCASED from the job specification. 87 88 Currently there is no enforcement that the meta values be lowercase, but using 89 multiple keys with the same uppercased representation will lead to undefined 90 behavior.