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.