The definition of a job is not static, and is meant to be updated over time. You may update a job to change the docker container, to update the application version, or to change the count of a task group to scale with load.
For now, edit the example.nomad file to update the count and set it to 3. This
line is in the cache section around line 143.
After modifying the job specification, use the nomad job plan command to
invoke a dry-run of the scheduler to see what would happen if you ran the
updated job:
The scheduler detected the change in count and outputs that it plans to create
two new allocations and to do an in-place update to the existing allocation to
update the job specification. In-place updates do not cause any service
interruption. You can then use the nomad job run command provided in the plan
output to run the job with version verification.
By running with the -check-index flag, Nomad checks that the job has not
been modified since the plan was run. This is useful if multiple people are
interacting with the job at the same time to ensure the job hasn’t changed
before you apply your modifications.
Copy the actual command from your output from the nomad job plan command in
the preceding step.
Because you 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 are created.
You can get the example job status to validate that Nomad started the additional
instances. Run nomad job status example and inspect the Allocations section
of the output. Note that there are three instances now.
Note also the Created times for the allocations. Allocation 635a981a, the original placement, was not re-created because of its create date; however, its job information was updated so the Modification time changed. Allocation 5765545f and 95a4f6b7 have the same Created time, because Nomad deployed the additional requested instances in parallel.
The Created time for an allocation is the moment when the plan is applied by the scheduler and the allocation is ready to be picked up by the Nomad client that should run it. The Created time is a fixed point in time. The Modified time reflects the last time that an update was made to the allocation record.
Allocations are updated to reflect their current status as the allocation starts and any events that might occur during its lifecycle—mainly restarts, which can be caused by template updates, workload failure, or health-check based restarts.
»Update the application version
Now, change the job to do an application update. In this case, change
the version of Redis you want to run. Edit the example.nomad file and change
the Docker image from redis:3.2 to redis:4.0. This is located around line
305.
You can run nomad job plan again to see what happens if you submit this change.
The command outputs the planned changes to the cluster.
The plan output shows that one allocation updates and that the other two are
ignored. While this might seem unexpected, Nomad is performing an update. In
this case, the update behavior is due to the max_parallel setting in the
update stanza, which is set to 1 to instruct Nomad to perform only a single
change at a time.
Once ready, use nomad job run command emitted in the plan output to push the
updated specification.
Copy the actual command from your output from the nomad job plan command
in the preceding step.
The command outputs the scheduling information.
After running, the rolling update can be followed by running nomad job status example and watching Allocations section at the bottom. A successful
deployment shows an updated version number for Version, a Desired value
of run, and a Status of running.
Here the output indicates that Nomad handled the update in three phases,
updating a single allocation in each phase and waiting for it to be healthy for
min_healthy_time of 10 seconds before moving on to the next. Because the
container is cached and Redis starts quickly, the second and third instances
start close to one another on this node; however, you can see that there is at
least the expected 10 seconds of time between each create.
You can configure the update strategy yourself, but the default rolling update behavior makes it less complex to update an application at large scale while resisting application outages.
»Next steps
In this tutorial, you scaled, updated, and verified each of these activities on your Nomad job. Next, briefly explore the Nomad web interface.
