github.com/ncodes/nomad@v0.5.7-0.20170403112158-97adf4a74fb3/website/source/docs/operating-a-job/update-strategies/blue-green-and-canary-deployments.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Blue/Green & Canary Deployments - Operating a Job"
     4  sidebar_current: "docs-operating-a-job-updating-blue-green-deployments"
     5  description: |-
     6    Nomad supports blue/green and canary deployments through the declarative job
     7    file syntax. By specifying multiple task groups, Nomad allows for easy
     8    configuration and rollout of blue/green and canary deployments.
     9  ---
    10  
    11  # Blue/Green & Canary Deployments
    12  
    13  Sometimes [rolling
    14  upgrades](/docs/operating-a-job/update-strategies/rolling-upgrades.html) do not
    15  offer the required flexibility for updating an application in production. Often
    16  organizations prefer to put a "canary" build into production or utilize a
    17  technique known as a "blue/green" deployment to ensure a safe application
    18  rollout to production while minimizing downtime.
    19  
    20  Blue/Green deployments have several other names including Red/Black or A/B, but
    21  the concept is generally the same. In a blue/green deployment, there are two
    22  application versions. Only one application version is active at a time, except
    23  during the transition phase from one version to the next. The term "active"
    24  tends to mean "receiving traffic" or "in service".
    25  
    26  Imagine a hypothetical API server which has ten instances deployed to production
    27  at version 1.3, and we want to safely upgrade to version 1.4. After the new
    28  version has been approved to production, we may want to do a small rollout. In
    29  the event of failure, we can quickly rollback to 1.3.
    30  
    31  To start, version 1.3 is considered the active set and version 1.4 is the
    32  desired set. Here is a sample job file which models the transition from version
    33  1.3 to version 1.4 using a blue/green deployment.
    34  
    35  ```hcl
    36  job "docs" {
    37    datacenters = ["dc1"]
    38  
    39    group "api-green" {
    40      count = 10
    41  
    42      task "api-server" {
    43        driver = "docker"
    44  
    45        config {
    46          image = "api-server:1.3"
    47        }
    48      }
    49    }
    50  
    51    group "api-blue" {
    52      count = 0
    53  
    54      task "api-server" {
    55        driver = "docker"
    56  
    57        config {
    58          image = "api-server:1.4"
    59        }
    60      }
    61    }
    62  }
    63  ```
    64  
    65  It is clear that the active group is "api-green" since it has a non-zero count.
    66  To transition to v1.4 (api-blue), we increase the count of api-blue to match
    67  that of api-green.
    68  
    69  ```diff
    70  @@ -2,6 +2,8 @@ job "docs" {
    71   group "api-blue" {
    72  -  count = 0
    73  +  count = 10
    74  
    75     task "api-server" {
    76       driver = "docker"
    77  ```
    78  
    79  Next we plan and run these changes:
    80  
    81  ```shell
    82  $ nomad plan docs.nomad
    83  ```
    84  
    85  Assuming the plan output looks okay, we are ready to run these changes.
    86  
    87  ```shell
    88  $ nomad run docs.nomad
    89  ```
    90  
    91  Our deployment is not yet finished. We are currently running at double capacity,
    92  so approximately half of our traffic is going to the blue and half is going to
    93  green. Usually we inspect our monitoring and reporting system. If we are
    94  experiencing errors, we reduce the count of "api-blue" back to 0. If we are
    95  running successfully, we change the count of "api-green" to 0.
    96  
    97  ```diff
    98  @@ -2,6 +2,8 @@ job "docs" {
    99   group "api-green" {
   100  -  count = 10
   101  +  count = 0
   102  
   103     task "api-server" {
   104       driver = "docker"
   105  ```
   106  
   107  The next time we want to do a deployment, the "green" group becomes our
   108  transition group, since the "blue" group is currently active.
   109  
   110  ## Canary Deployments
   111  
   112  A canary deployment is a special type of blue/green deployment in which a subset
   113  of nodes continues to run in production for an extended period of time.
   114  Sometimes this is done for logging/analytics or as an extended blue/green
   115  deployment. Whatever the reason, Nomad supports canary deployments. Using the
   116  same strategy as defined above, simply keep the "blue" at a lower number, for
   117  example:
   118  
   119  ```hcl
   120  job "docs" {
   121    datacenters = ["dc1"]
   122  
   123    group "api" {
   124      count = 10
   125  
   126      task "api-server" {
   127        driver = "docker"
   128  
   129        config {
   130          image = "api-server:1.3"
   131        }
   132      }
   133    }
   134  
   135    group "api-canary" {
   136      count = 1
   137  
   138      task "api-server" {
   139        driver = "docker"
   140  
   141        config {
   142          image = "api-server:1.4"
   143        }
   144      }
   145    }
   146  }
   147  ```
   148  
   149  Here you can see there is exactly one canary version of our application (v1.4)
   150  and ten regular versions. Typically canary versions are also tagged
   151  appropriately in the [service discovery](/docs/service-discovery/index.html)
   152  layer to prevent unnecessary routing.