github.com/jmitchell/nomad@v0.1.3-0.20151007230021-7ab84c2862d8/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 evaulation 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 `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  ## Meta
    60  
    61  The job specification also allows you to specify a `meta` block to supply arbitrary
    62  configuration to a task. This allows you to easily provide job-specific
    63  configuration even if you use the same executable unit in multiple jobs. These
    64  key-value pairs are passed through to the job as `NOMAD_META_{KEY}={value}`,
    65  where `key` is UPPERCASED from the job specification.
    66  
    67  Currently there is no enforcement that the meta values be lowercase, but using
    68  multiple keys with the same uppercased representation will lead to undefined
    69  behavior.