github.com/Ilhicas/nomad@v1.0.4-0.20210304152020-e86851182bc3/website/content/docs/runtime/environment.mdx (about)

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