Shulou(Shulou.com)05/31 Report--

What this article shares with you is about the concepts and differences of blue and green deployment, red and black deployment, AB testing, grayscale release, canary release and rolling release in microservices. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

In the discussion of microservices, DevOps, Cloud-native, system deployment, etc., the concepts of blue-green deployment, Amax B testing, grayscale release, rolling release, red-and-black deployment are often mentioned. What's the difference between them? By searching for relevant information, make a simple discrimination, as follows:

I. Blue and Green deployment (Blue/Green Deployment)

In the past 10 years, many companies have been using blue-green deployment (release) to achieve hot deployment, which is secure and reliable. Although the blue-green deployment is not a "Sliver Bullet", it is indeed very practical.

Blue-green deployment is the most common way of deploying 0 downtime, which is a technology for publishing applications in a predictable manner, designed to reduce the time it takes for services to stop during the release process. Blue-green deployment is simple in principle, which is to solve the problem through redundancy. Usually, the production environment requires two sets of configurations (blue-green configuration), one is the active production environment configuration (green configuration), and the other is the inactive configuration (blue-green configuration). When a user accesses, only the user is allowed to access the server cluster of active. Run the application in the current production environment in the green environment (active), that is, the old version of the application version1. When you want to upgrade to version2, do it in the blue environment (inactive), that is, deploy the new version of the application and test it. If the test is fine, you can point the load balancer / reverse proxy / route to the blue environment. You then need to monitor the new version of the application, that is, version2, for faults and anomalies. If it works well, you can delete the resources used by version1. If there is a problem with the operation, you can point to the load balancer to quickly roll back to the green environment.

Advantages of blue-green deployment:

The advantage of this method is that you can always rest assured to deploy the inactive environment. If the error does not affect the service of the production environment, if there is a problem after the switch, you can also switch it again in a very short time to complete the rollback. And there is only one version online at the same time. Blue and green deployments require no downtime and are less risky.

(1) deploy the application of version 1 (the initial state), and all the traffic of external requests will be sent to this version.

(2) deploy the application of version 2, the code of version 2 is different from version 1 (new features, Bug fixes, etc.).

(3) switch traffic from version 1 to version 2.

(4) if the version 2 test is normal, delete the resources (such as instances) that version 1 is using, and officially use version 2 from now on.

From the process, it is not difficult to find that the application is always online during deployment. Moreover, during the launch of the new version, nothing in the old version was modified, and the status of the old version was not affected during deployment. The risk is small, and, in theory, you can roll back to the old version at any time as long as the old version of the resource is not deleted.

Weaknesses of blue and green deployment:

Some details to pay attention to when using a blue-green deployment include:

1. When switching to a blue environment, unfinished business and new business need to be handled properly. If the database backend cannot handle it, it will be a troublesome problem.

2. There may be situations where both "micro-service architecture applications" and "traditional architecture applications" need to be dealt with at the same time. If the two are not well coordinated in the blue-green deployment, the service may stop.

3. The problem of synchronous migration / rollback of database and application deployment needs to be considered in advance.

4. Blue and green deployment requires infrastructure support.

5. Perform blue-green deployment on non-isolated infrastructure (VM, Docker, etc.). Blue and green environments are at risk of being destroyed.

6. In addition, the disadvantage of this approach lies in the additional maintenance caused by redundancy, the cost of configuration, and the cost of running the server itself.

Scenarios applicable to blue-green deployment:

1. Do not stop the old version, create a new version, and delete the old version when the test finds a new version of OK.

2. Blue and green publishing is a publishing strategy for upgrades and updates. The minimum dimension of deployment is the container, while the minimum dimension of the release is the application.

3. Blue and green releases have good support for incremental upgrades, but for irreversible upgrades involving changes in data table structure, it is not entirely appropriate to use blue and green releases. It needs to combine some business logic and data migration and rollback strategies to fully meet the requirements.

A _ Testing B test (A _ amp B test)

The Amob B test and the blue-green deployment are two different things. A big B test is a method used to test the functional performance of an application, such as usability, popularity, visibility, and so on. The purpose of the blue-green deployment is to securely and steadily release the new version of the application and roll back if necessary.

