Nomad application layout scheme 04 of hashicopy (scaling and updating a job)

One Preface

The definition of an assignment is not static , It means updating over time . You can update the job to change docker Containers 、 Update the application version or change the count of task groups to expand with load .

Two Telescopic Job

Now? , edit example.nomad File to update the count and set it to 3. This line is in 143 In the cache section around the line .

- count = 1+ count = 3

After modifying the operation specification , Use nomad job plan Command invokes a drill of the dispatcher , See what happens if you run the updated job ：

nomad job plan example.nomad	

The scheduler detected a change in the count , And output the plan to create two new assignments , And update the existing allocation in place , To update the job specification . In place updates do not cause any service disruption . You can then use the nomad job run Command to run a job with version validation .
By using -check-index Sign operation ,Nomad Check whether the job has not been modified after running the plan . If more than one person interacts with the job at the same time , This will be very useful , To ensure that the job is not changed before the changes are applied .

nomad job run -check-index 10 example.nomad

Because you set the count of task groups to three ,Nomad Two additional allocations are created to achieve the desired state . Running the same job specification again is idempotent , And no new assignments will be created .
You can get the sample job status , To verify Nomad Whether other instances are started . function nomad Example of job status and check the allocation part of the output . Please note that , Now there are three examples .

Also note the time created for the assignment , The initial container time has not changed , Means no updates , The two newly added containers are created concurrently .
The allocated creation time is scheduled by the scheduler application and the allocation is ready to be allocated by the run Nomad When the client receives . The creation time is a fixed point in time . The modified time reflects the time when the allocation record was last updated .
With the start of the assignment and any events that may occur during its life cycle （ It is mainly updated by the template 、 Restarts caused by workload failures or health check based restarts ）, The assignment will be updated to reflect its current status .

3、 ... and to update Job

Now modify example.nomad file , modify redis:3.2toredis:4.0, perform

nomad job plan example.nomad	

Use -check-index

nomad job run -check-index 44 example.nomad

After running , Rolling updates can be run at the bottom nomad job status Example and observation assignment section . A successful deployment will show version Updated version number of 、run The expected value and operating status of .

The output here shows Nomad Updates are processed in three stages , Update an assignment at each stage , And wait for it to min_healthy_time 10 Stay healthy for seconds , Then proceed to the next stage . Because containers are cached ,Redis It starts very quickly , So the second and third instances start close to each other on this node ; however , You can see that there is at least one expected... Between each creation 10 Second time .
You can configure the update policy yourself , But the default rolling update behavior makes it less complicated to update applications on a large scale and prevent application interruptions .

Four other

Use Nomad To carry out job In the case of containers , Can be quickly choreographed .

Reference link

• https://learn.hashicorp.com/tutorials/nomad/get-started-jobs?in=nomad/get-started