I know the API allows in-place restart of a specific allocation, but what I’d like to do is trigger a re-deployment (or re-evaluation and re-deployment) of all instances of a job. The use case is my CI / CD pipeline publishes a new ‘current’ container and now we want to restart into it, but I want Nomad, not my CI /CD pipeline to control the rolling restart. I don’t want to have to modify my job description file, but that’s the only way I know to trigger a safe, rolling restart (say, modify a ‘meta’ tag value). That seems like a hack. Why can I restart a single allocation but not all of them in a controlled way?
Hi @humane-jeremy,
Deployments within Nomad are fixed units of work and eventually reach a terminal state and cannot be restarted or re-run.
The Nomad API provides a method to stop allocations which results in a new allocation being scheduled and pulling a new container image (depending exactly on your config parameters. This, however, does not account for the portion where Nomad controls the rollout, as it doesn’t provide a way to control iterating over multiple allocations and controlling the iteration speed. It is best practice within Nomad to use non-latest/current Docker container tags and deploy a modified version of the job specification. This process results in using Nomad’s deployment mechanisms as you desire.
It may be useful to understand the requirement you have that means you do not wish or cannot modify the job specification? Does this also mean you would not be able to use HCL2 templating to template the Docker container tag, and then use variables to modify the parameter?
Thanks,
jrasell and the Nomad team
Agreed that generally it’s best not to use latest/current, and that’s especially inappropriate in a production environment, but in development and some testing environments it’s sometimes preferred. It’s nice to be able to just publish a new container and hit a single command line and initiate a safe update.