The difference between the Ajump B test and the blue-green deployment is that the purpose of the Amax B test is to obtain a representative experimental conclusion through scientific experimental design, sample representation, traffic segmentation and small flow test, and is convinced that the conclusion is credible when it is extended to all traffic.

The Ahand B test and blue-green deployment can be used at the same time.

Grayscale release / Canary release

Grayscale publishing refers to a release way that can make a smooth transition between black and white. Grayscale release is a type of incremental release, grayscale release is when the original version is available, while deploying a new version of the application as a "canary" (canaries are extremely sensitive to gas, mine workers carry canaries. In order to find the danger in time), test the performance and performance of the new version, in order to ensure the stability of the overall system, find and adjust the problem as soon as possible.

Grayscale publishing / canary publishing consists of the following steps:

1. Be ready to deploy artifacts at all stages, including: build artifacts, test scripts, configuration files and deployment manifest files.

2. Remove the Canary server from the load balancer list.

3. Upgrade the "Canary" application (drain the original traffic and deploy it).

4. Automatic testing of the application.

5. Add the Canary server back to the load balance list (connectivity and health check).

6. If Canary's online usage test is successful, upgrade the remaining servers. (otherwise roll back)

The grayscale release can ensure the stability of the whole system, and the problem can be found and adjusted at the initial gray level to ensure its influence.

Applicable scenarios for grayscale publishing / canary deployment:

1. Do not stop the old version, but create a new version, and different versions of the application will coexist.

2. In grayscale publishing, routing weights are often set by users. For example, 90% of users maintain the old version, and 10% of users try the new version.

3. It is often used in conjunction with the Aamp B test to choose a variety of options for testing. AB test is a grayscale publishing method that allows some users to continue to use An and some users to start using B. if users have no objection to B, then gradually expand the scope and migrate all users to B.

Anecdotes:

Canary deployment (and, in the same way, canary testing), the origin of "canary": in the 17th century, British miners found that canaries were very sensitive to the gas gas. Even if there is a tiny amount of gas in the air, the canary will stop singing, and when the gas content exceeds a certain limit, although dull humans are unaware of it, the canary has long been poisoned. At that time, under relatively poor mining equipment, workers would take a canary as a "gas detection indicator" every time they went down to the well in order to evacuate urgently in dangerous situations.

Scroll publish (rolling update)

Scrolling publishing usually takes one or more servers out of service, performs updates, and puts them back into use. Go round and round until all instances in the cluster are updated to the new version. This deployment is more resource-efficient than blue-green deployment-it doesn't need to run two clusters and twice the number of instances. We can deploy partially, for example, only 20% of the cluster is taken out at a time for upgrade.

This approach also has many disadvantages, such as:

(1) there is no environment that determines OK. With blue and green deployment, we can clearly know that the old version is OK, while with rolling release, we can't be sure.

(2) the existing environment is modified.

(3) if you need to roll back, it is very difficult. For example, in a release, we need to update 100 instances, 10 instances at a time, and each deployment takes 5 minutes. When you scroll to the 80th instance, a problem is found and needs to be rolled back. At this point, a bad-tempered programmer is likely to want to lift the table, because rollback is a painful and long process.

(4) sometimes, we may dynamically scale the system. If the system is automatically expanded / reduced during deployment, we still need to determine which node is using which code. Although there are some automated operation and maintenance tools, it is still frightening.

This is not to say that scrolling publishing is not good, scrolling publishing also has its very appropriate scenarios.

Red and Black deployment (Red-Black Deployment)

This is the deployment method adopted by Netflix, and the main infrastructure of Netflix is on AWS, so it takes advantage of the characteristics of AWS to create a new server through AutoScaling Group with LaunchConfiguration containing the new version of the application when deploying a new version. If the test fails, you can kill the newly generated server and Autoscaling Group directly after finding the cause of the problem. If the test passes, point the ELB to the new server cluster, and then destroy the old server cluster and AutoScaling Group.

The advantage of red-black deployment is that services are always online, while immutable deployment is adopted, unlike blue-green deployment, redundant services are always online.

These are the concepts and differences of blue-green deployment, red-black deployment, AB testing, grayscale release, canary release and rolling release in microservices. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.