Blue-green release, grayscale release (canary release) and rolling release
The biggest challenge facing application upgrades is to switch between old and new businesses, bringing the software from the final stage of testing to the production environment, while ensuring that the system provides uninterrupted services.
For a long time, business upgrades have gradually formed several release strategies: blue-green release, gray release, and rolling release. The purpose is to avoid traffic loss or service unavailability problems caused by release as much as possible.
1. Blue-green release
1.1 Implementation principle
1) The project is logically divided into group AB. In the project system, group A is first removed from the load balance and the new version is deployed. Group B still continues to provide services.
2) When the upgrade of group A is completed, the load balancer reconnects to group A, then removes group B from the load list, and deploys the new version. Group A provides services again.
3) Finally, the upgrade of group B is completed, and the load balancer reconnects to group B. At this time, the version of group AB has been upgraded and all services are provided to the outside world.
1.2 Features
- If something goes wrong, the scope of impact will be larger;
- Simple release strategy;
- The user has no perception, and the transition is smooth;
- Fast upgrade/rollback speed.
1.3 Disadvantages
- It is necessary to prepare servers that use more than twice the resources of normal business to prevent a single group from being unable to carry business bursts during the upgrade;
- A certain amount of resource cost was wasted in a short time;
- There is no change to the infrastructure, which increases the stability of the upgrade.
Blue-green release was relatively expensive in the early physical server era, and the cost was greatly reduced due to the popularity of cloud computing.
2. Grayscale release (canary release)
2.1 Implementation principle
Grayscale release only upgrades part of the service, that is, some users continue to use the old version, and some users start to use the new version. If users have no opinion on the new version, then gradually expand the scope and migrate all users to the new version.
2.2 Features
- To ensure the stability of the overall system, problems can be found and adjusted at the initial gray level, and the scope of influence is controllable;
- The new function gradually evaluates the performance, stability and health status. If the problem occurs, the scope of the impact is small, and the relative user experience is also small;
- The user has no perception and a smooth transition.
2.3 Disadvantages
High automation requirements
2.4 Deployment process
- Remove the grayscale server from LB and join LB after the upgrade is successful;
- A small amount of user traffic to the new version;
- If the gray server test is successful, upgrade the remaining servers.
Gray release is the process of gradually switching from one version to another by switching the routing weights between online coexisting versions.
3. Rolling release
3.1 Implementation principle
Rolling release refers to only upgrading one or more services at a time, adding to the production environment after the upgrade is completed, and performing this process continuously until all the old versions in the cluster are upgraded to the new version.
- Red: the instance being updated
- Blue: the instance that has been updated and joined the cluster
- Green: running instance
3.2 Features
- The user has no perception, and the transition is smooth;
- save resources.
3.3 Disadvantages
- The deployment time is slow, depending on the update time of each stage;
- The release strategy is more complicated;
- Unable to determine the OK environment, it is not easy to roll back.
3.4 Deployment process
- Upgrade 1 copy first, mainly for deployment verification;
- Each time a copy is upgraded, it is automatically removed from the LB, and automatically added to the cluster after the upgrade is successful;
- An automatic update strategy is required in advance, divided into several times, and the quantity/percentage can be configured each time;
- Rollback is the reverse process of release. First remove the new version from LB, and then upgrade the old version. This process generally takes a long time; the automation requirements are high.
4. Summary
In summary, all three methods can achieve a smooth upgrade. During the upgrade process, the service still maintains the continuity of the service, and the upgrade is unaware of the outside world.
Which deployment method is most suitable for production? It depends on which method best suits your business and technical needs.
- If the O&M automation capacity reserve is insufficient, the simpler the better, the blue-green release is recommended;
- If the business relies heavily on users, it is recommended to publish in grayscale;
- If it is the K8S platform, rolling update is a ready-made solution, it is recommended to use it directly.
Blue-green release : The two environments are upgraded alternately, and the old version is kept for a certain period of time to facilitate rollback.
Grayscale release : Upgrade the old version according to the proportion, for example, 80% of the user visits are the old version, and 20% of the user visits are the new version.
Rolling release : stop the old version instances in batches and start the new version instances.