github.com/dkerwin/nomad@v0.3.3-0.20160525181927-74554135514b/website/source/intro/getting-started/jobs.html.md (about) 1 --- 2 layout: "intro" 3 page_title: "Jobs" 4 sidebar_current: "getting-started-jobs" 5 description: |- 6 Learn how to submit, modify and stop jobs in Nomad. 7 --- 8 9 # Jobs 10 11 Jobs are the primary configuration that users interact with when using 12 Nomad. A job is a declarative specification of tasks that Nomad should run. 13 Jobs have a globally unique name, one or many task groups, which are themselves 14 collections of one or many tasks. 15 16 The format of the jobs is [documented here](/docs/jobspec/index.html). They 17 can either be specified in [HCL](https://github.com/hashicorp/hcl) or JSON, 18 however we recommend only using JSON when the configuration is generated by a machine. 19 20 ## Running a Job 21 22 To get started, we will use the [`init` command](/docs/commands/init.html) which 23 generates a skeleton job file: 24 25 ``` 26 $ nomad init 27 Example job file written to example.nomad 28 29 $ cat example.nomad 30 31 # There can only be a single job definition per file. 32 # Create a job with ID and Name 'example' 33 job "example" { 34 # Run the job in the global region, which is the default. 35 # region = "global" 36 ... 37 ``` 38 39 In this example job file, we have declared a single task 'redis' which is using 40 the Docker driver to run the task. The primary way you interact with Nomad 41 is with the [`run` command](/docs/commands/run.html). The `run` command takes 42 a job file and registers it with Nomad. This is used both to register new 43 jobs and to update existing jobs. 44 45 We can register our example job now: 46 47 ``` 48 $ nomad run example.nomad 49 ==> Monitoring evaluation "26cfc69e" 50 Evaluation triggered by job "example" 51 Allocation "8ba85cef" created: node "171a583b", group "cache" 52 Evaluation status changed: "pending" -> "complete" 53 ==> Evaluation "26cfc69e" finished with status "complete" 54 ``` 55 56 Anytime a job is updated, Nomad creates an evaluation to determine what 57 actions need to take place. In this case, because this is a new job, Nomad has 58 determined that an allocation should be created and has scheduled it on our 59 local agent. 60 61 To inspect the status of our job we use the [`status` command](/docs/commands/status.html): 62 63 ``` 64 $ nomad status example 65 ID = example 66 Name = example 67 Type = service 68 Priority = 50 69 Datacenters = dc1 70 Status = running 71 Periodic = false 72 73 ==> Evaluations 74 ID Priority Triggered By Status 75 26cfc69e 50 job-register complete 76 77 ==> Allocations 78 ID Eval ID Node ID Task Group Desired Status 79 8ba85cef 26cfc69e 171a583b cache run running 80 ``` 81 82 Here we can see that our evaluation that was created has completed, and that 83 it resulted in the creation of an allocation that is now running on the local node. 84 85 An allocation represents an instance of Task Group placed on a node. To inspect 86 an Allocation we use the [`alloc-status` command](/docs/commands/alloc-status.html): 87 88 ``` 89 $ nomad alloc-status 8ba85cef 90 ID = 8ba85cef 91 Eval ID = 26cfc69e 92 Name = example.cache[0] 93 Node ID = 58d69d9d 94 Job ID = example 95 Client Status = running 96 Evaluated Nodes = 1 97 Filtered Nodes = 0 98 Exhausted Nodes = 0 99 Allocation Time = 27.704µs 100 Failures = 0 101 102 ==> Task "redis" is "running" 103 Recent Events: 104 Time Type Description 105 15/03/16 15:40:57 PDT Started Task started by client 106 15/03/16 15:40:00 PDT Received Task received by client 107 108 ==> Status 109 Allocation "4b5f832c" status "running" (0/1 nodes filtered) 110 * Score "58d69d9d-0015-2c69-e9ba-cc9ee476bb6d.binpack" = 1.580850 111 112 ==> Task Resources 113 Task: "redis" 114 CPU Memory MB Disk MB IOPS Addresses 115 500 256 300 0 db: 127.0.0.1:52004 116 ``` 117 118 To inspect the file system of a running allocation, we can use the [`fs ls` 119 command](/docs/commands/fs.html): 120 121 ``` 122 $ nomad fs ls 8ba85cef alloc/logs 123 Mode Size Modfied Time Name 124 -rw-rw-r-- 0 B 15/03/16 15:40:56 PDT redis.stderr.0 125 -rw-rw-r-- 2.3 kB 15/03/16 15:40:57 PDT redis.stdout.0 126 127 $ nomad fs cat 8ba85cef alloc/logs/redis.stdout.0 128 1:C 15 Mar 22:40:57.188 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf 129 ``` 130 131 ## Modifying a Job 132 133 The definition of a job is not static, and is meant to be updated over time. 134 You may update a job to change the docker container, to update the application version, 135 or to change the count of a task group to scale with load. 136 137 For now, edit the `example.nomad` file to uncomment the count and set it to 3: 138 139 ``` 140 # Control the number of instances of this group. 141 # Defaults to 1 142 count = 3 143 ``` 144 145 Once you have finished modifying the job specification, use `nomad run` to 146 push the updated version of the job: 147 148 ``` 149 $ nomad run example.nomad 150 ==> Monitoring evaluation "127a49d0" 151 Evaluation triggered by job "example" 152 Allocation "8ab24eef" created: node "171a583b", group "cache" 153 Allocation "f6c29874" created: node "171a583b", group "cache" 154 Allocation "8ba85cef" modified: node "171a583b", group "cache" 155 Evaluation status changed: "pending" -> "complete" 156 ==> Evaluation "127a49d0" finished with status "complete" 157 ``` 158 159 Because we set the count of the task group to three, Nomad created two 160 additional allocations to get to the desired state. It is idempotent to 161 run the same job specification again and no new allocations will be created. 162 163 Now, let's try to do an application update. In this case, we will simply change 164 the version of redis we want to run. Edit the `example.nomad` file and change 165 the Docker image from "redis:latest" to "redis:2.8": 166 167 ``` 168 # Configure Docker driver with the image 169 config { 170 image = "redis:2.8" 171 } 172 ``` 173 174 This time we have not changed the number of task groups we want running, 175 but we've changed the task itself. This requires stopping the old tasks 176 and starting new tasks. Our example job is configured to do a rolling update via 177 the `stagger` attribute, doing a single update every 10 seconds. Use `run` to push the updated 178 specification now: 179 180 ``` 181 $ nomad run example.nomad 182 ==> Monitoring evaluation "ebcc3e14" 183 Evaluation triggered by job "example" 184 Allocation "9a3743f4" created: node "171a583b", group "cache" 185 Evaluation status changed: "pending" -> "complete" 186 ==> Evaluation "ebcc3e14" finished with status "complete" 187 ==> Monitoring evaluation "b508d8f0" 188 Evaluation triggered by job "example" 189 Allocation "926e5876" created: node "171a583b", group "cache" 190 Evaluation status changed: "pending" -> "complete" 191 ==> Evaluation "b508d8f0" finished with status "complete" 192 ==> Monitoring next evaluation "ea78c05a" in 10s 193 ==> Monitoring evaluation "ea78c05a" 194 Evaluation triggered by job "example" 195 Allocation "3c8589d5" created: node "171a583b", group "cache" 196 Evaluation status changed: "pending" -> "complete" 197 ==> Evaluation "ea78c05a" finished with status "complete" 198 ``` 199 200 We can see that Nomad handled the update in three phases, only updating a single task 201 group in each phase. The update strategy can be configured, but rolling updates makes 202 it easy to upgrade an application at large scale. 203 204 ## Stopping a Job 205 206 So far we've created, run and modified a job. The final step in a job lifecycle 207 is stopping the job. This is done with the [`stop` command](/docs/commands/stop.html): 208 209 ``` 210 $ nomad stop example 211 ==> Monitoring evaluation "fd03c9f8" 212 Evaluation triggered by job "example" 213 Evaluation status changed: "pending" -> "complete" 214 ==> Evaluation "fd03c9f8" finished with status "complete" 215 ``` 216 217 When we stop a job, it creates an evaluation which is used to stop all 218 the existing allocations. This also deletes the job definition out of Nomad. 219 If we try to query the job status, we can see it is no longer registered: 220 221 ``` 222 $ nomad status example 223 No job(s) with prefix or id "example" found 224 ``` 225 226 If we wanted to start the job again, we could simply `run` it again. 227 228 ## Next Steps 229 230 Users of Nomad primarily interact with jobs, and we've now seen 231 how to create and scale our job, perform an application update, 232 and do a job tear down. Next we will add another Nomad 233 client to [create our first cluster](cluster.html) 234