github.com/jmitchell/nomad@v0.1.3-0.20151007230021-7ab84c2862d8/website/source/intro/getting-started/jobs.html.md

---
layout: "intro"
page_title: "Jobs"
sidebar_current: "getting-started-jobs"
description: |-
  Learn how to submit, modify and stop jobs in Nomad.
---

# Jobs

Jobs are the primary configuration that users interact with when using
Nomad. A job is a declarative specification of tasks that Nomad should run.
Jobs have a globally unique name, one or many task groups, which are themselves
collections of one or many tasks.

The format of the jobs is [documented here](/docs/jobspec/index.html). They
can either be specified in [HCL](https://github.com/hashicorp/hcl) or JSON,
however we recommend only using JSON when the configuration is generated by a machine.

## Running a Job

To get started, we will use the [`init` command](/docs/commands/init.html) which
generates an skeleton job file:

```
$ nomad init
Example job file written to example.nomad

$ cat example.nomad

# There can only be a single job definition per file.
# Create a job with ID and Name 'example'
job "example" {
	# Run the job in the global region, which is the default.
	# region = "global"
...
```

In this example job file, we have declared a single task 'redis' which is using
the Docker driver to run the task. The primary way you interact with Nomad
is with the [`run` command](/docs/commands/run.html). The `run` command takes
a job file and registers it with Nomad. This is used both to register new
jobs and to update existing jobs.

We can register our example job now:

```
$ nomad run example.nomad
==> Monitoring evaluation "3d823c52-929a-fa8b-c50d-1ac4d00cf6b7"
    Evaluation triggered by job "example"
    Allocation "85b839d7-f67a-72a4-5a13-104020ae4807" created: node "2512929f-5b7c-a959-dfd9-bf8a8eb022a6", group "cache"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "3d823c52-929a-fa8b-c50d-1ac4d00cf6b7" finished with status "complete"
```

Anytime a job is updated, Nomad creates an evaluation to determine what
actions need to take place. In this case, because this is a new job, Nomad has
determined that an allocation should be created and has scheduled it on our
local agent.

To inspect the status of our job we use the [`status` command](/docs/commands/status.html):

```
$ nomad status example
ID          = example
Name        = example
Type        = service
Priority    = 50
Datacenters = dc1
Status      = <none>

==> Evaluations
ID                                    Priority  TriggeredBy   Status
3d823c52-929a-fa8b-c50d-1ac4d00cf6b7  50        job-register  complete

==> Allocations
ID                                    EvalID                                NodeID                                TaskGroup  Desired  Status
85b839d7-f67a-72a4-5a13-104020ae4807  3d823c52-929a-fa8b-c50d-1ac4d00cf6b7  2512929f-5b7c-a959-dfd9-bf8a8eb022a6  cache      run      running
```

Here we can see that our evaluation that was created has completed, and that
it resulted in the creation of an allocation that is now running on the local node.

## Modifying a Job

The definition of a job is not static, and is meant to be updated overtime.
You may update a job to change the docker container to update the application version,
or change the count of a task group to scale with load.

For now, edit the `example.nomad` file to uncomment the count and set it to 3:

```
# Control the number of instances of this groups.
# Defaults to 1
count = 3
```

Once you have finished modifying the job specification, use `nomad run` to
push the updated version of the job:

```
$ nomad run example.nomad
==> Monitoring evaluation "ec199c63-2022-f5c7-328d-1cf85e61bf66"
    Evaluation triggered by job "example"
    Allocation "21551679-5224-cb6b-80a2-d0b091612d2e" created: node "2512929f-5b7c-a959-dfd9-bf8a8eb022a6", group "cache"
    Allocation "b1be1410-a01c-20ad-80ff-96750ec0f1da" created: node "2512929f-5b7c-a959-dfd9-bf8a8eb022a6", group "cache"
    Allocation "ed32a35d-8086-3f04-e299-4432e562cbf2" created: node "2512929f-5b7c-a959-dfd9-bf8a8eb022a6", group "cache"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "ec199c63-2022-f5c7-328d-1cf85e61bf66" finished with status "complete"
```

Because we set the count of the task group to three, Nomad created two
additional allocations to get to the desired state. It is idempotent to
run the same job specification again and no new allocations will be created.

Now, lets try to do an application update. In this case, we will simply change
the version of redis we want to run. Edit the `example.nomad` file and change
the Docker image from "redis:latest" to "redis:2.8":

```
# Configure Docker driver with the image
config {
    image = "redis:2.8"
}
```

This time we have not changed the number of task groups we want running,
but we've changed the task itself. This requires stopping the old tasks
and starting new tasks. Our example job is configured to do a rolling update via
the `stagger` attribute, doing a single update every 10 seconds. Use `run` to push the updated
specification now:

```
$ nomad run example.nomad
==> Monitoring evaluation "d34d37f4-19b1-f4c0-b2da-c949e6ade82d"
    Evaluation triggered by job "example"
    Allocation "5614feb0-212d-21e5-ccfb-56a394fc41d5" created: node "2512929f-5b7c-a959-dfd9-bf8a8eb022a6", group "cache"
    Allocation "bf7e3ad5-b217-14fe-f3f8-2b83af9dbb42" created: node "2512929f-5b7c-a959-dfd9-bf8a8eb022a6", group "cache"
    Allocation "e3978af2-f61e-c601-7aa1-90aea9b23cf6" created: node "2512929f-5b7c-a959-dfd9-bf8a8eb022a6", group "cache"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "d34d37f4-19b1-f4c0-b2da-c949e6ade82d" finished with status "complete"
```

We can see that Nomad handled the updated in three phases, each
time only updating a single task group at a time. The update strategy
can be configured, but rolling updates makes it easy to upgrade
an application at large scale.

## Stopping a Job

So far we've created, run and modified a job. The final step in a job lifecycle
is stopping the job. This is done with the [`stop` command](/docs/commands/stop.html):

```
$ nomad stop example
==> Monitoring evaluation "bb407de4-02cb-f009-d986-646d6c11366d"
    Evaluation triggered by job "example"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "bb407de4-02cb-f009-d986-646d6c11366d" finished with status "complete"
```

When we stop a job, it creates an evaluation which is used to stop all
the existing allocations. This also deletes the job definition out of Nomad.
If we try to query the job status, we can see it is no longer registered:

```
$ nomad status example
Error querying job: Unexpected response code: 404 (job not found)
```

If we wanted to start the job again, we could simply `run` it again.

## Next Steps

Users of Nomad primarily interact with jobs, and we've now seen
how to create and scale our job, perform an application update,
and do a job tear down. Next we will add another Nomad
client to [create our first cluster](cluster.html)