First, the deployment of blue-green (Blue / Green Deployment)
over the past 10 years, many companies are using blue-green deployment (release) to achieve hot deployment, this deployment is safe, and reliable. Blue, green and deployment, while not "Sliver Bullet", but really very practical.
The deployment of blue-green is the most common way to deploy 0 downtime, is a predictable manner publishing application of technology aimed at reducing the time to stop publishing process services. Blue-green on the deployment of very simple principle, that is, to solve the problem through redundancy. Production typically requires two sets of configuration (configuration cyan), is arranged a set of active production environment (green configuration), a set of configuration is inactive (cyan configuration). When users access will only allow users to access the active server cluster. In the production application environment, green environment (active) run the current, which is the old version of the application version1. When you want to upgrade to version2, operate in a blue environment (inactive), the new version of the application is deployed, and tested. If the test is no problem, we can put a load balancer / reverse proxy / route points to a blue environment. Then we need to monitor new version of the application, that is, whether there is a failure and abnormal version2. If you run well, you can delete version1 use of resources. If you run a problem, you can quickly roll back a load balancer to point to the green environment.
Deployment of blue-green advantage:
the benefits of this approach you can always feel comfortable in the environment to deploy inactive, if an error does not affect the production of services, the question arises if switching is also possible to do in a very short period of time a switch is complete rollback. And while only one online version. Blue, green and deployment without downtime and less risk.
(1) deployment version of the application 1 (the beginning of the state), all traffic external requests have hit on this version.
(2) application deployed version 2, version 2 and version 1 of the code different (new features, Bug fix, etc.).
(3) the traffic is switched from version 1 to version 2.
(4) such as version 2 tests are normal, delete the version resources (such as the example) 1 is being used, with the official version from 2.
Not difficult to find from the process, in the course of the deployment, the application is always online. In addition, the new version of the process line, and did not modify any of the content of the old version, during deployment, the old version of the state are not affected. This risk is very small, and, as long as the old version of the resource is not removed, in theory, you can roll back to the old version at any time.
Blue-green deployment weakness:
the use of blue-green deploy some details to note include:
1, when switching to the blue environment, the need to properly deal with unfinished business and new business. If you can not handle the back-end database, it is a more troublesome problem.
2, there may be cases need to deal with "micro-service architecture application" and "traditional application architecture" will appear, if poor coordination in both the blue-green deployment, there are likely to cause service stop;
3, the database needs to be considered in advance and application deployment synchronization migration / rollback.
4, blue-green deployment requires infrastructure support.
5, the implementation of blue-green deployed in non-segregated infrastructure (VM, Docker, etc.), the blue and green environment environmental risk of being destroyed.
6. In addition, the poor in this way places that generate additional redundancy maintenance, cost configuration, and cost of the server itself is running.
Blue-green deployment applicable scenarios:
1, does not stop the old version, additional to engage a new version, such as after tests found the new version OK, delete the old version.
2, blue-green release is issued a strategy for upgrading and updating, the smallest dimension of the deployment of the vessel, while the smallest dimension of the application is released.
3, blue-green incremental upgrade release for a relatively good support, but the data-sheet structure involving irreversible changes, and so the upgrade is not entirely appropriate to achieve the release with blue, green, need to combine some business logic, and data migration and rollback strategy can fully meet the demand.
Second, the rolling release (rolling update)
rolling release, usually take one or more servers out of service, perform the update, and re-put it into use. Again and again, until all instances in the cluster are updated with the new version. This deployment with respect to deployment of blue-green, more resource conservation - it does not need to run two clusters, twice the number of instances. We can partially deployed, for example, a time out 20% of the cluster upgrade.
This embodiment has many disadvantages, such as:
(1) without a determination OK environment. Use blue-green deployment, we can clearly know the old version is OK, but use a rolling release, we can not determine.
(2) modify the existing environment.
(3) If you need to roll back, very difficult. For example, in a first release, we need to update the 100 instances, updated every 10 instances, each deployment requires 5 minutes. When rolling release to the 80th example, we found a problem and needs to be rolled back. In this case, a bad temper program ape is likely to want to lift the table, because the rollback is a painful and lengthy process.
(4) Sometimes, we may also dynamic stretching the system during deployment if the system automatically expansion / contraction capacity, and in the end we need to determine which node is which code to use. Although there are some automated tool operation and maintenance, but still nerve-wracking.
Rolling release is not to say bad, rolling release also has its very appropriate scene.
