github.com/diptanu/nomad@v0.5.7-0.20170516172507-d72e86cbe3d9/website/source/docs/operating-a-job/update-strategies/rolling-upgrades.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Rolling Upgrades - Operating a Job"
     4  sidebar_current: "docs-operating-a-job-updating-rolling-upgrades"
     5  description: |-
     6    In order to update a service while reducing downtime, Nomad provides a
     7    built-in mechanism for rolling upgrades. Rolling upgrades allow for a subset
     8    of applications to be updated at a time, with a waiting period between to
     9    reduce downtime.
    10  ---
    11  
    12  # Rolling Upgrades
    13  
    14  In order to update a service while reducing downtime, Nomad provides a built-in
    15  mechanism for rolling upgrades. Jobs specify their "update strategy" using the
    16  `update` block in the job specification as shown here:
    17  
    18  ```hcl
    19  job "docs" {
    20    update {
    21      stagger      = "30s"
    22      max_parallel = 3
    23    }
    24  
    25    group "example" {
    26      task "server" {
    27        # ...
    28      }
    29    }
    30  }
    31  ```
    32  
    33  In this example, Nomad will only update 3 task groups at a time (`max_parallel =
    34  3`) and will wait 30 seconds (`stagger = "30s"`) before moving on to the next
    35  set of task groups.
    36  
    37  ## Planning Changes
    38  
    39  Suppose we make a change to a file to upgrade the version of a Docker container
    40  that is configured with the same rolling update strategy from above.
    41  
    42  ```diff
    43  @@ -2,6 +2,8 @@ job "docs" {
    44     group "example" {
    45       task "server" {
    46         driver = "docker"
    47  
    48         config {
    49  -        image = "nginx:1.10"
    50  +        image = "nginx:1.11"
    51  ```
    52  
    53  The [`nomad plan` command](/docs/commands/plan.html) allows
    54  us to visualize the series of steps the scheduler would perform. We can analyze
    55  this output to confirm it is correct:
    56  
    57  ```shell
    58  $ nomad plan docs.nomad
    59  ```
    60  
    61  Here is some sample output:
    62  
    63  ```text
    64  +/- Job: "my-web"
    65  +/- Task Group: "web" (3 create/destroy update)
    66    +/- Task: "web" (forces create/destroy update)
    67      +/- Config {
    68        +/- image: "nginx:1.10" => "nginx:1.11"
    69      }
    70  
    71  Scheduler dry-run:
    72  - All tasks successfully allocated.
    73  - Rolling update, next evaluation will be in 30s.
    74  
    75  Job Modify Index: 7
    76  To submit the job with version verification run:
    77  
    78  nomad run -check-index 7 my-web.nomad
    79  
    80  When running the job with the check-index flag, the job will only be run if the
    81  server side version matches the job modify index returned. If the index has
    82  changed, another user has modified the job and the plan's results are
    83  potentially invalid.
    84  ```
    85  
    86  Here we can see that Nomad will destroy the 3 existing task groups and create 3
    87  replacements but it will occur with a rolling update with a stagger of `30s`.
    88  
    89  For more details on the `update` block, see the
    90  [job specification documentation](/docs/job-specification/update.html).