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

     1  ---
     2  layout: docs
     3  page_title: job Stanza - Job Specification
     4  sidebar_title: job
     5  description: |-
     6    The "job" stanza is the top-most configuration option in the job
     7    specification. A job is a declarative specification of tasks that Nomad
     8    should run.
     9  ---
    10  
    11  # `job` Stanza
    12  
    13  <Placement groups={['job']} />
    14  
    15  The `job` stanza is the top-most configuration option in the job specification.
    16  A job is a declarative specification of tasks that Nomad should run. Jobs have
    17  one or more task groups, which are themselves collections of one or more tasks.
    18  Job names are unique per [region][region] or [namespace][namespace].
    19  
    20  ```hcl
    21  job "docs" {
    22    constraint {
    23      # ...
    24    }
    25  
    26    datacenters = ["us-east-1"]
    27  
    28    group "example" {
    29      # ...
    30    }
    31  
    32    meta {
    33      my-key = "my-value"
    34    }
    35  
    36    parameterized {
    37      # ...
    38    }
    39  
    40    periodic {
    41      # ...
    42    }
    43  
    44    priority = 100
    45  
    46    region = "north-america"
    47  
    48    task "docs" {
    49      # ...
    50    }
    51  
    52    update {
    53      # ...
    54    }
    55  }
    56  ```
    57  
    58  ## `job` Parameters
    59  
    60  - `all_at_once` `(bool: false)` - Controls whether the scheduler can make
    61    partial placements if optimistic scheduling resulted in an oversubscribed
    62    node. This does not control whether all allocations for the job, where all
    63    would be the desired count for each task group, must be placed atomically.
    64    This should only be used for special circumstances.
    65  
    66  - `constraint` <code>([Constraint][constraint]: nil)</code> -
    67    This can be provided multiple times to define additional constraints. See the
    68    [Nomad constraint reference][constraint] for more
    69    details.
    70  
    71  - `affinity` <code>([Affinity][affinity]: nil)</code> -
    72    This can be provided multiple times to define preferred placement criteria. See the
    73    [Nomad affinity reference][affinity] for more
    74    details.
    75  
    76  - `spread` <code>([Spread][spread]: nil)</code> - This can be provided multiple times
    77    to define criteria for spreading allocations across a node attribute or metadata.
    78    See the [Nomad spread reference][spread] for more details.
    79  
    80  - `datacenters` `(array<string>: <required>)` - A list of datacenters in the region which are eligible
    81    for task placement. This must be provided, and does not have a default.
    82  
    83  - `group` <code>([Group][group]: &lt;required&gt;)</code> - Specifies the start of a
    84    group of tasks. This can be provided multiple times to define additional
    85    groups. Group names must be unique within the job file.
    86  
    87  - `meta` <code>([Meta][]: nil)</code> - Specifies a key-value map that annotates
    88    with user-defined metadata.
    89  
    90  - `name` `(string: <optional>)` - Specifies a name for the job, which otherwise
    91    defaults to the job ID.
    92  
    93  - `migrate` <code>([Migrate][]: nil)</code> - Specifies the groups strategy for
    94    migrating off of draining nodes. If omitted, a default migration strategy is
    95    applied. Only service jobs with a count greater than 1 support migrate stanzas.
    96  
    97  - `namespace` `(string: "default")` - The namespace in which to execute the job.
    98    Prior to Nomad 1.0 namespaces were Enterprise-only.
    99  
   100  - `parameterized` <code>([Parameterized][parameterized]: nil)</code> - Specifies
   101    the job as a parameterized job such that it can be dispatched against.
   102  
   103  - `periodic` <code>([Periodic][]: nil)</code> - Allows the job to be scheduled
   104    at fixed times, dates or intervals.
   105  
   106  - `priority` `(int: 50)` - Specifies the job priority which is used to
   107    prioritize scheduling and access to resources. Must be between 1 and 100
   108    inclusively, with a larger value corresponding to a higher priority.
   109  
   110  - `region` `(string: "global")` - The region in which to execute the job.
   111  
   112  - `reschedule` <code>([Reschedule][]: nil)</code> - Allows to specify a
   113    rescheduling strategy. Nomad will then attempt to schedule the task on another
   114    node if any of its allocation statuses become "failed".
   115  
   116  - `type` `(string: "service")` - Specifies the [Nomad scheduler][scheduler] to
   117    use. Nomad provides the `service`, `system` and `batch` schedulers.
   118  
   119  - `update` <code>([Update][update]: nil)</code> - Specifies the task's update
   120    strategy. When omitted, rolling updates are disabled.
   121  
   122  - `vault` <code>([Vault][]: nil)</code> - Specifies the set of Vault policies
   123    required by all tasks in this job.
   124  
   125  - `vault_token` `(string: "")` - Specifies the Vault token that proves the
   126    submitter of the job has access to the specified policies in the
   127    [`vault`][vault] stanza. This field is only used to transfer the token and is
   128    not stored after job submission.
   129  
   130    !> It is **strongly discouraged** to place the token as a configuration
   131    parameter like this, since the token could be checked into source control
   132    accidentally. Users should set the `VAULT_TOKEN` environment variable when
   133    running the job instead.
   134  
   135  - `consul_token` `(string: "")` - Specifies the Consul token that proves the
   136    submitter of the job has access to the Service Identity policies associated
   137    with the job's Consul Connect enabled services. This field is only used to
   138    transfer the token and is not stored after job submission.
   139  
   140    !> It is **strongly discouraged** to place the token as a configuration
   141    parameter like this, since the token could be checked into source control
   142    accidentally. Users should set the `CONSUL_HTTP_TOKEN` environment variable when
   143    running the job instead.
   144  
   145  ## `job` Examples
   146  
   147  The following examples only show the `job` stanzas. Remember that the
   148  `job` stanza is only valid in the placements listed above.
   149  
   150  ### Docker Container
   151  
   152  This example job starts a Docker container which runs as a service. Even though
   153  the type is not specified as "service", that is the default job type.
   154  
   155  ```hcl
   156  job "docs" {
   157    datacenters = ["default"]
   158  
   159    group "example" {
   160      task "server" {
   161        driver = "docker"
   162        config {
   163          image = "hashicorp/http-echo"
   164          args  = ["-text", "hello"]
   165        }
   166  
   167        resources {
   168          memory = 128
   169        }
   170      }
   171    }
   172  }
   173  ```
   174  
   175  ### Batch Job
   176  
   177  This example job executes the `uptime` command on 10 Nomad clients in the fleet,
   178  restricting the eligible nodes to Linux machines.
   179  
   180  ```hcl
   181  job "docs" {
   182    datacenters = ["default"]
   183  
   184    type = "batch"
   185  
   186    constraint {
   187      attribute = "${attr.kernel.name}"
   188      value     = "linux"
   189    }
   190  
   191    group "example" {
   192      count = 10
   193      task "uptime" {
   194        driver = "exec"
   195        config {
   196          command = "uptime"
   197        }
   198      }
   199    }
   200  }
   201  ```
   202  
   203  ### Consuming Secrets
   204  
   205  This example shows a job which retrieves secrets from Vault and writes those
   206  secrets to a file on disk, which the application then consumes. Nomad handles
   207  all interactions with Vault.
   208  
   209  ```hcl
   210  job "docs" {
   211    datacenters = ["default"]
   212  
   213    group "example" {
   214      task "cat" {
   215        driver = "exec"
   216  
   217        config {
   218          command = "cat"
   219          args    = ["local/secrets.txt"]
   220        }
   221  
   222        template {
   223          data        = "{{ secret \"secret/data\" }}"
   224          destination = "local/secrets.txt"
   225        }
   226  
   227        vault {
   228          policies = ["secret-readonly"]
   229        }
   230      }
   231    }
   232  }
   233  ```
   234  
   235  When submitting this job, you would run:
   236  
   237  ```shell-session
   238  $ VAULT_TOKEN="..." nomad job run example.nomad
   239  ```
   240  
   241  [affinity]: /docs/job-specification/affinity 'Nomad affinity Job Specification'
   242  [constraint]: /docs/job-specification/constraint 'Nomad constraint Job Specification'
   243  [group]: /docs/job-specification/group 'Nomad group Job Specification'
   244  [meta]: /docs/job-specification/meta 'Nomad meta Job Specification'
   245  [migrate]: /docs/job-specification/migrate 'Nomad migrate Job Specification'
   246  [namespace]: https://learn.hashicorp.com/tutorials/nomad/namespaces
   247  [parameterized]: /docs/job-specification/parameterized 'Nomad parameterized Job Specification'
   248  [periodic]: /docs/job-specification/periodic 'Nomad periodic Job Specification'
   249  [region]: https://learn.hashicorp.com/tutorials/nomad/federation
   250  [reschedule]: /docs/job-specification/reschedule 'Nomad reschedule Job Specification'
   251  [scheduler]: /docs/schedulers 'Nomad Scheduler Types'
   252  [spread]: /docs/job-specification/spread 'Nomad spread Job Specification'
   253  [task]: /docs/job-specification/task 'Nomad task Job Specification'
   254  [update]: /docs/job-specification/update 'Nomad update Job Specification'
   255  [vault]: /docs/job-specification/vault 'Nomad vault Job Specification'