github.com/smintz/nomad@v0.8.3/website/source/docs/commands/job/run.html.md.erb (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Commands: job run"
     4  sidebar_current: "docs-commands-job-run"
     5  description: >
     6    The job run command is used to run a new job.
     7  ---
     8  
     9  # Command: job run
    10  **Alias: `nomad run`**
    11  
    12  The `job run` command is used to submit new jobs to Nomad or to update existing
    13  jobs. Job files must conform to the [job specification](/docs/job-specification/index.html)
    14  format.
    15  
    16  ## Usage
    17  
    18  ```
    19  nomad job run [options] <job file>
    20  ```
    21  
    22  The `job run` command requires a single argument, specifying the path to a file
    23  containing a valid [job specification](/docs/job-specification/index.html). This file
    24  will be read and the job will be submitted to Nomad for scheduling. If the
    25  supplied path is "-", the job file is read from STDIN. Otherwise it is read
    26  from the file at the supplied path or downloaded and read from URL specified.
    27  Nomad downloads the job file using [`go-getter`](https://github.com/hashicorp/go-getter)
    28  and supports `go-getter` syntax.
    29  
    30  By default, on successful job submission the run command will enter an
    31  interactive monitor and display log information detailing the scheduling
    32  decisions and placement information for the provided job. The monitor will
    33  exit after scheduling has finished or failed.
    34  
    35  On successful job submission and scheduling, exit code 0 will be returned. If
    36  there are job placement issues encountered (unsatisfiable constraints, resource
    37  exhaustion, etc), then the exit code will be 2. Any other errors, including
    38  client connection issues or internal errors, are indicated by exit code 1.
    39  
    40  If the job has specified the region, the -region flag and NOMAD_REGION
    41  environment variable are overridden and the job's region is used.
    42  
    43  The run command will set the `vault_token` of the job based on the following
    44  precedence, going from highest to lowest: the `-vault-token` flag, the
    45  `$VAULT_TOKEN` environment variable and finally the value in the job file.
    46  
    47  ## General Options
    48  
    49  <%= partial "docs/commands/_general_options" %>
    50  
    51  ## Run Options
    52  
    53  * `-check-index`: If set, the job is only registered or
    54    updated if the passed job modify index matches the server side version.
    55    If a check-index value of zero is passed, the job is only registered if it does
    56    not yet exist. If a non-zero value is passed, it ensures that the job is being
    57    updated from a known state. The use of this flag is most common in conjunction
    58    with [`job plan` command](/docs/commands/job/plan.html).
    59  
    60  * `-detach`: Return immediately instead of monitoring. A new evaluation ID
    61    will be output, which can be used to examine the evaluation using the
    62    [eval status](/docs/commands/eval-status.html) command
    63  
    64  * `-output`: Output the JSON that would be submitted to the HTTP API without
    65    submitting the job.
    66  
    67  * `-policy-override`: Sets the flag to force override any soft mandatory Sentinel policies.
    68  
    69  * `-vault-token`: If set, the passed Vault token is stored in the job before
    70    sending to the Nomad servers. This allows passing the Vault token without
    71    storing it in the job file. This overrides the token found in $VAULT_TOKEN
    72    environment variable and that found in the job.
    73  
    74  * `-verbose`: Show full information.
    75  
    76  ## Examples
    77  
    78  Schedule the job contained in the file `job1.nomad`, monitoring placement:
    79  
    80  ```
    81  $ nomad job run job1.nomad
    82  ==> Monitoring evaluation "52dee78a"
    83      Evaluation triggered by job "example"
    84      Evaluation within deployment: "62eb607c"
    85      Allocation "5e0b39f0" created: node "3e84d3d2", group "group1"
    86      Allocation "5e0b39f0" status changed: "pending" -> "running"
    87      Evaluation status changed: "pending" -> "complete"
    88  ==> Evaluation "52dee78a" finished with status "complete"
    89  ```
    90  
    91  <a id="check-index"></a> Update the job using `check-index`:
    92  
    93  ```
    94  $ nomad job run -check-index 5 example.nomad
    95  Enforcing job modify index 5: job exists with conflicting job modify index: 6
    96  Job not updated
    97  
    98  $ nomad job run -check-index 6 example.nomad
    99  ==> Monitoring evaluation "5ef16dff"
   100      Evaluation triggered by job "example"
   101      Evaluation within deployment: "62eb607c"
   102      Allocation "6ec7d16f" modified: node "6e1f9bf6", group "cache"
   103      Evaluation status changed: "pending" -> "complete"
   104  ==> Evaluation "5ef16dff" finished with status "complete"
   105  ```
   106  
   107  Schedule the job contained in `job1.nomad` and return immediately:
   108  
   109  ```
   110  $ nomad job run -detach job1.nomad
   111  4947e728
   112  ```
   113  
   114  Schedule a job which cannot be successfully placed. This results in a scheduling
   115  failure and the specifics of the placement are printed:
   116  
   117  ```
   118  $ nomad job run failing.nomad
   119  ==> Monitoring evaluation "2ae0e6a5"
   120      Evaluation triggered by job "example"
   121      Evaluation status changed: "pending" -> "complete"
   122  ==> Evaluation "2ae0e6a5" finished with status "complete" but failed to place all allocations:
   123      Task Group "cache" (failed to place 1 allocation):
   124        * Class "foo" filtered 1 nodes
   125        * Constraint "${attr.kernel.name} = linux" filtered 1 nodes
   126      Evaluation "67493a64" waiting for additional capacity to place remainder
   127  ```