-
Notifications
You must be signed in to change notification settings - Fork 218
/
Copy pathblue-green.html.md.erb
121 lines (80 loc) · 5.38 KB
/
blue-green.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
---
title: Using blue-green deployment to reduce downtime
owner: CF for VMs Networking
---
Blue-green deployment is a technique that helps you reduce app downtime and risk by running
two identical production environments: "Blue" and "Green."
At any time, only one of the environments is live, with the live environment
serving all production traffic.
For the example discussed here, Blue is live and Green is idle.
As you prepare a new version of your software, deployment and the final stage of
testing takes place in the environment that is not live: in this example, Green.
After deploy and fully tested the software in Green, you switch the
router so that all incoming requests now go to Green instead of Blue.
Green is now live, and Blue is idle.
This technique can eliminate downtime due to app deployment.
In addition, blue-green deployment reduces risk: if something unexpected happens
with your new version on Green, you can immediately roll back to the last
version by switching back to Blue.
You can adjust the route mapping pattern to display a static maintenance page during a maintenance window for time-consuming tasks such as migrating a database. In this scenario, the router switches all incoming requests from Blue to Maintenance to Green.
<p class="note important">
If your app uses a relational database, blue-green deployment can lead to discrepancies between your green and glue databases during an update. To maximize data integrity, configure a single database for backward and forward compatibility.</p>
## <a id='blue-green-deployment'></a>Blue-green deployment with Cloud Foundry example
For this example, consider a simple app: "demo-time."
This app is a webpage that displays the words "Blue time" and the date/time on
the server.
### <a id='push-an-app'></a>Step 1: Push an app
Use the Cloud Foundry Command Line Interface (cf CLI) to push the app.
Name the app "Blue" with the subdomain "demo-time."
<pre class="terminal">
$ cf create-route example.com --hostname demo-time
$ cf push Blue
$ cf map-route Blue example.com --hostname demo-time
</pre>
As shown in the graphic:
* Blue is now running on Cloud Foundry.
* The Cloud Foundry Router sends all traffic for `demo-time.example.com` traffic to Blue.
![cf CLI pushing an app.](./images/../../images/blue-green/blue.png)
### <a id='update-and-push'></a>Step 2: Update app and push
Now make a change to the app.
1. Replace the word "Blue" on the webpage with "Green," then rebuild the source file for the app.
1. Run `cf push` again, but use the name "Green" for the app and provide a different subdomain to create a temporary route:
<pre class="terminal">
$ cf create-route example.com --hostname demo-time-temp
$ cf push Green
$ cf map-route Green example.com --hostname demo-time-temp
</pre>
After this push:
* Two instances of the app are now running on Cloud Foundry: the original Blue and the updated Green.
* The Cloud Foundry Router continues sending all traffic for `demo-time.example.com` to Blue.
The router now also sends any traffic for `demo-time-temp.example.com` to Green.
![The CF Router directs traffic to both Blue and Green sides.](../images/blue-green/blue-green.png)
### <a id='map-green'></a>Step 3: Map original route to Green
Now that both apps are up and running, switch the router so all incoming
requests go to both the Green app and the Blue app.
Use the [cf map-route](http://cli.cloudfoundry.org/en-US/cf/map-route.html) command to map the original URL route (`demo-time.example.com`) to the Green app.
<pre class="terminal">
$ cf map-route Green example.com -n demo-time
Binding demo-time.example.com to Green... OK
</pre>
After the `cf map-route` command :
* The Cloud Foundry Router continues sending traffic for `demo-time-temp.example.com` to Green.
* Within a few seconds, the Cloud Foundry Router begins load balancing traffic for `demo-time.example.com` between Blue and Green.
![CF Router load balances traffic between the Blue and Green sides.](./images/../../images/blue-green/map.png)
### <a id='unmap-blue'></a>Step 4: Unmap route to Blue
After you verify that Green is running as expected, stop routing requests to Blue
using the [cf unmap-route](http://cli.cloudfoundry.org/en-US/cf/unmap-route.html) command:
<pre class="terminal">
$ cf unmap-route Blue example.com -n demo-time
Unbinding demo-time.example.com from blue... OK
</pre>
After the `cf unmap-route` command:
* The Cloud Foundry Router stops sending traffic to Blue.
Now all traffic for `demo-time.example.com` is sent to Green.
![CF Router now directs all traffic to the Green side.](./images/../../images/blue-green/unmap.png)
### <a id='remove-temp-route'></a>Step 5: Remove temporary route to Green
You can now use `cf unmap-route` to remove the route `demo-time-temp.example.com` from Green. You can delete the route using `cf delete-route` or reserved it for later use. You can also decommission Blue, or keep it in case you need to roll back your changes.
![After all traffic is routed to Green, the Blue side can be removed or replaced.](./images/../../images/blue-green/green.png)
## <a id='implementations'></a>Implementation
Cloud Foundry community members have written a plug-in to automate blue-green deployment:
* [BlueGreenDeploy](https://github.com/bluemixgaragelondon/cf-blue-green-deploy): cf-blue-green-deploy is a plug-in, written in Go, for the Cloud Foundry Command Line Interface (cf CLI) that automates a few steps involved in zero-downtime deployments.